Главная › Блог › Blameless postmortem для веб-студии: разбор сбоя без поиска виноватого

Blameless postmortem для веб-студии: разбор сбоя без поиска виноватого

4 августа 2026 · 17 мин чтения

Blameless postmortem — это структурированный разбор инцидента, который изучает факты, решения и условия работы системы без персонального обвинения участников.

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

Для небольшой веб-студии postmortem не должен становиться трёхчасовым корпоративным ритуалом. Обычно достаточно 45–60 минут, одного владельца документа и трёх–семи проверяемых действий.

Коротко

Рабочий порядок:

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

Postmortem без действий — архив воспоминаний. Действия без владельцев — пожелания.

Blameless не означает «без ответственности»

Подход строится на исходном предположении:

Участники действовали добросовестно, исходя из информации, инструментов, ограничений и приоритетов, доступных им в тот момент.

Это не значит:

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

Наоборот, blameless-среда позволяет честно сказать:

Я увидел зелёный результат deploy и решил, что форма проверена. В инструкции не было доставки тестового письма, а мониторинг смотрел только HTTP-ответ.

Персональное обвинение обычно заканчивается советом «в следующий раз быть внимательнее». Системный разбор добавляет конкретный автоматический тест, стоп-условие и владельца.

Когда небольшой студии нужен полный разбор

Определите критерии заранее. Например, postmortem обязателен, если:

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

Для небольшого P2/P3 используйте облегчённую карточку из пяти вопросов:

Что произошло?
Как обнаружили?
Что восстановило функцию?
Почему существующие проверки не предотвратили или не заметили событие?
Нужно ли одно корректирующее действие?

Так дисциплина сохраняется без бюрократии.

Когда проводить

Не начинайте глубокий разбор, пока команда ещё восстанавливает сервис. Сначала пользовательская функция и безопасность.

Практичный ритм:

черновая хронология — во время инцидента;
владелец postmortem — при закрытии P1;
факты и вопросы — в течение следующего рабочего дня;
встреча — через 1–3 рабочих дня;
финальная версия и задачи — не позднее согласованного срока;
проверка действий — еженедельно до закрытия.

Не откладывайте на месяц: исчезает контекст, а временная мера становится постоянной.

Кто участвует

Для студии из 3–20 человек достаточно:

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

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

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

Что собрать до встречи

Владелец готовит пакет:

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

Автоматически переносите из карточки инцидента:

уровень;
роли;
время обнаружения и реакции;
начало и конец влияния;
ключевые изменения;
ссылки на проверки;
сообщения статус-страницы.

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

Правила встречи

Фасилитатор начинает с короткого соглашения:

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

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

Дополнительные правила:

один разговор одновременно;
утверждение отделяется от гипотезы;
время и данные имеют источник;
участник может исправить описание своего решения;
неизвестное разрешено оставлять неизвестным;
security- и персональные детали обсуждаются только в подходящем составе;
кадровые вопросы не решаются внутри технического postmortem.

Повестка на 60 минут

Время	Этап	Результат
0–5 минут	Цель и правила	Общая рамка
5–15 минут	Влияние и резюме	Что испытал пользователь
15–30 минут	Хронология	Согласованная последовательность
30–42 минуты	Причины и факторы	Модель, а не виновный
42–50 минут	Что сработало / мешало / где повезло	Сильные и слабые барьеры
50–58 минут	Действия	3–7 владельцев и сроков
58–60 минут	Подтверждение	Кто заканчивает документ и когда

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

Начинайте с влияния

Причина интересна инженеру, влияние — общее основание решения.

Зафиксируйте:

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

Плохая формулировка:

Сервер упал из-за Redis.

Полезная:

С 12:10 до 12:47 новые пользователи не могли завершить вход; существующие сессии продолжали работать. Проблема затронула веб-версию, мобильный API не проверялся. Временного пользовательского обхода не было.

Восстановите контекст решений

В хронологии важны не только действия, но и информация на тот момент.

Вместо:

12:22 — инженер сделал неправильный рестарт.

Запишите:

12:22 — при графике доступности 40 % и отсутствии метрики очереди инженер перезапустил два процесса, ожидая снять зависшие соединения. Runbook не описывал риск одновременного рестарта.

Потом можно спросить:

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

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

Триггер, непосредственная причина и системные факторы

Триггер

Событие, которое активировало проблему:

релиз;
изменение конфигурации;
рост нагрузки;
истечение сертификата или секрета;
изменение внешнего API;
необычные входные данные;
отказ узла.

Непосредственная причина

Механизм пользовательского сбоя:

процесс исчерпал соединения;
запрос попал в несовместимую схему базы;
форма не прошла SMTP-аутентификацию;
заказ не сопоставился с товаром в 1С;
кеш отдал старый JavaScript;
DNS указывал на неверную систему.

Системные факторы

Условия, позволившие триггеру стать инцидентом:

изменение прошло без canary;
не было проверки бизнес-пути;
rollback зависел от недоступного сотрудника;
предупреждение пришло только в один канал;
документация не описывала зависимость;
срок секрета не имел владельца;
порог алерта не соответствовал влиянию;
права позволяли выполнить опасное действие без второй проверки;
резервная копия не проходила тест восстановления.

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

Как использовать «Пять почему» без упрощения

Техника помогает пройти от симптома к системе, но не является математическим алгоритмом.

Пример:

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

Здесь возможны две ветки действий:

синхронизировать изменение секрета;
контролировать доставку результата.

Не задавайте «почему» до обвинительной формулировки «потому что сотрудник невнимателен». Спросите, почему процесс зависел от памяти и как убрать эту зависимость.

Три вопроса, которые дают хорошие действия

Что сработало хорошо?

Примеры:

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

Сильные элементы нужно сохранить, а не обсуждать только провал.

Что могло сработать лучше?

алерт не содержал конечный URL;
никто не был владельцем коммуникации;
доступ к хостингу нашли через 20 минут;
журнал не связывал событие с релизом;
ручной обход не был проверен.

Где нам повезло?

Этот вопрос обнаруживает риск, который не отражён в фактическом ущербе:

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

«Повезло» часто даёт самые ценные превентивные задачи.

Четыре типа действий

Предотвратить

Уменьшить вероятность:

валидация конфигурации;
безопасное значение по умолчанию;
поэтапный релиз;
ограничение прав;
автоматическая проверка совместимости;
управляемая ротация секретов.

Обнаружить

Увидеть раньше и точнее:

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

Смягчить

Ограничить влияние:

feature flag;
резервный способ оплаты;
graceful degradation;
лимит массового изменения;
автоматический circuit breaker;
заранее согласованный ручной обход.

Восстановить

Сократить время возврата:

проверенный rollback;
runbook;
тест восстановления;
резервный контакт;
автоматизированное переключение;
готовая статус-страница.

Хороший postmortem часто даёт хотя бы по одному действию из нескольких типов, а не только новый алерт.

Как формулировать действия

Слабое:

Следить внимательнее за обменом.

Сильное:

До 15 августа добавить heartbeat после подтверждённого применения каталога и P2 при отсутствии сигнала 90 минут. Владелец — Анна. Проверка готовности: искусственно пропущенный цикл открывает один сгруппированный инцидент и уведомляет дежурного в Telegram и резервном email.

Каждая строка отвечает:

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

Ограничьте список. Для небольшой студии три выполненных действия полезнее пятнадцати просроченных.

Ответственность после встречи

Blameless относится к анализу происхождения инцидента. После встречи ответственность конкретна:

владелец документа выпускает финальную версию;
владельцы задач выполняют действия;
технический руководитель расставляет приоритеты;
аккаунт согласует клиентские решения;
руководитель проверяет просроченные incident-actions;
команда подтверждает действие тестом.

Если задача не помещается в работу, это явное решение о принятии риска. Запишите его с владельцем, а не оставляйте действие без срока.

Копируемый шаблон postmortem

# Postmortem [ID]: [фактическое название]

Дата инцидента: [дата]
Уровень: [P1/P2]
Статус документа: [черновик / утверждён]
Автор: [имя]
Фасилитатор: [имя]
Участники: [роли]
Связанный клиентский отчёт: [ссылка]

## Резюме

[Что произошло, влияние, длительность и восстановление]

## Влияние

- Пользовательский результат: [описание]
- Масштаб: [факт / неизвестно]
- Период: [начало — конец]
- Данные и безопасность: [статус]
- Обход: [описание]

## Обнаружение и реакция

- Как обнаружено: [источник]
- Почему этот сигнал сработал: [факт]
- Какие сигналы отсутствовали: [список]
- Время обнаружения: [значение]
- Время реакции: [значение]
- Время восстановления: [значение]

## Хронология

| Время | Наблюдаемый факт | Доступная тогда информация | Решение |
|---|---|---|---|
| | | | |

## Триггер

[Событие, активировавшее проблему]

## Непосредственные причины

- [Механизм нарушения]

## Системные факторы

- [Процесс, инструмент, архитектура, полномочия или информация]

## Что сработало хорошо

- [Факт]

## Что могло сработать лучше

- [Факт]

## Где повезло

- [Риск, который не реализовался]

## Действия

| Действие | Тип | Владелец | Срок | Критерий готовности | Задача | Статус |
|---|---|---|---|---|---|---|
| | Предотвратить / обнаружить / смягчить / восстановить | | | | | |

## Открытые вопросы

| Вопрос | Владелец исследования | Срок | Результат |
|---|---|---|---|
| | | | |

## Проверка выполнения

Дата следующего review: [дата]
Кто закрывает postmortem: [имя]

Заполненный мини-пример

Инцидент

После релиза форма показывала «Спасибо», но письма не доходили 36 минут.

Плохой вывод

Разработчик забыл обновить пароль SMTP. Попросили быть внимательнее.

Системный разбор

Триггер: смена SMTP-секрета.
Непосредственная причина: приложение использовало старое значение.
Факторы: смена секрета и релиз не были одной операцией; секрет не имел контролируемого срока; post-release тест завершался на HTTP-ответе; резервный маршрут не тестировался.
Что сработало: сквозная проверка доставки открыла P1 через две минуты; был резервный маршрут.
Где повезло: сбой произошёл до начала основной рекламной рассылки.

Действия:

Действие	Тип	Владелец	Срок	Проверка
Управляемая ротация SMTP-секрета	Предотвратить	DevOps	12.08	Тестовая ротация без сбоя
Алерт срока секрета	Обнаружить	Поддержка	08.08	Предупреждение за 14 дней
Тест доставки после релиза	Обнаружить	QA	06.08	Письмо найдено по маркеру
Квартальный тест резерва	Восстановить	Руководитель поддержки	30.09	Переключение подтверждено

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

Фразы, которые меняют качество разговора

Обвинительная формулировка	Системный вопрос
Кто это сломал?	Какое изменение активировало нарушение?
Почему он не проверил?	Какие проверки были обязательными и видимыми?
Кто забыл пароль?	Почему критический секрет зависел от ручной памяти?
Почему дежурный так долго думал?	Какой информации и полномочий не хватало для решения?
Клиент снова всё сделал не так	Как процесс допускает изменение без общей карточки?
Больше так не делайте	Какой барьер технически предотвращает повтор?

Системный вопрос не оправдывает действие. Он ведёт к изменению, которое работает и с другим сотрудником.

Как работать с клиентом

Внутренний postmortem может быть глубже клиентского отчёта. Клиенту передают:

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

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

внутренние споры;
персональные оценки;
security-чувствительные детали;
данные других проектов;
все неудачные гипотезы;
кадровые вопросы.

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

Готовый формат: отчёт об инциденте сайта для клиента.

Как создать культуру в маленькой команде

Начните с простого:

руководитель публично разбирает собственное неудачное решение без самооправдания;
для всех P1 используется один шаблон;
язык «кто виноват» останавливается фасилитатором;
действия попадают в обычный backlog;
каждую неделю проверяются просроченные incident-actions;
удачные действия команды тоже фиксируются;
через квартал сравниваются повторяющиеся факторы.

Доверие разрушается, если один раз разбор объявили blameless, а потом использовали цитаты для публичного наказания участника. Кадровые и этические нарушения могут требовать отдельной процедуры, но её нельзя маскировать под обучающий postmortem.

Метрики процесса

Не измеряйте число найденных виноватых или длину документа.

Полезно смотреть:

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

Цель — улучшение системы, а не красивый показатель заполнения шаблона.

Частые ошибки

«Без обвинений» означает избегать прямых фактов

Команда говорит общими словами и не обсуждает ошибочное решение. Нужно разбирать действие честно, но в его контексте.

Встреча проводится как суд

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

Корневая причина — человек

Это редко даёт защитный барьер. Ищите, почему система зависела от безошибочности.

Создаётся слишком много задач

Список из двадцати улучшений не получает приоритета. Выберите действия по влиянию и типам.

Действия не проверяются

«Добавили мониторинг» закрывается без тестового сбоя. Для каждой задачи нужен критерий.

Обсуждается только техника

Медленная эскалация, непонятное сообщение и отсутствующий владелец могут увеличить влияние сильнее кода.

Не фиксируется удача

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

Security-инцидент полностью разбирается в общем документе

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

Как помогает Pingvera

Pingvera может подготовить факты для разбора:

точное время первого нарушения и восстановления;
результаты проверок по регионам;
историю алертов;
изменение доступности и времени ответа;
состояние формы, домена, SSL, CMS, сервера или фоновой задачи;
запись отправленных уведомлений;
связь с клиентским статусом и отчётом.

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

Подготовьте разбор до следующего P1: сохраните шаблон, назначьте фасилитатора и убедитесь, что история критических проверок доступна в Pingvera.

Часто задаваемые вопросы

Нужно ли приглашать клиента на postmortem?

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

Что делать, если ошибку действительно совершил конкретный человек?

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

Обязательно ли искать одну корневую причину?

Нет. У инцидента могут быть несколько непосредственных причин и системных факторов. Важнее построить модель, которая приводит к эффективным действиям.

Кто должен фасилитировать?

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

Сколько действий должно быть?

Столько, сколько команда реально выполнит. Для небольшой студии часто достаточно трёх–семи. Обязательно закройте наиболее сильные причины и сократите обнаружение или восстановление.

Когда postmortem можно закрыть?

Документ можно утвердить после согласования фактов и создания задач. Инцидентные улучшения отслеживаются до выполнения. Полезно различать «postmortem опубликован» и «действия завершены».

Можно ли использовать ИИ для черновика?

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

Главное

Blameless postmortem — не мягкий разговор о том, что «все молодцы». Это строгий анализ без персонального унижения.

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

Источники и дополнительное чтение

Следующая учебная ступень: масштабирование поддержки на 10, 50 и 100 клиентских сайтов без потери контроля.

Узнавайте о проблеме раньше клиента

Pingvera следит за сайтами клиентов «снаружи и изнутри» — доступность из регионов, формы, оплата, домен, SSL, сервер — и предупреждает в Telegram, email и Max раньше, чем напишет клиент.

Попробовать Pingvera бесплатно

← Все статьи · Политика конфиденциальности · pingvera.ru · Telegram-канал