Передача инцидента между инженерами кажется простой, пока все помнят детали. Но при смене исполнителя, окончании рабочего дня или эскалации часто теряется главное: что уже известно, что проверяли, что временно помогает и какой следующий шаг имеет смысл.
Хорошая передача не должна быть длинным отчетом. Ее задача практическая: следующий инженер должен продолжить расследование с текущей точки, а не начинать заново. Для этого нужна короткая, но полная структура.
Симптом и влияние на бизнес
Первое, что нужно передать, это не внутреннее предположение, а наблюдаемый симптом. Не «сломался сервер», а «пользователи отдела продаж не могут открыть такую-то систему», «отчеты формируются дольше обычного», «часть касс не отправляет данные». Симптом должен быть связан с тем, что видит пользователь или бизнес-процесс.
Рядом фиксируется влияние: сколько пользователей затронуто, какие операции остановлены, есть ли обходной способ работы, насколько срочно нужно восстановление. Без этого следующий инженер не понимает приоритет и может тратить время на технически интересную, но не самую важную ветку.
Временная шкала важнее пересказа
Инцидент почти всегда развивается во времени. Когда началось, кто заметил, что изменилось перед этим, когда появились первые ошибки, какие действия уже предпринимались, после чего стало лучше или хуже. Временная шкала помогает отделить причину от совпадения.
| Факт | Зачем он нужен |
|---|---|
| Время первого симптома | Сравнить с изменениями, заданиями, нагрузкой и внешними событиями. |
| Кого затронуло | Понять масштаб и приоритет коммуникации. |
| Что уже проверено | Не повторять действия без причины. |
| Что временно помогло | Поддержать работу бизнеса, пока идет устранение причины. |
| Что ухудшило ситуацию | Не повторить опасный шаг. |
Доказательства нужно прикладывать, а не описывать словами
Слова «ошибка в журнале» или «пинг нестабильный» мало помогают без конкретики. Лучше приложить безопасный фрагмент: время ошибки, код, имя службы без секретов, скриншот пользовательского сообщения, график нагрузки, номер заявки, результат контрольной проверки. Доказательств должно быть достаточно для продолжения расследования, но они не должны раскрывать лишние данные.
Не нужно передавать пароли, ключи, персональные данные, полные конфигурации или сведения о клиентах. Если полный артефакт чувствительный, в карточке инцидента указывают безопасный признак и место, где уполномоченный инженер может посмотреть исходник.
Что уже сделано и что это изменило
Самая частая потеря контекста возникает из-за фразы «проверили сеть» или «перезапускали службу». Для следующего инженера это почти бесполезно. Нужно записать, какую гипотезу проверяли, каким признаком, какой результат получили и изменилось ли состояние после действия.
Например: «проверяли гипотезу о проблеме канала связи; у трех пользователей из разных сетей симптом одинаковый; локальная сеть офиса не выглядит единственной причиной». Такая запись не доказывает окончательный диагноз, но сужает поле и показывает, куда двигаться дальше.
Временное решение должно иметь ограничения
Если найден временный способ продолжить работу, его нужно передавать вместе с границами. Кому он подходит, какие операции остаются недоступны, сколько времени его можно использовать, что нельзя делать, чтобы не ухудшить состояние. Временное решение без ограничений быстро превращается в скрытый постоянный процесс.
Также важно указать, кто сообщил пользователям о временном порядке и кто должен отменить его после исправления. Иначе техническая проблема может быть устранена, а бизнес еще долго продолжит работать по аварийному сценарию.
Следующая гипотеза и владелец коммуникации
Передача должна завершаться ближайшим проверяемым шагом. Не «разобраться дальше», а «проверить такую-то зависимость», «сопоставить время ошибки с таким-то изменением», «получить подтверждение у владельца сервиса». Это снижает паузу между исполнителями.
Отдельно назначается владелец коммуникации. Пользователи и руководители должны понимать, кто дает обновления по статусу, когда будет следующее сообщение и какие ожидания уже согласованы. В рамках ITSM это часть управления сервисом, а не дополнительная любезность инженера.
Минимальная карточка передачи
- Наблюдаемый симптом и затронутые пользователи или процессы.
- Влияние на бизнес и текущий приоритет.
- Временная шкала с ключевыми событиями.
- Доказательства без секретов и лишних персональных данных.
- Гипотезы, которые уже проверены, и результаты.
- Действия, которые помогли, не помогли или ухудшили ситуацию.
- Временное решение и его ограничения.
- Следующий проверяемый шаг.
- Владелец технического расследования и владелец коммуникации.
Качественная передача инцидента не делает расследование медленнее. Она экономит время на повторных вопросах, защищает от случайных действий и помогает команде сохранять единый контекст даже при смене исполнителя.