August 18, 2020 • Время на прочтение: 6 минут

Postmortem или как не c совершать факапов

Postmortem | Андрей Осипенко

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

  • Почему факап произошел? Какие к этому были предпосылки и какие у факапа причины или истоки.
  • Какие части системы были заэфекченны данным факапом? Почему? Это поможет понять взаемосвязь элементов системы.
  • Что мы сделали чтобы факап исправить? Описание шагов. Т.е. если упал сервер из-за большого количество данных на нем, и вы его почистили и перезапустили, буквально задокументируйте процесс, чтобы любой человек смог воспроизвести его в будущем.
  • Кто фиксил факап?
  • Как проверить, что факап устранен?
  • Что было предпринято, чтобы этот факап больше не проявлялся в будущем?

Процесс

После составления подобного документа, положите его в БД, это может быть папочка в Google Drive, страничка в Confluenc’e или что-то подобное. Важно чтобы все было под рукой. Если возможно, проставьте теги и сделайте хороший заголовок, чтобы если через месяц-два подобная проблема воспроизвелась, вы бы смогли ее быстро исправить.

И теперь главное — периодический просмотр. Попросите команду, раз в месяц просматривать постмортемы. Косяки часто происходят из-за недостаточного понимания контекста ситуации. К примеру, забыли что место на сервере не бесконечное, и сделали MVP решение которое сильно грузит сервер, соответственно через пару месяцев гигабайты логов или бекапов положили вашу систему.

Добавьте ссылку на папку с постмортемами в хендбук или онбоардинг документ, чтобы его прочитывал каждый новый человек в вашей команде перед началом работы на проекте

Чем вам поможет этот инструмент?

  • Новички вступая в работу на продакшене будут иметь контекст о ситуациях, когда, то или иное решение отстреливало ноги. А главное, будут знать почему, и как если что это правилось.
  • Даже если команда постоянно меняется, у всех будет контекст о факапах в прошлом, а главное — как их фиксить.
  • При передаче проекта другой команде или менеджеру — поможет ускорить этот процесс и передачу контекста.
  • Вероятность возникновения проблемы в будущем — уменьшается, скорость решения если проблема воспроизвелась — ускоряется

Если у вас нет такой корпоративной практики, заведите себе за правило документировать подобные штуки в своем личном окружении, к примеру в заметках или Notion.

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

Как понять, что вы написали хороший постмортем?

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

Примеры

Постмортемы пишутся не только для внутреннего использования часто, их используют компании для коммуникации со своей аудиторией, когда этот факап заафектил существующих пользователей. Год назад случился большой факап у компании DigitalOcean - они предоставляют хостинг решений дешевле чем у Amazon Web Services или Microsoft Azure, тем самым, собирая часть рынка которая не может себе позволить или не хочет хоститься у них.

У них есть скриптик, который проходится по всей пользовательской базе и если видит какую-то специфическую активность ( майнинг криптовалют в данном случае ) - блокирует аккаунт. Случилось так, что скриптик сработал на реальную компанию, которая с криптой не имела ничего общего и их аккаунт был заблокирован. Вы можете представить, что это значит для компании, у которой есть инвестора, клиенты и обязательства. Одним днем твоего бизнеса не стало. Потом сработал человеческий фактор, долго отвечала клиентская поддержка. Разблокировали аккаунт только через 12 часов, но забыли промаркировать его как false positive (ложное срабатывание).

Через некоторое время, скриптик сработал вновь и снова заблокировал сервера компании. И снова, человеческий фактор с долгим ответом клиенту.

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

Чтобы не пропустить следующий пост, подписывайте на мой телеграм канал :)


Андрей Осипенко Работаю с финтехом днем - Product Manager, dashdevs.com. А ночью обучаю проектных менеджеров - Redcamp.pro

© 2020, Built with ❤️