Ретроспективы инцидентов (или посмерти, после инциденты, RCAS и т. Д.)-самая важная часть инцидента. Здесь вы берете дар этого опыта и превращаете его в знания. Затем эти знания возвращаются в продукт, повышая надежность и гарантирование того, что ни один инцидент не является потраченной впустую возможности для обучения. Каждый инцидент является незапланированной инвестицией, и команды должны стремиться максимально использовать его.
Тем не менее, многие команды не могут регулярно выполнять ретроспективы инцидентов. Одной из общих причин этого является то, что повседневные задачи, такие как исправление ошибок, управление пожарными учениями и развертывание новых функций, имеют приоритет, что затрудняет инвестирование в процесс оптимизации после завершения отчета после инцидента. Чтобы максимально использовать каждый инцидент, командам нужен солидный шаблон после инцидента, который может помочь минимизировать когнитивную нагрузку в процессе анализа. Ниже приведен пример того, как может выглядеть всеобъемлющая ретроспектива инцидента.
Это должно содержать 2-3 предложения, которые дают читателю обзор факторов, способствующих инциденту, разрешения, классификация и уровень воздействия на клиента. Чем больше, тем лучше это то, что инженеры смотрят сначала, пытаясь решить для аналогичного инцидента.
Пример: Google Compute Engine Incment #17007 В этом резюме говорится, что «в среду, 5 апреля 2017 года, запросы на балансировщик нагрузки Google Cloud HTTP (S) испытали 25% -ную частоту ошибок в течение 22 минут. Приносим извинения за этот инцидент. Мы понимаем, что балансировщик нагрузки должен быть очень надежным, чтобы вы могли предложить вашим клиентам высококачественный сервис. Мы приняли и будем принимать различные меры, чтобы предотвратить повторение этого типа инцидента ».
Этот раздел должен перечислить участников инцидента, а также какие роли они сыграли. Общие роли включают:
- Командир инцидента: Управляет инцидентом. Их конечная цель состоит в том, чтобы завершить инцидент как можно быстрее.
- Ведущий общения: Отвечает за лидерство в коммуникациях, хотя для небольших инцидентов эта роль обычно подчиняется командиру инцидента.
- Технический лидер: Человек, который осведомлен в рассматриваемой технической области и помогает управлять техническим разрешением, связавшись с экспертами по вопросам.
- Писец: Человек, который, возможно, не полностью активен в инциденте, а транскрибирует ключевую информацию во время инцидента. У вас может быть один или ни один из них в зависимости от того, как вы структурируете инцидент.
В этом разделе описывается уровень воздействия на клиента. Сколько клиентов повлияло на инцидент? Клиенты теряли частичную или общую функциональность? Добавление тегов также может быть полезным, чтобы помочь в будущей отчетности, фильтрации и поиске.
Пример: Инцидент Google Cloud Networking #19009 В разделе под названием «Подробное описание удара» авторы тщательно разбили, на которые повлияли пользователи и возможности.
Этот раздел невероятно важен для обеспечения того, чтобы подотчетность в отношении решения вопросов, способствующих инцидентам, вновь ожидает. Последующие действия могут включать модернизацию вашего мониторинга и наблюдения, исправления ошибок или даже более крупные инициативы, такие как рефакторирование части базы кода. Лучшие последующие действия также подробно описывают, кто несет ответственность за элементы, а когда остальная часть команды должна ожидать обновления.
Пример: Инцидент с безопасностью Sentry (12 июня 2016 г.) В то время как подробные элементы действия редко видны для общественности, Sentry опубликовал список улучшений, которые команда планировала сделать после этого отключения, охватывающего как исправления, так и изменения процесса.
С увеличением сложности системы сложнее, чем когда -либо, точно определить коренную причину для инцидента. Каждый инцидент может иметь несколько зависимостей, которые влияют на обслуживание. Каждая зависимость может привести к элементам действия. Так что нет единой основной причины. Чтобы определить способный фактор, рассмотрите возможность использования «потому что, почему» утверждения.
Пример: Трэвис CI на основе контейнеров Linux точная инфраструктура Аварийное обслуживание В этой ретроспективе авторы охватывают такие факторы, как изменение в Docker Backend, выполняют сценарии сборки, отсутствующие покрытия с точки зрения предупреждения об ошибках и многое другое.
Этот раздел является одним из самых важных, но в то же время один из самых редко заполненных. Повествовательный раздел Вы пишете инцидент, как будто рассказываете историю.
Кто такие персонажи и как они чувствовали и отреагировали во время инцидента? Каковы были сюжетные точки? Чем закончился рассказ? Это будет неполным без точки зрения каждого.
Убедитесь, что вся команда, вовлеченная в инцидент, получает шанс написать свою собственную часть этого повествования, будь то с помощью асинхронного сотрудничества документов, шаблонов или других средств.
График является важным снижением инцидента. В нем подробно описываются самые важные моменты. Он может содержать ключевые коммуникации, снимки экрана и журналы. Это часто может быть одной из самых трудоемких частей отчета после инцидента, поэтому мы рекомендуем инструмент для автоматизации. Сроки могут быть автоматически агрегированы через Инструмент Анкет
Технический анализ является ключом к любой успешной ретроспективе. В конце концов, это служит записью и возможным разрешением для будущих инцидентов. Любая информация, относящаяся к инциденту, от графиков архитектуры, до связанных инцидентов, для повторяющихся ошибок, должна быть подробно описана здесь.
- Вот несколько вопросов, чтобы ответить с вашей командой:
- Вы видели такой инцидент раньше?
- Эта ошибка произошла ранее, и если да, то как часто?
- Какие зависимости вступили в игру здесь?
В основе каждого инцидента лежит команда, пытающаяся исправить корабль. Но как идет этот процесс? Ваша команда запаниковала, висит нитью и полагаясь на героизм? Или у вашей команды есть кодифицированный процесс, который делает всех прохладными? Настало время подумать о том, как команда работала вместе.
- Вот несколько вопросов, чтобы ответить на вашу команду:
- Что прошло хорошо?
- Что прошло плохо?
- Где вам повезло и как улучшить движение вперед?
- Ваш мониторинг и оповещение запечатлели эту проблему?
Коммуникация во время инцидента является необходимостью. Заинтересованные стороны, такие как менеджеры, линейка бизнеса (то есть продажи, поддержка, PR и т. Д.) Уровень C, а также клиенты будут нуждаться в обновлениях. Но общение внутри и снаружи может выглядеть совсем по -другому. Даже общение внутри может отличаться между тем, что вы бы отправили VPE, против вашей команды по продажам.
Здесь документируйте обмен сообщениями, которые были распространены в различных категориях заинтересованных сторон. Таким образом, вы можете создать шаблоны для будущего, чтобы продолжать оптимизировать общение.
Пример: Google Compute Engine Incment #15056 В этом инциденте Google гарантирует, что все основные обновления регулярно сообщаются. Команда также дает пользователям знать, когда они могут ожидать, что будут обновлены. «Мы все еще работаем над восстановлением услуг Google Compute Engine Disks в Европе-WEST1-B. Мы предоставим еще одно обновление статуса к 19:00 США/Тихоокеанский регион с текущими деталями».
- Сделайте отчет в течение 48 часов
- Убедитесь, что отчеты размещены таким образом, чтобы их можно динамически вспять во время инцидентов
- Добавить графику и диаграммы, чтобы помочь читателям визуализировать инцидент
- Быть безупречным. Помните, что все делают все возможное, и неудача — это возможность выучить
Неудача является самым мощным инструментом обучения, и заслуживает времени и внимания. Каждая ретроспектива, которую вы завершаете, подталкивает вас к оптимальной надежности. В то время как они требуют времени и усилий, результатом является артефакт, который полезен еще долго после разрешения инцидента.
Используя этот шаблон, ваша команда находится на пути к в полной мере использовать каждый инцидент.
Если вам понравился этот пост в блоге, проверьте эти ресурсы:
- Список публичных посмерти : Коллекция посмерти, ретроспективы инцидентов и многое другое от различных компаний по всей отрасли.
- 5 лучших практик в области гвоздей посмерти : 5 лучших практик, которые ваша команда может начать использовать сегодня, чтобы вывести вашу ретроспективу на новый уровень.
- Улучшение посмертных практик с ветераном Google SRE, Steve McGhee : Ветеран Google Стив МакГи дает совет по своему опыту в этой области.
- Улучшение посмертных матчей от дел до мастер -класса с Полом Османом : Пол Осман рассказывает о том, как вы можете узнать больше о ваших инцидентах.
Оригинал: «https://dev.to/blameless/the-ultimate-free-incident-retrospective-template-48a6»