С чего начать внедрение
- Назначьте регулярную встречу для разбора инцидентов и сразу внесите её в календари участников.
- Составьте, обсудите и примите командой правила работы с инцидентами. В них определите, что считается инцидентом, и задайте классы критичности систем: критическая для выручки, важная для бизнеса, операционная или вспомогательная.
- Договоритесь, где создаются инциденты: в отдельном канале или теме в Zulip, Mattermost, Rocket.Chat, Slack либо другом общем рабочем пространстве. Одно корневое сообщение — один инцидент; обсуждение остаётся в его ветке.
- Ознакомьте с правилами всех сотрудников, которые могут первыми получить сведения об инциденте: поддержку, продажи, операторов, руководителей и других участников рабочих процессов. При появлении первых сведений о возможном инциденте они регистрируют его в выбранном общем канале.
- Назначьте дежурного на неделю. Он принимает сигнал, собирает сведения и помогает найти ответственного за инцидент — владельца следующего шага.
- Выберите одно место для PIR и короткий шаблон. Журнал нужен для обзора, но не должен задерживать первую реакцию.
Первые 15 минут
- Автор сигнала пишет в общий канал: что не работает, для кого, когда замечено и как воспроизвести.
- Дежурный или ответственный за инцидент ставит
👀: «инцидент взят в работу», а не «причина уже известна». - Создайте PIR и привяжите его к треду. Записывайте факты и доказательства; версии помечайте как гипотезы.
- Назначьте владельца следующего действия. Рискованное изменение рабочей системы подтверждает человек с соответствующими полномочиями.
С правилами регистрации должны быть заранее ознакомлены все сотрудники, которые могут первыми узнать о возможном инциденте. При появлении первых сведений они регистрируют инцидент в выбранном общем канале, а не сообщают о нём только в личной переписке программисту, руководителю или системному администратору. Получивший личное сообщение не забирает проблему себе, а напоминает автору правила регистрации инцидента, даёт ссылку на них и помогает зарегистрировать инцидент в общем канале. Если детали содержат персональные данные или сведения о безопасности, в общем канале всё равно создают минимальную запись, а чувствительную часть переносят в согласованное закрытое место.
Не начинайте исправление незарегистрированного инцидента. Сначала создайте сообщение в общем канале и документ PIR. Если восстановление нельзя задерживать, регистрацию одновременно выполняет другой участник или агент. «Тихое» исправление без следа в канале и PIR запрещено.
Когда сервис снова работает
👀 В работеответственный принял следующий шаг
🏁 Исправленорешение готово к проверке
✅ Принятосценарий проверен
✅ означает, что текущее воздействие устранено. PIR остаётся открытым до выполнения и проверки обязательных предотвращающих действий.
Разбор и предотвращение
На назначенной в первом шаге регулярной встрече по разбору инцидентов рассматривайте открытые PIR:
- дополните хронологию и проверяемые данные;
- проведите анализ корневых причин (RCA), например цепочку «5 почему»;
- отделите варианты решения от причины;
- создайте предотвращающие задачи с владельцем, сроком и способом проверки;
- существенный архитектурный или рискованный выбор оформите отдельным решением (ADR) и свяжите с PIR.
Как подключить ИИ-агента
Рабочий цикл: «определи необходимые источники → собери данные и доказательства → создай или обнови PIR → проведи анализ причин → проверь анализ → закрой пробелы».
Источниками могут быть сообщение заявителя и тред, журналы работы системы, показатели наблюдения, история выкладок и изменений кода, задачи, обращения поддержки и сведения владельца затронутой системы. До анализа агент должен перечислить, какие источники доступны, каких не хватает и что именно нужно получить.
Агент собирает хронологию и находит недостающие доказательства, но не подтверждает причину, не принимает риск изменения рабочей системы и не закрывает PIR.
Первые три недели
Назначьте регулярную встречу, примите правила и выберите общий канал. Разберите учебный или свежий случай.
Проведите первый регулярный разбор. Уберите неиспользуемые поля.
Проверьте ответственного, статус и следующий шаг у каждого PIR. Уточните правила по итогам первых случаев.
Процесс прижился, когда люди создают сообщения вместо личной переписки, руководитель видит зависшие статусы, а закрытые PIR имеют проверенные предотвращающие задачи.