Привет! Я — Алексей Ткаченко, руководитель отдела L1 в диджитал-продакшене Далее. Наша команда отвечает за мониторинг работоспособности ресурсов клиентов, оперативно реагирует на проблемы и помогает с ними разбираться. Попутно облегчает жизнь клиентов и менеджеров. Расскажу, зачем бизнесу может понадобиться такой отдел, как строится работа в команде и к каким результатам мы пришли за год.
Немного теории: L1 — служба, которая занимается мониторингом клиентских ресурсов, отвечает на технические вопросы, не требующие специальных знаний. При появлении проблем с работоспособностью сайтов или приложений первой реагирует на инцидент, в случае необходимости подключает следующие линии поддержки: L2 или L3.
Как все привыкли работать с инцидентами
Я думаю, большая часть адекватных агентств и продакшенов ставит ресурсы клиентов на мониторинг после разработки. Цель мониторинга — отслеживать работоспособность ресурса и оповещать команду проекта и клиента об инцидентах.
Чаще всего мониторингом занимаются проджекты. Мы долгое время тоже так жили. Но у этого подхода есть нюансы. Загибайте пальцы.
Менеджеры не всегда будут оперативно включаться в ситуацию
Речь даже не о тех случаях, когда ресурсы падают ночью и приходится поднимать сайт. В рабочее время ваши проджекты могут быть на встрече с другими заказчиками или командой. Поэтому сразу связаться с клиентом, организовать девопсов, чтобы те выяснили причину ошибки и начали с ней разбираться, получится не всегда.
Разбор инцидента занимает время, а другие менеджерские задачи страдают
Чтобы разобраться с инцидентом, нужно организовать работу команды для устранения ошибки, быть в это время на связи с клиентом. При этом часть инцидентов будет незначительной: например, падение работоспособности на пять секунд, после которых ресурс восстанавливался самостоятельно. Уверен, многие с этим сталкивались. По нашей внутренней статистике, таких кейсов было около 70%. Но даже по ним приходили оповещения: и клиенту, и команде. Срабатывание ложной тревоги по итогу стоит времени сотрудникам, а компании — денег.
Проджекты тратят время на отчеты по каждому инциденту
В идеале, по каждому инциденту менеджеру нужно писать отчет. Подробно описывать саму проблему, ее причину, действия, которые предприняла команда, и другие детали. Даже для случаев ложной тревоги. Отчет требует времени: от часа и чуть ли не до рабочего дня в сложных случаях. У проджекта при этом копится бэклог, отчет задерживается, клиент недоволен.
Наверняка есть еще какие-то проблемы, которые мы не упомянули. Можете дополнить список в комментариях. Далее привожу инструкцию по созданию такого отдела.
Как создать такой отдел и за что он должен отвечать
Вот инструкция по созданию отдела, основанная на нашем опыте:
-
Начинаем с разработки алгоритма работы отдела — от приема запроса клиента до подготовки документации. В нем надо прописать, воркфлоу. Ниже привожу базовую схему, которая работает у нас.
-
Затем, учитывая количество проектов и загрузку по обработке инцидентов, рассчитываем, сколько человек нужно в отделе и какой будет предварительный график работы. Мы выбрали график 2/2, так как он лучше всего подходил под условия компании. При таком графике меньше энтропия системы, как следствие, меньше трансакционных издержек на менеджмент внутри компании.
-
Дальше рассчитываете бюджет на отдел и начинаете искать людей. Вот пример рабочих обязанностей специалиста по L1. Можно добавлять к себе в вакансии.
Отдельно прикладываю нашу таблицу расчета почасового графика, откуда мы вывели необходимое количество человек.
Оптимизация процессов, связанных с отработкой инцидентов
Опять же — процессы у каждого свои, но когда мы запускали работу отдела, то сделали следующие шаги:
-
перестроили порядок реагирования и взаимодействия с клиентом;
-
создали систему предупреждения потенциальных проблем;
-
сняли всю коммуникацию по инцидентам и подготовку отчетов с менеджеров и отдали сотрудникам отдела;
-
взяли на себя клиентские обращения по техническому состоянию сайтов;
-
настроили контроль SSL сертификатов и клиентских доменов.
И еще: если у вас краткосрочное падение (менее 5 секунд), то лучше настроить систему так, чтобы оповещения приходили только отделу L1. Причины сбоя в этот момент выясняются отделом. Если тревога не ложная, то дальше она передается в работу команде.
Если же падение более серьезное, то в первые же минуты надо писать проджекту, или девопсам. И только после этого идем к заказчику и сообщаем, что проблему видим и уже решаем. В процессе отвечаем на вопросы клиента, обновляем статусы работы.
Схема работы с проектами
С проектами работа может быть построена по-разному. Например, приходит менеджер и говорит: «Мне нужна техподдержка по проекту. Хочу поставить его на мониторинг, чтобы вы смотрели показатели серверов, отвечали на запросы относительно работоспособности, реагировали на инциденты».
А кто-то просит, чтобы мы просто контролировали работоспособность ресурса, вели статистику по случаям потери работоспособности в неделю, но сами такие кейсы не отрабатывали. Так что тут все зависит от потребностей конкретного бизнеса и его команд.
Однако какую бы схему вы ни выбрали, есть еще один важный артефакт, который вам понадобится при налаживании работы отдела — это карта эскалации для каждого клиента.
В ней должен быть прописан алгоритм действий с конкретным ресурсом по этапам: к кому обращаемся, когда пишем девопсам, как ставим задачи на разбор инцидента, что делаем, если инцидент произошел в нерабочее время и так далее.
Какие трудности возникают в работе отдела
Основные трудности связаны с тем, что сотрудникам не всегда удается оценить характер и масштаб инцидента: если проблема нетипичная, возникает соблазн сразу бежать к девопсам или тимлидам и просить помощи. Это создает определенный риск того, что часы дорогих специалистов будут потрачены впустую.
Мы пока что видим только два основных способа решения проблемы:
-
Повышать уровень технической грамотности специалистов
-
Вводить регламенты, где будет описано множество возможных ситуаций.
Заключение
У каждого аутсорс-подрядчика есть клиенты, с которыми работаешь много лет и вроде бы вы уже закрыли вместе кучу проектов, процессы налажены и все идет своим чередом. Пока однажды сайт или приложение клиента не упадут из-за какого-нибудь инцидента. И несмотря на годы наработанных отношений, можно потерять клиента из-за пары таких кейсов. L1 как раз нужен, чтобы избежать таких ситуаций — когда такая маленькая вещь, как уведомление об алертах, стоит вам крупного контракта.
И спасибо, что дочитали статью. Если у вас есть похожий отдел в компании — делитесь в комментариях. Всем классных проектов и меньше алертов.
Автор: Time_Seeker
