Пост №4. Разбор инцидентов или Postmortem

Postmortem – это медицинский термин, который обозначает процесс вскрытия трупа для исследования причин смерти.

Postmortem в IT – это ретроспектива, направленная на тему “что нужно сделать сейчас, чтобы избежать подобной ошибки в будущем”. Будет довольно странно обсудить фейл и просто понадеяться, что в будущем это не повторится, не правда ли? Именно поэтому посыл должен звучать про будущее и ни в коем случае не “найти того, кто сломал”.

Найти того, кто сломал всё равно нужно, но это не цель постмортема. Найти его нужно будет, потому что он будет владеть подробной информацией о шагах, которые привели к краху. А может он был просто марионеткой, в ситуации, когда кто-то вмёржил в мастер, но не задеплоил. Есть такие среди вас? :)

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

Цель

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

Процесс

Типичный постмортем выглядит следующим образом:

• Назначается встреча и обговаривается состав участников
• Составляется документ (артефакт встречи), составляется список договоренностей
• Происходит проверка выполнения договоренностей через установленное время
• Если договоренности не выполнены, то следует их “подтюнить” – изменить стратегию, собрать дополнительные факты или отложить

Состав

1. Участники инцидента
2. Человек с менеджерскими навыками
3. Человек с техническими компетенциями

Пункты 2 и 3 вполне могут сочетаться в одном человеке: тимлид, “старший разработчик”, системный аналитик.

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

Артефакт

Артефактом встречи должен быть документ, в котором отражены следующие пункты:

• Короткое описание того, что случилось, например: “Сайт начал отвечать 500 после неудачного обновления MySQL” – понятно что было сделано и к чему это привело. “Сломался сайт” – очень плохо
• Подробное описание таймлайна произошедшего:

- 12:00 @user1 Делает релиз с повышением версии сторонней библиотеки (ссылка на комит)
- 12:03 @user2 Пишет в чат поддержки, что пользователи жалуются на неработающий функционал (ссылка на сообщение)
- 12:05 @user3 Звонит @user2 и просит заглянуть в чат
- 12:06 @user1 Смотрит мониторинг (ссылка на метрики) и делает вывод, что проблема была в последнем деплое. Делает rollback последнего деплоя
- 12:15 @user1 Находит проблему в библиотеке, делает патч (ссылка на патч), проверяет на тестовом стенде, деплоит исправление
- 12:16 @user2 подтверждает исправность текущей системы

• Метрики: сколько длился инцидент; сколько пользователей охватил инцидент; потенциальные потери в "псевдоденьгах"; дополнительные метрики, которые можно собрать, меняются от случая к случаю
• Договоренности “как такого не допустить в будущем”:

- @user1 пишет тест на компонент “А”. [дата, до которой это нужно выполнить]
- @user1 внедрит code review [дата]
- @user2 добавит линтер, статический анализатор или какую-то другую автоматическую проверку [дата]

• Состав, при котором производился разбор инцидента

Когда делать?

Например, всегда.

• Сайт отдавал 500 2 минуты? Постмортем
• У пользователя пропала кнопка оплаты? Постмортем
• Пользователя ограничили в какой-то функциональности? Постмортем
• В админке для менеджеров пропала кнопка? Ладно, здесь на усмотрение критичности кнопки

Сам разбор можно выставить в какой-нибудь временной слот, когда работа заканчивается. Например, вечер пятницы. Если у вас произошло больше 2-х инцидентов за неделю, то лучше перенести часть на следующий созвон. Лучше глубоко проработать 1-2 инцидента, чем поверхностно пройтись по 5.

Самое главное – зачем?

Можно предположить, что это “еще один созвон”, но смотрите в будущее.

Давайте рассмотрим ситуацию в двух сторон:

Если вы в комитете по разбору инцидентов

Вы делаете неописуемо полезную работу для проекта и компании:

1. Зарабатываете “очки кармы” в глазах своего руководителя и других сотрудников
2. Тренируете свои менеджерские навыки или даете технические инсайды “как лучше делать”
3. Делаете процесс падения прозрачным и понятным – Упасть – не стыдно, стыдно – не подняться
4. Улучшаете систему, иногда и не напрямую: добавляете дополнительные механизмы по восстановлению или устойчивости системы
5. Узнаете больше о тонкостях других подсистем

Если вы в составе участников инцидента

Здесь вы развиваетесь “вглубь”:

1. Узнаете что и как лучше делать в следующий раз
2. Увеличиваете понимание важности тестирования изменений перед релизом
3. Получаете “зеленый свет” на задачку из “техдолга” – договоренности после инцидента обычно составляют какие-то технические задачки
4. Разбор инцидентов не самое приятное времяпровождения, поэтому вы захотите в следующий раз не приходить сюда, а значит будете тщательно следить за своими изменениями и изменениями коллег

Постмортем с любой стороны – это развитие, как себя или других участников, так и системы.

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

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

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

Ссылка на пост: https://t.me/handle_topic/13

Ссылка на группу для обсуждения https://t.me/handle_topic_chat