Процесс: управление инцидентом
Учебный пример для команды с общим каналом инцидентов и мониторингом. Послеинцидентный разбор: PIR — документ и этап процесса, а не название всего управления инцидентом.
Зачем
- Какую проблему решаем: факты разбросаны между каналом, журналами и мониторингом, а участники вручную ведут хронологию во время восстановления.
- Какой результат должен измениться: сократить время до подтверждения влияния и восстановления, не отвлекая ответственного за инцидент.
- Как процесс связан с целью внедрения: агент собирает разрешённые факты и ведёт черновик; человек подтверждает влияние, действия, сообщения и выводы.
Точка входа
- Что запускает процесс: сигнал мониторинга, поддержки или участника команды о возможном влиянии на пользователей.
- Кто может запустить: ответственный за инцидент или дежурный инженер.
- Где это происходит: выделенный канал инцидента, мониторинг и система задач.
- Как понять, что входные данные готовы: есть время сигнала, его источник и предполагаемое влияние.
Участники и ответственность
- Владелец процесса: ответственный за инцидент.
- Кто готовит входные данные: источник сигнала и дежурный инженер.
- Кто принимает результат: ответственный за инцидент и владелец затронутого сервиса.
- Кто обновляет шаблоны, промпты или скиллы: SRE, DevOps или Tech Lead.
Входные данные
- Сигнал и сообщения из выделенного канала инцидента.
- Разрешённые данные мониторинга и журналов.
- Карта сервиса и актуальная инструкция восстановления.
Выходные артефакты
- Подтверждённое влияние и хронология фактов.
- Подтверждение восстановления и журнал принятых решений.
- Решение о необходимости PIR и назначенные действия.
Шаги процесса
Промпты, скиллы и инструменты
- Канал инцидента, мониторинг, журналы и система задач.
- Версионируемый шаблон инцидента и инструкции агента.
- Шаблон PIR для случаев, где после восстановления нужен отдельный разбор.
Контрольные точки с человеком
- Где человек обязан проверить результат: при подтверждении влияния, перед действием восстановления, перед внешним сообщением и при формулировке причины.
- Какие решения нельзя отдавать агенту: приоритет, опасное действие, публичная коммуникация и утверждение корневой причины.
- Что делать, если результат сомнительный: пометить его как гипотезу и вернуть ответственному за инцидент.
Данные и доступы
- Какие данные разрешены: выделенный канал, согласованные журналы и метрики затронутого сервиса.
- Какие данные запрещены: производственные секреты, лишние персональные данные и источники вне инцидента.
- Где лежат секреты или инструкции по доступу: в принятом командой хранилище секретов; агент получает только необходимый доступ.
- Как отключить агента и продолжить вручную: отозвать доступ, закрепить текущую хронологию и продолжить по инструкции инцидента.
Метрики
- Основная метрика результата: время от сигнала до подтверждения влияния и время до восстановления; источник — журнал инцидента.
- Метрика качества или внедрённости: доля инцидентов с подтверждённой хронологией и назначенными действиями.
- Негативный сигнал: опасное действие, неподтверждённая причина или повтор инцидента по той же причине.
- Исходный уровень: отдельно измерить на симуляциях и на доступной выборке реальных инцидентов.
Ресурсы и срок
- Срок первого этапа: 6 недель, потому что частота реальных инцидентов непредсказуема.
- Время команды: около 10 часов на настройку, две симуляции, 6 часов на разбор и фактическое время участников реальных событий.
- Лимит на инструменты и инфраструктуру: определить до запуска и не расширять доступ без решения владельца.
- Стоимость одного запуска: стоимость инструментов плюс время ответственного и участников; считать отдельно для симуляции и инцидента.
- Полная стоимость этапа: настройка, две симуляции, разборы и фактические расходы на реальные запуски.
Критерий внедрённости
- Когда процесс считается принятым: две симуляции пройдены, реальные сигналы регулярно превращаются в подтверждённую хронологию и решение без лишней нагрузки.
- Когда процесс нужно остановить или пересобрать: агент отвлекает участников, утверждает неподтверждённую причину, получает лишний доступ или не ведёт журнал.
- Кто принимает решение: ответственный за инцидент и владелец сервиса.
- Когда пересматривать: после двух симуляций и после достаточной выборки реальных инцидентов.
Журнал запусков
