Во время инцидента людям важно понять, затронута ли их работа, что делать и когда появится следующая информация. Презентация для коммуникаций при инциденте помогает команде давать согласованные ответы. Клиенты и руководители не должны расшифровывать технический чат реагирования.
Рассмотрим первое клиентское сообщение о вымышленном сервисе загрузки вложений. Все отметки времени, наблюдения и сообщения ниже придуманы для примера. Они не описывают инцидент Presenti.
10:15 UTC — Исследуем ошибки загрузки вложений
Мы исследуем ошибки загрузки новых вложений в части рабочих пространств, размещённых в нашем регионе ЕС. Впервые ошибки наблюдались в 10:05 UTC; полный масштаб влияния ещё выясняем. Следующее сообщение опубликуем не позднее 10:30 UTC.
Сообщение называет затронутое действие, известный охват и время следующего обновления, не выдумывая причину или срок восстановления. Стройте брифинг на тех же подтверждённых фактах. После согласования заметок Presenti поможет превратить текст в редактируемую презентацию для заинтересованных сторон. Он не наблюдает за инцидентом, не подтверждает восстановление и не публикует за вас обновления страницы состояния.
Используйте единый фактический журнал для разных сообщений
До оформления слайдов подготовьте короткую запись об инциденте, доступную всем авторам обновлений. Наблюдению нужны время и источник. Гипотезе — явная пометка. Вопрос без ответа остаётся открытым, пока не появятся доказательства.
В вымышленном инциденте запись на 10:18 UTC может выглядеть так:
| Статус | Содержание | Основание или следующее действие |
|---|---|---|
| Подтверждено | Загрузка новых вложений возвращает ошибки для части рабочих пространств в ЕС. | Записи ошибок шлюза и неуспешная проверочная загрузка из затронутого пространства; первое наблюдение в 10:05 UTC. |
| Подтверждено в ограниченном охвате | Скачивание существующих файлов прошло выполненные к этому моменту проверки. | Записанные результаты тестов; они не доказывают отсутствие влияния на каждое скачивание каждого клиента. |
| Неизвестно | Точное начало инцидента и общее число затронутых пространств. | Операционная команда проверяет более ранние записи и охват неуспешных запросов. |
| Гипотеза | Возможно влияние изменения маршрутизации. | Команда сервиса сопоставляет журнал изменений с отказами. Совпадение времени не устанавливает причину. |
| Неизвестно | Все ли загрузки с тайм-аутом завершились неудачей до сохранения вложения. | Нужно сопоставить исходы запросов. Не сообщайте клиентам, что данные не потеряны или что ничего не сохранилось. |
Разделяйте точное начало и первое наблюдение. Здесь обоснованно сказать: «Мы впервые наблюдали ошибки в 10:05». Но не: «Инцидент начался в 10:05». Это различие избавляет от необходимости исправлять уверенное утверждение, если в логах найдутся более ранние ошибки.
Презентация — датированный снимок журнала, а не конкурирующий источник фактов. На внутреннем брифинге укажите «По состоянию на 10:18 UTC». Если его перешлют через час, возраст информации должен быть очевиден.
Давайте каждой аудитории пригодную для неё информацию
Руководство Google по реагированию на инциденты разделяет управление, операционную работу и коммуникации. Оно также учитывает разные потребности клиентов, поддержки, инженеров и руководителей. Меняйте с учётом этого акценты, но не факты.
| Аудитория | Основной вопрос | Содержание сообщения |
|---|---|---|
| Клиенты | Могу ли я выполнить задачу и что делать? | Затронутая функция и охват, подтверждённое действие или обходной путь, состояние, время следующего сообщения. |
| Поддержка | Как отвечать согласованно и передавать полезные сведения? | Согласованная публичная формулировка, признаки проблемы, недопустимые обещания и запрашиваемые диагностические сведения. |
| Участники реагирования | Что известно, что проверяется и кто этим занимается? | Доказательства, гипотезы, действия, ответственные, зависимости и нерешённые технические вопросы. |
| Руководители | Каковы последствия и требуется ли моё решение? | Известное влияние на клиентов, неизвестный масштаб, ответственность за реагирование, решения по ресурсам и сообщениям, следующий брифинг. |
Клиентскому сообщению обычно не нужна теория о маршрутизации, а команде реагирования нужна. Руководству важно знать, что число затронутых пространств ещё выясняется, а не получить приблизительную догадку, которая после пересылки слайда превратится в официальную цифру.
Вот краткое внутреннее сообщение руководителям для того же вымышленного брифинга на 10:18:
Новые вложения не загружаются в части рабочих пространств нашего региона ЕС. Число затронутых пространств и точное начало пока не подтверждены. Команда сервиса исследует проблему; руководитель инцидента отвечает за решения по реагированию, а ответственный за коммуникации координирует сообщения клиентам и поддержке. Срок восстановления для внешнего сообщения не согласован. Следующее клиентское обновление должно выйти до 10:30 UTC. Дополнительного решения руководства сейчас не требуется.
Для поддержки добавьте отдельную инструкцию: запросить через обычный канал поддержки идентификатор пространства, примерное время UTC и видимое сообщение об ошибке. Не просите публиковать частные файлы или учётные данные на открытой странице состояния. Если подтверждённого обходного пути нет, скажите это вместо предложения непроверенных действий.
Покажите отдельно события инцидента и события коммуникации
Операционное действие и сообщение о нём — разные записи. Применение меры в 10:42 не означает, что клиентов уведомили в 10:42 или что восстановление уже проверили. Включите в хронологию оба типа событий.
| Время | Тип события | Содержание записи |
|---|---|---|
| 10:05 | Наблюдение | Впервые замечены ошибки загрузки. Точное начало неизвестно. |
| 10:12 | Реагирование | Объявлен инцидент; назначены руководитель и ответственный за коммуникации. |
| 10:15 | Публичное сообщение | Подтверждено начало расследования; следующее сообщение обещано до 10:30. |
| 10:30 | Публичное сообщение | Восстановление не подтверждено, расследование продолжается; следующее сообщение до 10:50. |
| 10:42 | Реагирование | Применена мера смягчения. Её эффект ещё нужно проверить. |
| 10:50 | Публичное сообщение | Последние проверки показывают улучшение; идёт наблюдение; следующее сообщение до 11:15. |
| 11:15 | Публичное сообщение | После согласованных проверок объявлена восстановленная доступность загрузки. Поддержка остаётся доступна для нерешённых клиентских проблем. |
Эти интервалы — примеры, не универсальная политика. Выберите частоту, которую команда действительно выдержит, и сокращайте интервалы, если того требует ситуация. О существенном изменении сообщайте раньше обещанного времени.
Обещание обновления — не обещание исправления. Пишите «следующее сообщение до 10:50 UTC», а не «восстановим к 10:50», если для второго нет обоснования и согласования. Обязанность обновить информацию остаётся, даже когда расследование не дало нового вывода.
Пишите сообщения, сохраняющие точность при изменении ситуации
Первое уведомление фиксирует проблему публично. Следующие примеры показывают развитие того же вымышленного инцидента, не превращая предварительные данные в уверенность.
10:30: расследование продолжается
10:30 UTC — Расследование продолжается
Продолжаем исследовать ошибки загрузки вложений в части рабочих пространств нашего региона ЕС. Подтверждённого времени восстановления и проверенного обходного решения пока нет. Следующее сообщение опубликуем до 10:50 UTC.
Это полезно, даже если исправление ещё не объявлено. Сообщение подтверждает, что работа продолжается, и не позволяет молча пропустить обещанное время. Не заполняйте текст фразами «наши инженеры трудятся не покладая рук» и не повторяйте непроверенную причину.
10:50: улучшение проверяется
10:50 UTC — Наблюдаем за восстановлением
Мы применили меру смягчения, и последние проверки показывают, что вложения снова успешно загружаются в затронутом регионе. Прежде чем объявить восстановление, продолжаем наблюдать за результатами загрузки. Если ошибка сохраняется, сообщите поддержке идентификатор рабочего пространства и примерное время. Обновим эту страницу до 11:15 UTC.
«Проверки показывают улучшение» — более узкое утверждение, чем «у всех всё работает». Сохраняйте эту границу. Нормализовавшийся график сам по себе не определяет исход прежних попыток и не доказывает восстановление каждого клиентского сценария.
11:15: назовите восстановленную функцию
11:15 UTC — Доступность загрузки вложений восстановлена
Загрузка вложений в затронутом регионе работает штатно. На протяжении периода наблюдения её результаты оставались в нормальном для сервиса диапазоне, согласованные проверки загрузки пройдены. Если прежняя попытка вернула ошибку или её исход непонятен, проверьте список вложений перед повторной отправкой. Если проблема остаётся, обратитесь в поддержку.
Последнее сообщение предполагает, что вымышленная команда завершила указанные проверки и подтвердила применимость клиентской инструкции. Не копируйте его в реальный инцидент до появления таких данных. Оно не объявляет причину, не подсчитывает всех затронутых клиентов и не делает общего заявления об отсутствии потери данных.
Для собственных сообщений замените функцию, охват, наблюдаемый симптом, доказанное состояние, действие клиента и время следующего обновления. Именно эти поля несут смысл. Сменить только название сервиса, оставив необоснованное утверждение о восстановлении, — не безопасная адаптация.
Сделайте согласование и следующую публикацию видимыми
Ответственному за коммуникации нужен не только готовый абзац. В брифинге должно быть видно, кто подтверждает технические факты, кто утверждает публичную формулировку и кто публикует её через разрешённый канал. Используйте реальные роли реагирования; не считайте автора слайдов автоматически уполномоченным объявить восстановление.
Для вымышленного сервиса может хватить пяти слайдов:
- Текущее состояние: затронутая функция и регион, время снимка и действующий руководитель инцидента.
- Последствия и неопределённость: подтверждённое, неизвестное и источник каждого важного утверждения.
- Реагирование: текущие действия и необходимые решения без выдачи непроверенной гипотезы за причину.
- Коммуникации: утверждённое сообщение клиентам, заметка для поддержки, ответственный за публикацию и следующее время обновления.
- Доказательства восстановления: проверки перехода от расследования к наблюдению или восстановлению и их реальные результаты, когда они появятся.
Явно разделяйте черновую и отправленную формулировки. Записывайте версию, время согласования, время и место публикации. Если команда сузила охват с «региона ЕС» до определённых пространств, обновите общий фактический журнал и последующие сообщения вместе, не оставляя в обороте противоречащие друг другу слайды.
Руководство Google по управлению инцидентами подчёркивает важность актуального рабочего журнала и явной передачи ответственности. Для этой презентации практический вывод прост: её владелец и время должны оставаться видимыми, особенно при смене команды.
Отделите восстановление сервиса от последующего объяснения
При восстановлении сообщайте, какая функция снова работает и что ещё нужно сделать клиентам. Не ждите полного анализа причин, чтобы признать восстановление. Но и не прячьте продолжающиеся клиентские последствия за меткой «решено» только потому, что улучшилась одна системная метрика.
После инцидента можно исследовать сопутствующие факторы и долгосрочные изменения в презентации разбора инцидента. Это другой результат работы. Оперативному брифингу не нужна выдуманная история первопричины ради завершённого повествования.
Если ответственный за коммуникации передаёт работу до разрешения инцидента, оставьте пригодную запись. Вот вымышленная передача в 10:35 UTC, между сообщениями о расследовании и наблюдении:
Передача коммуникаций — 10:35 UTC
Текущий публичный статус: исследуем ошибки загрузки вложений в части пространств региона ЕС. Последнее сообщение: версия 2, опубликована в 10:30 UTC. Следующее публичное сообщение: до 10:50 UTC, включая уведомление без изменений, если восстановление не подтверждено. Новый ответственный за коммуникации подтвердил, что принимает эту роль. Руководитель инцидента подтверждает операционное состояние; ответственный за коммуникации публикует согласованный текст. Время восстановления, точное начало и число затронутых пространств неизвестны. Общий журнал содержит последние доказательства и сообщение для поддержки.
Теперь новый владелец может отправить следующее точное обновление, не восстанавливая ход событий по чату и не угадывая, какой слайд актуален.
