Привет, Хабр! Я — Алексей Ткаченко, руководитель отдела L1 в диджитал-продакшене Далее. Наша команда отвечает за мониторинг работоспособности ресурсов клиентов, оперативно реагирует на проблемы и помогает с ними разбираться. Попутно облегчает жизнь клиентов и менеджеров. Расскажу, зачем бизнесу может понадобиться такой отдел, как строится работа в команде и к каким результатам мы пришли за год. 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• перестроили порядок реагирования и взаимодействия с клиентом;  

• создали систему предупреждения потенциальных проблем; 

• сняли всю коммуникацию по инцидентам и подготовку отчетов с менеджеров и отдали сотрудникам отдела;

• взяли на себя клиентские обращения по техническому состоянию сайтов; 

• настроили контроль SSL сертификатов и клиентских доменов. 

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

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

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

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

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

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

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

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

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

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

1. Повышать уровень технической грамотности специалистов

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

Заключение

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

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