Инциденты — чек-лист самопроверки
Проверьте готовность до первого P1. Подробности — глава 1, итоги и FAQ.
Severity и регламент
- Есть письменная шкала severity (P1–P4 или аналог) с примерами.
- Известно, кто реагирует на P1 и как эскалировать за 15–30 минут.
- Severity согласована с ITSM и SLA.
- В аутсорсе в договоре прописано время реакции на P1.
- Команда отличает severity от приоритета тикета в backlog.
On-call и runbook
- On-call ротация в календаре; дежурный знает, что делать при звонке.
- Runbook для топ-5 алертов актуальны (ревью < 6 мес или после P1).
- Есть цепочка L1 → L2 → L3 и контакты вендоров.
- Политика отдыха после ночного P1 (не обязательные встречи наутро).
- Incident commander назначается по регламенту на P1/P2.
Восстановление сервиса
- Известен путь rollback (версия, команда, кто утверждает).
- Известен процесс hotfix в prod (тесты, CAB, согласование заказчика).
- Есть feature flags или mitigation для отключения сломанной части.
- Миграции БД учтены в плане отката (можно ли rollback).
- После стабилизации фиксируется время восстановления для MTTR.
Observability
- Централизованные логи с correlation / trace id.
- Алерты по SLO, не только по загрузке CPU.
- Дашборды для on-call (error rate, latency, RPS).
- Алерты не создают лавину тикетов без дедупа и порога.
- Distributed tracing для цепочек между сервисами (если микросервисы).
Postmortem и улучшения
- После P1/P2 проводится postmortem в течение ~5 рабочих дней.
- Postmortem blameless — фокус на системе, не на казни.
- Action items с владельцем и сроком попадают в backlog.
- PO приоритизирует items из postmortem.
- Postmortem публикуются в wiki для онбординга.
- Повторный P1 по той же причине — эскалация (архитектура, ADR).
Agile и поток работ
- Инциденты в Kanban — класс Expedite с правилом WIP (Kanban).
- В Scrum при P1 понятно, как пересматривается цель спринта.
- Дефекты после инцидента не теряются — связь тикет инцидент → баг.
Коммуникация
- Есть статус-страница или шаблон сообщения пользователям.
- Поддержка знает обходной путь при типовых P2.
- Один канал инцидента (чат/bridge), не десять личных чатов.
Вопросы для устной самопроверки
- Что у вас считается P1? Приведите пример.
- Кто сейчас on-call и как с ним связаться?
- Как откатить последний релиз API?
- Где лежит runbook по падению БД?
- Что такое MTTR и как вы его считаете?
- Когда последний postmortem и сколько action items закрыто?
- Чем mitigation отличается от hotfix?
- Нужен ли CAB для ночного hotfix в вашей организации?
- Где в логах искать trace id?
- Что делать, если алерт ложный уже третий раз за неделю?
Красные флаги
- "У нас нет P1, только срочно" от каждого менеджера.
- Дежурный никогда не делал rollback на stage.
- Postmortem пишут, action items годами в backlog.
- После аварии уволили дежурного без изменения процесса.
- Заказчик в аутсорсе узнаёт о P1 из Twitter пользователей.
Три и более флага — план готовности с тимлидом и DevOps.
Минимальный план за один спринт
- Описать P1–P3 с примерами в wiki.
- Написать 3 runbook на реальные алерты.
- Провести учебный rollback на stage.
- Шаблон postmortem в репозитории или wiki.
- Назначить ротацию on-call на квартал вперёд.