С целью изучить реальный опыт компаний по организации DevOps в целом и службы поддержки в частности, я решил взять интервью у TeamLead-а крупной аутсорсинговой компании. И привожу здесь первую часть своего интервью.
Интервьюер: Здравствуй. Расскажи, пожалуйста, о вашем опыте организации рабочего процесса и о том можешь ли ты назвать его идеальным для данной отрасли.
TeamLead: Здравствуй. Я думаю, идеального опыта не может быть, так как он сильно отличается от того, чем конкретно занимается компания.
Интервьюер: А какая разница?
TeamLead: Разница в подходах, разница в деньгах, разница во многих факторах. Даже, если сравнивать бизнес в разных странах СНГ, то увидишь совершенно разные ценности. Что-то более важно в одной стране, что-то в другой.
Интервьюер: Я немного не об этом. Исходя из моего опыта, нет двух компаний, в которых одинаково построена поддержка. Но мне хотелось бы узнать твое мнение: можно ли организовать бизнес-процесс наиболее оптимальным способом, и чтобы он был хорош, возможно, идеален, для разных заказчиков. Вот, например, в чем отличие между вами и вашими ближайшими конкурентами.
TeamLead: Я думаю, мы отличаемся только подходами к работе.
Интервьюер: Можно это как-то формально описать?
TeamLead: Наш президент компании периодически выступает декларируя ключевые ценности. Мы продаем эффективное управление. То есть, в первую очередь, умение правильно, легко доносить информацию до заказчика, то что многие люди любят называть visibility. Мы стремимся к тому, чтобы заказчик всегда знал: на какой стадии сейчас находится проект, что с ним сейчас происходит, хорошо или плохо. И вот это правильное управление, грубо говоря, экономит их деньги.
Интервьюер: Хорошо. Но, по большому счету, visibility – штука хорошая, но, опять же, никто из любой другой компании (ваших коллег по рынку) не скрывает от заказчика, куда он тратит их деньги. Они, как и вы, высылают репорты…
TeamLead: Тут дело немного в другом. Например, когда я пришел работать сюда, для меня явилась неким откровением, например, структура написания писем: как правильно излагать информацию внутри письма; что помечать, как важное; или, например, простые вещи, как правильно нумеровать письмо. У нас все эти вещи описаны в дедлайнах или статусах работы. И они минимизируют лишние вопросы, лишние итерации в коммуникациях и так далее. То есть мы продаем эффективные коммуникации. Мы предоставляем такой формат изложения информации, который позволяет заказчику минимум тратить времени для того, чтобы с нами сотрудничать. Это ключевая ценность, которая продается в компании. Помимо нее, есть еще какие-то технические вещи сопутствующие, но основной упор именно на это.
Интервьюер: Но, по большому счету, бизнес-процессы в поддержке, они же не сильно отличаются.
Рисунок 1-Основные задачи техподдержки
TeamLead: Основная компетенция нашей компании – это не поддержка. Точно так же, как и у наших коллег-конкурентов. У них основное – это идет разработка и development, а поддержка и 24 на 7 – это сопутствующие сервисы. Потому что они хотят оказать заказчику полный цикл услуг и поэтому они включают дополнительные пункты. Соответственно, у нас примерно такая же структура. Очень редко, когда бывает проект, в котором нужно только 24 на 7. Чаще всего там нужна разработка, нужно тестирование, заказчикам нужен хороший проджект менеджер, но они хотели бы, чтобы мы и поддерживали продукт, который мы выпустили для них. И поэтому мы занимаемся саппортом, мы занимаемся поддержкой своего проекта.
Интервьюер: Получается задачи поддержки, которые ложатся на ваши плечи, потому что вы разработали это продукт и отдавать его кому-то еще нелогично?
TeamLead: Нелогично, плюс это всегда лишнее время, которое нужно потратить. Потому что одно дело – это взять своего же инженера, который деплоил код или разрабатывал код, потратить с ним в переговорной комнате 20 минут и он тебе расскажет, как он все это делал. То есть перехватить проект по саппорту гораздо легче у себя внутри, чем вывести его и предоставить весь пакет документации, описания своих внутренних процессов и так далее, для того, чтобы кто-то (сторонняя организация) мог адекватно поддерживать этот продукт. Поэтому проще, конечно же внутри организоваться и сделать еще и поддержку. Ну, и, в принципе, мы считаем, что у нас качество поддержки достаточно высокое. Я не знаю, что там есть у ребят в других компаниях, но у нас 24 на 7 и по нему достаточно жесткие требования по времени реагирования, апдейтам и так далее.
Интервьюер: Следующий мой вопрос: как устроено время реакции?
TeamLead: Время реакции у нас описано следующим образом: после оповещения (у нас сложная система оповещений по разным sms-провайдерам и по разным вообще системам), то есть после того, как инженер уведомлен о том, что у него возник срочный тикет, за 5 минут должен подключиться к серверу и написать: «Здравствуй, заказчик, мы проверяем, что у тебя там происходит». И дальше он должен давать заказчику регулярные апдейты о состоянии тикета, в котором он находится, что он нашел, что он успел сделать, что происходит. Ну и, естественно есть процедуры эскалации.
Рисунок 2-каналы информирования оператора техподдержки
Интервьюер: Это первая линия поддержки, которая сразу реагирует на оповещения?
TeamLead: Да, а после этого есть flow, для работы с тикетом, которое выстроено в зависимости от проекта, либо, чаще всего, есть просто выделенный человек, который больше вовлечен в проект, владеет большим количеством информации.
Интервьюер: Ну, скажем, главный инженер?
TeamLead: архитектор или инженер поддержки, который более тесно работает с проектом. Какой-то человек, который более глубоко технически знает, как все устроено. То есть с помощью первой линии техподдержки ты можешь отсечь каких-либо навязчивых ботов, которые пришли поштормить твой сайт, ты можешь залочить парочку айпишников, ты можешь ребутнуть какой-то сервачок, если у него что-то пошло не так. То есть, простые кейсы разрешить с помощью ребят из 24 на 7. Все, что сложнее, эскалируется. Но эскалаций, на самом деле, не много. Потому что в любом, нормально настроенном проекте, эскалации встречаются крайне редко. И ситуация, когда специалист первой линии звонит кому-то из инженеров посреди ночи и говорит: «Ребята, подскажите, что происходит, я хочу разобраться» случается нечасто.
Интервьюер: А почему такое случается нечасто? Потому что уровень инженера очень хороший или потому что нормально прописаны действия инженера для разных ситуаций?
TeamLead: Я думаю, что здесь как раз комплекс. С одной стороны, мы пытаемся постоянно апдейтить документацию, делать регулярные совместные созвоны, а, если появляется новый проект, то это обязательно доносим до всех сотрудников службы 24 на 7. Рассказываем, что в проекте как устроено, где находятся сервера. Пытаемся на каждый этап доставлять документацию. Плюс, мы очень не любим менять наших инженеров, большинство из них работают достаточно долго, они уже хорошо знают свои проекты. Их уровень и общетехнический и уровень погружения в проекты очень высокий. Да и сами по себе серьезные сбои случаются крайне редко, потому что-либо это настроена какая-то полнофункциональная система, которая легко восстанавливается, либо процесс построен так, чтобы минимизировать всплески активности и количество звонков посреди ночи лидам или техническим специалистам с просьбой разъяснить, что происходит.
Интервьюер: А какое количество человек первой линии, в принципе выходит на смену?
TeamLead: У нас есть два человека задействованных в дневную смену и три в ночную.
Интервьюер: Они по 12 часов работают?
TeamLead: Да, примерно так получается.
Интервьюер: 12-часовая смена – это пожелание сотрудников или производственная необходимость?
TeamLead: Тут надо прояснить, что есть разные виды поддержки. Например, есть поддержка, когда человек сидит у монитора и должен делать всякие репорты, следить за каким-то там ростом трафика и тому подобные вещи. Наши ребята, которые работают днем, они, собственно, и выполняют вот эту работу по предиктивному анализу, по каким-то сбоям, то есть то, что связано непосредственно с устранением либо причин сбоев, которые возникли в течение дежурства, либо по предотвращению этих причин, чтобы они не возникли в будущем. Задача 24 на 7 среагировать на тикет и просто решить тикет, по которому пришло уведомление.
Я знаю, что есть системы, в которых ребята посреди ночи должны делать какие-то отчеты: сколько каких ip-шников было заблокировано, смотреть что-то в логах и сдавать смену с описанием того, что приключилось. Мы пошли по другому пути – мы это все не делаем. Вся эта нагрузка ложится на дневные команды. Соответственно, в дневной команде есть люди, которые этим всем занимаются. А задача 24 на 7 просто среагировать на тикет.
Интервьюер: А зачем их три человека? Такое большое количество тикетов?
TeamLead: Нет, они меняются. На смене один человек. Но в дневное время есть люди, которые вовлечены в 24 на 7 и дополнительные участники команды. То есть в дневное время ИТ-команда примерно 7 человек, но те, которые дежурят только ночью, их получается трое.
Интервьюер: Ночные дежурные работают полноценно всю ночь или только реагируют в случае возникновения проблем?
TeamLead: они, конечно, должны соблюсти минимальные процедуры, например, просмотреть состояние систем мониторинга, проверить последние письма и т.п. Но основная их задача – реагировать на тикет.
Интервьюер: Как организован график работы этих троих человек?
TeamLead: У нас есть дневная команда поддержки из семи человек, двое из которых вовлечены в 24 на 7, остальные не вовлечены в 24 на 7. И есть три человека, которые перекрывают только ночные смены.
Рисунок 3-График оповещений инженеров
Интервьюер: То есть круглосуточная поддержка осуществляется 5-ю людьми?
TeamLead: Да. Но организация следующая. В дневную смену всегда выходит сразу два человека и выполняют обычную рутинную ежедневную работу. Они работают с небольшим сдвигом по времени, чтобы максимально растянуть дневную смену. Но в ночную смену приходит только один человек.
Продолжение данного интервью ждите в следующей статье.
About The Author
Виктор Карабедянц
ИТ директор (CIO), руководитель нескольких DevOps команд. Профессиональный руководитель проектов по внедрению, поддержке ИТ систем и обслуживанию пользователей.