# Как запустить управление инцидентами в малой группе

Эта инструкция рассчитана на команду из 3–8 человек, у которой ещё нет
дежурств, SRE-функции и сложного трекера. Цель первого месяца — не «внедрить
ITIL», а создать привычку: заметный сбой становится общим, получает владельца,
проверяемое восстановление и след, который не исчезает из чата.

## С чего начать внедрение

1. Назначьте регулярную встречу для разбора инцидентов и сразу внесите её в
   календари участников.
2. Составьте, обсудите и примите командой правила работы с инцидентами. В них
   определите, что считается инцидентом, и задайте классы критичности систем:
   критическая для выручки, важная для бизнеса, операционная или вспомогательная.
3. Договоритесь, где создаются инциденты: в отдельном канале или теме в Zulip,
   Mattermost, Rocket.Chat, Slack либо другом общем рабочем пространстве. Одно
   корневое сообщение — один инцидент; обсуждение остаётся в его ветке.
4. Ознакомьте с правилами всех сотрудников, которые могут первыми получить
   сведения об инциденте: поддержку, продажи, операторов, руководителей и других
   участников рабочих процессов. При появлении первых сведений о возможном
   инциденте они регистрируют его в выбранном общем канале.
5. Назначьте дежурного на неделю. Это не обязанность всё чинить: он принимает
   сигнал, собирает первые сведения и помогает найти ответственного за инцидент.
6. Выберите одно место для PIR и один короткий шаблон. Не начинайте с таблицы:
   журнал нужен позже для обзора, а не как барьер перед первой реакцией.

## Первые 15 минут

1. Автор сигнала создаёт сообщение в общем канале: что не работает, для кого,
   когда замечено и как повторить.
2. Дежурный или ответственный за инцидент ставит `👀`: это означает «инцидент взят в работу», а не
   «я уже знаю причину».
3. Создайте PIR по шаблону и привяжите к треду. Запишите только факты и ссылки
   на доказательства; гипотезы помечайте как гипотезы.
4. Назначьте владельца следующего действия. Рискованное изменение рабочей
   системы подтверждает человек с соответствующими полномочиями.

С правилами регистрации должны быть заранее ознакомлены все сотрудники, которые
могут первыми узнать о возможном инциденте. При появлении первых сведений они
регистрируют инцидент в выбранном общем канале, а не сообщают о нём только в
личной переписке программисту, руководителю или системному администратору.
Получивший личное сообщение не забирает проблему себе, а напоминает автору
[правила регистрации инцидента](https://pismenny.ru/incident-management/rules/#registration),
даёт ссылку на них и помогает зарегистрировать инцидент в общем канале. Если детали содержат персональные
данные или сведения о безопасности, в общем канале всё равно создают минимальную
запись, а чувствительную часть переносят в согласованное закрытое место.

Не начинайте исправление незарегистрированного инцидента. Сначала создайте
сообщение в общем канале и документ PIR. Если восстановление нельзя задерживать,
регистрацию одновременно выполняет другой участник или агент. «Тихое»
исправление без следа в канале и PIR запрещено.

## Когда сервис снова работает

- Исполнитель отмечает `🏁`, когда выполнил восстановление, срочное исправление или обходной
  путь.
- Поддержка, заявитель или другой назначенный человек проверяет реальный
  пользовательский сценарий и ставит `✅`.
- `✅` не закрывает PIR. Оно означает лишь, что текущее воздействие устранено.

## Разбор и предотвращение

На назначенной в первом шаге регулярной встрече по разбору инцидентов
рассматривайте открытые PIR:

1. дополните хронологию и проверяемые данные;
2. проведите анализ корневых причин (RCA), например цепочку «5 почему», не
   выдавая правдоподобные версии за причину;
3. отделите варианты решения от причины;
4. создайте предотвращающие задачи с владельцем, сроком и критерием проверки;
5. если выбор затрагивает архитектуру, продуктовый компромисс или допустимый
   риск, оформите ADR и свяжите его с PIR.

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

Полный цикл: «определи необходимые источники → собери данные и доказательства →
создай или обнови PIR → проведи анализ причин → проверь анализ → закрой
пробелы». Агент не подтверждает причину, не принимает риск изменения рабочей
системы и не закрывает PIR.

## Первые три недели

**Неделя 1.** Назначьте регулярную встречу, примите правила и выберите общий
канал. Разберите один учебный или свежий случай.

**Неделя 2.** Проведите первый регулярный разбор открытых PIR. Уберите из
шаблона поля, которые никто не заполняет, и добавьте только реально нужные.

**Неделя 3.** Посмотрите журнал: есть ли у каждого открытого инцидента ответственный,
текущий статус и следующий шаг. Уточните правила по итогам первых случаев.

Процесс прижился, когда люди сами создают сообщение вместо личной переписки,
руководитель видит зависшие `👀` и `🏁`, а закрытые PIR действительно имеют
проверенные предотвращающие задачи.