3 уровня техподдержки и 50 оттенков её организации

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

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

Кто-то расширяет штат и под задачи техсаппорта нанимает новых специалистов. Но тут тоже не без подводных камней: нередки ситуации, квалифицированные сотрудники занимаются простыми проблемами, или наоборот, со сложными задачами один на один остаются люди, которым просто не хватает компетенций для их решения.

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

И что же с этой нуждой делать? Строить отдел с нуля внутри, нагружать имеющихся айтишников или отдать всё на откуп подрядчику? — Нет единственного решения, подходящего для всех. Но мы хотим поделиться своим опытом создания службы технической поддержки: возможно, он поможет вам это решение найти, не утонув в нюансах различных сценариев её организации.

3 линии

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

Первая линия 

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

• первичная обработка и/или маршрутизация всех вопросов, возникающих у заказчиков, со всех каналов взаимодействия (чаты, почта, телефония): мы гарантируем, что ни одна задача не будет потеряна, а также будут соблюдены условия SLA по времени реакции на запрос.

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

• формирование задач на основе запросов и комментирование статусов задач заказчику, дополнение задач согласно новой информации, полученной от заказчика, ведение календаря запланированных работ.

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

Вторая линия 

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

• разрешение базовых инцидентов — кончилось место на диске, истёк срок действия SSL-сертификата и т.п.

• консультация клиентов по вопросам работы мониторинга;

• решение типовых задач.

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

Третья линия 

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

• расследования, решение и анализ сложных инцидентов;

• решение сложных комплексных задач;

• формирование инструкций и пополнение базы знаний.

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

Инструменты

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

База знаний

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

• шаблонизировать всё, что можно шаблонизировать, и сделать общую структуру максимально прозрачной;

• сделать доступ к базе быстрым, а поиск — простым и предсказуемым;

• формализовать процесс внесения знаний в базу и их актуализации.

Всё это позволит увеличить желание сотрудников сначала искать ответы там, а не в гугле или личках у коллег.

Процесс внесения новой информации в базу, а также актуализация текущих статей должен быть прозрачен и поделен на зоны ответственности, например:

• первая линия фиксирует изменения в пути эскалации алертов и особенности взаимодействия с заказчиком;

• вторая линия вносит типовые инструкции, полученные в ходе решения алертов, и следит за их актуальностью;

• третья линия разрабатывает новые инструкции и контролирует актуальность общего описания инфраструктуры.

Мониторинг

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

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

• определенный порядок эскалации для алертов: кроме инструкций, к каждому алерту необходима чётко прописанная схема эскалации. Потому как в любой ситуации сотрудник ТП должен знать, к кому он может обратиться за консультацией, к кому за выдачей доступов и подтверждением своих действий при необходимости, а к кому может пойти, если всё плохо и не получается справиться с аварией самостоятельно.

• формализованный цикл жизни алерта и процесс менеджмента алертов в целом: алерт не должен появляться из ниоткуда и исчезать в никуда после резолва (подробнее об этом в разделе "Менеджмент алертов").

Бэкапы

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

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

• система бэкапов должна быть обвешана инструкциями, как новогодняя елка шарами, чтобы у техподдержки не возникало вопросов “а как развернуть бэкап той базы?”

• наличие в схеме бэкапов времени восстановления конкретного ресурса — чтоб понимать, сколько времени потребует восстановление работоспособности системы или ее частей.

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

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

Тикетная система

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

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

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

Каналы взаимодействия

Под каждый канал коммуникации можно выбрать один или несколько инструментов — или использовать один для всех. У себя мы выделяем следующие каналы:

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

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

Менеджмент задач

Не всегда техподдержка 24/7 — это только реакция на аварии. Наши сотрудники обеспечивают полный цикл жизни задач по сопровождению системы: 

• приемка,

• первичная обработка,

• распределение задач по исполнителям,

• выполнение,

• консультация по задаче коллег и заказчика,

• передача результатов выполнения.

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

• для каждого типа задач существуют свои шаблоны, в которых указано, какие данные нужны для задачи, а также в какое подразделение она должна попасть;

• для каждой задачи должны быть определены: постановщик, исполнитель, планируемое время, крайний срок, приоритет выполнения и, конечно же, DoD;

• в процессе выполнения исполнитель обязан оставлять комментарии и записывать потраченное время;

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

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

Менеджмент инцидентов

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

• Оповещение об алерте согласно порядку эскалации.

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

• Сбор информации об инциденте.

• Решение инцидента.

• Анализ инцидента, который должен привести как к разработке или дополнению инструкций по решению, так и к формированию мер для предотвращения инцидента в дальнейшем.

Также хорошей практикой является на регулярной основе анализировать статистику срабатывания алертов и на основе этого вносить корректировки в систему мониторинга.

Вместо вывода: 50 оттенков и 100 нюансов...

Организация службы техподдержки требует достаточно большого количества времени, ресурсов и не только. Обучение персонала, внедрение инструментов, адаптация процессов — всё это тернистый путь, полный скрытых грабель. На него можно вступить самостоятельно, получая зачастую сомнительное удовольствие от встречи с этими граблями и на собственном опыте разбираясь во всех оттенках и нюансах процесса организации службы техподдержки. Или можно довериться тем, кто уже разведал дорогу. У нас на поддержке находится более 400 разнообразных проектов, и мы всегда готовы принять к себе еще. Если же вы решили справиться собственными силами, мы всегда поддержим морально и проконсультируем по каждому шагу и этапу!

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