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



Разбором инцидентов в нашей компании занимается отдел эксплуатации (или, проще, support). Поэтому начну с описания того, как он устроен. В Туту.ру у нас есть некоторый набор продуктов, это — ЖД, авиа, туры, электрички, автобусы. В команде каждого продукта есть специалисты отдела эксплуатации. Также представители нашего отдела есть в кроссфункциональной и инфраструктурной командах.

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

Инцидент (или сбой, ЧП) — это некая критическая (обычно массовая) проблема, которая существенно снижает доступность, корректность, эффективность или надежность бизнес-функционала или инфраструктурных систем.

В рамках процесса управления инцидентами мы ставим перед собой следующие основные цели:

1. Как можно быстрее восстановить работоспособность наших систем.
2. Не допускать возникновения одного и того же сбоя дважды.
3. Своевременно информировать заинтересованных лиц.

Как работали раньше:

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

При этом, существовали очевидные проблемы:

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

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

3. Не было возможности следить за информацией об инциденте в динамике.

4. Отсутствовало понимание того, увидел ли кто-либо сообщение от мониторинга? Среагировал ли? Какие уже выяснили подробности, и есть ли прогресс в решении?

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

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

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

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

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

Что сделали:

• Разделили работу с инцидентами на две фазы — активную и ретроспективную — и начали улучшать каждую из них по отдельности.

• Разработали стандарт обработки ЧП, где зафиксировали все требования и соглашения, описали набор действий, которые обязательны для каждой фазы процесса.

• Начали писать документы-рекомендации, в которых собрали хорошие практики для разных этапов процесса разбора инцидентов.

Теперь подробнее об этих изменениях.

Активная фаза

Направлена на достижение первой цели процесса — быстрое восстановление работоспособности наших систем.

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

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

Это оказалось очень удобной практикой, так как все участники процесса обработки инцидентов собраны в одном месте, и информация о происходящем есть у всех. Часто теперь даже не нужно по очереди обзванивать, допустим, администраторов, чтобы найти того, кто может заняться проблемой. Все необходимые люди есть в чате, и сами отписываются, когда заметили алерт (или их можно призвать). Здесь поясню — у нас нет как такового on-call, поэтому решением инцидентов в нерабочее время занимается тот, кто в этот момент находится возле компьютера. Пока для нас это работает.

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

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

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

• по алертам от мониторинга,

• от наших сотрудников, которые заметили проблему — если мониторинг по каким-то причинам нам о ней не сообщил.

В любом случае, мы должны зафиксировать инцидент в JIRA — для контроля времени возникновения/решения проблемы, а также информирования заинтересованных лиц. Для этого у нас выделен специальный раздел в Service Desk («ЧП-бой»), куда может поставить задачу любой сотрудник компании. Также у нас есть панель, на которой выводятся все активные задачи с этим компонентом. Панель доступна непосредственно из интерфейса постановки задачи в Service Desk, и на ней можно найти ответ на вопрос, есть ли на бою проблема, и решается ли она.
На событие постановки задачи «ЧП-бой» мы настроили отправку автоматического уведомления в Telegram-чат для решения ЧП. Это позволяет быть уверенными, что проблема будет замечена даже в нерабочее время.

Если же мы узнали о проблеме от мониторинга, то задачу «ЧП-бой» мы должны поставить сами. Так как соответствующие алерты приходят в чат, нам показалось удобным автоматизировать постановку задачи в JIRA. Теперь мы можем сделать это нажатием одной кнопки в чате — задача создается от лица специального пользователя для автоматики и содержит текст сработавшего алерта. Таким образом, фиксация инцидента происходит быстро и удобно, мы не тратим на это лишнее время.

Когда приходит задача «ЧП-бой», определяем «штурмана» — человека из отдела эксплуатации, который будет отвечать за то, чтобы сбой устранили. Это не значит, что остальные перестают участвовать в разборе, вовлечены все, но штурман необходим для того, чтобы сотрудники не дублировали действия друг друга. Штурман должен координировать коммуникации и действия по решению инцидента, привлекать необходимые для этого силы. А также своевременно фиксировать информацию о ходе работ, чтобы потом при разборе можно было легко восстановить хронологию.
Штурман назначается исполнителем задачи «ЧП-бой». Когда задача назначена, наши коллеги понимают, что проблемой занимаются, и, в случае чего, знают к кому обращаться с вопросами.
Когда нам удалось устранить негативные эффекты — активная фаза завершена, задача закрывается.

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

Ретроспективная фаза

Начинается непосредственно после завершения активной. Служит достижению второй цели процесса — не допускать повторения одного и того же сбоя.

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

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

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

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

У нас получилась следующая структура документа:

Описание инцидента. Состоит из двух частей. Первая — краткое описание случившегося, с указанием причин и эффекта. Вторая часть — детализация. В ней мы подробно описываем причины, которые привели к инциденту, как мы о нем узнали, как он развивался, какие были записи в логах/сообщения об ошибках, и как в итоге починили. В общем, здесь собирается полная техническая информация о произошедшем.

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

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

Графики и статистика. В этом разделе собираем все графики, которые показывают эффект (например сколько было 5ХХ ошибок), а также любые другие иллюстрации каких-либо аспектов инцидента.

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

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

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

Как решились проблемы активной фазы:

• Не было полной уверенности в том, что на критичный алерт кто-либо подписан.

Сейчас все критичные сообщения от мониторинга выведены в телеграм-чат для решения ЧП, в котором есть все необходимые сотрудники. А чат обязателен для быстрого реагирования в любое время.

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

• Отсутствие в каждый момент времени информации, связанной с инцидентом.

• Несколько специалистов дублировали действия друг друга.

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

Решение проблем ретроспективной фазы:

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

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

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

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

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

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