Успешные постмортемы без поиска виноватых помогают учиться на инцидентах, чтобы не допускать подобных ошибок в будущем.
Постмортем — это сам и процесс, и его результат, то есть документ, где вы описываете инцидент, его разрешение и меры, которые можно принять, чтобы такого больше не повторилось.
Это такая сложная структура, что почти невозможно предотвратить или хотя бы спрогнозировать сбои.
Раз инциденты будут возникать в любом случае, они должны приносить пользу, а не вред.
Допустим, у нас есть простая система с тремя компонентами (A, B и C) со следующими свойствами:
Внезапно B начинает тормозить. В результате A поддерживает много открытых соединений с C, пока тот не начинает отказываться от новых входящих соединений. A не может открывать новые соединения с C и тоже начинает сбоить.
Мы открыли скрытую связь между B и C. Вот как выглядит новая схема:
В идеале результатом постмортема будет документ, где описано, что нужно изменить в системе, чтобы проблема не повторилась.
А если она будет повторяться, нужно описать, как смягчить ее последствия и ускорить разрешение.
В теории — любой инцидент. На практике вам вряд ли хватит ресурсов, поэтому начните с инцидентов, которые напрямую влияют на клиентов и стейкхолдеров.
Приступайте к делу как можно раньше, лучше даже на этапе разрешения, пока события еще свежи в памяти.
Попробуйте найти первопричину, если с ней можно что-то сделать:
Если это случится снова:
Если мы будем тыкать друг в друга пальцами, люди станут скрывать информацию, и весь процесс развалится.
Не копайте слишком глубоко
Между вашей системой и остальным миром нет четкой границы — они плавно перетекают друг в друга. В поисках первопричины возникает искушение зайти слишком далеко — в область, которую вы не контролируете. Вы потратите ресурсы попусту.
Источник статьи: https://habr.com/ru/company/southbridge/blog/562758/
Постмортем — это сам и процесс, и его результат, то есть документ, где вы описываете инцидент, его разрешение и меры, которые можно принять, чтобы такого больше не повторилось.
Зачем нужен постмортем?
Ваша система включает не только информационные технологии, но и элементы реального мира — вас и ваших коллег, начальника, пользователей, вендоров, пространство и, самое ужасное, — время.Это такая сложная структура, что почти невозможно предотвратить или хотя бы спрогнозировать сбои.
Раз инциденты будут возникать в любом случае, они должны приносить пользу, а не вред.
При сбое мы узнаем о системе что-то новое, особенно о скрытых связях между компонентами.
Допустим, у нас есть простая система с тремя компонентами (A, B и C) со следующими свойствами:
- A связан с B;
- A связан с C;
- между B и C никаких связей не наблюдается;
- любой процесс, порожденный A, открывает соединение с B и C.
Внезапно B начинает тормозить. В результате A поддерживает много открытых соединений с C, пока тот не начинает отказываться от новых входящих соединений. A не может открывать новые соединения с C и тоже начинает сбоить.
Мы открыли скрытую связь между B и C. Вот как выглядит новая схема:
В идеале результатом постмортема будет документ, где описано, что нужно изменить в системе, чтобы проблема не повторилась.
А если она будет повторяться, нужно описать, как смягчить ее последствия и ускорить разрешение.
Когда проводить постмортем
Когда в системе происходит достаточно серьезный инцидент.В теории — любой инцидент. На практике вам вряд ли хватит ресурсов, поэтому начните с инцидентов, которые напрямую влияют на клиентов и стейкхолдеров.
Приступайте к делу как можно раньше, лучше даже на этапе разрешения, пока события еще свежи в памяти.
Что нужно делать
Опишите, что произошло. Четко сформулируйте последствия инцидента:- Кто?
- Что?
- Как долго?
Попробуйте найти первопричину, если с ней можно что-то сделать:
- пять почему;
- практичность важнее «истины»;
- процесс поиска первопричины нужно документировать.
Привлеките всю команду, если это возможно, — чем больше голов, тем лучше. Вместе учитесь на ошибках и попытайтесь устранить инцидент, пока он не пошел дальше.
Предложите улучшение для системы
Если это случится снова:
- Запишите меры по устранению, чтобы в следующий раз все сделать быстрее.
- Что можно сделать, чтобы свести последствия к минимуму?
- Мы вовремя узнали об инциденте?
- Все нужные люди получили уведомление?
- Нужные подсистемы (например, автомасштабирование) получили нужный фидбэк?
Чего не нужно делать
Никого не обвиняйтеЕсли мы будем тыкать друг в друга пальцами, люди станут скрывать информацию, и весь процесс развалится.
Не копайте слишком глубоко
Между вашей системой и остальным миром нет четкой границы — они плавно перетекают друг в друга. В поисках первопричины возникает искушение зайти слишком далеко — в область, которую вы не контролируете. Вы потратите ресурсы попусту.
Что делать с документом?
Главная цель — извлечь урок для себя и своей организации. Документы по постмортему должны быть:- доступны для поиска;
- открыты максимально широкой аудитории (без раскрытия конфиденциальной информации);
- понятны аудитории (инженерам, стейкхолдерам, пользователям и т. д.).
Для вдохновения
Вот список общедоступных (и подробных) постмортемов:- Summary of the Amazon Kinesis Event
- Google Cloud Networking Incident
- Stripe — Significantly elevated error rates
Источник статьи: https://habr.com/ru/company/southbridge/blog/562758/