Postmortem в DevOps
Постмортемы (от лат. post mortem — «после смерти») — это структурированные отчеты, которые создаются после возникновения инцидента или сбоя в системе. Их цель — не просто зафиксировать, что произошло, но и понять причины, а также выработать стратегии предотвращения подобных ситуаций в будущем. В DevOps они являются важной частью культуры непрерывного улучшения.
А нужны ли они?
Предположим, вы считаете, что важность постмортемов переоценена. Вы думаете - "Зачем записывать свои неудачи? Зачем рассказывать кому-то о том, что я не смог правильно настроить кубернетис? Зачем вообще это документировать? Лол, я ж и так все помню". Так вот, такой тип мышления - в корне неверный.
Ситуация
Представьте, что вы инженер DevOps в компании, занимающейся потоковым видео. В один из вечеров на сервере произошел сбой, из-за которого пользователи не могли воспроизводить видео на протяжении часа. Вы оперативно устранили проблему, обнаружив, что её причиной стал переполненный лог-файл, занимающий всё свободное место на диске. После быстрого удаления файла и настройки автоматической ротации логов сервер снова заработал.
Вы чувствуете себя героем: проблема устранена, система работает, пользователи довольны.
Но вот что происходит через месяц: аналогичная ошибка возникает снова, на этот раз на другом сервере. Проблема повторяется, но в этот раз вы были не "в кондициях", поэтому поиск решения занял у вас немного больше времени. Вам опять пришлось вручную освобождать место. В этот раз это затронуло больше пользователей и длилось дольше. Руководство начинает задавать вопросы: «Почему это случилось снова? Почему не было предпринято мер для предотвращения повторения? Вы там чем вообще занимаетесь?».
Польза
Если бы после первого сбоя был составлен отчет, ситуация могла развиваться иначе:
- Документирование уроков: Вы зафиксировали бы, что проблема произошла из-за некорректной настройки ротации логов и переполнения диска. Вам не пришлось бы снова тратить свое драгоценное время и когнитивные ресурсы на поиск решения той же самой проблемы.
- Выявление корневой причины: Вместо ручного удаления файла вы могли бы задать вопрос: почему ротация логов не была настроена на всех серверах?
- Разработка действий: Постмортем привел бы к следующему плану: проверить настройки ротации логов на всех серверах - настроить мониторинг использования дискового пространства - добавить уведомления о достижении критического уровня свободного места.
- Предотвращение повторения: Благодаря внедренным мерам проблема была бы предотвращена ещё до того, как она снова могла бы повлиять на пользователей.
- Повышение доверия: Руководство видит, что вы не просто «гасите пожары», а стремитесь улучшать систему и предотвращать проблемы, показывая себя как квалифицированного и ответственного специалиста.
Как составлять постмортемы?
Общего шаблона/стандарта как вы обязаны писать постмортем - нет, но они обычно включают:
- Описание инцидента: Что произошло и какие были последствия.
- Хронологию: Последовательность действий до и после сбоя.
- Анализ причин: Корневые причины инцидента.
- План улучшений: Рекомендации по предотвращению подобных ситуаций.
Где их хранить?
Тут, опять же, нет какого-то идеального инструмента для такого. Кто-то использует Google Docs, кто-то Notion. В Google же используют Morgue. Тут гораздо важнее то, каким функционалом должно обладать это хранилище, а именно:
- Удобный поиск: Возможность быстро находить постмортемы по ключевым словам, датам или ответственным командам.
- Централизованное хранение: Все постмортемы должны храниться в одном месте, чтобы команда могла легко получить доступ к любому из них.
- История изменений: Хранилище должно поддерживать версионирование, чтобы было понятно, кто и когда вносил изменения.
- Совместная работа: Возможность команде одновременно работать над постмортемом, добавлять комментарии и предлагать правки.
- Шаблоны: Наличие готовых шаблонов для быстрого заполнения постмортемов, чтобы все отчёты имели единообразную структуру.
- Доступность: Возможность ограничивать или предоставлять доступ на основе ролей, чтобы постмортемы могли быть доступны только соответствующим участникам.
Безобвинительная культура
Безобвинительная культура постмортемов фокусируется на анализе системных причин инцидентов, а не на поиске виновных. Она признает, что ошибки неизбежны, особенно в сложных системах, и рассматривает их как возможность для обучения и улучшения. В такой культуре основной вопрос — «Почему это произошло и как предотвратить?», а не «Кто виноват?». Это создает атмосферу психологической безопасности, где сотрудники могут открыто говорить об ошибках без страха наказания. Вместо концентрации на личных промахах команда ищет способы улучшить процессы, инструменты и системы. Такой подход снижает число повторяющихся ошибок, ускоряет устранение инцидентов и повышает доверие в команде. Он способствует совместной ответственности за результат и помогает строить более устойчивые системы. Безобвинительный постмортем — это инструмент для роста, который превращает ошибки в шаги к совершенству.