Как написать сообщение о сбое с помощью ИИ

Как написать сообщение о сбое с помощью ИИ: соберите подтверждённые факты с отметкой времени, дайте модели готовый промпт с двумя снимками журнала, получите черновик с клиентским эффектом и отправьте его вручную после проверки. Модель помогает с формулировкой. Факты она не поставляет.

Кто читает сообщение и какой у сбоя статус

Первый шаг — определить аудиторию и статус на момент отправки. У сообщения о сбое несколько читателей, и каждому нужен свой текст. В руководстве PagerDuty по внешним коммуникациям перечислены критерии, по которым решают, сообщать ли публично: какие продукты затронуты, насколько серьёзна деградация, сколько клиентов затронуто, насколько заметен эффект. Эти же критерии задают, кому адресован текст.

Slack различает сообщения для клиентов, внутренних команд и руководителей. Для клиентов важны влияние и восстановление, для исполнителей — техническое состояние. Здесь готовим клиентский текст; внутренние действия сохраняем в отдельной сводке.

Статус на момент сообщения — вторая половина этого шага. В документации PagerDuty первое сообщение указывает, что инцидент расследуется, и выходит в течение пяти минут после начала разбора. Второе сообщение с первичной оценкой масштаба выходит в течение пяти минут после первого, когда часть масштаба уже известна. Дальше идут периодические обновления.

Для нашего учебного примера статус задан явно. Учебный сервис «Лист», 10 ноября 2026 года, все времена UTC. Снимок A утверждён ответственным в 14:12: с 14:06 подтверждены ошибки отправки формы заявки, чтение страниц проверено и работает, количество затронутых пользователей неизвестно, причина неизвестна, команда изучает журнал ошибок, следующий статус обещан в 14:30, срок устранения неизвестен. Снимок B утверждён в 14:25: в 14:20 и 14:23 две контрольные отправки формы прошли, команда продолжает наблюдение, полное восстановление для всех пользователей не подтверждено, причина и объём воздействия остаются неизвестными, следующий статус в 14:40. Это вымышленные записи, внешних логов нет.

Разница между снимками — это разница статусов. Снимок A описывает расследование. Снимок B описывает наблюдение после технической проверки. Тексты для них отличаются, и смешивать их нельзя.

Подтверждённые факты с отметкой времени

Второй шаг — собрать факты с отметками времени. Observer описывает отделение вычисляемых кодом фактов от черновика модели. В нашем ручном примере источником служат только два утверждённых снимка журнала.

Этот же приём применим вручную. Вы выписываете строки журнала с временем и подтверждением, и только они попадают в промпт. Для снимка A это: с 14:06 подтверждены ошибки отправки формы заявки; чтение страниц работает; число пользователей неизвестно; причина неизвестна; журнал изучается; следующий статус 14:30; срока устранения нет. Для снимка B: контрольные отправки в 14:20 и 14:23 успешны; наблюдение продолжается; восстановление для всех не подтверждено; причина и масштаб неизвестны; следующий статус 14:40.

Observer отдельно предупреждает: близкое по времени развёртывание не объявляют причиной инцидента. В наших снимках развёртывание вообще не названо, поэтому в сообщения оно не попадёт.

Таблица собирается до промпта. Она задаёт границы того, что модель имеет право написать.

Пользовательский эффект вместо технического шума

Третий шаг — перевести факты в клиентский эффект. Rootly советует писать понятным аудитории языком: технические подробности сами по себе не объясняют, чего ожидать. Выделите затронутое действие пользователя и сохраните неизвестное.

В снимке A подтверждены ошибки отправки формы заявки. Это достаточное описание затронутого действия. Из него нельзя выводить, что пользователь потерял заявку или не увидел подтверждения: этих наблюдений журнал не содержит. Чтение страниц проверено и работает. Изучение журнала ошибок относится к внутренней работе команды; его можно оставить во внутренней сводке.

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

Отсюда рабочее правило для черновика. Каждое предложение отвечает на вопрос «что это меняет для читателя». Если ответа нет, предложение уходит во внутреннюю сводку.

Полный промпт для двух снимков журнала

Четвёртый шаг — сам промпт. Он передаёт модели оба снимка и требует два отдельных клиентских сообщения плюс внутреннюю сводку. Ниже полный текст, который можно скопировать без правок.

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

Учебный сервис «Лист», 10 ноября 2026 года. Все времена UTC.

Снимок A, 14:12 UTC: с 14:06 подтверждены ошибки отправки формы заявки; чтение страниц работает; число пользователей и причина неизвестны; изучаем журнал; следующий статус 14:30; срока устранения нет.

Снимок B, 14:25 UTC: контрольные отправки в 14:20 и 14:23 успешны; продолжаем наблюдение; восстановление для всех не подтверждено; причина и масштаб неизвестны; следующий статус 14:40.

Не переносить более поздние знания в A. Не писать о сохранности данных и устранении причины. В каждом сообщении укажи дату, UTC, пользовательский эффект и следующий контакт.

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

Требование «не переносить более поздние знания в A» задаёт границу времени. При проверке раннего сообщения закройте снимок B и найдите основание для каждого предложения только в A. Упоминание успешных отправок в ранней версии будет ошибкой: обе проверки произошли позже её утверждения.

Сообщения с неизвестной причиной и без выдуманного ETA

Пятый шаг — проверить причину и срок. Observer отклоняет черновики с выдуманными причинами, числами и восстановлением. Здесь все три риска проверяются по полному журналу ниже; краткое сообщение не должно скрывать неизвестное.

Вот два готовых клиентских сообщения для нашего примера.

10 ноября, 14:12 UTC. Исследуем ошибки отправки формы заявки, подтверждённые с 14:06 UTC. Страницы сервиса открываются. Причину и масштаб уточняем; подтверждённого срока восстановления пока нет. Следующее сообщение — в 14:30 UTC.

10 ноября, 14:25 UTC. Две контрольные отправки формы в 14:20 и 14:23 UTC прошли успешно. Продолжаем наблюдение; полное восстановление для всех пользователей пока не подтверждено. Следующий статус — в 14:40 UTC.

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

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

Переход от расследования к наблюдению

Шестой шаг — проверить переход между статусами. Не заменяйте неизвестный масштаб сообщением о восстановлении всех пользователей. Успех двух контрольных отправок подтверждает только эти проверки; это основание продолжать наблюдение.

В нашем примере переход выглядит так. Снимок A — расследование: подтверждённые ошибки, причина и масштаб неизвестны. Снимок B — наблюдение: две контрольные отправки прошли, полное восстановление для всех не подтверждено. Слово «наблюдение» здесь несёт точный смысл: проверки прошли, но подтверждения по всем пользователям нет.

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

Практическая проверка перехода: возьмите текст снимка B и спросите, можно ли по нему решить, что сбой закончился. Если да, формулировку надо ослабить до наблюдения. В нашем втором сообщении стоит «полное восстановление для всех пользователей пока не подтверждено» — этого достаточно, чтобы читатель не считал вопрос закрытым.

Дата, часовой пояс и следующий контакт

Седьмой шаг — сверить дату, часовой пояс и следующий контакт. Rootly рекомендует сообщать, что известно, что делает команда и когда будет следующее обновление. Для каждого времени в черновике найдите соответствующую строку снимка.

Отсюда три проверки для готового текста.

Первая: дата. В обоих сообщениях стоит «10 ноября». Дату сверяют с утверждённым снимком журнала.

Вторая: часовой пояс. В обоих сообщениях стоит UTC, и он указан у каждого времени. Без пояса «14:30» читается по-разному в разных регионах.

Третья: следующий контакт. В снимке A это 14:30 UTC, в снимке B — 14:40 UTC. Это время следующего сообщения, и оно не означает обещания ремонта к этому часу. Проверьте, что время контакта не представлено как обещанный срок устранения.

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

Согласование и ручная отправка

Восьмой шаг — согласование и отправка. В Observer ИИ заполняет черновик редактора, а оператор читает, правит и решает, публиковать ли. Здесь также передаём ответственному текст вместе со снимком, по которому он подготовлен.

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

В учебном сценарии сообщение A относится к утверждению в 14:12 UTC, сообщение B — к утверждению в 14:25 UTC. Перед каждой ручной отправкой ответственный сверяет соответствующий снимок и время в тексте. Вторая версия сообщает результат двух проверок раньше обещанного контакта 14:30 и задаёт следующий контакт 14:40. Это допустимое раннее обновление внутри примера; время следующего статуса не нужно выдавать за время составления B. Если отправка задержалась, получите подтверждение актуальности фактов и обновите время сообщения. Не публикуйте старую шапку автоматически.

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

Частые вопросы

Чем сообщение о сбое отличается от постмортема?

В нашем примере оба сообщения относятся к ещё открытому инциденту: в A идёт расследование, в B продолжается наблюдение. Для постмортема потребуется подтверждённое завершение и отдельный разбор событий. Два успешных теста этого не заменяют.

Можно ли поручить модели публикацию сообщения?

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

Что делать, если причина сбоя ещё неизвестна?

В снимке A причина неизвестна; в B подтверждения также нет. Сохраните эту границу в обоих сообщениях. Фраза о сбое базы данных не имеет основания в журнале и должна быть удалена.

Как часто публиковать обновления во время сбоя?

Порядок обновлений согласуют заранее для своего инцидента. В снимке A следующий контакт обещан в 14:30 UTC; сообщение B подготовлено раньше, в 14:25 UTC, и называет следующий контакт в 14:40 UTC. Эти значения относятся к учебному журналу и не задают универсальный интервал.

Что делать, если черновик содержит неподтверждённое обещание?

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