Инциденты: on-call, runbooks, postmortem
↑ Этап 7 · Observability и эксплуатация
Зачем это на собесе
Процесс реагирования на инциденты — показатель зрелости: on-call, runbook, коммуникации, blameless постмортем.
Что такое инцидент
Инцидент — внеплановое событие, снижающее качество сервиса или угрожающее ему (недоступность, деградация, потеря данных, нарушение безопасности). Цель реагирования: быстро восстановить сервис, минимизировать ущерб, извлечь уроки.
Уровни серьёзности (пример):
| Уровень | Описание | Реакция |
|---|---|---|
| SEV1 / P1 | полная недоступность ключевого сервиса, потеря данных, инцидент безопасности | немедленно, 24/7, оповещение руководства, статус-страница |
| SEV2 / P2 | существенная деградация, затронута значимая часть пользователей | срочно, в рабочее/дежурное время |
| SEV3 / P3 | ограниченное влияние, есть обход | в рабочее время |
| SEV4 | косметика, наблюдение | тикет |
Критерии: влияние на пользователей, бизнес-влияние, срок, наличие обхода.
Жизненный цикл
Обнаружение → Триаж → Реагирование (смягчение) → Восстановление → Постмортем → Улучшения- Обнаружение: алерты (по SLO/симптомам), синтетика, жалобы пользователей/поддержки; MTTD (время обнаружения).
- Триаж: подтвердить, оценить серьёзность и влияние, назначить ответственных, открыть канал (чат/звонок).
- Смягчение (mitigation) важнее поиска причины: откат релиза, отключение фичи (feature flag), перевод трафика, масштабирование, перезапуск, деградация функциональности. Сначала остановить кровотечение, потом искать причину.
- Диагностика: гипотезы по метрикам/логам/трейсам, последние изменения, зависимости.
- Восстановление и проверка: подтверждение метриками, мониторинг после исправления.
- Закрытие, постмортем, задачи на улучшение; MTTR (время восстановления).
Роли
| Роль | Задачи |
|---|---|
| Incident Commander (IC) | координирует, принимает решения, не занимается «руками»; удерживает фокус, эскалации, приоритеты |
| Operations / технический лидер | диагностика и исправление |
| Communications lead | внутренние и внешние коммуникации (статус-страница, поддержка, руководство) |
| Scribe | ведёт таймлайн событий и решений |
| Subject-matter experts | привлекаются по необходимости |
На малых командах роли совмещаются, но IC должен быть назначен явно.
On-call
Дежурство — график ответственных за реагирование на алерты.
- ротация (неделя/сутки), primary и secondary, «follow the sun» для распределённых команд; справедливая нагрузка, компенсация, отдых после тяжёлых смен;
- инструменты: PagerDuty, Opsgenie, Grafana OnCall, Alertmanager + Telegram, VictorOps; эскалационные политики (не ответил за N минут → следующий уровень);
- оповещения: только действительно срочные (page), остальное — тикеты; цель — минимум ночных страниц;
- передача смены (handoff): открытые инциденты, риски, плановые работы;
- требования: доступ к системам (VPN, kubectl, ssh, dashboards), актуальные runbook’и, подготовка и «shadowing» новичков, учения (game days);
- здоровье: метрики нагрузки (число страниц на дежурного, ночные срабатывания), борьба с усталостью и выгоранием; здоровый on-call — инженерная задача (автоматизация, исправление причин шума).
Runbooks
Пошаговые инструкции для конкретных алертов и сценариев.
Алерт: HighErrorRate (API)
Влияние: пользователи получают 5xx при записи на приём.
Проверить: 1) Дашборд «API RED» (ссылка); 2) Последние релизы (kubectl rollout history deploy/api); 3) Логи: {app="api"} |= "error"; 4) Состояние БД (ссылка), зависимости.
Смягчить: если ошибки начались после релиза → kubectl rollout undo deploy/api -n clinic; если БД перегружена → включить read-only режим флагом X; масштабировать api до 10 реплик.
Эскалация: backend-lead @name, DBA @name (если БД).
Проверка восстановления: error ratio < 1% 10 минут.Принципы: ссылка на runbook в каждом алерте; конкретные команды и ссылки, а не общие слова; владелец и дата актуальности; проверка в учениях; автоматизация повторяющихся действий («runbook → скрипт/кнопка»); общие сценарии: откат, перезапуск, масштабирование, переключение на реплику/DR, деградация, очистка диска, ротация сертификатов.
Коммуникации
- внутренние: выделенный канал инцидента (Slack/Telegram), регулярные апдейты (каждые 15–30 минут), статус «что известно / что делаем / следующая проверка»;
- внешние: статус-страница (Statuspage, Cachet, Upptime), поддержка, клиенты; честно, без технических деталей и обвинений; время следующего обновления;
- эскалация по серьёзности: руководство, юристы/безопасность (при утечках), регуляторы (сроки уведомления по GDPR — 72 часа);
- шаблоны сообщений; единая «правда» (таймлайн).
Blameless постмортем
Документ и обсуждение после значимого инцидента (SEV1/SEV2, новые классы проблем, «почти-инциденты»). Без поиска виноватых: люди действовали рационально с доступной информацией; ищем системные причины (процессы, инструменты, архитектура, мониторинг).
Структура:
- Резюме: что произошло, влияние (длительность, пользователи, деньги), серьёзность.
- Таймлайн (UTC): обнаружение, ключевые действия, решения, восстановление.
- Причины: корневая (root cause) и сопутствующие (contributing factors); методы: 5 почему, диаграмма Исикавы, анализ изменений, barrier analysis.
- Что сработало / что нет (обнаружение, коммуникации, инструменты).
- Метрики: MTTD, MTTA, MTTR, потраченный error budget.
- Action items: конкретные задачи с владельцем и сроком (предотвращение, обнаружение, смягчение, процесс), приоритет, трекинг до закрытия.
- Уроки и ссылки (алерты, дашборды, логи).
Принципы: проводить в течение 1–5 рабочих дней, публиковать внутри организации, не наказывать за честность, «счастливый случай» тоже разбирать, не ограничиваться «человеческая ошибка» (вопрос: почему система позволила ошибку?), проверять выполнение действий, вести реестр инцидентов и анализировать тренды.
Метрики инцидентов
| Метрика | Значение |
|---|---|
| MTTD | среднее время обнаружения |
| MTTA | время до подтверждения/начала работы |
| MTTR | время восстановления (Repair/Recovery/Respond — уточняйте) |
| MTBF | среднее время между отказами |
| Прочие показатели | число инцидентов по серьёзности, повторяемость, доля обнаруженных пользователями (а не мониторингом), потраченный error budget, число ночных страниц |
Улучшение надёжности
- автоматизация откатов и деплоев (canary, feature flags, автоматический rollback по метрикам);
- Chaos engineering и game days: тренировка реакции;
- улучшение мониторинга: алерты по SLO, трассировки, runbook’и;
- устранение единых точек отказа, запасы ёмкости, graceful degradation, таймауты/ретраи/circuit breaker;
- снижение «радиуса поражения» (изоляция, cell-based архитектура, постепенные релизы);
- управление изменениями: большинство инцидентов связано с последними изменениями → ревью, тесты, малые релизы;
- инциденты безопасности — отдельный процесс (IR): изоляция, сохранение улик, расследование, уведомления.
Вопросы с ответами
Что делать первым при инциденте: искать причину или восстанавливать сервис?
Сначала смягчить воздействие (откат, отключение фичи, переключение трафика, масштабирование), затем расследовать причину; быстрое восстановление важнее понимания.
Что такое blameless постмортем?
Разбор инцидента без поиска виноватых: выясняются системные причины и улучшения (процессы, мониторинг, автоматизация) с конкретными задачами, владельцами и сроками.
Какие роли нужны при крупном инциденте?
Incident Commander (координация и решения), технический исполнитель, ответственный за коммуникации и scribe (ведение таймлайна); эксперты подключаются по необходимости.