WTF это постмортем

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

Кто может сделать вскрытие?

В отказоустойчивой среде любой может вызвать вскрытие. Однако в целом лучше всего вызывать вскрытие тот, кто знает о проблеме, но не принимает непосредственного участия в ее решении. Это облегчает беспристрастный процесс и гарантирует, что коренные причины и лежащие в их основе решения могут быть правильно определены.

Когда вызывать вскрытие

Вскрытие должно вызываться всякий раз, когда в производственной среде возникает критическая проблема. Это может быть что угодно, от ошибки до сбоя процесса. Чем выше вероятность того, что проблема возникнет снова, тем важнее провести вскрытие, пока еще есть возможность адаптироваться и дорабатывать. Если по какой-либо причине проблема вряд ли повторится, то по усмотрению заинтересованных сторон может быть проведено вскрытие.

Анатомия успешного вскрытия

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

Соберите команду

Первый шаг к успешному вскрытию — собрать команду и выделить в календаре час или два (по мере необходимости) для обсуждения и размышлений. На высоком уровне «команда» должна включать всех, кто был прямо или косвенно вовлечен в основную проблему; разработка, продажи, поддержка и т. д. Любой, кто помогал планировать, проектировать, создавать, развертывать, сортировать или устранять проблему, должен быть включен, поскольку все они обладают соответствующими знаниями, которые могут помочь определить основные причины.

Соберите факты

После того, как команда собрана, следующим этапом является сбор фактов. Сосредоточьтесь на том, что произошло, когда это произошло и что было сделано для смягчения проблемы (или проблем). Определив временную шкалу и четко обозначив, что пошло не так (и как отреагировала команда), мы получим общую основу, с которой можно начать.

Чтобы было ясно, сбор фактов должен быть лишен мнения. Все, что имеет значение, это то, что произошло без каких-либо красок или оговорок. Кроме того, это единственный раздел, в котором должно упоминаться имя любого человека, и только в той мере, в какой это обеспечивает контекст (например, «В 10:53 сигнал тревоги указывал, что в лаборатории отсутствует сетевое соединение. Джо Смит перезагрузил сетевой коммутатор). , восстановление связи").

Определите причины высокого уровня

Имея подробную временную шкалу и всю информацию, которую мы можем собрать, пришло время приступить к выявлению высокоуровневых причин проблемы. Это не подробный анализ, а общее определение того, где возникла первая проблема. Например, если была выпущена программная ошибка, вызвавшая данную проблему, то сама ошибка будет причиной высокого уровня. Имейте в виду, что в зависимости от инцидента может быть несколько причин высокого уровня.

Копай глубже

Как только основные причины выявлены, пора начинать настоящую работу. Хотя программная ошибка могла быть первоначальной причиной, она не является основной причиной. Почему ошибка возникла в первую очередь? Почему его не поймали на тесте? Почему это произошло, когда это произошло? Подобные вопросы позволяют нам определить истинную причину проблемы.

Полезным упражнением здесь является «[Процесс 5 Почему] (https://buffer.com/resources/5-whys-process/)», который (как следует из названия) включает в себя вопрос «почему?» для каждой последующей первопричины, пока мы не зададим ее пять раз подряд. Если мы будем честны в своих ответах, то велики шансы, что ответ на последнее «почему?» является истинной основной причиной проблемы и местом, на котором мы должны сосредоточить нашу энергию для решения проблемы. Чтобы проиллюстрировать, вот пример «5 почему» на практике из статьи выше:

1. Почему приложение упало?

• Потому что база данных заблокирована.

1. Почему база данных стала заблокированной?

• Потому что было слишком много операций записи в базу данных.

1. Почему мы делаем так много операций записи в базу данных?

• Потому что этот риск не был предусмотрен и как таковой не тестировался под нагрузкой.

1. Почему не была протестирована загрузка изменений?

• Потому что у нас не настроен процесс разработки, когда мы должны загружать тестовые изменения.

1. Почему у нас нет процесса разработки, определяющего, когда загружать тест?

• Мы выходим на новый уровень масштабируемости, поэтому раньше не приходилось проводить нагрузочные тесты.

Принимать меры

После того, как мы определили нашу истинную первопричину (или первопричины), пришло время действовать и поручить это конкретному человеку. Присвоение — важный шаг, потому что если действие никому не принадлежит, оно не будет выполнено. В этом контексте «действие» определяется двумя разными, но важными способами: корректирующие действия и предупреждающие действия.

Корректирующие действия

Корректирующие действия — это реализация решений, которые, как считается, устраняют основную причину наблюдаемой проблемы, дефекта или сбоя. В приведенном выше примере с базой данных корректирующим действием будет реализация нагрузочного теста для устранения конкретного поведения, вызвавшего проблему.

Превентивные действия

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

Закрыть цикл

После того, как элементы действий были назначены, следует запланировать последующую встречу, чтобы закрыть цикл. Будь то две недели или два месяца спустя, команда должна снова собраться вместе, просмотреть пункты действий и подумать, были ли они ценными. Это возможность взять на себя ответственность и убедиться, что мы действительно работаем над улучшением наших основных процессов. Ходить пешком, а не просто болтать.

Также опубликовано на flower.codes.