Пост №4. Разбор инцидентов или Postmortem
Dmitrii Derepko (@xepozz)Postmortem – это медицинский термин, который обозначает процесс вскрытия трупа для исследования причин смерти.
Postmortem в IT – это ретроспектива, направленная на тему “что нужно сделать сейчас, чтобы избежать подобной ошибки в будущем”. Будет довольно странно обсудить фейл и просто понадеяться, что в будущем это не повторится, не правда ли? Именно поэтому посыл должен звучать про будущее и ни в коем случае не “найти того, кто сломал”.
Найти того, кто сломал всё равно нужно, но это не цель постмортема. Найти его нужно будет, потому что он будет владеть подробной информацией о шагах, которые привели к краху. А может он был просто марионеткой, в ситуации, когда кто-то вмёржил в мастер, но не задеплоил. Есть такие среди вас? :)
Процесс разбора инцидентов обязательно вам потребуется. Вопрос лишь времени. Если у вас его еще нет – самое время делать это сейчас, например.
Цель
Выявить слабые места системы и попытаться улучшить их в будущем или максимально обезопасить и повторного инцидента.
Процесс
Типичный постмортем выглядит следующим образом:
- Назначается встреча и обговаривается состав участников
- Составляется документ (артефакт встречи), составляется список договоренностей
- Происходит проверка выполнения договоренностей через установленное время
- Если договоренности не выполнены, то следует их “подтюнить” – изменить стратегию, собрать дополнительные факты или отложить
Состав
- Участники инцидента
- Человек с менеджерскими навыками
- Человек с техническими компетенциями
Пункты 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.
Самое главное – зачем?
Можно предположить, что это “еще один созвон”, но смотрите в будущее.
Давайте рассмотрим ситуацию в двух сторон:
Если вы в комитете по разбору инцидентов
Вы делаете неописуемо полезную работу для проекта и компании:
- Зарабатываете “очки кармы” в глазах своего руководителя и других сотрудников
- Тренируете свои менеджерские навыки или даете технические инсайды “как лучше делать”
- Делаете процесс падения прозрачным и понятным – Упасть – не стыдно, стыдно – не подняться
- Улучшаете систему, иногда и не напрямую: добавляете дополнительные механизмы по восстановлению или устойчивости системы
- Узнаете больше о тонкостях других подсистем
Если вы в составе участников инцидента
Здесь вы развиваетесь “вглубь”:
- Узнаете что и как лучше делать в следующий раз
- Увеличиваете понимание важности тестирования изменений перед релизом
- Получаете “зеленый свет” на задачку из “техдолга” – договоренности после инцидента обычно составляют какие-то технические задачки
- Разбор инцидентов не самое приятное времяпровождения, поэтому вы захотите в следующий раз не приходить сюда, а значит будете тщательно следить за своими изменениями и изменениями коллег
Постмортем с любой стороны – это развитие, как себя или других участников, так и системы.
Мне всегда хватало подобной схемы ведения инцидентов. Я был как с одной стороны, так и другой. Я не боюсь появиться перед "крутыми пацанами" и сказать, что я сломал прод. Я не стыжу тех, кто это сделал. Я только рад сделать так, чтобы подобного падения больше не было. Я открыт к помощи коллегам.
Если у вас еще нет процесса разбора инцидентов, то сделайте в качестве эксперимента несколько разборов, а потом попросите коллег дать фидбек: что было лишнего на созвоне; что упустили; какие есть идеи по улучшению; видят ли они ценность в этом процессе. Не забудьте показать своему руководителю этот процесс и узнайте его мнение по этому поводу.
Если вам интересно почитать про какие-то пункты побольше, то дайте мне знать, я попробую дополнить информацию.
Ссылка на пост: https://t.me/handle_topic/13
Ссылка на группу для обсуждения https://t.me/handle_topic_chat