Два очевидных сценария организации техподдержки в ИТ
ИТ-компании, разрабатывающие собственные программные продукты (ПО), проходят несколько этапов становления службы технической поддержки. На первом этапе все обращения, поступающие от пользователей ПО, обычно решают его же разработчики. Это приводит к перегрузке специалистов и отвлекает от основных задач.Столкнувшись с этой проблемой, компании начинают развивать выделенную службу техподдержки. Чаще всего они выбирают один из двух наиболее очевидных сценариев.
- Техподдержка с минимальным количеством задействованных сотрудников.
Компании, только приступающие к построению собственной технической поддержки, как правило, реализуют сценарий, предполагающий минимальное количество сотрудников, выделенных в службу. Обычно это не более двух-трёх человек, работающих в формате 5/2.
Одновременно с этим графиком предусматриваются дежурства в ночные часы и выходные дни. Однако в эти периоды задействован лишь один сотрудник. Он регистрирует все поступающие обращения клиентов и решает те из них, которые соответствуют его квалификации. Оставшиеся задачи, требующие большего объёма знаний, откладываются до прихода разработчиков.
При подобном сценарии, службе технической поддержки крайне сложно выдерживать сроки, поставленные в соглашении об уровне сервиса (SLA), что влияет как на отношение клиентов, так и на репутацию компании. Кроме того, остаются перегруженными разработчики ПО. - Техподдержка на основе сменного графика сотрудников равнозначной квалификации.
Этот сценарий обеспечивает круглосуточное присутствие инженеров технической поддержки. Они оперативно приступают к решению обращений, поступающих от клиентов.
Для организации круглосуточной смены потребуется минимум пять специалистов. Найти такое количество сотрудников требуемой квалификации в короткие сроки достаточно ресурсоёмко: их мало на рынке, они дорого стоят и крайне востребованы среди других компаний.
В дополнение, нагрузка распределяется по дежурящим инженерам не равномерно. В вечерние часы и на выходных она значительно меньше (по нашей практике на 75 — 80%), чем в рабочее время.
На одних специалистов ложится максимум задач, другие простаивают. Возникают проблемы с выгоранием перегруженных и мотивацией недогруженных. Либо неравномерная загрузка (если они меняются) приводит к неисполнению SLA в нагруженные часы.
- создать поддержку по другим программным продуктам Arenadata;
- организовать службу таким образом, чтобы она могла исполнять обязательства по SLA перед заказчиками, фиксировать заявки, время их заведения, количество затраченного на их решение времени, и в целом фиксировать и контролировать параметры всех обращений;
- обеспечить техподдержку в круглосуточном режиме работы без выходных.
Техподдержка на текущий момент
Сейчас служба технической поддержки в Arenadata представляет собой три линии. Первая — дежурная смена, которая работает в режиме 24/7 в сменном графике.Вторая линия — инженеры-эксперты, разделённые по продуктам и часовым поясам. Они работают в режиме обычной пятидневки, но имеют график дежурств. Сотрудники первой линии, столкнувшись с задачей, выходящей за пределы их квалификации, точно знают, кто из инженеров доступен и кого из них можно подключить к работе.
Третья линия — это продуктовая разработка, которая приходит на помощь в самых нетиповых случаях и при необходимости устранять выявленные баги в коде продуктов (рис. 1).
Таким образом, мы имеем возможность работать по обращениям заказчиков в круглосуточном режиме, и одновременно подключать экспертизу разного уровня только при реальной необходимости.
Выбрав именно такой формат построения техподдержки, мы получили возможность понимать свою нагрузку, анализировать её и знать, когда и сколько людей нам нужно, чтобы решить инцидент, возникший у заказчика.
Сложности перехода
При переходе на круглосуточный формат работы технической поддержки, компания может столкнуться с различными сложностями. Как показывает наш опыт, самыми распространёнными являются:- отсутствие Operational level agreement (OLA, соглашение операционного уровня) между линиями поддержки — затруднено подключение дополнительных сотрудников к решению нетиповых задач;
- создание прозрачных SLA для клиентов — несовпадение ожиданий клиентов и возможностей службы техподдержки;
- отсутствие автоматизации внутри службы — трата времени на выполнение рутинных действий инженеров.
Функции, которые в Arenadata выполняет техподдержка
ИТ-компании зачастую мыслят в узких рамках возможных функций техподдержки, возлагая на неё довольно стандартные задачи. В Arenadata мы вышли за эти пределы, и наша служба:- оказывает заказчикам услуги технической поддержки программного обеспечения компании;
- взаимодействует с клиентом — техническая поддержка выступает лицом компании;
- является точкой практической экспертизы по продуктам внутри компании. Столкнувшись и успешно справившись со сложными комплексными кейсами, мы проводим технические консилиумы для своих внутренних подразделений.
Метрики для SLA
Для нас самыми важными метриками SLA являются: скорость предоставления первого ответа, время обслуживания клиентов и тип лицензии, который они выбрали.Ответом на обращение пользователя могут быть:
- предоставление информации по запросу пользователя (консультация, ссылка на документацию, статью в базе знаний);
- описание рекомендаций по устранению инцидента или описание временного/ обходного решения инцидента (workaround);
- запрос информации для проведения диагностики (описание действий заказчика, логов, настроек системы).
- поддержка высоконагруженных критичных систем в режиме 24*7;
- менее критичные системы — 8*5 (рис. 2).
Что касается типа лицензии, то у нас Enterprise (для продуктивной среды и тестовой среды) и Community лицензии.
Инструменты, которые используем
- Основной наш инструмент — портал поддержки клиентов (Jira Service Management), где они видят свои текущие запросы, могут посмотреть историю обращений, получают уведомления о статусе решаемой задачи. Там же собрана база знаний, доступная клиентам, где они могут найти ответы на типовые кейсы, и либо решить проблему самостоятельно, либо совершить подготовительные действия, пройти первые этапы диагностики, которые ускорят общее решение инцидента.
- В этой системе представлены статистика, отчётность в различных разрезах. Она же позволяет нам автоматизировать работу техподдержки и снять с сотрудников рутинные операции по управлению заявками, например, автоматически переключать статусы задачи, контролировать SLA.
- Внешний колл-центр, который в режиме 24/7 эскалирует инженерам или дежурным смены о том, что, например, подходит срок решения заявки, поступила новая заявка. В ближайшее время у нас есть планы по автоматизации этого функционала.
- Корпоративный мессенджер Slack, куда клиентам поступают уведомления о том, что происходит с их заявками — что также является дополнительным инструментом контроля. Сейчас мы в пилотном режиме подключаем клиентов к нашим каналам по поддержке. И в ближайшее время запустим новый канал приёма обращений — чат-бот в Slack. Посредством него клиент может, не выходя из Slack, заводить заявки, оставлять по ним комментарии, видеть ответы наших сотрудников.
Типовые и нетиповые задачи, которые мы решаем
Для себя мы выделили топ-3 типовых задач, которые мы решаем по нашим программным продуктам. Так, в Arenadata Hadoop это падение сервисов, снижение производительности, конфигурация центра управления. С Arenadata DB (ADB) чаще всего связаны задачи, возникающие из-за нарушения работы или медленного выполнения запроса, падения одного или нескольких сегментов и снижения производительности. С Arenadata Streaming (ADS) типовыми задачами являются заполнение дискового пространства и падение брокера/продюсера/консюмера.Конечно, регулярно техподдержка сталкивается и с нетиповыми задачами. Рассмотрим на примерах.
- Проблемы вокруг Hive (продукт AD Hadoop)
При установке новой версии прикладного ПО установщик падает с ошибкой Hive: не может выполнить drop table.
Для решения задачи мы протестировали работу на разных версиях внешней базы данных. Диагностика показала, что проблема в конкретной версии внешней базы данных, которая являлась metastore Hive. Чтобы решить её, потребовалось установить более старшую версию внешней базы данных. - Обновление кластера
При проведении миграции на AD Hadoop выполнялись плановые работы по обновлению кластера с ADH 1.5 на ADH 1.6. Вернуться на старую версию уже невозможно. Потребовалось протестировать совместимость с внешней BI-системой, работу скриптов и стороннего ПО с новыми версиями компонентов ADH. - Плавающие проблемы
Во время работы с Arenadata DB у клиента возникли сложности при увеличении объёма данных и нагрузки. Длительность запросов к каталогу DB превышала десятки минут.
Порекомендовав клиенту проверить сеть, мы выявили потерю более 30% пакетов. Инцидент был исчерпан после того, как заказчик устранил проблему в сетевой инфраструктуре.
Как поставить KPI
Для нас основными ключевыми показателями эффективности (KPI) являются выполнение SLA и оценка удовлетворенности пользователя. После решения любого инцидента заказчик получает возможность по шкале от 0 до 5 оценить нашу работу и оставить комментарий или предложить улучшения.Советы тем, кто строит техподдержку
Необходимость адекватных регламентов не новость, но факт. Описанный понятным языком алгоритм действий сотрудников в конкретных ситуациях повысит вероятность того, что задача будет выполнена качественно и в срок.
Доскональное знание собственных продуктов компании поможет сотрудникам технической поддержки эффективно решать поступающие от клиентов обращения. Например, все специалисты нашей службы в обязательном порядке проходят обучения по решению типовых задач по продуктам Arenadata. Это же помогает эффективно работать с выгоранием сотрудников — они получают возможность развиваться, как с точки зрения знаний, так и в рамках карьерной лестницы, а не стоять на месте, решая рутинные задачи (рис. 4).
Пользуйтесь теми инструментами, которые позволяют внедрять быструю и простую автоматизацию рутинных действий инженеров. На текущий момент мы автоматизировали многие операции, связанные с работой по обращениям пользователей.
Вся нотификация о важных событиях (например, поступление нового тикета, изменение приоритета, истечение сроков этапов работ) предоставляется инженерам в автоматическом режиме в Slack и на мобильные телефоны по СМС и звонкам. Внедрения таких механизмов контроля позволило повысить на 23,7% исполнение SLA.
В рамках OLA, в первую очередь, необходимо соглашение между подразделениями поддержки и разработки. В нём желательно описать случаи, в которых подключается разработка, требования по предоставлению информации, сроки обратной связи. Подобные документы позволяют снизить время работы вдвое над теми обращениями, где задействованы несколько исполнителей.
Для построения эффективной работы технической поддержки, необходимо обеспечить совпадение ожиданий заказчика (не важно внешнего или внутреннего) и реальных измеримых результатов работы службы. Этой цели невозможно добиться, не используя согласованный и прозрачный для обеих сторон SLA. В нём описываются состав работ, сроки выполнения этапов процесса поддержки, объёмы услуг, время обслуживания и другие значимые в конкретном случае параметры.
Статистика позволяет принимать решения, опираясь на конкретные факты. Вы лучше понимаете, на какие параметры обращать внимание в первую очередь, если речь идёт, например, об уменьшении времени решения обращений. После анализа сразу становится видно, на какие операции уходит больше всего времени специалистов (рис. 5).
Создание эффективной службы технической поддержки в ИТ-компании и особенно перевод её работы на формат 24/7 требует значительных трудозатрат, объёма знаний, наличия грамотных специалистов. Прежде, чем приступать к этим задачам, непредвзятым взглядом оцените, хватит ли вам ресурсов для их решения. Возможно, финансово более оправдано будет отдать их на откуп сторонних специалистов, уже имеющих богатую экспертизу по решению клиентских обращений с соблюдением строгих SLA.
Всегда на связи. Техническая поддержка от Arenadata
Arenadata предоставляет квалифицированную техническую поддержку, которая поможет вашей платформе работать как часы: мы оперативно решаем возникающие у клиентов инциденты согласно строгим SLA.Получите предложение на техническую поддержку!
