Инцидент это незапланированное ухудшение сервиса для пользователей, которое требует срочной реакции. Цель реагирования не найти виноватого и даже не найти первопричину, а как можно быстрее вернуть пользователям работающий сервис. Разбор будет потом.
Уровни критичности
Шкалу задают заранее, чтобы в стрессе не спорить. Пример:
- SEV1: недоступна ключевая функция для многих пользователей (оплата, вход), потеря данных, утечка. Реагируют все нужные люди немедленно, днём и ночью.
- SEV2: серьёзная деградация части пользователей или функции, есть обходной путь.
- SEV3: небольшое влияние, можно чинить в рабочее время.
Уровень можно поднимать и понижать по ходу. Лучше объявить инцидент и потом закрыть его как ложный, чем молча чинить час.
Роли
- Incident Commander (IC): координирует, принимает решения, распределяет задачи. Сам руками не чинит.
- Ответственный за коммуникацию: обновляет статус для пользователей, поддержки и руководства через равные промежутки (например, каждые 30 минут), чтобы инженеров не дёргали вопросами.
- Эксперты (ops): разбираются и чинят.
- Секретарь (scribe): ведёт хронологию: что увидели, что сделали, когда.
В маленькой команде роли совмещают, но IC и тот, кто чинит, лучше разные люди.
Порядок действий
- Подтвердить алерт (acknowledge), чтобы не будить следующего по эскалации.
- Оценить влияние: что видят пользователи, сколько их, с какого времени. Дашборд SLO и RED.
- Объявить инцидент и уровень, открыть канал, назначить IC.
- Стабилизировать (mitigate): откатить последний релиз, переключить трафик, выключить флаг, добавить мощности, включить деградацию. Действия обратимые и быстрые.
- Коммуникация: статус-страница и внутренние каналы.
- Убедиться, что метрики вернулись в норму.
- Закрыть инцидент и назначить постмортем.
Классический вопрос «что изменилось?»: релиз, конфиг, флаг, миграция, внешняя зависимость, рост трафика. Большая часть инцидентов вызвана изменениями, поэтому откат часто самый быстрый путь.
Метрики реагирования
- MTTD (mean time to detect): от начала проблемы до обнаружения.
- MTTA (mean time to acknowledge): от алерта до реакции человека.
- MTTR (mean time to restore / recover): от начала до восстановления.
Средние по небольшому числу инцидентов шумные, поэтому смотрят тренды и конкретные разборы, а не гонятся за цифрой.
Дежурства (on-call)
- Ротация: основной и запасной дежурный, понятная эскалация.
- Передача смены: открытые проблемы, недавние релизы, особенности.
- Раннбук на каждый алерт: что проверить, как смягчить, кого звать.
- Нагрузка: ориентир из книги Google SRE не больше двух инцидентов за 12-часовую смену, иначе не остаётся времени на качественный разбор.
- Компенсация и отдых после тяжёлой ночи. Выгоревший дежурный опаснее сломанного сервиса.
- Дежурят те, кто пишет код сервиса: так у них есть мотивация делать его надёжным.
Постмортем без поиска виноватых
После значимого инцидента пишут разбор. Blameless значит: ищем, почему система позволила ошибке случиться и не поймала её, а не кто нажал кнопку. Человек, которого наказывают, в следующий раз промолчит, и организация ничего не узнает.
Структура:
- кратко: что случилось и влияние (сколько пользователей, сколько времени, деньги, бюджет ошибок);
- хронология с точным временем;
- причины и способствующие факторы (их почти всегда несколько: баг плюс отсутствие теста плюс алерт, который не сработал);
- обнаружение: как узнали, могли ли раньше;
- что сработало хорошо, что плохо, где повезло;
- действия: конкретные задачи с владельцем и сроком, а не «быть внимательнее».
«Пять почему» полезны, но тянут к одной линейной причине. В сложных системах причин несколько, и важно найти все звенья.
Постмортемы публикуют внутри компании и регулярно перечитывают: повторяющиеся причины подсказывают системные инвестиции.
Частые ошибки
- Искать первопричину, пока пользователи страдают, вместо отката.
- Все в одном звонке чинят, никто не координирует и не сообщает статус.
- Постмортем с выводом «виноват инженер, провести беседу».
- Действия без владельцев и сроков, которые никто не делает.
- Не объявлять инцидент, «чтобы не поднимать шум».
Что спросят на собесе
- Алерт в 3 ночи: ваши действия по шагам.
- Роли в инциденте и зачем IC.
- Что такое blameless-постмортем и что в нём должно быть.
- Расскажите о самом серьёзном инциденте в вашей практике.
- Как сделать дежурства устойчивыми для людей.