Как проверить postmortem, подготовленный LLM. Разбираем инцидент Cloudflare

«Все сервисы восстановили в 14:30» выглядит как обычная строка хронологии. Но для инцидента Cloudflare, который мы разберём ниже, она неверна: к этому времени в значительной степени восстановился основной трафик, а полное восстановление наступило позже.

Такое сокращение меняет оценку последствий сбоя. Команда рискует пропустить часть проблем и меры, которые помогли бы их устранить.

Если вы поручаете большой языковой модели, LLM, подготовить postmortem, письменный разбор причин и последствий сбоя, результату нужна содержательная проверка.

Разберём её на материале публичного отчёта Cloudflare об инциденте 18 ноября 2025 года. Спорные формулировки в статье, включая первую, составлены для иллюстрации ошибок.

Результаты конкретной модели здесь не оцениваются.

Цель проверки состоит в том, чтобы подготовить к ретроспективе подтверждённые сведения, вопросы участникам и обоснованные предложения.

На встрече команда сможет обсудить причины сбоя и решить, что изменить.

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

Сначала проверьте, что именно сломалось

Изменение прав в ClickHouse расширило видимость метаданных.

Запрос без фильтра по имени базы вернул лишние записи. На его основе сформировали конфигурацию Bot Management, системы распознавания автоматизированного трафика.

Число признаков для оценки запросов превысило лимит модуля.

Необработанная ошибка в прокси FL2 приводила к серверным ошибкам HTTP 5xx.

Механизм описан в разделах The query behaviour change и Memory preallocation.

Если сократить объяснение до «сбой произошёл из‑за изменения прав», последовательность станет менее полезной.

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

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

Проверьте основание каждой связи в этой последовательности.

Близость событий по времени сама по себе не доказывает, что одно вызвало другое.

При этом техническое объяснение не даёт права дописывать организационные причины.

Из него не следует, что инженер проигнорировал регламент или команда отказалась от тестирования ради скорости.

Если в отчёте не описаны проверки перед изменением, пока известно только отсутствие этих сведений в доступном тексте.

Практическое различие здесь существенное.

• Если нужной проверки не существовало, обсуждаем её добавление.

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

• Если проверка выполнялась и дала неверный результат, исследуем её ограничения.

Формулировка «усилить тестирование» объединяет три разные задачи, для которых нужны разные исполнители и оценки.

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

В хронологии важно сохранить смысл отметок

В отчёте Cloudflare есть четыре отметки, различия между которыми важно сохранить. Время указано в UTC.

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

С восстановлением другая ситуация: записи описывают разные состояния системы. Поэтому фразу «все сервисы восстановили в 14:30» следует исправить, а не считать допустимым сокращением. Она меняет смысл события.

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

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

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

Проверьте, что рекомендация подходит к описанной системе

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

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

Проверьте, какую зависимость между компонентами предполагает рекомендация и подтверждена ли она. Если зависимость придумана, полезность самой практики не спасает предложение.

Зная итоговую причину, легко написать, что команда слишком долго проверяла неверную версию.

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

В практике Etsy John Allspaw предлагает выяснять, что инженеры наблюдали, чего ожидали и из каких предположений исходили.

Это основа blameless‑разбора: внимание направлено на условия принятия решений и работу системы, без обвинений участников.

Полезный черновик подсказывает вопросы для встречи:

• Какие наблюдения поддерживали версию, а какие ей противоречили?

• Что проверялось параллельно?

• Какое свидетельство изменило направление работы?

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

Проверять нужно и сами вопросы.

Фраза «почему дежурный проигнорировал сигнал?» уже предполагает, что сигнал был доступен, понятен и сознательно оставлен без внимания.

Сначала следует выяснить, что дежурный действительно видел.

Иначе неподтверждённое объяснение попадёт в обсуждение в форме вопроса.

Превратите предложение в проверяемую задачу

Для каждой меры нужно установить, что она меняет:

• вероятность ошибки;

• масштаб её распространения;

• время восстановления.

От этого зависит приоритет работы.

Возьмём предложение «добавить откат конфигурации».

Что произойдёт после возврата рабочей версии, если автоматический процесс снова пришлёт некорректное обновление?

У Cloudflare конфигурация формировалась регулярно; восстановление включало остановку генерации и распространения плохого файла.

Описание восстановления.

Для аналогичной системы можно предложить требование:

некорректное обновление не заменяет последнюю подтверждённую конфигурацию и не нарушает обслуживание запросов.

Это наш вариант для обсуждения, а не описание внутреннего плана Cloudflare.

Черновик задачи можно дополнить сценарием приёмки:

Активна подтверждённая конфигурация A.
Приходит конфигурация B с числом признаков выше лимита.

B отклонена. Активной остаётся A.
Причина отказа и версия B доступны дежурному.
Ошибки и задержки запросов остаются в согласованных пределах.

Повторная доставка B не меняет активную версию.
Следующая корректная конфигурация C успешно применяется.

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

Нужно также определить, где выполняется проверка. Контроль перед публикацией конфигурации и защита принимающего компонента закрывают разные места отказа.

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

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

Автоматическое переключение на предыдущую версию без этого решения ещё не составляет законченной политики восстановления.

В SRE Workbook для последующих задач рекомендуют указывать владельца, приоритет и проверяемое конечное состояние. К назначению исполнителя стоит переходить, когда понятны цель и ограничения изменения.

Что должно остаться после проверки черновика

Задайте структуру результата до обращения к LLM. Передайте сами материалы и попросите привязывать существенные утверждения к сообщению, фрагменту лога, графику или разделу документа. Общая ссылка на длинный отчёт затрудняет проверку.

Для подготовки черновика подойдёт такой запрос:

Подготовь материалы к ретроспективе по приложенным источникам.

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

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

Этот запрос задаёт форму работы, но проверка всё равно требует открыть источники.

Особенно внимательно стоит читать связки:

• «из‑за»;

• «поэтому»;

• «это привело к».

Именно в них отдельные наблюдения превращаются в объяснение.

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

После чтения у утверждений и предложений должен появиться понятный статус.

Критерий готовности такого черновика прост:

участники видят, на чём основаны выводы и что ещё предстоит выяснить.

Гипотеза становится задачей на сбор данных, подтверждённый риск позволяет обсуждать исправление.

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

LLM помогает ускорить подготовку postmortem, но без проверки фактов и гипотез легко принять красивое объяснение за реальную причину сбоя.

На открытых уроках разберём, как анализировать production‑инциденты, находить причины проблем и использовать инструменты для повышения надёжности систем.

• 23 сентября в 20:00. «eBPF: рентгеновское зрение для production». Записаться.

• 20 октября в 20:00. «OpenTelemetry в.NET: от чёрного ящика к наблюдаемой системе». Записаться.

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