Перевод статьи Our incident postmortem template
Примечание: Это вольный и дословный перевод указанной статьи выше, который будет написан от лица авторов
Эта статья - заключительная в цикле статей про процессы в работе SRE, в которой авторы публикуют свой шаблон Postmortem с некоторыми моментами, на которые стоит обратить внимание, что можно включить в каждую секцию, плюс примеры лучших практик. Этот шаблон следует принципам, уже описанным в недавнем руководстве по написанию Postmortem и является тем, что нужно держать в уме, прежде чем начать писать Postmortem. Если вы его не читали - убедитесь, что сделали это сначала.
Написание как двухступенчатый процесс
В Hosted Graphite пользователи хорошо технически подкованы и ценят детали событий. Поэтому, для публичных документов мы прилагаем значительные усилия, что бы выбрать правильный язык и уровень детализации для событий. Это значит, что сначала акцент должен быть на как можно более полном и точном сборе информации, а уже после этого текст должен быть приведен к более читаемому виду.
Имея это ввиду, при написании вашего первого черновика (шаг 1) Postmortem, вы должны сфокусироваться на сборе информации, которую хотите включить и проверить ее точность. Этот черновик должен отражать: что случилось, объяснения почему, включить все уроки, которые вы (коллективно) вынесли из этого инциндента. Когда у вас будет положительный отклик на этот черновик - самое время (шаг 2), что бы поработать над языком и тоном этого документа, для того, что бы сделать его достоянием общественности (конечно, если ваша цель - внешняя публикация документа). Это позволит сосредоточиться на правильной подаче информации и разделить проблемы, сфокусировав обзор так, что бы разные проблемы имели разный язык и тон.
Рецензирование документа
В идеальном случае, ваш черновик должны рецензировать все SRE, задействованные в процессе решения инциндента: те кто сделал свой вклад, и те, кто вынес для себя уроки. Как минимум двое SRE должны подписать черновик, прежде чем переходить к шагу два, что также потребует как минимум двоих SRE, прежде чем документ будет готов для публикации.
Если ваш Postmortem был рецензирован (если это публичный документ), вы можете скопировать его на свою страницу Statuspage. Держите в уме, что форматирование документа также имеет большое значение, поэтому перед публикацией необходимо проверить, как будет выглядеть документ.
Обязательно убедитесь, что поделились этим документом с остальной (незадействованной в инцинденте) частью команды SRE. То, что вы пишете Postmortem будет полезно только в том случае, если все в вашей команде смогут прочитать его, поэтому попросите всех выделить время для его прочтения и, по возможности, отправить вам обратный отклик.
Секции
Это простой шаблон с помощью которого можно сфокусироваться на процессах и содержании больше, чем на структуре самого документа. Ниже будет приведено краткое объяснение каждой секции и некоторые советы, касательно написания, а также примеры того, что нужно в него включить.
{% gist 743f4821589972706ef5bb9c67b242bd %}
“Краткое описание”
Это просто краткое описание инциндента: что случилось и (что) какие сервисы были затронуты. Обычно это описание занимает не больше одного-двух предложений. После прочтения этого описания, лицо, незнакомое с инциндентом, должно понять, в чем проблема и почему он должен прочесть этот документ целиком.
“Background”
Помните: Postmortem - это технический документ и иногда его читают те, кто не до конца может его понять. Иногда даже технически подкованная аудитория может иметь проблемы с его пониманием, если будет утерян важный контекст. В этой секции постарайтесь добавить важных деталей, которые нужны для полного понимания всего документа. Для примера, в Postmortem могут быть ссылки на внутренние документы, поэтому имеет смысл кратко объяснить, как они могут быть полезны (и заработать бонусные баллы себе, оставив ссылку на ваш багтрекер).
Когда это возможно, не забывайте добавлять ссылки на публичную документацию и/или записи блогов. Если вы поймете, что объясняете какой-то момент снова и снова - возможно, имеет смысл опубликовать статью об этом в своем блоге для того, что бы была возможность сослаться на эту стать в будущих документах.
“Что произошло?”
Здесь вы рассказываете историю инциндента. Все что произошло, включая временные метки событий, должны быть здесь. Это включает вещи, что случились без нашего ведома (например, увеличение трафика, о котором мы не знали), срабатывание оповещений, действия, которые мы предпринимали, что бы исправить проблему (смягчить последствия). Для долговременных инциндентов, хронология может быть достаточно длинной. Тогда имеет смысл перенести хронологию в отдельную секцию, что бы люди могли ссылаться на нее, если захотят более подробной информации, не загромождая раздел “Что произошло”.
То ценное, что можно добавить в этот раздел - это конкретная (специфическая) информация, которая была у нас, когда мы выполняли какие-то действия. Одно дело сказать, что мы добавили больше емкости в кластер (и не добавить ничего к этому), но другое дело сказать, что мы увидели увеличение нагрузки и задержки в кластере Х и интерпретировали это как проблему в емкости, и решили увеличить емкость кластера. Если впоследствии это предположение окажется неверным - будет понятно, почему мы неправильно решили, почему предприняли конкретное действие и сможем позаботиться о том, что бы в следующий раз получить более точную информацию о статусе инциндента.
“Что прошло хорошо (получилось сделать)?”
“Не все так плохо” (Я имел ввиду, я так думаю… по крайней мере это то, что люди говорят мне!). Даже в случае худшего инциндента некоторые вещи пройдут хорошо. Может быть наш мониторинг очень быстро среагировал и предупредил нас, как раз вовремя, что бы предотвратить дальнейшие проблемы. Может наш балансировщик увел маршруты от затронутых узлов, увеличив задержку к сервисам, но не допустив потерю данных.
Для большинства сервисов есть факторы, которые смягчили ситуацию, не позволив стать ситуации гораздо хуже. Важно понять, что это за факторы, и так они помогут улучшить наше понимание, как сделать так, что бы система работала лучше, чем искать факторы, которые позволили системе стать уязвимой.
“Что прошло плохо (не получилось сделать)?”
Здесь будут вещи, о которых мы не рады будем рассказывать: как случилось так, что произошел инциндент, или где наши утилиты/сервисы подвели нас. Это хорошее место, что бы показать, что мы смогли бы сделать лучше. Здесь будет заключаться хороший стимул для определения необходимых задач, для улучшений в будущем.
Здесь также будут факторы, которые поспособствовали тому, что этот инциндент стал хуже, чем ожидалось сначала. Мы хотим понять эти факторы, и не просто их исправить, но и улучшить свое понимание, как работает наша система и что делает ее менее устойчивой.
“Что мы будем делать в будущем?”
Этот раздел часто интересует наших пользователей. Конечно, все что мы сделали, что бы решить проблему - мы сделали хорошо, однако более важно то, что мы вынесли для себя из этого случая, какие уроки для себя извлекли, что бы данные (метрики) больше не пропадали? Самый важный результат этого документа - это то, что мы узнаем о нашей системе, и о том, как наши сотрудники (команда SRE, итд) взаимодействуют с ней и наши пользователи заслуживают того, что бы конкретные уроки стали конкретными действиями в будущем.
Имея это ввиду, любые запланированные действия должны иметь открытый ticket, что бы убедится, что они не станут “заложниками ситуации”. В нашем внутреннем документе должна быть ссылка на подобный ticket. Для общедоступных Postmortem мы не включаем полное содержание ticket, только оставляем ссылку на него (например: SRE-420; #121242). Это поможет нам лучше отслеживать ход выполнения каких-либо следующих действий и приучать себя к тому, что любое действие в этой секции должно иметь ссылку на ticket. Эти ticket должны быть четко связаны с отслеживанием инциндента (и также иметь ссылку на исходный инциндент на нашей странице статуса).
Пример (плохого содержания):
Мы будем разбрасывать Skittles на наши сервера, что бы они работали быстрее (Ticket: SRE-420).
Явным признаком плохого Postmortem является то, что мы не знаем, что включить в этот раздел или думаем, что нам нечего в него включить. Postmortem, который показывает подобные результаты, лишь означает то, что мы не достаточно хорошо искали причины проблем. Если мы говорим о том, что извлекли для себя полезные уроки из инциндента, а в следующий раз (когда ситуация повторяется) мы не можем придумать, что можно было бы сделать лучше - то это значит, что мы не вынесли для себя правильные уроки. Помните, что “в следующий раз нам повезет больше” или “не делать ошибок в следующий раз” это неправильные уроки.
Вещи, которые нужно держать в уме
Стиль наших Postmortem должен совпадать по стилю Statuspage и другими средствами коммуникации с пользователями (в конце концов, они пишутся одной и той же командой для одних и тех же пользователей).
При (последующем) просмотре Postmortem постарайтесь больше сосредотачиваться на содержании, чем на языке его написания. Конечно, всегда важно правильно понять, о чем говорится в документе, но также важно понять процесс (на основании деталей), который привел к возникновению данного документа, а также извлеченные из него уроки и действия. Помните, что когда вы просматриваете Postmortem, вы также просматриваете и события, которые привели к созданию этого инциндента и финальной версии этого документа (и тут некая рекурсия).
Другие ресурсы
Есть огромное количество замечательных ресурсов вне этого списка, всех не перечислить, но точно нужно прочитать (или хотя бы просмотреть) следущие статьи по ссылкам в списке ниже (в “Дополнительные ссылки”).
На этом все.
Дополнительные ссылки
- “It’s dead, Jim”: How we write an incident postmortem
- Hosted Graphite
- Chapter 15 of the SRE book
- “The infinite hows” - John Allspaw
- Incidents as we Imagine Them Versus How They Actually Are - John Allspaw (video)
- How complex systems fail - Richard Cook
- The Multiple Audiences and Purposes of Post-Incident Reviews
- Some Observations On the Messy Realities of Incident Reviews
- Hindsight and sacrifice decisions