Протокол реакции на инциденты
Мы не только разрабатываем ПО для наших клиентов, но и сами поставляем его в продакшен и поддерживаем. Естественно, иногда случаются аварии и различные инциденты. Ниже описан типовой порядок нашей реакции на инциденты, который настоятельно рекомендуется к использованию во всех командах разработки в ivelum.
Под инцидентом здесь понимается критическая ситуация, требующая немедленной реакции. Примерами инцидентов являются даунтайм каких-либо проектов в продакшене или серьезное нарушение их ключевой функциональности. Некритические проблемы, решение которых может подождать хотя бы один рабочий день, к инцидентам не относятся.
Реакция на инциденты входит в прямые обязанности всех инженеров в ivelum. В случае обнаружения критических проблем с продакшеном ей начинает заниматься тот, кто наиболее близко знаком с данным участком проекта (из тех людей, кто сейчас находится в онлайне, или получил сигнал от автоматизированной системы оповещения). Если в онлайне нет никого, и проблема обнаружена самим клиентом, клиент будет звонить на мобильные номера людей близких к этому проекту. Порядок действий:
- Немедленно подтвердить клиенту в публичном канале чата, что вы онлайн и начали изучать этот вопрос;
- Произвести первоначальную диагностику - понять, воспроизводится ли проблема, и на каком уровне она находится - проблема с приложением, проблема с инфраструктурой или у стороннего провайдера, проблема с контентом, другое;
- Определить, кто может решить данную проблему. Если вы способны сделать это самостоятельно, значит, подтвердить клиенту, что вы уже начали работать над решением. Если это не ваш проект или вы затрудняетесь с решением, значит, постараться связаться с кем-то из команды поддерживающей этот проект, и привлечь его к решению. Если это проблема у стороннего провайдера, значит, отправить запрос в техническую поддержку этого провайдера (если применимо) и продумать, какие могут быть обходные пути решения своими силами;
- В любом из вариантов развития событий следует поддерживать регулярную обратную связь с клиентом через публичный канал чата, или вплоть до окончательного решения проблемы, или же до момента, когда вы согласились с клиентом, что проблема не является критической, и ее решение может подождать;
- Если инцидент относился к серьезным, и включал в себя длительные перебои в работе продакшена, потери данных или другие заметные убытки для клиента (включая репутационные), то сообщите клиенту, что на следующий рабочий день он получит детальный отчет об этом инциденте.
ВАЖНО: даже если случай кажется вам очевидным, не торопитесь предоставлять детальный отчет немедленно, лучше отложите это до завтра. Опыт показывает, что критические инциденты являются стрессовыми ситуациями, и анализ их причин сразу же после их устранения обычно получается некачественным, потому что люди все еще находятся под влиянием эмоций. В стрессовых ситуациях люди склонны винить себя, и могут не видеть картины в целом, например, не осознавать недостатков в существующих процессах работы команды, которые создали предпосылки к возникновению проблемы. Откладывание детального отчета на один день дает вам возможность взглянуть на ситуацию свежим взглядом, и обсудить это с командой.
Отчет пишется кем-либо из команды, поддерживающей данный проект, и он должен быть обязательно осмотрен и утвержден тимлидом этой команды. Отчет должен отвечать на следующие вопросы:
-
Что произошло? В этой части описывается последовательность событий, которая привела к инциденту, и приводится информация о том, какой именно урон был нанесен в результате инцидента. Если это был перебой в работе какого-либо сервиса, нужно указать конкретно - какой сервис не работал, не работал ли он полностью или не работали отдельные функции (какие), и, по возможности, указать точный временной интервал, когда он не работал. Если инцидент связан с потерей или компрометацией данных - указать какие конкретно данные были потеряны или скомпрометированы.
-
Как проблема была устранена? В этой части описываются действия, которые были предприняты командой для решения проблемы, и результаты этих действий.
-
Каковы причины возникновения проблемы? Здесь производится анализ предпосылок к возникновению проблемы. Это могут быть самые различные аспекты - логика, заложенная в ПО, архитектура системы, особенности процессов разработки или поставки кода в продакшен, выбор ненадежных поставщиков сторонних сервисов, человеческий фактор, и др.
-
Что мы предприняли или собираемся предпринять для минимизации этих рисков в будущем? В этом разделе описываются конкретные меры, которые утверждены тимлидом команды для снижения риска возникновения подобных проблем в будущем, или же для минимизации ущерба от подобных проблем.
Чтобы те меры, которые вы запланировали для избежания подобных проблем в будущем, сработали, их нужно выполнить. Это совершенно очевидный факт, но, к сожалению, люди иногда игнорируют это на практике. Каждая команда всегда загружена работой, всегда найдутся "другие более важные" дела, поэтому есть соблазн отодвинуть принятие этих мер на потом, когда появится удобный момент. Не делайте так. Если вы не можете сделать это прямо сейчас, значит, поставьте задачу с четким дедлайном и назначенным исполнителем, и отнесите ее к высокоприоритетным.
English
Русский