Close

Путь к успешному управлению инцидентами начинается здесь

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

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

Справочник по управлению инцидентами

Закажите печатную версию нашего справочника или скачайте PDF-версию

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


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

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

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

В 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. Задать участникам вопросы «Что прошло хорошо?», «Что могло пройти лучше?», «В чем нам повезло?»

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

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

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

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

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


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

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

Поле

Инструкции

Пример

Краткое описание инцидента

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

В период <временной диапазон инцидента, например с 14:30 до 15:00> <дата> <количество> клиентов жаловались на <симптомы события>. Событие было вызвано развертыванием в <время развертывания или изменение, которое привело к инциденту>. Развертывание содержало изменение кода для <описание изменения или его причина>. Баг в этом развертывании вызвал <описание проблемы>.

Событие было обнаружено <система>. Мы смягчили последствия события путем <действия, предпринятые для решения проблемы>.

Этот инцидент <уровень опасности> затронул X% клиентов.

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

Предшествующие события

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

В <время> <дата> (<время, прошедшее до момента проявления проблемы у клиентов>) в <продукт или сервис> было внесено изменение, чтобы <описание изменений, приведших к инциденту>. Изменение вызвало <описание последствий изменений>.

Сбой

Опишите, что не работало должным образом. Прикрепите снимки экрана с соответствующими схемами или данными о сбое.

<Количество> ответов были некорректно отправлены на X% запросов в течение <период времени>.

Воздействие

Опишите, что видели внутренние и внешние клиенты во время инцидента. Укажите, сколько поступило заявок в поддержку.

В течение <промежуток времени> между <временной диапазон> <дата> наблюдалось <описание инцидента>.

Это затронуло <количество> клиентов (X% общего количества клиентов <система или сервис>), у которых происходило <описание симптомов, которые испытывали на себе клиенты>.

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

Обнаружение

Когда и как в Atlassian обнаружили инцидент?

Как можно было ускорить обнаружение? В качестве упражнения на сообразительность ответьте на вопрос: как бы вы сократили это время вдвое?

Инцидент был обнаружен, когда сработало <тип оповещения> и было отправлено сообщение <команда или человек, которому было отправлено сообщение>. Затем им пришлось отправить сообщение <человек или команда, отреагировавшие на инцидент вторыми>, потому что они не отвечали за работу сервиса, осуществлявшего запись на диск, что вызвало задержку реагирования на <промежуток времени>.

<Описание улучшения> будет подготовлено <команда, отвечающая за улучшение> с целью <эффект от улучшения>.

Ответ

Кто отреагировал, когда и как? Были ли какие-то задержки или барьеры, препятствующие устранению инцидента?

После отправки сообщения инженеру KITT в 14:34 UTC он вышел в сеть в 14:38 и присоединился к чату для обсуждения инцидента. Однако дежурный инженер не имел достаточного опыта работы с инструментом автомасштабирования Escalator, поэтому в 14:50 было отправлено дополнительное оповещение старшему инженеру KITT, который присоединился к чату в 14:58.

Восстановление

Опишите, как и когда была восстановлена работа сервиса. Как вы подошли к пониманию того, как можно смягчить последствия инцидента?

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

Меры по восстановлению принимались в трех направлениях.

  • Увеличение размера EC2 ASG для BuildEng, чтобы увеличить количество доступных узлов для обслуживания рабочей нагрузки и сократить вероятность планирования задач на перегруженных узлах.

  • Отключение инструмента автомасштабирования Escalator, чтобы предотвратить активное масштабирование кластера в сторону уменьшения.

  • Возврат планировщика Build Engineering к предыдущей версии.

График

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

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

Часовой пояс всех временных отметок: UTC.

11:48 - завершено обновление плоскости управления K8S 1.9
12:46 - завершено обновление Goliath до версии 1.9, включая средство автомасштабирования кластера и инстанс планировщика BuildEng
14:20 - Build Engineering сообщает о проблеме инженеру KITT Disturbed
14:27 - KITT Disturbed начинает изучение сбоев на конкретном инстансе EC2 (ip-203-153-8-204)
14:42 - KITT Disturbed блокирует конкретный узел
14:49 - BuildEng сообщает, что проблема затрагивает несколько узлов. Обнаружено 86 проблемных инстансов, что говорит о системном характере сбоев
15:00 - KITT Disturbed предлагает переключиться на стандартный планировщик
15:34 - BuildEng сообщает о 300 неудачно отработавших подах
16:00 - BuildEng принудительно завершает все неудачные сборки с отчетами OutOfCpu
16:13 - BuildEng сообщает, что сбои не были временными и постоянно повторяются с новыми сборками.
16:30 - KITT определяет возникшие сбои как инцидент, и начинает обрабатывать их соответствующим образом.
16:36 - для облегчения проблемы KITT отключает инструмент автомасштабирования Escalator, чтобы предотвратить изъятие вычислительных ресурсов.
16:40 - KITT подтверждает, что состояние группы автомасштабирования стабилизировалось, загрузка кластера нормальная и последствия для клиентов устранены.

Пять «почему»

Используйте этот метод определения основной причины.

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

Документируйте свои «почему» в виде списка здесь или на диаграмме, прикрепленной к задаче.

  1. Сбой сервиса произошел, потому что была заблокирована база данных.

  2. Потому что было слишком много операций записи в базу данных.

  3. Потому что в сервис было внесено изменение, а увеличения активности не ожидалось.

  4. Потому что в нашем процессе разработки не учитывается необходимость нагрузочного тестирования изменений.

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

Основная причина

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

Баг <причина бага или сервис, где он обнаружился> в обработке пула подключений привел к разрывам подключений в условиях сбоя. Это наложилось на отсутствие возможности наблюдать за состоянием соединений.

Проверка бэклога

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

Честная оценка на этом этапе поможет проверить принятые ранее решения по приоритетам и рискам.

Конкретных задач нет. Есть известные текущие задания по улучшению типизации контекста исполнения, связанные с некоторыми стандартами (например, добавлять типы в зависимости от контекста исполнения при изменении/создании файла). Создавались заявки на исправление интеграционных тестов, но попытки их реализации пока не завершились успехом.

Повторение

Этот инцидент (с той же основной причиной) происходил раньше? Если да, почему он произошел снова?

Та же самая основная причина привела к инцидентам HOT-13432, HOT-14932 и HOT-19452.

Полученный опыт

Какой опыт мы получили?

Обсуждаем, что прошло хорошо, что могло пройти лучше и в чем нам повезло, чтобы найти возможности улучшения.

  1. Необходим юнит-тест, который проверял бы настройку ограничителя скорости для рабочей нагрузки.

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

  3. Пакетные операции должны запускаться постепенно и контролироваться. Наращивание операций должно происходить при номинальных значениях показателей сервиса.

Корректирующие действия

Что мы планируем предпринять для предотвращения таких инцидентов в будущем? Кто выполнит необходимые действия и к какому сроку?

Свяжите приоритетные действия с задачами. Это поможет отслеживать каждое действие.

  1. Временно ввести в действие ручное ограничение скорости автомасштабирования, чтобы уменьшить вероятность отказов.

  2. Юнит-тестирование и повторная реализация ограничения скорости выполнения заданий.

  3. Введение дополнительного механизма сбора информации о скорости распределения по кластеру для контроля последствий масштабирования.

  4. Для больших миграций необходима координация, поскольку AWS ES не поддерживает масштабирование.

  5. Проверить, что поиск Stride по-прежнему классифицирован как Tier-2.

  6. Отправить заявку в случае частичного (а не полного) сбоя работы pf-directory-service при неудачном завершении операции xpsearch-chat-searcher.

  7. Оповещение Cloudwatch на случай повышения нагрузки ввода-вывода в кластере ElasticSearch.


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

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

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

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

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

Сценарий Непосредственная причина и действие Основная причина Устранение основной причины

В сервисах команды Red Dawn в Stride не было мониторинга Datadog и оповещений для дежурных (либо они были неправильно настроены).

Участники команды не настроили мониторинг и оповещения для новых сервисов.

Настроить все необходимое для этих сервисов.

Отсутствует процедура запуска новых сервисов, включающая настройку мониторинга и оповещений.

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

Stride невозможно использовать в IE 11 из-за обновления Fabric Editor, который не работает в этой версии браузера.

Обновление зависимости.

Отменить обновление.

Отсутствие тестирования на кросс-браузерную совместимость.

Автоматизировать непрерывное тестирование на кросс-браузерную совместимость.

Записи из Micros EU не попадали в сервис ведения журналов.

Роль, предоставленная Micros для отправки записей, была некорректной.

Исправить роль.

Нет возможности определить, когда не работает отправка журналов из той или иной среды.

Добавить функцию мониторинга и оповещения об отсутствующих журналах для всех сред.

Вследствие произошедшего ранее инцидента AWS узлы Confluence Vertigo исчерпали свой пул соединений с медиасервером. Это в свою очередь привело к перебоям подключения и ошибкам при доступе к мультимедийным материалам у клиентов.

Сбой AWS.

Получить разбор инцидента AWS.

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

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


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

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

КАТЕГОРИЯ

Определение

Что следует сделать на этот счет?

Баг

Изменение, внесенное Atlassian в код (особый тип изменения)

Тестировать. Проводить канареечные тесты. Выполнять инкрементные развертывания и контролировать их. Использовать флаги возможностей. Обсудить это с инженером по качеству.

Изменение

Изменение, внесенное Atlassian (не изменение кода)

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

Масштаб

Неудачное масштабирование (например, не учтены ограничения ресурсов или отсутствует планирование производительности)

Каковы ограничения ресурсов вашего сервиса? Осуществляется ли мониторинг, установлены ли для них оповещения? Если у вас нет плана производительности, создайте его. Если он есть, то какое дополнительное ограничение нужно принять в расчет?

Архитектура

Несоответствие проектного решения эксплуатационным условиям

Проверить проектное решение. Нужно ли менять платформу?

Зависимость

Сбой стороннего сервиса (не принадлежащего Atlassian)

Управляете ли вы риском стороннего сбоя? Было принято решение допустить этот риск или необходимо разработать меры для его снижения? См. раздел «Основные причины и зависимости» ниже.

Неизвестно

Определение отсутствует (требуется действие для увеличения потенциала диагностирования)

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


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

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

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

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

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

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

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


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

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

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

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

КАТЕГОРИЯ Вопрос, который нужно задать Примеры

Исследование инцидента

«Что стало причиной этого инцидента и почему?» Ваша истинная цель — определение основных причин.

анализ журналов, создание диаграммы прохождения запроса, проверка дампов памяти

Смягчение последствий инцидента

«Какие действия мы немедленно предприняли для решения проблемы и управления этим конкретным событием?»

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

Устранение ущерба, причиненного этим инцидентом

«Как мы устранили непосредственный или косвенный ущерб от этого инцидента?»

восстановление данных, ремонт устройств, удаление искаженных маршрутов трафика

Обнаружение инцидентов в будущем

«Как мы можем сократить время точного обнаружения подобных сбоев?»

мониторинг, оповещения, проверки достоверности ввода/вывода

Смягчение последствий инцидентов в будущем

«Как мы можем уменьшить опасность и/или продолжительность подобных инцидентов в будущем?»

«Как мы можем уменьшить процент пользователей, затрагиваемых сбоями этого типа, если они будут происходить снова?»

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

Предотвращение инцидентов в будущем

«Как мы можем предотвратить повторение такого рода сбоев?»

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

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

Формулировка действий по разбору инцидентов

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

Быть выполнимым. Формулируйте каждое действие как предложение, начинающееся с глагола. Указанное действие должно привести к полезному результату, а не процессу. Например, «Соберите список важнейших зависимостей» является хорошо сформулированным действием, а «Исследуйте зависимости» — нет.

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

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

Исходный вариант Как надо

Исследуйте мониторинг для этого сценария.

Добавьте оповещения для всех случаев, когда этот сервис возвращает >1% ошибок. (Выполнимость.)

Исправьте проблему, которая привела к отказу.

Реализуйте защиту от неправильного ввода почтового индекса в форме адреса пользователя. (Конкретность.)

Убедитесь, что перед обновлением инженер проверил возможность парсинга для схемы базы данных.

Добавьте автоматическую проверку изменений схемы перед отправкой. (Ограниченность.)


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

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

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

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

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


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

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

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

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

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

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

Сохраняйте спокойствие и продолжайте

Вы дочитали наш справочник по разбору инцидентов до конца. Спасибо за внимание!

Если у вас есть какие-либо комментарии или предложения, напишите нам по адресу incident-handbook@atlassian.com.

продолжение темы
Template generator