Командные правила · обязательны для всех сотрудников

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

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

01

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

Инцидент — заметный сбой пользовательского или бизнес-процесса, нарушение доступности, корректности, безопасности или целостности данных. Он не обязан быть ошибкой в коде.

Если имеющихся сведений недостаточно для уверенной классификации, событие всё равно регистрируют как возможный инцидент. Решение можно уточнить позже, не теряя первоначальный сигнал.

Срочность определяют с учётом класса критичности затронутой системы: критическая для выручки, важная для бизнеса, операционная или вспомогательная.

02

Инцидент регистрируют сразу

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

Одно корневое сообщение соответствует одному инциденту. Обсуждение продолжается в его ветке. Человек или агент создаёт документ PIR и связывает его с сообщением.

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

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

03

Принятие в работу должно быть видно

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

Ни одна реакция сама по себе не означает закрытие инцидента.

04

Причина должна быть подтверждена

Инженер или агент сначала определяет необходимые источники, затем собирает данные и доказательства и отмечает пробелы. Факты отделяют от гипотез, а хронологию снабжают ссылками на источники.

Анализ корневых причин (RCA) выполняют по собранным сведениям. Агент может подготовить анализ, но подтверждённую причину принимает ответственный человек.

05

Полномочия остаются у людей

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

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

06

Чувствительные сведения отделяют от сигнала

Если детали содержат персональные данные или сведения о безопасности, в общем канале всё равно создают минимальную запись об инциденте. Чувствительную часть переносят в заранее согласованное закрытое место и оставляют доступную участникам ссылку.

07

Восстановление не равно закрытию

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

08

Правила должны быть приняты и известны

Команда обсуждает и принимает эти правила до первого инцидента. С ними знакомят всех сотрудников, которые могут первыми получить сведения о сбое: поддержку, продажи, операторов, руководителей и других участников рабочих процессов.

Изменения правил обсуждают на регулярной встрече по разбору инцидентов и доводят до всех затронутых сотрудников.