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

Типичность

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

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

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

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

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

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

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

• выросла из стадии всё на коленке,

• начала получать первых реальных пользователей,

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

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

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

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

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

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

1. узнаёте о проблеме,

2. находите человека, который может её решить,

3. исправляете проблему,

4. убеждаетесь, что она действительно исправлена,

5. и делаете выводы, чтобы не повторять ошибок,

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

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

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

1. Проблема на проде ↓

2. Обнаружение (мониторинг, алерты, пользователи) ↓

3. Классификация (инцидент? приоритет?) ↓

4. Мобилизация (дежурный, эскалация) ↓

5. Исправление ↓

6. Проверка на проде ↓

7. Деплой хотфикса ↓

8. Post-Mortem (24-48 часов) ↓

9. Выполнение задач из постмортема ↓

10. Еженедельный обзор → системные изменения

Каждый разрыв в цепочке — потерянное время. Нет дежурного? Минус 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 (охват)

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

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

SLA

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

Принципы

• 24/7 доступность — дежурный должен быть доступен круглосуточно, включая выходные. Это не значит, что он сидит у компьютера 24 часа. Он может заниматься своими делами, гулять, даже спать — но должен иметь возможность быстро выйти на связь и подключиться к решению

• Квалификационный ценз — только после испытательного срока, с правом деплоя на прод

• Ротация — смена каждую неделю, никто не дежурит постоянно

• Компенсация — работа в нерабочее время оплачивается

• Backup — еще 1 человек на след уровне эскалации , например тимлид, как страховка

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

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

• Быть на связи (Slack, Telegram, телефон)

• Иметь доступ к рабочему устройству

• Иметь стабильный интернет

Структура

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

• Dev on-call — разработчик, который будет фиксить

• QA on-call — тестировщик для проверки фикса

• Team Lead — backword при недоступности дежурных

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

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

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

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

Принципы

• Инициировать может любой — саппорт, джун, кто угодно

• Чёткие тайм-ауты — 20 минут без ответа = следующий шаг

• Последовательность каналов — Slack → Telegram сообщение → Telegram звонок → мобильный

• Лучше эскалировать зря, чем не эскалировать когда нужно

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

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

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

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

Источники:

• Служба поддержки

• Внутренний сотрудник

• Мониторинг и алертинг (Grafana, Datadog, Crashlytics)

• Аномалии в метриках

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

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

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

1. Это инцидент? (по критериям)

2. Какой приоритет? (по матрице Rich × Criticality)

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

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

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

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

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

1. Локализация — понять причину;

2. Фикс — написать исправление;

3. Тест на dev-стенде — QA проверяет;

4. Hotfix — готовим для прода.

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

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

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

1. Деплой на прод

2. Проверка на проде

3. Мониторинг метрик

4. Сообщение в чат команды

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

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

Шаблон:

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

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

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

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

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

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

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

Повестка:

1. Инциденты за неделю (список, критичность)

2. Статус постмортемов

3. Статус задач из постмортемов

4. Тренды и системные улучшения

5. Затраты на переработки

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

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

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

Да:

• Работа за пределами рабочего времени

• Работа в выходные/праздники

• Срочное решение инцидентов

• C-lvl решил дернуть по срочному вопросу на его усмотрение (классика)

Нет:

• Не уложился в дедлайн по своей вине

• Работал по собственной инициативе без запроса

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

Отгул — час за час. Переработал 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)

Error Budget

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

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

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

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

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

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

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

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

Заключение

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

1. Завтра: определите, что для вас инцидент

2. На этой неделе: назначьте первого дежурного

3. В этом месяце: проведите первый постмортем

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

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

• Duty Bot: github.com/letya999/duty_bot

• Google SRE Book: sre.google/sre-book

• PagerDuty Guide: response.pagerduty.com

• Atlassian Incident Management: atlassian.com/incident-management