Реалізація 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: Робота проводиться у виділеному Slack-каналі. Оновлення — кожні 20-30 хвилин. Всі значимі дії логуються у тред інцидента (хто, що, коли).
Resolution: Сервіс відновлен, користувачі сповіщені, інцидент закритий.
Post-mortem: Протягом 48 годин.
Інструментарій
Slack/Teams-інтеграція. Бот автоматично створює канал інцидента, запрошує учасників, постить шаблон інцидент-тікета.
Runbooks. Кожен alert посилається на конкретний 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) — час від alert до прийняття у роботу
- MTTR (Mean Time to Resolve) — середній час усунення
- Incident Frequency — частота інцидентів за severity
Терміни впровадження
- Визначення процесу + ролей + severity matrix — 2-3 дні
- Налаштування PagerDuty/OpsGenie + on-call rotation — 1-2 дні
- Slack-інтеграція + шаблони — 1-2 дні
- Runbooks для топ-10 alerts — 3-5 днів
- Навчання команди + пробний drill — 1 день