Перед тем, как начнем разговор об этой материи, должен предупредить, что не стОит гуглить слово Postmortem, особенно картинки. На рубеже XIX-XX веков это была не самая лицеприятная традиция фотографирования недавно покинувшей этот мир родни. Содержание текста ниже к этой практике никакого отношения не имеет.

Что есть Postmortem в епархии информационных технологий?

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

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

Проще говоря, цель этого упражнения — исследовать некую новую, неочевидную или неожиданную ситуацию, ошибку, с которыми вы / компания не хотите сталкиваться снова. Рассмотрение инцидента или проблемы для того, чтобы понять, что всё-таки произошло, и предотвратить это в будущем, ну, или по крайней мере, научиться раньше обнаруживать, минимизировать ущерб и пр.

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

Существуют разные подходы, политики, разные культуры и бескультурья составления Postmortem’ов. В этой статье я попытаюсь кратко рассказать о наиболее распространённых практиках и о самых популярных граблях.

И все же, а что достойно Postmortem’a?

И тут мнения сразу же разделились — «мы запускаем расследование, когда произошло что?»:

1. Что-то новое

2. Что-то неприятное

3. Что-то масштабное

(Иногда применяется сочетание нескольких признаков, перечисленных выше.)

Скажу за себя: я считаю, что препарировать целесообразно только что-то новое. Повторное расследование идентичных случаев, по моему глубочайшему убеждению, полновесного разбора не стОит — тут, скорее всего, целью следует ставить подсчет потерь. Все остальные же элементы инцидента уже разбирались и будут выглядеть как бег по кругу и пустая трата времени. 

В конце концов, цель хорошего Postmortem’а — помочь нам стать лучше, это должен быть именно анализ, а не пугало для коллег. Не нужно им страшить (даже в шутку), или ставить в KPI. Я встречал весьма странный пункт в KPI технического директора, который звучал «не больше Х Postmortem’ов в зоне ответственности за квартал».

К чему это может привести (на самом деле рано или поздно приведет)? Да просто к тому, что во имя выполнения KPI инциденты, действительно достойные разбора, этого самого разбора получать не будут. Начнется заметание пыли под ковер и обычное сокрытие проблем. Если мы не честны друг перед другом — Postmortem теряет всякий смысл.

Про форму поговорили, теперь самое время поговорить о содержании.

Пожалуй, начну с того, чего в документе быть не должно.

Имён. Не «Иванов не обратил внимания на странное поведение метрики», не «дежурный девопс Иванов проигнорировал алерт», а «дежурный девопс выставил завышенный трешхолд». Мы не называем имён — мы обозначаем роли. Роли не только тех, кто допустил ошибку, но и роли участников события. Мы не ставим своей целью никого обвинить — как правило, имя виновного и так уже известно, и мы не хотим ничьей крови и прочих «организационных выводов». Мы хотим понять, как выглядел инцидент с разных точек зрания: инженеров, клиентщиков, финансистов, поддержки — кого угодно. Хотим дополнить наши чеклисты, учебные и справочные материалы, чтобы результатом нашего Postmortem’a стало знание вида «эта ситуация выглядит так же, как у нас в прошлом квартале было… ну, когда произошла та беда, по которой ребята ещё Postmortem написали».

Некоторое время назад знакомый рассказал мне просто жуткий антипример проведения Postmortem’ов:

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

Посещение этого амфитеатра всячески приветствовалось (за заполняемостью «зрительного зала» тщательно следили специально подготовленные люди).

Я не смог сам себе объяснить, что могло быть целью этого действа. Пристыдить виновных? Да они сами себя уже по сто раз казнили за случившееся. А вот инициативность и самостоятельность явно уйдут в ноль после такого — начнется бесконечное согласовывание каждого шага (ну так, на всякий случай). Причем это ждет не только попавших за стол обвиняемых, но и зрителей и обвинителей — никто не захочет попасть на такое судилище в качестве жертвы.

Так, это снова было про форму. Вернемся к содержанию.

Содержание Postmortem

Как правило, Postmortem состоит из 3 больших разделов:

• Таймлайн

• Детали

• Выводы

А вот теперь подробности.

Тут важно отметить, что составитель Postmortem’a, кем бы он ни был, вряд ли может знать все детали. Поэтому составитель должен быть не экспертом в материи, а, скорее, носителем неких общих знаний. Нельзя знать всё, но нужно знать, где всё узнать, поэтому эта работа обычно ложится на плечи менеджера проекта, менеджера продукта и… (не, ну не получится тут выдержать МХАТовскую паузу) тимлида поддержки, как того, кто в контакте со всеми в компании, а заодно и с пользователями.

Что же все-таки следует указать?

Заглавие, сабж, с кратким описанием беды.

Часть 1. 

Печальная хроника.

1. Затронутые проекты или клиенты

2. Точная временная шкала инцидента 

   1. Когда он начался?

   2. Когда был замечен? NB! начало инцидента и его обнаружение — далеко не всегда одно и то же время.

   3. Кто это заметил и как это выглядело? NB! Вот это стОит внесения в чеклисты. 

   4. Задержка между обнаружением и началом работ по предотвращению (иногда указывается время между началом инцидента и стартом лечения, иногда и то, и другое).

3. Какие действия были выполнены для того, чтобы это исправить?

4. Когда именно проблема была устранена?

Часть 2.

Детали.

1. Краткое описание того, что и почему произошло на самом деле.

2. Технические подробности (полная версия) — это, как правило, самая объемная часть нашего повествования, за которой придется зайти к самым разным командам.

3. Прямой денежный импакт — идём к финансистам.

4. Предполагаемый денежный импакт — тут к продукту.

5. Косвенный и репутационный импакт — тут к тому же продукту и SMM, насколько нами недовольны?

Часть 3.

А что же делать?

1. Могли ли мы заметить и исправить проблему раньше? Что нам нужно для этого?

2. Меры по предотвращению повторения и уроки, извлеченные из инцидента (ну, тут нужно взять на себя роль Стэна Марша из South Park и заявить что «сегодня мы многое поняли»)

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

(Основано на реальных событиях.)

Часть, которой может и не быть, но хорошо бы, если бы оказалась.

Что еще может войти в наш документ?

1. Чего мы пытались добиться и что пошло не так? Ну, мы же не нарочно все разломали… Мы хотели что-то хорошее сделать, но… (см первые 2 части)

2. Как выглядела проблема с разных сторон? Присутствует не всегда, ибо трудозатратно это всё описывать, но все-таки крайне желательно в это вложиться.

3. Комментарии коллег. Ну, да, комментарии и дополнения приветствуются. Но без тех «нельзя», которые я описал в начале текста. Пресекайте незамедлительно, орудуйте банхаммером беспощадно!

(Тут я хотел привести пример настоящего Postmortem’a, но понял, что объяснение специфики компании и ее процессов потребует отдельной статьи и решил, что нуйво.)

А напоследок, перефразируя еще одних классиков, в этот раз — Стругацких, скажу: «Народу не нужны нездоровые постмортемы — народу нужны здоровые постмортемы».

Dixi.

Ну и в качестве Postscriptum’a к Postmortem’у:
В эту и многие другие темы мы старательно зарываемся на одном из курсов Отуса для тимлидов поддержки. Та, что я изложил выше - одна из самых хитовых тем среди студентов, с поправкой на то, что в статье не получится привести реальный пример, без распухания текста в полтора раза, а про практику я просто промолчу.
Еще одна из тем, которая вызвала интерес - это тикет-трекинговые системы. Многие из них после известных событий ушли, их место занимают новые решения, в т.ч. “самописные”.
Вместе с ребятами из Отуса готовим демо-занятие об этой материи. Мы не будем ничего “впаривать” - мы лишь рассмотрим общий функционал, и отдельно остановимся на том, как не попасться на удочку “продаванов”.