У всех ИТ-команд время от времени случаются сбои — разделить их на тех, кто ошибается, и тех, кто живет без ошибок, невозможно. Но можно провести другое условное деление: на тех, кто забывает про инциденты на следующий день, и тех, кто использует их как точку роста.
Вторая группа использует постмортемы — разборы, в которых команда фиксирует причины сбоя и думает, как снизить вероятность его повторения. В статье разберем, в каких ситуациях постмортемы особенно полезны, какими они могут быть, чтобы не превращаться в поиск виноватых, что обычно включают в отчеты об инцидентах и как такие разборы помогают команде развиваться.
Когда инцидент заслуживает постмортема
В разработке периодически случаются отклонения от нормальной работы: метрики в системе мониторинга ведут себя не так, как ожидалось, сервер обрабатывает запросы медленнее, данные на графиках появляются с задержкой. Иногда ошибка в коде приводит к некорректному отображению информации для пользователей.Но что считать инцидентом, который стоит разобрать в формате постмортема? В книге SИТe ReliabilИТy Engineering Google приводит типичные критерии, при которых команды обычно проводят постмортем:
• Пользователи заметили ухудшение работы сервиса. Например, замедлился сайт или перестали проходить платежи.
• Произошла потеря данных. Допустим, из-за сбоя в базе данных пропала вся контактная информация клиентов.
• Потребовалось вмешательство дежурного инженера: ручной откат релиза, перераспределение трафика или другое восстановление.
• На решение проблемы ушло значительно больше времени, чем обычно.
• Мониторинг не сработал, и о проблеме узнали другими способами — например, при ручной проверке или от пользователей.
Эти критерии помогают команде заранее договориться, в каких случаях разбор будет полезен. Если инцидент затрагивает несколько пунктов сразу, постмортем стоит провести как можно скорее, для этого нужно собрать отчет об инцеденте.
Что входит в отчет об инциденте
Как правило, отчеты об инцидентах состоят из трех основных разделов:● Детали инцидента.
● Выводы.
● Таймлайн.
Разберемся, что должно входить в каждый из этих разделов.
Детали инцидента
В этой части отчета собираются все факты, которые помогут точно понять, что произошло, как это повлияло на систему и пользователей, а также какие шаги были предприняты для решения проблемы. Вот что в него входит:1. Краткое описание того, что произошло.
Например: сбой, затронувший несколько серверов, из-за которого компания не выполнила соглашение об уровне обслуживания с клиентами.
2. Контекст.
В отчете важно объяснить термины и особенности системы, которые могут быть не очень знакомы другим командам, например, если используется специфическое архитектурное решение, нужно дать общее представление, как оно работает.
3. Влияние на метрики, пользователей и доход.
Описывается, как инцидент отразился на ключевых показателях системы и бизнесе. Это может быть увеличение времени отклика на 10 секунд или потеря 2 млн рублей.
4. Затронутые продукты.
Перечень сервисов, на которые повлиял сбой. Это могут быть базы данных или приложения.
5. Технические подробности инцидента.
Это одна из самых больших и сложных частей отчета, в ней с разных сторон дается подробное описание, как происходил сбой. Для этого опрашивают всех, кто был связан с инцидентом.
6. Первопричины инцидента.
Что стало основной причиной сбоя? Это могут быть ошибки в коде, недостаточная автоматизация или проблемы с мониторингом.
7. Как проблема была решена.
Описание того, какие действия были предприняты для устранения инцидента. Например, был ли откат релиза или перераспределение трафика.
Выводы
Этот раздел подводит итоги и помогает извлечь уроки из произошедшего. В нем отвечают на следующие вопросы:1. Что пошло не так? Что именно привело к сбою, какие процессы не сработали, какие ожидания не совпали с реальностью.
2. Что сработало хорошо? Важно отметить не только негатив, но и положительные моменты, возможно, какие-то меры были выполнены успешно и система быстро восстановилась.
3. Можно ли было заметить и исправить проблему раньше? Сюда входят размышления о том, на какие признаки можно было обратить внимание еще до инцидента: во время тестирования или мониторинга.
4. Какие меры могут быть приняты сразу, чтобы избежать повторения инцидента в будущем? Речь про быстрые решения, которые можно внедрить прямо сейчас. Например, настройка новых алертов.
5. Что требует долгосрочных изменений? Возможно, нужны более серьезные изменения в процессах: переработка CI/CD-процессов или улучшение автоматизации.
Таймлайн
В таймлайне дается подробная хронология событий, которая помогает отследить, как развивался инцидент и когда специалисты предприняли ключевые действия. Вот какие временные точки и детали вносят в него:1. Когда инцидент начался и когда был зафиксирован. Эти два события могут быть разнесены во времени.
2. Кто заметил проблему и как это выглядело. Здесь указывают, кто первый увидел сбой, будь то команда мониторинга или пользователи.
3. Когда началась работа по предотвращению инцидента.
4. Когда проблема была решена.
Таймлайн может быть более детализированным, если нужно. Желательно, чтобы он был подкреплен графиками, которые показывают, как события развивались во времени.
Не искать виноватых: что такое постмортемы без обвинений
Когда инцидент произошел, важен не только точный протокол, как составлять постмортем. Большую роль играет атмосфера в команде: могут ли сотрудники честно и без страха делиться подробностями о случившимся. Чтобы создать такую атмосферу, используют постмортемы без обвинений — подход к постмортемам, при котором внимание смещается с поиска виновных на анализ причин и улучшение процессов.Культура постмортемов без обвинений основывается на том, что ошибки — это естественная часть работы с высоконагруженными и сложными системами. Инциденты в этой парадигме рассматриваются как возможность для роста, а не как повод для наказания.
Суть этого подхода в том, что нельзя исправить людей, но можно изменить процессы, чтобы помогать сотрудникам делать правильный выбор при проектировании и обслуживании сложных систем. Культура таких постмортемов дает возможность инженерам, чьи действия привели к инциденту, открыто и честно отчитаться о том:
• какие действия они предприняли и в какое время,
• какие последствия они наблюдали,
• какие у них были ожидания,
• какие предположения они сделали,
• как понимали хронологию событий по мере их развития.
И самое важное: они не боятся дать такой подробный отчет потому что не опасаются негативных последствий. Инженер, который думает, что ему сделают выговор, не заинтересован в том, чтобы сообщать детали, необходимые для понимания неисправности.
Как постмортемы без обвинений работают на практике
1. Вместо того, чтобы фокусироваться на том, кто что сделал неправильно, обращают внимание на инструменты, которые не сработали. Если ошибка произошла из-за недостаточного тестирования, нужно понять, почему тесты не были достаточными, а не обвинять инженеров.2. После составления постмортема его отдельно проверяют на персонализацию ответственности. Формулировки, которые переводят разговор с анализа причин на оценку конкретного сотрудника не решают проблему.
3. Все действия, предпринятые после инцидента, должны быть публичными для всей команды. Это позволяет всем быть в курсе того, что именно сделано для исправления ситуации, и помогает избежать недоразумений.
4. Инциденты обсуждают на ретроспективах, где важно сохранять фокус на причинах и действиях, а не на поиске виноватых. Полезно, чтобы за обсуждением следил модератор: он помогает возвращать разговор к фактам.
5. Важно не воспринимать большое количество постмортемов как повод для критики команды или отдельных сотрудников. Частые постмортемы могут быть следствием высокой нагрузки или особенностей проекта. Если связывать их количество с ошибками конкретных людей, у команды может сформироваться ощущение, что за фиксацию инцидентов приходится оправдываться.
Как постмортемы превращают недостатки в преимущества
В парадигме постмортемов без обвинений каждый инцидент — это инвестиция в развитие. Они могут быть болезненными, даже привести к потере денег, но в то же время помогают улучшить процессы и повысить безопасность.Как превратить проблему в точку развития? Вот что для этого можно использовать:
1. Методика «5 почему» для глубокого анализа.
Эта методика помогает найти коренные причины инцидента, а не останавливаться на поверхностных. Для этого нужно пять раз задать вопрос «Почему?», каждый раз углубляя анализ. Например:
• Почему сервер не работал? Потому что в коде была ошибка.
• Почему ошибка в коде осталась незамеченной? Потому что тесты не покрывали этот сценарий.
• Почему тесты не покрывали этот сценарий? Потому что это была новая фича, и тесты не были обновлены.
• Почему тесты не обновили? Потому что в процессе разработки/CI не было обязательного шага обновления тестов при изменении функциональности.
• Почему в процессе разработки/CI не было такого шага? Потому что при формировании процесса основной акцент сделали на автоматической проверке существующих тестов, а не на контроле их актуальности.
Такой анализ помогает увидеть системные причины и найти пути улучшения процесса.
2. Постмортемы на всех уровнях организации.
Может показаться, что постмортемы — это привилегия только технических команд. Но это не так: их можно проводить на всех уровнях компании.
Например, если инцидент связан с неудачным взаимодействием между командами, постмортем может выявить неэффективную коммуникацию, которая стала причиной сбоя.
3. Внедрение изменений в процессы
После анализа инцидента и выявления причин нужно сделать так, чтобы проблема не повторялась. Это может быть изменение в процессах, настройка новых инструментов или улучшение существующих. Например, обновление процедуры мониторинга, автоматизация восстановления, переработка CI/CD процессов.
Почему с постмортемами лучше, чем без них
Правильно проведенные постмортемы, без осуждения, — это инструмент для улучшения процессов, повышения безопасности и развития культуры открытого обсуждения проблем. Они помогают команде расти и создают атмосферу, в которой ошибки становятся частью обучения, а не поводом для наказания.Постмортемы дают возможность анализировать даже не столько сам инцидент, сколько процессы, которые к нему привели. Можно, конечно, быстро забыть о проблеме и бежать дальше, к новым запускам и проектам. Но если система сама дает нам шанс сделать ее лучше, почему бы им не воспользоваться?
