Реализация Incident Management процесса для веб-приложения
Incident Management — это не инструмент, это процесс. Инструменты (PagerDuty, OpsGenie, Jira) без процесса — просто источники шума. Процесс без инструментов — хаос в мессенджерах. Вместе они дают предсказуемое поведение команды в момент сбоя.
Определение инцидента и приоритетов
Не каждая ошибка — инцидент. Инцидент — это незапланированное нарушение качества сервиса, влияющее на пользователей.
| Severity | Критерии | RTO | Пример |
|---|---|---|---|
| SEV1 | Сервис полностью недоступен | 30 мин | Сайт отдаёт 503 для всех |
| SEV2 | Критическая функция деградирует | 2 часа | Платёжная система не работает |
| SEV3 | Некритическая функция нарушена | 8 часов | Медленная загрузка отчётов |
| SEV4 | Незначительная проблема | 24+ часов | Опечатка на странице |
Роли в инциденте
Incident Commander (IC). Координирует ответ, принимает решения, не копается в коде. Один на инцидент.
Technical Lead. Руководит расследованием и устранением. Может быть несколько при широком инциденте.
Communications Lead. Обновляет Status Page, отвечает на вопросы бизнеса, пишет обновления в Slack-канал инцидента.
Разделение ролей критично: один человек не может одновременно дебажить и отвечать на вопросы CEO.
Жизненный цикл инцидента
Detection → Triage → Escalation → Response → Resolution → Post-mortem
Detection: Alertmanager / PagerDuty обнаруживает аномалию и нотифицирует дежурного.
Triage (5-10 минут): Дежурный оценивает severity, создаёт инцидент-тикет, открывает Slack-канал #incident-YYYY-MM-DD-brief-description.
Escalation: Для SEV1-2 — немедленное привлечение IC и дополнительных инженеров. On-call rotation определяет, кто дежурит.
Response: Работа ведётся в dedicated Slack-канале. Обновления — каждые 20-30 минут. Все значимые действия логируются в тред инцидента (кто, что, когда).
Resolution: Сервис восстановлен, пользователи уведомлены, инцидент закрыт.
Post-mortem: В течение 48 часов.
Инструментарий
Slack/Teams-интеграция. Бот автоматически создаёт канал инцидента, приглашает нужных участников, постит шаблон инцидент-тикета.
Runbooks. Каждый алерт ссылается на конкретный runbook в Confluence/Notion: что делать при этой ошибке, какие команды выполнить, кого вызвать.
Shared terminal (tmux/screen): При удалённой работе — tmate или Teleport для совместного доступа к консоли без передачи credentials.
Пример Slack-бота для создания инцидента
# /incident create sev=1 "Payment system down"
@app.command("/incident")
def create_incident(ack, command, client):
ack()
severity = parse_severity(command["text"])
title = parse_title(command["text"])
channel = client.conversations_create(
name=f"incident-{date.today()}-{slugify(title)}"
)
client.chat_postMessage(
channel=channel["channel"]["id"],
text=INCIDENT_TEMPLATE.format(
severity=severity,
title=title,
commander=command["user_id"],
started_at=datetime.now().isoformat()
)
)
# Обновить Status Page
update_status_page(severity, title)
# PagerDuty: создать инцидент
pagerduty.create_incident(severity, title)
Коммуникация во время инцидента
Внутри команды — технические детали в канале инцидента. Для бизнеса — простые обновления каждые 30 минут: «Проблема обнаружена, работаем над устранением. Следующее обновление через 30 минут.» Для пользователей — Status Page.
Никогда не отвечать «скоро исправим» без временных оценок. Лучше «ожидаем восстановление через 2 часа» с дальнейшим уточнением.
Метрики процесса
- MTTD (Mean Time to Detect) — среднее время обнаружения инцидента
- MTTA (Mean Time to Acknowledge) — время от алерта до принятия в работу
- MTTR (Mean Time to Resolve) — среднее время устранения
- Incident Frequency — частота инцидентов по severity
Сроки внедрения
- Определение процесса + ролей + severity matrix — 2-3 дня
- Настройка PagerDuty/OpsGenie + on-call rotation — 1-2 дня
- Slack-интеграция + шаблоны — 1-2 дня
- Runbooks для топ-10 алертов — 3-5 дней
- Обучение команды + пробный drill — 1 день