Сигналы и договорённости: как перестать просыпаться от «всего подряд»
Инцидент-менеджмент начинается с соглашений, а не со «списка алертов». Сначала формулируются пользовательские SLO: доступность/латентность/ошибки для ключевых сценариев (покупка, авторизация, платежи, загрузка контента). Эти SLO превращаются в сигналы: сервисные метрики (p95 latency, доля 5xx, error budget), бизнес-метрики (успешные оплаты, конверсия, скорость выдачи результатов) и инфраструктурные индикаторы (health-checks, очередь заданий, нагрузка). Алерты строятся на симптомах, а не на «внутренностях»: если p95 и доля ошибок в сценарии «оплата» рушатся — звонок; если CPU подскакивает, но пользователь не страдает — тикет на дневной слот. Любой алерт имеет три поля: условие, кому звонит (ротация), что делать (ссылка на ранбук). Ротации on-call простые и прозрачные: расписание, коридоры времени, вторые номера, дежурство не чаще 1 из N недель, «тихие смены» компенсируются. Эскалации работают по SEV: SEV-1 — массовое влияние, «красная» комната, команда L1+L2+владелец бизнеса; SEV-2 — серьёзная деградация с обходными путями; SEV-3 — локальные проблемы без внешнего шума. В каждом SEV прописаны каналы (чат/звонок), периодичность апдейтов, формат статуса (что знаем, что делаем, когда следующий апдейт), кто «говорит вовне» и кто держит стенографию. В аннотациях к алертам размещаются «шпаргалки»: ссылки на дашборды, метрики «здоровья», команды для снижения нагрузки, фичефлаги для деградации функционала. Алерты тестируются так же, как код: симуляции и «сухие учения» раз в квартал. Плохие сигналы удаляются без сожаления: шум — это долг, который ворует время и доверие. Мы не меряем «сколько алертов в минуту», мы меряем MTTD/MTTR и процент «полезных» срабатываний. Такой набор договорённостей радикально снижает бессонницу и превращает дежурство из «лотереи» в управляемый процесс.
War-room — это не чат с криками, а сцена с ролями и темпом. У инцидента есть Incident Commander (ведёт процесс и фиксирует решения), Tech Lead (разворачивает гипотезы и координирует инженеров), Communications (пишет статус-апдейты внутрь и вовне), Scribe (ведёт хронологию). Командир не чинит — он управляет временем и рисками: кто делает A/B/C, когда следующий апдейт, какая гипотеза закрыта, где нужен откат. Решения принимаются принципом «самый маленький безопасный шаг»: отключить фичу флагом, сузить трафик, перевести на пассивный регион, поднять лимиты, включить «грэйсфулы». Все «опасные» изменения проходят озвученный чек-лист (что меняем, какой сигнал увидим через X минут, как откатываем). Переписка в war-room структурируется: каждый апдейт в одном формате «время → что видим → что сделали → что дальше», длинные логи — в тредах. Наружу идет статус-страница с фиксированной частотой апдейтов (например, каждые 20–30 минут) и понятной шкалой влияния. Бизнес не дергает инженеров — он получает апдейты от Communications. Параллельно «включается» экономия ущерба: баннеры деградации, отключение неключевых виджетов, очередь заказов в «пауза и восстановление», упрощённые флоу оплаты/авторизации. Когда сигнал вернулся в норму, инцидент закрывается явно и назначается постмортем. Обязательно: инвентаризация «дыр» в алертах/дашбордах, отметка «что помогло найти правду», «что тянуло вниз», «каких данных не было», список улучшений с владельцами и сроками. War-room — это дисциплина и вежливость: одно слово «виноват» запрещено, виноватых нет; есть система, которую улучшаем. Чем предсказуемее сцена — тем короче MTTR и меньше нервов.
Постмортемы и учения превращают инциденты в инвестиции. Постмортем пишется для людей, не для «комиссий»: одна страница на русском/английском, понятные термины, чёткая хронология (время, сигнал, гипотеза, действие, эффект), карты метрик и скриншоты. Корневая причина разделяется на техническую и организационную («регрессия в модуле X», «у протокола эскалации не было владельца», «алерт молчал, потому что порог завышен»). Каждое улучшение имеет владельца, дату, PR/тикет, а главное — сигнал, как увидим эффект (например, новая метрика охватывается алертом; время на диагностику сокращается, потому что добавлен лог/трейс). «Герои» не возносятся, «тихая работа» ценится: за стандарты, за документацию, за автоматизацию. Раз в квартал команда проводит game-day: отключение AZ на препроде, деградация базы, истечение сертификата, сбой DNS; учения идут по сценарию, секундомером фиксируется время обнаружения/реакции, после — мини-постмортем и обновление ранбуков. Для устойчивости важна карта долгов: технический (нет идемпотентности, слабые таймауты/повторы, нет флагов переключения), операционный (нет 24×7 дежурства, устаревшие контакты, нет «тихих часов»), аналитический (нет графов зависимостей/трассировок, SLO не привязаны к бизнесу). Долги горят красным в «борде реальности» и гасятся по расписанию — иначе инциденты повторяются. Экономика инцидентов — это честные числа: стоимость минуты простоя × частота × сезонность; на них легко отбивается второй регион, резервная БД, дублирование DNS и 24×7 ротации. И главное — прозрачная память: база знаний с шаблонами постмортемов, индекс инцидентов, дашборд «что исправлено» и «что в работе». Так UOUO №2 превращает «пожарную часть» в культуру инженерной взрослости: меньше шума, быстрее восстановление, больше предсказуемости.