Инцидент-менеджмент с нуля: практический гайд для растущих команд / Хабр

Типичность

3 часа ночи. Звонок от незнакомого номера. ”Пользователи не могут залогиниться, п****ц”.

Вы лихорадочно листаете Slack. Непонятно, где проблема и кого будить. Подняли тестеров — они тоже гадают. Бэкенд? Инфра?

Идёте во флудилку в телеге, ищете похожий ник тимлида. Не отвечает. Кто замещает - никто не знает. Начинается массовый обзвон. Через 40 минут находится человек. Смотрит код. “Не моё. Это к Сане — он, кажется, редирект криво поменял в гугл клауд консоли”. Ещё 20 минут — поиск Сани, доступы только у него.

Утром все разбитые. CTO вопрошает. И становится ясно: баг простой. Проблема не в коде. Проблема в бардаке.

Знакомо? Я тоже через это прошел. И после такой ночи решил: хватит. Нужна система.

Для кого эта статья

Если вы технический руководитель, PM или просто заинтересованный инженер в компании, которая:

выросла из стадии всё на коленке,
начала получать первых реальных пользователей,
столкнулась с первыми серьёзными инцидентами,

→ то эта статья для вас. Я расскажу, как я обычно строю процесс инцидент-менеджмента с нуля и кучи сложных рефернсов на ITIL4 и pagerduty. Без Enterprise-уровня сложности, но с реальными работающими практиками.

В конце статьи - ссылка на open-source инструмент Duty Bot, который я написал по приколу для автоматизации дежурств, для небольших компаний, у которых нет денег на что-то вроде https://slack.com/marketplace/A02MJR2A7TQ-rotationapp

Философия: скорость петли обратной связи

Прежде чем углубляться в процессы и таблицы, давайте поговорим о главном. Инцидент-менеджмент - это не про документы и не про бюрократию. Это про скорость петли обратной связи.

Чем быстрее вы:

узнаёте о проблеме,
находите человека, который может её решить,
исправляете проблему,
убеждаетесь, что она действительно исправлена,
и делаете выводы, чтобы не повторять ошибок,

→ тем здоровее ваш продукт и команда.

Полный цикл инцидента как конвейер

Инцидент — это не просто «упало → починили». Это цепочка из 10 шагов, каждый из которых можно (и нужно) оптимизировать:

Проблема на проде ↓
Обнаружение (мониторинг, алерты, пользователи) ↓
Классификация (инцидент? приоритет?) ↓
Мобилизация (дежурный, эскалация) ↓
Исправление ↓
Проверка на дев/стейдж стенде↓
Деплой хотфикса ↓
Проверка на проде↓
Post-Mortem (24-48 часов) ↓
Выполнение задач из постмортема ↓
Еженедельный обзор → системные изменения

Каждый разрыв в цепочке — потерянное время. Нет дежурного? Минус 30 минут на поиск. Нет постмортемов? Те же грабли через месяц.

Культура blameless

Не ищем виноватых. Вместо “кто накосячил?» спрашиваем: «что в системе позволило этой ошибке произойти?”.

Пример: разработчик сломал авторизацию через Apple ID. Вместо выговора провели разбор:

Ревьюер не заметил - объем изменений большой и ревью идет случайным образом;
Автотесты не покрывали - сложно тестировать автоматически;
QA не проверил на iOS - проджект гнал быстрее в релиз;
Мониторинг не поймал - в нем только типовые метрики вроде latency

Результат: добавили метрики, алерт, чек-лист ревью завели. Система стала надёжнее.

Что считать инцидентом

Инцидент - критическая проблема, которая:

Массово влияет на пользователей (не единичная жалоба);
Не имеет простого обходного пути;
Блокирует важный функционал;
Влияет на бизнес-показатели.

Это инцидент	Не инцидент
Пользователи не могут авторизоваться	Пуши приходят с небольшой задержкой
Подписки не автопродлеваются	Визуальный баг в баннере
Упала БД	Единичная жалоба на специфичном устройстве

Классификация: матрица Rich × Criticality

Когда вы определились, что такое инцидент, встаёт следующий вопрос: как приоритизировать? Не все инциденты одинаковы.

Подход 1: Простая шкала P1-P5 (PagerDuty-стиль)

Классика: один показатель, пять уровней. P1 — всё горит, P5 — посмотрим когда-нибудь.

Плюсы: Простота, все понимают.

Минусы: Субъективность. Один человек назовёт баг P2, другой — P4. Нет чётких критериев.

Подход 2: SEV1-SEV4 (Google SRE)

Фокус на бизнес-импакте. SEV1 — критическое влияние на бизнес, SEV4 — минимальное.

Плюсы: Привязка к бизнесу, понятно руководству.

Минусы: Требует зрелой культуры и чёткого понимания, что такое «бизнес-импакт» для вашего продукта.

Подход 3: ITIL Impact × Urgency

Классика из корпоративного мира: матрица влияния и срочности.

Плюсы: Структурированность, стандарт индустрии.

Минусы: Абстрактно, требует много обучения, избыточно для небольших команд.

Подход 4: Rich × Criticality (мойвыбор)

Мы выбрали подход с двумя осями: охват пользователей (Rich) и критичность функционала (Criticality). Почему?

Конкретность. Вместо абстрактного “высокий импакт” мы спрашиваем: “сколько процентов пользователей затронуто?” и “насколько критичен этот функционал?”.

Кстати для этого достаточно сделать дашборд с числом активных пользователей и воронкой по фунционалу сервиса + разметить функции продукта по классам критичности

Скорость принятия решений. Когда 3 часа ночи и всё горит — не время для философских дискуссий. Две простых оценки → итоговый приоритет.

Понятность для всех. И разработчик, и PM, и CEO понимают: «затронуто 60% пользователей, отвалилась авторизация» = P1.

Rich (охват)

Уровень	Описание
R1	>30% пользователей (все iOS, все с версией X)
R2	10-30% пользователей (все WebApp, конкретный регион)
R3	<10% пользователей (новореги с Android 9.0)

Criticality (критичность)

Уровень	Описание
C1	Критический функционал: авторизация, регистрация, оплата, core flow
C2	Важный функционал: есть workaround, но UX страдает
C3	Второстепенный: UI нарушения, некритичные фичи

Матрица приоритетов

Rich / Criticality	C1	C2	C3
R1	P1	P1	P2
R2	P1	P2	P3
R3	P2	P2	P3

SLA

Приоритет	Реакция	Решение
P1 HIGH	15 мин	ASAP (до 4ч)
P2 MEDIUM	1 час	24 часа
P3 LOW	Рабочий день	72 часа

Организация дежурств

Принципы

24/7 доступность — дежурный должен быть доступен круглосуточно, включая выходные. Это не значит, что он сидит у компьютера 24 часа. Он может заниматься своими делами, гулять, даже спать — но должен иметь возможность быстро выйти на связь и подключиться к решению
Квалификационный ценз — только после испытательного срока, с правом деплоя на прод
Ротация — смена каждую неделю, никто не дежурит постоянно
Компенсация — работа в нерабочее время оплачивается
Backup — еще 1 человек на след уровне эскалации , например тимлид, как страховка

Если это не Blue team или какие-то SRE, то дежурства без привлечения на инциденты сами по себе не оплачиваются

Необходимые условия для дежурного

Быть на связи (Slack, Telegram, телефон)
Иметь доступ к рабочему устройству
Иметь стабильный интернет

Структура

Для каждой команды рекомендую заводить кастомные роли:

Dev on-call — разработчик, который будет фиксить
QA on-call — тестировщик для проверки фикса
Team Lead — backword при недоступности дежурных

Пример таблицы дежурств

Роль	Кто	Slack	Telegram	Телефон
Dev on-call	Иван Иванов	@ivan	@ivan_dev	+7 999 123-45-67
QA on-call	Мария Петрова	@maria	@maria_qa	+7 999 765-43-21
Team Lead	Алексей Сидоров	@alexey	@alexey_tl	+7 999 111-22-33

Период (для начала советую сменами): понедельник–воскресенье

Тимлид обновляет таблицу в начале каждой недели. При уходе в отпуск — назначает заместителя.

Процесс эскалации

Принципы

Инициировать может любой — саппорт, джун, кто угодно
Чёткие тайм-ауты — 20 минут без ответа = следующий шаг
Последовательность каналов — Slack → Telegram сообщение → Telegram звонок → мобильный
Лучше эскалировать зря, чем не эскалировать когда нужно

Цепочка эскалации

Шаг	Кого	Каналы	Тайм-аут	Условие перехода
1	Идентификация	—	Немедленно	Любой инициирует
2	Dev on-call	Slack → TG msg → TG call → Mobile	20 мин	Не отвечает → шаг 4
3	QA on-call	Slack → TG msg → TG call → Mobile	20 мин	Не отвечает → QA Lead
4	Team Lead	Slack → TG msg → TG call → Mobile	20 мин	Не может помочь → шаг 5
5	PM	Slack → TG msg → TG call → Mobile	10 мин	Недоступен → C-level
6	CTO	Slack → TG msg → TG call → Mobile	10 мин	Не должно доходить

Инфраструктурные проблемы (упала БД, сервер недоступен) — сразу на DevOps, минуя Dev on-call.

Полный цикл работы с инцидентом

Этап 1: Обнаружение

Источники:

Служба поддержки
Внутренний сотрудник
Мониторинг и алертинг (Grafana, Datadog, Crashlytics)
Аномалии в метриках

Цель: минимизировать MTTD. Чем раньше узнали — тем раньше начали чинить.

*(Mean Time To Detect) — это среднее время обнаружения проблемы

Этап 2: Классификация

Это инцидент? (по критериям)
Какой приоритет? (по матрице Rich × Criticality)

Правило: сомневаетесь между P1 и P2 — ставьте P1. Понизить всегда можно.

Этап 3: Мобилизация

Рабочее время: Тимлид/PM назначает разработчика.

Нерабочее время: Dev on-call + QA on-call по таблице (а лучше сервису) дежурств.

Этап 4: Исправление

Локализация - понять причину;
Фикс - написать исправление;
Тест на dev-стенде - QA проверяет;
Hotfix - готовим для прода.

Важно: не занимайтесь root cause analysis сейчас. Цель - восстановить сервис. Разбор - на постмортеме.

*для мобильных приложений если у вас маркеты и сторы быстро фиксить бесполезно

Этап 5: Верификация

Деплой на прод
Проверка на проде
Мониторинг метрик
Сообщение в чат команды

Критерий закрытия: проблема не воспроизводится, метрики в норме.

Этап 6: Post-Mortem (24-48 часов)

Шаблон:

Параметр	Описание
Дата инцидента	Дата и время начала
Серьёзность	High/Medium/Low
Длительность	Время простоя для пользователей
Импакт	Сколько пользователей затронуто, влияние на бизнес
Хронология	Когда заметили, кто сообщил, что делали последовательно
Причина	Техническая или процессная
Действия для фикса	Что сделали для устранения
Действия для профилактики	Как предотвратить повторение
Действия для наблюдаемости	Какие метрики/алерты добавить

Плохо: “Разработчик допустил ошибку”

Хорошо: “Изменение в API VK OAuth не было отслежено, т.к. не подписаны на changelog”

Этап 7: Выполнение задач

Все задачи из постмортема → тикеты в вашем тасктрекере с ответственными и дедлайнами.

Не “надо бы добавить мониторинг”, а “JIRA-12345: Добавить алерт на auth_success_rate, @ivan, дедлайн: 15.01”.

Этап 8: Еженедельный обзор

Участники: Проджекты, Хеды, C-lvl

Повестка:

Инциденты за неделю (список, критичность)
Статус постмортемов
Статус задач из постмортемов
Тренды и системные улучшения
Затраты на переработки

*Без участия топов обычно ничего не меняется, а если их вовлекать в инциденты внезапно все очень быстро едет.

Компенсация переработок

Что считается переработкой

Да:

Работа за пределами рабочего времени
Работа в выходные/праздники
Срочное решение инцидентов
C-lvl решил дернуть по срочному вопросу на его усмотрение (классика)

Нет:

Не уложился в дедлайн по своей вине
Работал по собственной инициативе без запроса

Варианты компенсации

Отгул — час за час. Переработал 2 часа → завтра уходишь на 2 часа раньше.

Деньги (тут описано по ТК РФ):

Время	Коэффициент
Будни, первые 2 часа	×1.5
Будни, следующие часы	×2
Выходные и праздники	×2

Лимиты

Не более 4 часов переработки подряд в течение двух дней
Не более 120 часов в год

Философия: переработки — исключение, не норма. Много переработок = проблема в процессах.

Автоматизация: Duty Bot

Проблема Google Sheets и Confluence

“Кто сегодня дежурит?” - искать в таблице в 3 ночи такое себе
Забывают обновлять
Нет напоминаний
Нет истории
“Этот не отозвался, кого звать следом?”
“Как тегнуть Машу из Auth team?”

Решение

Open-source бот для Telegram и Slack: github.com/letya999/duty_bot

Возможности:

/duty - кто дежурит сегодня
/duty backend - дежурный конкретной команды
/schedule backend set 25.12 @ivan — назначить дежурство
/escalate backend - эскалация на тимлида
/incident start "..." — начать инцидент

Автоматизация:

Утренний дайджест
Напоминания о дежурстве
Автоэскалация по таймауту
Синхронизация с Google Calendar

Веб-панель:

Визуальный календарь
Управление командами
Отчёты и статистика

Быстрый старт

git clone https://github.com/letya999/duty_bot && cd duty_bot
cp .env.example .env
python scripts/generate_security_keys.py --output .env.security
cat .env.security >> .env && rm .env.security
# Заполнить TELEGRAM_TOKEN и SLACK_BOT_TOKEN в .env
docker-compose up -d --build

Что я делаю дальше и чего нет в гайде: Observability и SLO

А дальше у меня путь в более глубокую автоматизацию. В настройку мониторинга и алертинга и быстрый автоматический роутинг.

Разметка событиями

Каждая важная функция отправляет события, например:

auth_started → auth_success / auth_failed
payment_started → payment_success / payment_failed
message_sent → message_delivered / message_failed

Метрики из событий

success_rate — процент успешных операций
latency — время выполнения (p50, p95, p99)
error_rate — процент ошибок

SLO (Service Level Objectives)

Сервис	Метрика	SLO
Авторизация	success_rate	≥99.9%
Отправка сообщений	success_rate	≥99.5%
Оплата	success_rate	≥99.99%
API	latency p95	<500ms

Error Budget

SLO = 99.9% → Error Budget = 0.1% ошибок в месяц (~43 минуты простоя).

Потратили бюджет? Замораживаем фичи, чиним надёжность.

Алерты привязаны к SLO

❌ cpu_usage > 80% — не понятно влияние на пользователей

✅ auth_success_rate < 99.5% — авторизация деградирует

Маршрутизация алертов

Каждая команда видет перечень компонентов, за которые отвечает, с указанием класса критичности и перечнем алертов, которые позволяют соотнести проблему с компонентом

Алерт	Команда	Канал
auth_success_rate < 99.5%	Backend	#backend-alerts
payment_success_rate < 99.9%	Payments	#payments-alerts
app_crash_rate > 1%	Mobile	#mobile-alerts

Метрики успеха

Метрика	Что показывает	Цель
MTTD	Как быстро узнаём	<5 мин
MTTR	Как быстро чиним	<1ч для P1
Кол-во инцидентов	Тренд	Снижение
% повторных	Одни и те же проблемы	<10%
% выполнения SLA	Укладываемся в тайминги	>95%
% постмортемов	Документируем	100%
% задач из постмортемов	Чиним причины	>80%

Заключение

Инцидент-менеджмент - зеркало устойчивости организации. Начните с малого:

Завтра: определите, что для вас инцидент
На этой неделе: назначьте первого дежурного
В этом месяце: проведите первый постмортем

Главное -> культура, не документы. Документы -> инструмент. Культура -> фундамент.

Инцидент-менеджмент с нуля: практический гайд для растущих команд

Типичность

Для кого эта статья

Философия: скорость петли обратной связи

Полный цикл инцидента как конвейер

Культура blameless

Что считать инцидентом

Классификация: матрица Rich × Criticality

Подход 1: Простая шкала P1-P5 (PagerDuty-стиль)

Подход 2: SEV1-SEV4 (Google SRE)

Подход 3: ITIL Impact × Urgency

Подход 4: Rich × Criticality (мойвыбор)

Rich (охват)

Criticality (критичность)

Матрица приоритетов

SLA

Организация дежурств

Принципы

Необходимые условия для дежурного

Структура

Пример таблицы дежурств

Процесс эскалации

Принципы

Цепочка эскалации

Полный цикл работы с инцидентом

Этап 1: Обнаружение

Этап 2: Классификация

Этап 3: Мобилизация

Этап 4: Исправление

Этап 5: Верификация

Этап 6: Post-Mortem (24-48 часов)

Этап 7: Выполнение задач

Этап 8: Еженедельный обзор

Компенсация переработок

Что считается переработкой

Варианты компенсации

Лимиты

Автоматизация: Duty Bot

Проблема Google Sheets и Confluence

Решение

Быстрый старт

Что я делаю дальше и чего нет в гайде: Observability и SLO

Разметка событиями

Метрики из событий

SLO (Service Level Objectives)

Error Budget

Алерты привязаны к SLO

Маршрутизация алертов

Метрики успеха

Заключение

Полезные ссылки