Вернемся к более детальному разбору стратегии надежности, которую я публиковал ранее.
Ранее подробно описал мысли про надежность релизов.
Сегодня поговорим о кейсах, когда мы знали (или могли знать), что шлёпнемся так-то, но почему-то не сделали достаточно, чтобы этого избежать.
Инциденты неизбежно случаются. Но нет ничего хуже, чем наступить на те же грабли. Поэтому каждый инцидент проходит процедуру разбора и выявления экшн-айтемов. Но их еще надо сделать. И чем раньше - тем меньше вероятность рецидива. Поэтому мы постепенно сокращаем SLA на выполнение экшн-айтемов. Тут важно не пережестить - не нужно вешать SLA на всевозможные nice-to-have идеи по мотивам. Только на задачи, "в лоб" предотвращающие повторное падение, или драматически снижающие импакт от оного.
А еще иногда бывают первые звоночки перед инцидентом. Точечная жалоба пользователя, попавшего в эксперимент. Багрепорт уровня блокер из релиза, который только начал раскатку в сторах. Обращение коллеги, который открывает приложение каждые 10 минут. Если на них не обращать внимание, можно упустить ситуацию. Поэтому соблюдение SLA на обработку обращений тоже в ряде случаев помогает заметить инцидент на ранней стадии и купировать эффект.
Очень важно регулярно проводить разного рода учения. Например, по имитации потери одного из дата-центров. Это поможет в условиях сохранения контроля найти те проблемы, которые нас похоронят в случае реальной потери ДЦ. И речь не только о запасе прочности - само изменение топологии может вызвать "бум" - от автофейловера БД до metastable failure.
У вас бывало такое, что вроде бы железа под сервисом было достаточно, а в пятницу вечером оно почему-то начало стремительно заканчиваться? Ну было же. А что, если бы была некая автоматика, которая это заметит быстрее вас и сама докинет ресурсов? А когда ресурсы простаивают, сама перекинет их, например, на аналитические вычисления. Круто же? Надо делать.
