Разбор инцидентов

Что такое разбор инцидента?

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

• последствия инцидента;
• действия, предпринятые для сокращения последствий или устранения инцидента;
• основная причина инцидента;
• дальнейшие действия, которые были предприняты для предотвращения повторения инцидента.

В Atlassian мы отслеживаем разбор всех инцидентов с помощью задач Jira, чтобы гарантировать выполнение и утверждение итогов разбора. Если требуется вариант попроще, можно использовать другую систему, например создавать для каждого разбора инцидента страницу Confluence.

Почему мы проводим разбор инцидентов?

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

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

• Очные совещания позволяют провести необходимый анализ и согласовать с командой перечень проблем, требующих исправления.
• Предстоящее утверждение итогов разбора руководителями команд доставки и операционной команды заставляет проводить разбор инцидента очень подробно.
• Назначенным приоритетным действиям присваивается согласованный целевой уровень сервиса (SLO), в зависимости от сервиса составляющий 4 или 8 недель. Чтобы гарантировать выполнение этих действий, настраиваются напоминания и отчеты.

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

Когда разбор инцидента необходим?

Мы проводим разбор инцидентов с уровнями опасности 1 и 2. В остальных случаях это не обязательно.

Во время или сразу после устранения инцидента ответственный за разбор создает новую задачу разбора инцидента.

Кто выполняет разбор инцидента?

За выполнение разбора инцидента отвечает команда доставки сервиса, в котором произошел сбой (команда, которой принадлежит «проблемный сервис» в задаче по инциденту). Эта команда выбирает ответственного за разбор инцидента и назначает ему задачу разбора инцидента.

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

У нас есть страница Confluence, на которой перечислены ответственные за утверждение разбора инцидентов (обязательные и необязательные) по группам сервисов — обычно они соответствуют продуктам Atlassian (например, Bitbucket Cloud).

Как отслеживаются действия по итогам разбора инцидента?

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

• Создаем задачу в Jira и помещаем ее в бэклог соответствующей команды. Все действия по разбору инцидента должны отслеживаться в Jira.
• Связываем эти задачи с задачей разбора инцидента как «приоритетные действия» (исправление основных причин) либо как «дополнительные улучшения» (для исправлений, не связанных с основными причинами).

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

Процесс разбора инцидента

Процесс разбора инцидента включает в себя создание задачи разбора инцидента, проведение совещания по разбору инцидента, определение действий, получение утверждения и (необязательно) публикацию результатов.

Ответственный за разбор инцидента должен обеспечить выполнение следующих операций.

1. Создать задачу по разбору инцидента и связать ее с инцидентом.
2. Отредактировать задачу разбора инцидента, прочитать описания полей и заполнить их.
3. Для определения основной причины инцидента выполнить анализ причинно-следственной цепочки методом «Пять "почему"», пока не выяснится подлинная основная причина.
4. Запланировать совещание по разбору инцидента. Используя шаблон приглашения, пригласить к участию команду доставки, а также все команды и заинтересованные стороны, на которые повлиял инцидент.
5. Собрать команду и провести совещание в соответствии с планом, приведенным ниже.
6. По итогам связаться с ответственными менеджерами команды разработки и заручиться их поддержкой при выполнении конкретных действий, которые предотвратят этот тип инцидентов.
7. Создать задачу Jira для каждого действия в бэклогах соответствующих команд. Связать эти задачи с задачей разбора инцидента в качестве «приоритетных действий» (исправление основных причин) либо «дополнительных улучшений» (прочие исправления).
8. Найти подходящих подтверждающих в Confluence и добавить их в поле Approvers (Подтверждающие) задачи по разбору инцидента.
9. Установить статус Request Approval (Запросить подтверждение), чтобы отправить задачу на подтверждение назначенным подтверждающим. К задаче будет автоматически добавлен комментарий с инструкциями по подтверждению.
10. Выполнять дополнительные действия по мере необходимости, пока разбор инцидента не будет утвержден.
11. После утверждения разбора инцидента настройки нашей системы автоматически создают в блоге Confluence черновик материала о разборе инцидента, который можно отредактировать и опубликовать. Публикация разбора инцидентов в блоге предоставляет другим доступ к опыту, полученному в суровых условиях, и тем самым приумножает его ценность.

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

Совещания по разбору инцидента

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

Мы предлагаем следующий план для таких совещаний.

1. Напомнить команде, что разбор инцидентов всегда проводится без поиска виновных (объяснить, почему).
2. Подтвердить график событий.
3. Подтвердить основные причины.
4. Выработать действия путем «мыслей вслух» в ответ на вопрос «Что мы можем сделать, чтобы предотвратить инциденты такого типа в будущем?»
5. Задать участникам вопросы «Что прошло хорошо?», «Что могло пройти лучше?», «В чем нам повезло?»

Возможный шаблон для создания события в календаре.

Пожалуйста, присоединитесь к разбору инцидента <ссылка на инцидент> (без поиска виновных), где мы обсудим <краткое описание инцидента>.

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

На этом собрании мы попытаемся определить основные причины и выработать действия по их устранению.

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

Поля задач по разбору инцидентов

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

Непосредственные и основные причины

При создании или чтении разбора инцидента необходимо различать непосредственные и основные причины.

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

Разбор инцидента проводится с целью выявить основные причины и принять решение о наилучшем способе их устранения. Поиск того самого участка в цепочке событий является настоящим искусством в разборе инцидентов. Используя методы наподобие «Пяти "почему"», пройдите вдоль всей цепочки и найдите основные причины.

Ниже приведено несколько примеров непосредственных и основных причин.

Категории основных причин и соответствующие действия

Мы используем следующие категории для группировки основных причин и обсуждения соответствующих действий по каждой из них.

Основные причины и зависимости

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

Если это внутренняя зависимость, задайте вопрос: «Каков целевой уровень сервиса (SLO) этой зависимости?»

• Был ли нарушен зависимостью заявленный уровень SLO?
  • Ответственность за сбой лежит на владельце зависимости, и он должен повысить ее надежность.
• Зависимость функционировала в рамках SLO, но сервис все равно неудачно завершил работу?
  • Необходимо повысить устойчивость вашего сервиса.
• У зависимости нет уровня SLO?
  • Он ей необходим!

Если это сторонняя зависимость, спросите: «Каковы наши разумные ожидания* относительно доступности, задержки и т. п. этой сторонней зависимости?»

• Сторонняя зависимость превысила наши ожидания (в негативном смысле)?
  • Наши ожидания были неадекватны.
    • Мы уверены, что это не произойдет снова? Например, мы проверили результаты анализа основных причин, проведенного владельцем зависимости, и приняли эти результаты. В этом случае действием является проведенный им анализ основных причин.
    • Или же нам необходимо скорректировать наши ожидания? В этом случае необходимыми действиями будут повышение нашей устойчивости и корректировка наших ожиданий.
    • После корректировки наших ожиданий они оказались неприемлемыми? В этом случае нужно как-то устранить разрыв между требованиями и решением, например найти другого поставщика.
• Сторонняя зависимость функционировала в рамках наших ожиданий, но сервис все равно неудачно завершил работу?
  • В этом случае необходимо увеличить устойчивость сервиса.
• У нас на самом деле нет ожиданий?
  • Владелец сторонней зависимости должен установить ожидаемый уровень производительности и предоставить командам доступ к этой информации. Тогда они будут знать, какой уровень надежности требуется обеспечить для встраивания в зависимые сервисы.

* Почему речь идет об «ожидании»? Разве у нас нет SLA со сторонними поставщиками? В действительности уровни договорных SLA с третьими сторонами слишком низкие, чтобы приносить пользу при определении ответственных сторон и действий по нейтрализации инцидентов. Например, AWS практически не публикует SLA для EC2. Поэтому когда мы зависим от стороннего сервиса, необходимо принять решение о том, какого уровня надежности, доступности, производительности или другого базового показателя будет разумно от него ожидать.

Действия по итогам разбора инцидента

Сью Льюдер и Бетси Бейер из Google выпустили отличную презентацию и статью о действиях по разбору инцидентов. Мы используем эти материалы в Atlassian как подсказку для команд.

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

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

Утверждение результатов разбора

Чтобы обеспечить утверждение итогов разбора инцидентов, в Atlassian используется процесс Jira, содержащий этап утверждения. Утверждающие участники, как правило, являются владельцами сервисов или иными руководителями, несущими ответственность за работу сервиса. Утверждение итогов разбора инцидента означает:

• согласие с выводами в результате проверки, проведенной после инцидента, включая определение основной причины, и
• согласие с тем, что созданные «приоритетные действия» являются приемлемым способом устранения основной причины.

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

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

Разбор инцидентов без поиска виновных

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

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

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

• В начале совещания по разбору инцидента мы заявляем, что он будет проходить без поиска виновных (и объясняем почему).
• Упоминаем сотрудников, называя их роли (например, «дежурный инженер по виджетам»), а не имена. При этом все факты объявляются ясно и недвусмысленно.
• Обеспечиваем, чтобы график разбора инцидента, причинно-следственная цепочка и меры по смягчению последствий были сформулированы в контексте систем, процессов и ролей, а не конкретных лиц.

Наша идея разбора инцидентов без поиска виновных и полезная концепция «вчерашних историй» позаимствованы из эпохальной статьи Джона Оллспоу.