Руководство по DevOps (Ким, Уиллис) - страница 217

Запланируйте встречи для разбора ошибок без поиска виноватых

Чтобы развить в организации культуру беспристрастности, после аварий и значительных инцидентов (например, после неудачного развертывания или проблемы в эксплуатации, повлиявшей на клиентов), когда последствия сбоя уже устранены, нужно провести «послеаварийную ретроспективу» (blameless post-mortem)[145]. Разбор ошибок без поиска виноватых (автор термина — Джон Оллспоу) помогает изучить «ошибки так, чтобы сфокусироваться на ситуационных аспектах механизма сбоя и на процессе принятия решений у человека, стоявшего ближе всех к сбою».

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

Во время совещания по разбору ошибок мы делаем следующее:


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

• мотивируем всех инженеров улучшать безопасность, побуждая их давать подробные описания того, как их действия способствовали возникновению сбоя;

• поощряем людей, совершающих ошибки, становиться экспертами, показывающими остальным, как избежать этих ошибок в будущем;

• допускаем, что всегда есть ситуации, где люди могут действовать только по своему усмотрению, а оценить эти действия можно только в ретроспективе;

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


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


• принимавшие решения, имеющие отношение к проблеме;

• обнаружившие проблему;

• устранявшие проблему;

• диагностировавшие проблему;

• пострадавшие от проблемы;

• все остальные заинтересованные в разборе проблемы.


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

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