Как собрать и запустить отдел по работе с инцидентами в продакшене — разбираемся в статье-инструкции

Меня зовут Алексей Ткаченко, руководитель отдела L1 в диджитал-продакшене Далее.

Алексей Ткаченко
Руководитель отдела L1

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

Как собрать и запустить отдел по работе с инцидентами в продакшене — разбираемся в статье-инструкции

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

Как все привыкли работать с инцидентами

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

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

Менеджеры не всегда будут оперативно включаться в ситуацию

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

Разбор инцидента занимает время, а другие менеджерские задачи страдают

Чтобы разобраться с инцидентом, нужно организовать работу команды для устранения ошибки, быть в это время на связи с клиентом. При этом часть инцидентов будет незначительной: например, падение работоспособности на пять секунд, после которых ресурс восстанавливался самостоятельно. Уверен, многие с этим сталкивались. По нашей внутренней статистике, таких кейсов было около 70%. Но даже по ним приходили оповещения: и клиенту, и команде. Срабатывание ложной тревоги по итогу стоит времени сотрудникам, а компании — денег.

Проджекты тратят время на отчеты по каждому инциденту

В идеале, по каждому инциденту менеджеру нужно писать отчет. Подробно описывать саму проблему, ее причину, действия, которые предприняла команда, и другие детали. Даже для случаев ложной тревоги. Отчет требует времени: от часа и чуть ли не до рабочего дня в сложных случаях. У проджекта при этом копится бэклог, отчет задерживается, клиент недоволен.

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

Как создать такой отдел и за что он должен отвечать

Пошаговая инструкция

Инструкция по созданию отдела, основанная на нашем опыте:

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

Как собрать и запустить отдел по работе с инцидентами в продакшене — разбираемся в статье-инструкции

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

3. Дальше рассчитываете бюджет на отдел и начинаете искать людей. Вот пример рабочих обязанностей специалиста по L1. Можно добавлять к себе в вакансии.

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

Как собрать и запустить отдел по работе с инцидентами в продакшене — разбираемся в статье-инструкции

Пояснение к цифре, если не понятно: нам нужно, чтобы Л1 был на связи 24/7 круглый год. Соответственно нам нужно, чтобы в год они вырабатывали 8760 часов. Эту цифру мы делим на 1645 часов (среднее кол-во рабочих часов специалиста за год). И отсюда получаем, что нужно 5 человек.

Оптимизация процессов, связанных с отработкой инцидентов

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

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

И еще: если у вас краткосрочное падение (менее 5 секунд), то лучше настроить систему так, чтобы оповещения приходили только отделу L1. Причины сбоя в этот момент выясняются отделом. Если тревога не ложная, то дальше она передается в работу команде.

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

Схема работы с проектами

С проектами работа может быть построена по-разному. Например, приходит менеджер и говорит: «Мне нужна техподдержка по проекту. Хочу поставить его на мониторинг, чтобы вы смотрели показатели серверов, отвечали на запросы относительно работоспособности, реагировали на инциденты».

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

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

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

Это лишь кусочек карты, визуализация 1 этапа. Полную карту в PDF можно взять <a href="https://api.vc.ru/v2.8/redirect?to=https%3A%2F%2Fdrive.google.com%2Ffile%2Fd%2F16d1ZsEyzaDxaLA7avTpvhMZDqzlw8AQi%2Fview%3Fusp%3Dsharing&postId=1472031" rel="nofollow noreferrer noopener" target="_blank">по ссылке с Диска</a>.
Это лишь кусочек карты, визуализация 1 этапа. Полную карту в PDF можно взять по ссылке с Диска.

Какие трудности возникают в работе отдела

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

Мы пока что видим только два основных способа решения проблемы:

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

Заключение

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

И спасибо, что дочитали статью. Если у вас есть похожий отдел в компании — делитесь в комментариях. Всем классных проектов и меньше алертов.

Где нас найти

Да, тут будет ссылка на наш телеграм-канал :) Вот она.

Публикуем там вакансии, анонсы и просто интересный контент на подумать и поразмышлять.

88
Начать дискуссию