Postmortem сбоя сайта: как разобрать причины и не повторить инцидент
Postmortem сбоя сайта — это разбор уже восстановленного инцидента: что произошло, кого затронуло, какие условия позволили проблеме возникнуть и что команда изменит. Его практический результат — проверяемые меры, которые уменьшают вероятность похожего отказа, ограничивают его последствия или помогают раньше его обнаружить.
Формулировка «сайт упал после обновления, разработчик исправил» для этого недостаточна. Она не объясняет механизм отказа, границы влияния и причины, по которым существующие проверки пропустили проблему. Через несколько недель такая запись мало поможет следующему специалисту.
Ниже — структура постмортема, пример инцидента и таблица мер с критериями приёмки. Учебный сценарий полностью вымышлен: числа, времена и названия версий показывают способ рассуждения, а не описывают реального клиента или статистику SiteGuard.
Когда проводить разбор и что должно получиться
Согласуйте, какие события требуют постмортема. Для небольшого сайта это могут быть нарушение ключевого действия, повторяющаяся неисправность, потеря результатов обработки или сбой, который обнаружили пользователи при молчащем мониторинге. Масштаб документа выбирайте по сложности и последствиям, а не по стремлению заполнить одинаковое число страниц.
В главе Google SRE о культуре постмортемов разбор связывается с документированием влияния, пониманием причин и последующими улучшениями. Это работа после восстановления, когда уже можно спокойно сопоставить свидетельства и проверить предположения. Текущее устранение продолжающегося сбоя остаётся приоритетом.
Назначьте одного владельца документа и участников, которые знают затронутые компоненты. Владелец собирает материал и доводит разбор до согласованного результата; ему необязательно лично выполнять все будущие изменения. У каждой меры затем появляется отдельный ответственный.
Хороший итог позволяет ответить на четыре вопроса: что подтверждено, что осталось неизвестным, какие изменения выбраны и как будет проверено их действие. Если команда только пересказала события, но не связала их с конкретными решениями, разбор ещё не завершил свою задачу.
Какие доказательства собрать до выводов
Начните с журнала инцидента, версий приложения и конфигурации, результатов проверок, технических событий и статусов бизнес-операций. Для каждого существенного утверждения укажите источник и период, к которому он относится. Ссылка на общий график без временного диапазона часто не позволяет воспроизвести вывод.
Процесс постмортема PagerDuty предусматривает восстановление хронологии с подтверждающими данными и ответственным за подготовку. Для своего проекта удобно завести короткий реестр: что наблюдали, откуда это известно и какие ограничения есть у источника.
| Источник | Что может подтвердить | Какое ограничение учитывать |
|---|---|---|
| История внешних проверок | Результат конкретного сценария в моменты запусков | Между проверками нет непрерывного наблюдения всех пользователей |
| Журнал развёртывания | Время применения определённой версии | Совпадение по времени ещё не доказывает причину |
| Журнал приложения | Обработанные запросы и записанные ошибки | Не показывает действия, которые не дошли до приложения |
| Состояния операций | Принятые, завершённые и незавершённые действия | Требуют проверки правил учёта и повторов |
| Сообщения участников | Какая информация была доступна при решении | Оценки и воспоминания могут быть неточными |
Сохраняйте достаточный контекст, но не переносите в общий документ секреты и полные пользовательские данные. Если техническое свидетельство доступно ограниченному кругу, оставьте понятное описание и ссылку для уполномоченных участников. Не заменяйте недоступный источник уверенной формулировкой без проверки.
Как восстановить хронологию и не придумать точное время
Приведите события к одному часовому поясу и разделите момент события, момент обнаружения и время записи в журнал. Сообщение «заметил в 14:05» не доказывает, что отказ начался именно тогда. Позднее поступление логов также может отличаться от фактического выполнения операции.
Для каждого пункта хронологии достаточно времени, события, источника и степени уверенности. Помечайте оценки прямо: «около 14:03 по воспоминанию участника» или «14:03:12 по журналу приложения». Если часы двух систем расходились, укажите поправку либо оставьте неопределённость вместо искусственной точности.
Предположим, внешняя проверка была успешной в 14:00, неуспешной в 14:02 и снова успешной в 14:10. Эти данные описывают наблюдения конкретной проверки. Они не устанавливают точные начало и конец влияния на всех посетителей, не исключают колебаний между запусками и ничего не доказывают о непроверенных маршрутах.
Поэтому вместо «сайт не работал ровно восемь минут» запишите последнее успешное наблюдение, первое обнаруженное нарушение и первое подтверждение восстановления. Отдельно укажите границы, установленные журналами и состояниями операций. Если точный интервал бизнес-влияния восстановить нельзя, так и напишите.
Как разделить триггер, механизм отказа и способствующие условия
Триггер запускает развитие инцидента: например, применение новой конфигурации. Механизм объясняет, как изменение нарушило действие пользователя. Способствующие условия показывают, почему проблема прошла существующие проверки, затронула заметную часть системы или затянулась.
Вместо общего «обновление сломало форму» можно проверить цепочку: новое правило требует поле, которое действующая форма не отправляет; сервер отклоняет обращения; проверка перед выпуском открывает страницу, но не отправляет допустимый набор данных. Здесь есть несколько разных мест для улучшения.
Проверяйте причинную связь доступным безопасным способом. Сопоставление конфигураций, воспроизведение на стенде и подтверждённое поведение конкретного запроса сильнее одной временной близости. Если после перезапуска всё заработало, это фиксирует восстановление после вмешательства. Чтобы связать результат именно с перезапуском и объяснить первоначальную причину, нужны дополнительные подтверждения: одновременно могла восстановиться внешняя зависимость.
Не заставляйте все события укладываться в одну «корневую причину». Отказ может требовать сочетания несовместимого изменения, пробела в тестировании и недостаточной видимости результата. При этом не включайте в список любую обнаруженную техническую задолженность: для каждого условия покажите связь с данным инцидентом.
Полезно проверить и альтернативное объяснение. Например, ошибка формы могла совпасть с отказом внешней интеграции. Сопоставьте место отклонения запроса: если валидация завершилась до обращения к партнёру, его состояние не объясняет этот конкретный отказ. Такое уточнение сужает вывод до подтверждённого механизма и не позволяет исправлять случайно оказавшийся рядом компонент.
Как разбирать действия без поиска виноватого
Постмортем должен объяснять, какие сведения были у человека в момент решения и какие ограничения влияли на выбор. После восстановления команда знает больше, поэтому оценивать прошлое действие только по окончательному результату несправедливо и мало полезно для проектирования защиты.
Вопросы для анализа PagerDuty помогают изучать доступные сигналы, ожидания и условия работы участников. Для своего обсуждения спросите: что считалось безопасным, какой результат ожидался и какого подтверждения не хватило. Это позволяет найти исправляемые пробелы в инструментах и процессе.
| Слабая формулировка | Что полезнее выяснить и записать |
|---|---|
| Разработчик невнимательно выпустил изменение | Какая проверка совместимости отсутствовала и почему выпуск прошёл принятую процедуру |
| Сотрудник слишком поздно отреагировал | Когда сигнал стал доступен, был ли понятен его приоритет и кто считался получателем |
| Нужно всем быть осторожнее | Какое конкретное ограничение или проверка остановит похожую ошибку |
Отказ от обвинений не отменяет ответственности за улучшения. Документ всё равно содержит владельцев задач, сроки и результат проверки. Разница в том, что будущая надёжность не сводится к обещанию человека никогда не ошибаться.
Как описать влияние на сайт и бизнес
Укажите затронутую функцию, известный охват и наблюдаемый результат: отклонённые отправки, задержанные операции, недоступные страницы. Разделяйте число запросов, технических операций и людей. Несколько повторов одного обращения нельзя автоматически считать несколькими потерянными клиентами.
Для каждого числа сохраните правило подсчёта. Например: «в выбранном интервале найдены 12 неуспешных запросов с девятью различными идентификаторами операции; внутренние контрольные запросы исключены». Такое описание проверяемо. Вывод «потеряно девять заказов» потребовал бы дополнительных данных о намерении пользователей и последующем результате.
Если часть обращений обработана позже, отметьте задержку отдельно от окончательной потери. Если аналитика перестала работать вместе с сайтом, отсутствие зарегистрированных событий не означает отсутствие попыток. Укажите неполноту данных и возможное направление ошибки оценки.
Финансовое влияние не следует угадывать по числу технических ошибок. Можно описать подтверждённые расходы или отдельно согласованную модель с допущениями, но её оценка не должна выглядеть как фактическая выручка, потерянная из-за каждого отказа. Для технического постмортема честные границы известного полезнее эффектной суммы.
Шаблон постмортема для сбоя сайта
Эта авторская заготовка подходит для внутреннего документа. Заполняйте её короткими связанными выводами, а подробные доказательства оставляйте по ссылкам. Если раздел не применим, объясните почему; если данных нет, пометьте пробел и решите, нужно ли отдельное исследование.
| Раздел | Содержание |
|---|---|
| Паспорт | Номер инцидента, дата, сайт, владелец разбора, участники, статус документа |
| Краткое описание | Какое действие было нарушено, как восстановлено и что установлено |
| Воздействие | Функции, операции, подтверждённые числа, метод подсчёта и ограничения |
| Хронология | Значимые события с часовым поясом, источниками и отметками неопределённости |
| Механизм отказа | Триггер, причинная последовательность, подтверждения и альтернативные объяснения |
| Способствующие условия | Пробелы, которые позволили проблеме возникнуть, распространиться или дольше сохраняться |
| Полезные действия | Что помогло ограничить влияние и какие подтверждения это показывают |
| Неизвестное | Открытые вопросы, значение для решений, владелец дополнительной проверки |
| Меры | Приоритет, конкретное изменение, ответственный, срок, задача и критерий приёмки |
| Проверка результата | Как воспроизвести контролируемые условия и подтвердить действие новой меры |
| Согласование | Кто проверил факты, какие разногласия остались, где отслеживаются последующие задачи |
Краткое описание пишите последним, когда проверены основная цепочка и влияние. Оно должно оставаться понятным владельцу сайта без чтения каждого журнала. Технические термины объясняйте ровно настолько, насколько нужно для оценки выбранных действий.
Учебный пример: несовместимое правило проверки формы
Представим сайт услуг, где поле «Компания» было необязательным. Новая серверная конфигурация стала требовать его заполнения, а действующая форма продолжала разрешать отправку без этого поля. После восстановления команда воспроизвела такое поведение на стенде и подготовила разбор. Все сведения этого примера заданы для иллюстрации.
| Время UTC | Наблюдение | Условное доказательство |
|---|---|---|
| 14:00 | Контрольная отправка формы успешна | Сохранённый результат проверки сценария |
| 14:01 | Применена конфигурация B | Журнал развёртывания и сохранённая версия |
| 14:02 | Контрольная отправка без поля «Компания» отклонена | Результат проверки и связанная запись приложения |
| 14:04 | Сравнение конфигураций выявило изменение обязательности поля | Сохранённые версии A и B; сформулирована проверяемая гипотеза |
| 14:09 | В рабочую среду возвращена конфигурация A | Журнал изменения |
| 14:10 | Контрольная отправка и сохранение результата подтверждены | Связанные результаты внешней и внутренней проверки |
| Следующий день, 09:00 | На стенде воспроизведено различие конфигураций A и B | Одинаковые тестовые данные, разные результаты валидации |
Подтверждённый механизм: в конфигурации B отсутствующее поле отклоняется, хотя интерфейс позволяет такую отправку. На стенде один и тот же допустимый для действующей формы набор принимается конфигурацией A и отклоняется B. Сравнение выполнено при одинаковых остальных условиях. Временная связь с выпуском дополняется воспроизведением, поэтому вывод не основан только на совпадении времени.
Способствующие условия: проверка перед выпуском открывала страницу, но не проверяла отправку без необязательного поля. Правило обязательности хранилось отдельно от описания интерфейса. Эти сведения подтверждены просмотром сценария проверки и конфигурации. Наличие отдельного файла само по себе не объявляется ошибкой: проблема в отсутствии проверки согласованности.
Воздействие: в учебном журнале найдены 12 неуспешных пользовательских запросов с девятью техническими идентификаторами операции. Контрольные запросы исключены. Из этих данных нельзя вывести число людей, отказавшихся от обращения, или точное количество потерянных продаж. Неизвестно также, сколько пользователей не отправляли форму после повторной ошибки.
Границы вывода: точные начало и конец бизнес-влияния не установлены. Есть дискретные контрольные результаты и записи дошедших до сервера запросов. Успех после возврата конфигурации подтверждает восстановление проверенного сценария, но сам по себе не доказывает исправность всех форм и вариантов данных.
Как превратить выводы в проверяемые меры
Каждая мера должна отвечать на конкретный обнаруженный пробел. «Улучшить тестирование» слишком широко: непонятно, что сделать и когда задача завершена. Лучше назвать сценарий, ожидаемое поведение и свидетельство, которое проверяющий сможет воспроизвести.
В практическом руководстве Google SRE по постмортемам отдельно рассматриваются определённые владельцы, приоритеты, отслеживание задач и проверяемый результат. Для учебного примера ниже роли обозначают будущих ответственных; в рабочем плане их заменяют конкретными людьми и согласованными датами.
| Мера | Ответственный | Критерий приёмки |
|---|---|---|
| Проверить совместимость формы и серверной валидации | Разработчик приложения | Набор с пустым необязательным полем принимается; действительно обязательное поле проверяется согласованно |
| Добавить сценарий отправки в проверку выпуска | Владелец релиза | Тест подтверждает приём и сохранение синтетического обращения; на несовместимой конфигурации он завершается ошибкой |
| Проверить сигнал о нарушении сценария | Ответственный за наблюдение | Контролируемый отказ на стенде приводит к ожидаемому сообщению; после восстановления результат меняется корректно |
| Уточнить судьбу затронутых операций | Владелец обработки заявок | По каждому известному ID зафиксировано доступное состояние; неизвестные результаты перечислены отдельно |
Укажите также приоритет, срок и ссылку на задачу. Не назначайте всем мерам одинаковую срочность автоматически. Сначала рассмотрите действия, которые закрывают подтверждённую причину повторения или существенно ограничивают влияние, затем — улучшения удобства диагностики.
Если выбран только дополнительный сигнал, честно опишите его эффект: он помогает обнаружить повторение, но не устраняет несовместимость. Обучение и документация тоже могут быть полезны, однако их результат лучше проверять практическим сценарием, чем фактом проведения встречи.
Для каждой задачи обозначьте зависимость от других изменений. Тест выпуска бесполезно объявлять завершённым, если он написан, но ещё не подключён к процедуре, по которой команда выпускает сайт. Приёмочный критерий в таком случае включает запуск в нужной среде и ожидаемую реакцию на неуспех. Срок должен относиться к этому законченному результату, а не только к созданию файла с тестом.
Как проверить результат и не закрыть задачи формально
После внесения изменения воспроизведите контролируемые условия, которые раньше приводили к отказу. Для примера с формой проверьте допустимые данные, нарушение обязательного поля и несовместимую тестовую конфигурацию. Приёмка должна показать не только успешный случай, но и способность проверки заметить возвращение дефекта.
Сохраните версию, условия запуска и наблюдаемый результат. Изменение кода, новая инструкция или отметка «готово» не заменяют доказательство поведения. Если результат проверяется в несколько этапов, зафиксируйте, какие завершены, а какие ещё ожидаются.
Не каждую меру можно доказать одним тестом. Для организационного изменения проведите упражнение с человеком, который не составлял инструкцию. Для нового контроля убедитесь, что сигнал понятен получателю. Для ограничения масштаба проверьте границу его применения. Способ приёмки выбирайте по заявленному эффекту.
Период без новых инцидентов полезен как наблюдение, но сам по себе не доказывает устранение причины: похожие условия могли не повториться. Поэтому сочетайте проверку механизма с последующим наблюдением, а не заменяйте одно другим.
Кто проверяет постмортем и когда работа считается завершённой
Попросите участников проверить факты о своих компонентах, а владельца процесса — влияние и критерии результата. Разногласия разрешайте через данные; если подтверждений пока нет, оставьте вопрос открытым с понятным следующим шагом. Согласование не должно превращать гипотезу в факт только ради завершения документа.
Статус разбора и статус мер ведите отдельно. Документ может быть согласован, пока отдельные улучшения ещё выполняются. Ответственный за последующие задачи должен видеть просроченные действия, отклонённые меры и основания принятого риска, а не только число закрытых постмортемов.
Назначьте конкретную точку повторной проверки плана: например, согласованную дату или ближайший выпуск затронутой функции. Это выбор команды, а не обязательный универсальный интервал. На такой проверке достаточно выяснить, какие критерии приёмки выполнены, где появилось препятствие и кто принимает решение о переносе или изменении меры.
Если похожий сбой повторился, сопоставьте механизмы и условия с предыдущим разбором. Возможно, мера не была внедрена, проверяла слишком узкий сценарий или работала только для другой конфигурации. Это повод уточнить защиту и её границы, а не механически переписать прежний отчёт.
Как подготовить данные для следующего разбора
Сохраняйте результаты важных проверок, версии изменений и состояния ключевых операций так, чтобы их можно было сопоставить по времени. Внешнее наблюдение помогает установить, когда конкретный сценарий был проверен успешно или неуспешно; внутренние данные дополняют картину фактического воздействия.
Подключите внешнее наблюдение за HTTP-доступностью важных страниц через SiteGuard. Используйте подтверждённые результаты вместе с журналами приложения для следующего разбора.