Презентация по итогам инцидента должна объяснить, с чем столкнулись пользователи, как команда восстановила работу сервиса, что известно о сбое и какие изменения стоит обсудить. Для этого не нужно пересказывать всю переписку из канала дежурной команды. И не стоит превращать непроверенную версию причины в установленный факт только потому, что так получается стройный рассказ.
Начните с проверенного отчёта об инциденте. На слайдах важно сохранить различия: затронутые задания и затронутые пользователи, восстановление обработки и разбор накопившейся очереди, наблюдение и объяснение. На примере ниже видно, как эти различия влияют на содержание презентации.
Определите, какой вопрос должен решить разбор
До подготовки слайдов сформулируйте вопрос встречи. Для команды сервиса это может быть: «Достаточно ли мы понимаем сбой, чтобы возобновить выпуск этой версии, и какие работы нужно выполнить в первую очередь?» На встрече с клиентами, возможно, потребуется объяснить последствия и порядок дальнейшего информирования. Используйте версию материалов, согласованную для конкретной аудитории.
В руководстве Google по SRE на английском языке разбор инцидента описывается как документирование последствий, мер по их снижению, причин и дальнейших действий. Внимание уделяется условиям, в которых люди принимали решения, а не поиску виноватого. Это полезная основа для презентации: сначала соберите факты, затем объясните их. Слайды не заменяют расследование.
Если нужно сообщить об обычном ходе работы, подойдёт структура еженедельного отчёта — руководство на английском. Общий статус проекта внутри разбора инцидента может заслонить вопросы, на которые пока нет ответа.
Пример: генерация отчётов остановилась, затем очередь была обработана
Рассмотрим вымышленный сервис, который готовит отчёты для скачивания. Все события происходят в одну дату; время указано в UTC.
| Время | Что установлено по записям | Какой источник сохранить при реальном разборе |
|---|---|---|
| 09:00 | Начинается развёртывание новой версии. В 09:00 также появляются первые зарегистрированные ошибки заданий на генерацию отчётов. | Журнал развёртывания и логи заданий с указанием точности часов. |
| 09:04 | Оповещение сообщает дежурной команде об ошибках заданий. | Событие срабатывания и запись о доставке оповещения. |
| 09:12 | Команда начинает откат версии. | Журнал инцидента и запись об откате. |
| 09:27 | Мониторинг показывает, что вновь поступающие задания снова выполняются нормально. | Проверка восстановления и период наблюдения. |
| 10:00 | По результатам сверки все 180 выявленных затронутых заданий отмечены как завершённые. | Сверка на уровне отдельных заданий с учётом повторных запусков. |
В сопроводительных записях говорится, что во время сбоя обработчики фиксировали неизвестное значение статуса. Пока не установлено, какой компонент его передал и почему проверки перед выпуском не выявили проблему. В отчёте есть 180 уникальных идентификаторов заданий, но нет подтверждённого числа разных клиентов и расчёта коммерческих потерь.
Этого достаточно для содержательного разбора без выдуманных подробностей. Сохраните ссылки на логи, но не переносите на экран конфиденциальное содержимое запросов, токены доступа и данные клиентов.
Разделите восстановление обработки и завершение очереди
Можно было бы начать со слов: «27-минутный простой затронул 180 клиентов». Но обе части этой фразы требуют исправления. В примере зафиксированы ошибки заданий на генерацию отчётов, а не полный простой сервиса. И посчитаны задания, а не люди: один клиент мог отправить несколько запросов.
Точнее будет так: «Ошибки генерации отчётов наблюдались в течение 27 минут; к 10:00 сверка подтвердила завершение 180 выявленных затронутых заданий». Ниже покажите два интервала:
- 09:00–09:27: от первой зарегистрированной ошибки до нормального выполнения новых заданий.
- 09:27–10:00: ещё 33 минуты до завершения сверки затронутых заданий.
Второй интервал важен для человека, который всё ещё ждёт отчёт, хотя новые запросы уже обрабатываются. Нельзя приписывать каждому заданию часовую задержку: для такого расчёта нужны индивидуальные времена поступления и завершения. Кроме того, статус «завершено» сам по себе не доказывает правильность содержимого отчёта или отсутствие потери данных.
На слайде используйте горизонтальную шкалу времени с отдельными отметками восстановления и завершения очереди. Рядом с осью укажите часовой пояс. Если в реальном инциденте время первой ошибки известно лишь приблизительно, отразите эту неопределённость, а не подставляйте удобное время начала развёртывания.
Постройте разбор из семи слайдов вокруг подтверждённых данных
Для этого примера семь слайдов — подходящая отправная точка. При простом наборе фактов их может быть меньше; для спорного вопроса можно добавить подробные материалы.
- Что произошло и что требует внимания. Укажите установленные границы последствий, текущее состояние сервиса и нерешённый вопрос о выпуске версии.
- Кого или что затронул сбой. Покажите 180 отдельных заданий, затронутый процесс и отсутствие проверенного числа клиентов. Не заменяйте неизвестное правдоподобной оценкой.
- Как развивался инцидент. Покажите пять временных отметок, не смешивая оповещение, откат, восстановление новых заданий и завершение очереди.
- Что уже объясняют данные. Поместите наблюдение о неизвестном статусе рядом с вопросом расследования. Последовательность отката важна, но сама по себе не раскрывает весь механизм сбоя.
- Что помогало и что задерживало ответ. Обсудите конкретную информацию, инструменты и проблемы координации, подтверждённые записями. Не добавляйте выдуманные «уроки» ради симметричного слайда.
- Какие изменения предложены. Отделите предотвращение сбоя от улучшения реакции, укажите ответственного и способ проверки выполнения.
- Что участникам нужно решить. Согласуйте приоритеты, недостающие доказательства и условия повторного рассмотрения выпуска.
Подробные логи, условия тестов и правила сверки оставьте в приложении. Краткое резюме для руководителей — руководство на английском поможет более широкой аудитории сориентироваться, но и в нём нужно различать восстановленную обработку и последствия, которые пользователи продолжали испытывать.
Объясняйте причину, не выдавая гипотезу за результат расследования
Фраза «кто-то выкатил неудачное изменение» не поможет следующему инженеру распознать или предотвратить сбой. Она обходит вопросы примера: какие версии производителя заданий и обработчиков работали, какие статусы они понимали и что именно проверялось перед выпуском.
Разделите слайд на три части: наблюдение, предполагаемое объяснение и недостающие доказательства. Здесь наблюдение — ошибка неизвестного статуса. Возможная несовместимость остаётся гипотезой, пока её не подтверждают сведения о версиях и воспроизведение проблемы. Полезный следующий шаг — сравнить версии и повторить ошибочный сценарий в подходящей тестовой среде.
Если два источника указывают разное время, сохраните обе записи до выяснения расхождения. Если участник оспаривает причину, сузьте формулировку заголовка до установленных фактов. Встреча может закончиться решением продолжить расследование; законченная история о причине не является обязательным условием полезного разбора.
Замените «быть внимательнее» конкретными предложениями
Для вымышленного инцидента можно обсудить следующие действия. Это ещё не выполненные исправления и не принятые обязательства:
| Предлагаемое изменение | На какой вопрос отвечает | Как проверить выполнение |
|---|---|---|
| Добавить проверку совместимости затронутых версий производителя заданий и обработчика. | Может ли процесс выпуска выявить этот сбой до развёртывания? | Документированный тест воспроизводит отклонение статуса на проблемном сочетании версий и фиксирует ожидаемое поведение на исправленном. |
| Добавить в регламент инцидента раздел о восстановлении и завершении очереди. | Различает ли команда восстановленную обработку новых заданий и ещё не завершённые затронутые задания? | Проверенный регламент и учебный прогон с отдельной фиксацией восстановления, сверки и нерешённых заданий. |
Попросите ответственные команды согласовать исполнителей, приоритет и сроки. Не назначайте инженера владельцем задачи только потому, что он первым отреагировал. Не обещайте «такое больше никогда не повторится»: ни тест, ни регламент этого не доказывают. Объясните, какой конкретный сбой или задержку должно уменьшить каждое действие.
Подготовьте черновик в Presenti по проверенному отчёту
Составьте краткий документ без конфиденциальных данных: границы последствий, хронология, ссылки на источники, установленные факты, открытые вопросы и предложенные действия. В Presenti можно подготовить презентацию по тексту, используя этот документ для последовательности из семи слайдов. Попросите сохранить отдельные отметки 09:27 и 10:00 и не заполнять неизвестное число клиентов.
Проверьте структуру до выбора оформления. Если черновик заменил «возможную несовместимость» на «подтверждённую первопричину», исправьте это до дальнейшего оформления. В редактируемой презентации оставьте место для читаемых подписей на шкале времени, а способ проверки действия разместите рядом с самим предложением. Presenti помогает организовать объяснение, но не проверяет достоверность логов и не определяет безопасность выпуска.
Скачайте рабочий документ и план семи слайдов или используйте такую инструкцию:
Подготовь черновик разбора инцидента по предоставленному отчёту. Раздели последствия, обнаружение, откат, восстановление новых заданий и сверку затронутых заданий. Отделяй наблюдения от гипотез. Сохрани неизвестные данные, ссылки на источники и часовые пояса. Не придумывай число затронутых клиентов, финансовые потери, причины, согласованных исполнителей или выполненные действия.
В конце встречи запишите, о чём действительно договорились и какие доказательства ещё нужны. Именно эти пункты перенесите в следующий разбор. Полезный результат — более точное понимание инцидента и обоснованный выбор дальнейших изменений, а не слайд с обещанием, что повторение невозможно.
