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

Что случилось?

Хронология инцидента от начала до конца, часто вместе с журналами общения или системных ошибок.

Опрос

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

Что нужно исправить?

Что нужно исправить, чтобы улучшить безопасность системы и избежать повторения в будущем подобных инцидентов.

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

Безупречность

Концепция безупречности является противоположной культуре, основанной на обвинениях. Несмотря на то что эта концепция обсуждалась уже несколько лет, в основном Сидни Деккером и его сторонниками, настоящую известность она получила после появления поста Джона Оллспоу, посвященного постмортемам, не содержащим упреков (https://codeascraft.com/2012/05/22/blameless-postmortems/). Суть этого поста заключается в том, что ретроспектива инцидента будет более эффективной в случае акцента на обучении, а не на наказании.

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

Организационное обучение

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

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

Выводы

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

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

Глава 5. Заблуждения и антишаблоны, относящиеся к devops