Postmortem vs CAST
После инцидента обычно остаётся документ.
Что сломалось. Когда заметили. Как восстановили. Что сделаем, чтобы не повторилось.
Это postmortem - разбор, который помогает команде учиться на сбоях.
Но глубина такого разбора бывает разной. Можно восстановить хронологию и найти технический дефект. А можно разобраться, почему существующие проверки, правила и взаимодействие команд позволили этому дефекту дойти до пользователя.
Вот здесь интересен CAST.
Сначала важное уточнение
Postmortem и CAST - разные по назначению вещи.
▪️ Postmortem - практика разбора инцидента и фиксации выводов. Конкретный метод анализа может отличаться от команды к команде.
▪️ CAST - метод анализа на основе теории систем. Он помогает исследовать решения участников, доступную им информацию, ограничения и обратную связь.
Поэтому CAST можно использовать внутри postmortem. Хороший postmortem тоже может учитывать организационные причины - это не эксклюзив CAST.
Что показали в Google
На SREcon26 Americas Ruben Barroso разобрал инцидент Google Maps: после импорта данных US Census на картах появились неправильные названия городов.
Данные прошли проверку. Ошибки обнаружили пользователи.
Первоначальный разбор выявил ограничения инструмента проверки и отсутствие определённой стратегии выборки. Предложили усилить автоматические проверки и ревью.
CAST помог рассмотреть контекст решений:
▪️ Команда считала существующие правила проверки достаточными. Предыдущий опыт поддерживал это представление, хотя новый набор данных имел другие особенности.
▪️ Откат задержался из-за неясного масштаба проблемы и размытой ответственности между командами.
К техническим исправлениям добавились вопросы: как пересматривать правила при изменении данных, кто принимает решение об откате и какую информацию он для этого получает.
Что добавляет CAST
Он задаёт структуру для такого исследования. Нужно понять:
▪️ за что отвечал каждый участник и на что реально мог повлиять;
▪️ какую информацию получал;
▪️ как представлял себе состояние системы;
▪️ какие правила и условия влияли на его действия;
▪️ где потерялась обратная связь.
Подробное в руководстве Nancy Leveson.
Что я бы взял для следующего разбора
Один вопрос:
После аварии у нас уже есть полная хронология, логи и объяснение от разработчиков. У дежурного в три часа ночи были совсем другие вводные. Полезно сначала восстановить их, а уже потом оценивать его действия.
Доклад Google: видео и материалы
#ТехПод #incidentManagement #ProblemManagement #Postmortem #CAST
После инцидента обычно остаётся документ.
Что сломалось. Когда заметили. Как восстановили. Что сделаем, чтобы не повторилось.
Это postmortem - разбор, который помогает команде учиться на сбоях.
Но глубина такого разбора бывает разной. Можно восстановить хронологию и найти технический дефект. А можно разобраться, почему существующие проверки, правила и взаимодействие команд позволили этому дефекту дойти до пользователя.
Вот здесь интересен CAST.
Сначала важное уточнение
Postmortem и CAST - разные по назначению вещи.
▪️ Postmortem - практика разбора инцидента и фиксации выводов. Конкретный метод анализа может отличаться от команды к команде.
▪️ CAST - метод анализа на основе теории систем. Он помогает исследовать решения участников, доступную им информацию, ограничения и обратную связь.
Поэтому CAST можно использовать внутри postmortem. Хороший postmortem тоже может учитывать организационные причины - это не эксклюзив CAST.
Что показали в Google
На SREcon26 Americas Ruben Barroso разобрал инцидент Google Maps: после импорта данных US Census на картах появились неправильные названия городов.
Данные прошли проверку. Ошибки обнаружили пользователи.
Первоначальный разбор выявил ограничения инструмента проверки и отсутствие определённой стратегии выборки. Предложили усилить автоматические проверки и ревью.
CAST помог рассмотреть контекст решений:
▪️ Команда считала существующие правила проверки достаточными. Предыдущий опыт поддерживал это представление, хотя новый набор данных имел другие особенности.
▪️ Откат задержался из-за неясного масштаба проблемы и размытой ответственности между командами.
К техническим исправлениям добавились вопросы: как пересматривать правила при изменении данных, кто принимает решение об откате и какую информацию он для этого получает.
Что добавляет CAST
Он задаёт структуру для такого исследования. Нужно понять:
▪️ за что отвечал каждый участник и на что реально мог повлиять;
▪️ какую информацию получал;
▪️ как представлял себе состояние системы;
▪️ какие правила и условия влияли на его действия;
▪️ где потерялась обратная связь.
Подробное в руководстве Nancy Leveson.
Что я бы взял для следующего разбора
Один вопрос:
Почему это решение казалось человеку разумным в тот момент?
После аварии у нас уже есть полная хронология, логи и объяснение от разработчиков. У дежурного в три часа ночи были совсем другие вводные. Полезно сначала восстановить их, а уже потом оценивать его действия.
Доклад Google: видео и материалы
#ТехПод #incidentManagement #ProblemManagement #Postmortem #CAST