Skip to content

Протокол реакции на инциденты

Denis Stebunov edited this page Sep 28, 2017 · 7 revisions

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

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

Первая реакция

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

  1. Немедленно подтвердить клиенту в публичном канале чата, что вы онлайн и начали изучать этот вопрос;
  2. Произвести первоначальную диагностику - понять, воспроизводится ли проблема, и на каком уровне она находится - проблема с приложением, проблема с инфраструктурой или у стороннего провайдера, проблема с контентом, другое;
  3. Определить, кто может решить данную проблему. Если вы способны сделать это самостоятельно, значит, подтвердить клиенту, что вы уже начали работать над решением. Если это не ваш проект или вы затрудняетесь с решением, значит, постараться связаться с кем-то из команды поддерживающей этот проект, и привлечь его к решению. Если это проблема у стороннего провайдера, значит, отправить запрос в техническую поддержку этого провайдера (если применимо) и продумать, какие могут быть обходные пути решения своими силами;
  4. В любом из вариантов развития событий следует поддерживать регулярную обратную связь с клиентом через публичный канал чата, или вплоть до окончательного решения проблемы, или же до момента, когда вы согласились с клиентом, что проблема не является критической, и ее решение может подождать;
  5. Если инцидент относился к серьезным, и включал в себя длительные перебои в работе продакшена, потери данных или другие заметные убытки для клиента (включая репутационные), то сообщите клиенту, что на следующий рабочий день он получит детальный отчет об этом инциденте.

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

Отчет об инциденте

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

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

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

  • Каковы причины возникновения проблемы? Здесь производится анализ предпосылок к возникновению проблемы. Это могут быть самые различные аспекты - логика, заложенная в ПО, архитектура системы, особенности процессов разработки или поставки кода в продакшен, выбор ненадежных поставщиков сторонних сервисов, человеческий фактор, и др.

  • Что мы предприняли или собираемся предпринять для минимизации этих рисков в будущем? В этом разделе описываются конкретные меры, которые утверждены тимлидом команды для снижения риска возникновения подобных проблем в будущем, или же для минимизации ущерба от подобных проблем.

You can’t perform that action at this time.