Именно поэтому крупные IaaS-провайдеры подходят к вопросу организации технической поддержки очень ответственно, стремясь максимизировать удовлетворенность своих клиентов. В этой статье на примере компании «ИТ-ГРАД», облачного корпоративного IaaS-провайдера, мы расскажем об организации и ключевых особенностях службы технической поддержки, значимости ресурсно-сервисной модели, системах мониторинга и о многом другом.
Особенности службы поддержки облачного провайдера в модели IaaS
Отметим, что в основе бизнеса облачного IaaS-провайдера лежит качественное предоставление услуг большому количеству клиентов, где каждому в отдельности должно быть уделено максимум внимания. Такой поставщик стремится минимизировать простои и любую деградацию уровня сервиса, поскольку несет финансовую ответственность в рамках подписанных с клиентами SLA. Именно поэтому служба технической поддержки должна быть высококвалифицированной, а специалисты отличаться хорошим ИТ-бэкграундом, широким кругозором, опытом практической реализации различных задач и умением оперативно принимать правильные решения.
Служба технической поддержки «ИТ-ГРАД» за восемь лет присутствия на облачном рынке значительно трансформировалась. Команда специалистов, накопив опыт в вопросах предоставления услуг и реализации поддержки как малых, так и крупных клиентов, сегодня справляется с огромным количеством задач, обеспечивая высокий уровень оказания сервиса, где качество по-прежнему стоит на первом месте.
Служба поддержки IaaS-провайдера и кол-центр: основные отличия
Как отмечалось ранее, служба технической поддержки облачного IaaS-провайдера является важным звеном облачного бизнеса. А чтобы суть вопроса стала более ясна, предлагаем сравнить облачный техсаппорт с привычным и знакомым всем кол-центром. Последний состоит из типовых операторов, принимающих входящие звонки и обрабатывающих стандартный набор заявок, причем не всегда технических. Компетенции таких специалистов в большинстве случаев недостаточно для решения нестандартных инцидентов или задач, не прописанных в скрипте оператора кол-центра, что существенно снижает вероятность качественного решения заявки пользователя при любом подобном обращении, не говоря уже об устранении сложных технических проблем.
Что касается корпоративного облачного IaaS-провайдера, здесь зачастую приходится работать с клиентами, оборот бизнеса которых достигает высоких финансовых показателей, а простой одного из сервисов может поставить на кон существование бизнеса компании в целом. Поэтому специалисты саппорта должны грамотно реагировать на возникающие события, не допускать аварий и предаварийных состояний, минимизировать простои и влияние на бизнес клиента, уметь общаться на понятном обеим сторонам техническом языке, ведь любое недопонимание со стороны службы поддержки дискредитирует облачного поставщика в глазах клиента. А этого допустить никак нельзя.
«ИТ-ГРАД», являясь одним из крупнейших облачных поставщиков, обеспечивает доступность своих услуг в том числе посредством недопущения потенциально опасных ситуаций, а на рабочих местах провайдера работает не просто команда, способная вникнуть в техническую проблему каждого клиента, а компетентные специалисты с огромным практическим опытом за плечами, умеющие выйти из любых сложных ситуаций, связанных не только с предоставлением сервиса IaaS, но и любой другой услуги.
Ресурсно-сервисная модель
Сегодня многие компании, включая и облачных IaaS-провайдеров, стараются выйти на путь эффективности ИТ, ориентируясь не только на стандарты и лучшие мировые практики, но и беря во внимание концепцию построения собственной ресурсно-сервисной модели.
Ресурсно-сервисная модель — это система взаимосвязей между различными услугами и инфраструктурными элементами — конфигурационными единицами. Каждый компонент модели определяется набором собственных характеристик и связями с другими компонентами.
Рассмотрим в качестве примера реализацию ресурсно-сервисной модели базовой услуги компании «ИТ-ГРАД» — IaaS. В составе бизнес-услуги IaaS можно выделить укрупненные компоненты:
- виртуальная инфраструктура;
- интерфейс управления vCloud;
- сеть;
- резервное копирование виртуальных машин;
- служба поддержки.
Рисунок 1. Связь операционной услуги Storage и конфигурационных единиц
На рисунке 1 можно проследить, что IaaS в составе виртуальной инфраструктуры (VI), помимо перечисленных выше компонентов, зависит от работоспособности инфраструктуры физических серверов, систем хранения данных (Storage), услуг центра обработки данных по размещению оборудования, сетевой инфраструктуры «ИТ-ГРАД», а также внешних поставщиков услуг доступа в Интернет.
Каждый из упомянутых компонентов, в свою очередь, обеспечивается функционированием других сервисов и элементов инфраструктуры. Например, система хранения данных (Storage) — операционная услуга в составе бизнес-услуги IaaS (см. рисунок 2) — может предоставляться как отдельными массивами, так и их кластерами.
Рисунок 2. Зависимость бизнес-услуги IaaS от операционных услуг
Доступность кластерного массива NetApp формируется из доступности контроллеров и виртуальных СХД, называемых Storage Virtual Machine (SVM). Детализировать подобную цепочку зависимостей можно и дальше исходя из задач, которые решаются c использованием ресурсно-сервисной модели.
Отметим, что ресурсно-сервисная модель незаменима для правильной настройки мониторинга услуги, оценки меры влияния инцидентов по услуге, при планировании рисков в рамках процесса управления изменениями, соблюдении окон обслуживания для затронутых элементов при выполнении изменений. Динамическое формирование списков оповещения потребителей услуг также опирается на связи между услугами и конфигурационными единицами инфраструктуры.
Системы мониторинга
Благодаря правильно организованной ресурсно-сервисной модели IaaS-провайдер может диагностировать многие инциденты «на лету», а используя систему мониторинга в связке с ресурсно-сервисной моделью — получать оценку качества ИТ-инфраструктуры более развернуто.
Сегодня позиция многих крупных хостинг-провайдеров сводится к поиску оптимального решения, и если находится продукт, способный лучше отслеживать состояние важных элементов инфраструктуры, он незамедлительно берется на вооружение, тестируется и вводится в эксплуатацию. Нередки случаи, когда для мониторинга различных элементов инфраструктуры одновременно используется несколько разных решений.
# Средство мониторинга SCOM
«ИТ-ГРАД» в своей практике использует различные системы мониторинга, каждая из которых заточена под соответствующую задачу. Для мониторинга ИТ-сервисов и продуктов на базе семейства Microsoft используется решение System Center Operations Manager (SCOM). Благодаря возможности консолидировать информацию о функционировании различных компонентов ИТ-среды, SCOM позволяет получать детализацию по всем происходящим событиям через единую консоль управления и при необходимости уведомлять администратора через различные каналы связи (e-mail, SMS). Администратор имеет возможность гибко определять логику мониторинга, отслеживать происходящие события на уровне системного и прикладного ПО, настраивать алерты на уровне конкретных сервисов, чтобы узнавать о вероятности проблем, не дожидаясь их наступления.
# Средство мониторинга ZABBIX
Средство мониторинга ZABBIX пользуется большой популярностью среди специалистов технической поддержки. И это неудивительно, ведь решение, представляя собой свободную систему мониторинга, позволяет отслеживать статусы сетевых сервисов, серверов и сетевого оборудования, выполнять несколько видов мониторинга, проверять доступность и реакцию стандартных сервисов без установки дополнительного ПО на наблюдаемом узле. ZABBIX также используется для получения данных о загрузке процессора, дисковой подсистемы и может выполнять мониторинг по протоколу SNMP.
В «ИТ-ГРАД» запущено несколько экземпляров ZABBIX, один из которых выполняет мониторинг Linux-машин и веб-приложений, другой — мониторинг сети.
# AlienVault Unified Security Management™ (USM)
Многие IaaS-провайдеры сегодня предлагают услугу PCI DSS хостинга, что подразумевает безопасное обращение платежных карт для организаций, разместивших свою инфраструктуру на стороне сертифицированного поставщика, где хранятся, обрабатываются или передаются платежные данные клиентов. В рамках требований PCI DSS поставщик обязуется использовать соответствующие решения, позволяющие выполнять в том числе и специализированный мониторинг. К решениям такого формата относится система AlienVault Unified Security Management (USM), характеризующаяся широкими возможностями, легкостью в использовании и доступной стоимостью приобретения. «ИТ-ГРАД» в рамках подготовки и сертификации PCI DSS остановился на использовании USM.
Интеграция систем мониторинга с ITSM-системой ServiceNow
На сегодняшний день система ServiceNow не нуждается в особом представлении, ведь о примерах и вариантах ее использования сказано достаточно много. Но если все же возникло желание узнать о ней подробнее, предлагаем воспользоваться полезной хабро-ссылкой.
В «ИТ-ГРАД» система мониторинга интегрирована с ITSM-системой ServiceNow, где по различным сложным правилам как создаются сами инциденты, так и выполняется привязка зафиксированных событий к уже существующим. Могут отлавливаться и такие события, когда, например, средство мониторинга не получает информации от определенных систем и с целью определения корректности их работы настраивается регулярная отправка «маячков», сигнализирующих, что все в порядке. Как только такие маячки перестают поступать, в ServiceNow создается инцидент либо находится существующий, к которому по аналогичному событию выполняется привязка.
Управление инцидентами
При возникновении инцидента специалист поддержки действует в рамках установленного регламента, оперируя прописанными в инструкциях действиями, которые требуют работать по схеме линейного либо разветвляющегося алгоритма. В зависимости от типа инцидента — инфраструктурного или неинфраструктурного, типового или нетипового, крупного или незначительного — определяется метод решения проблемы. Для решения сложных задач и выхода из нештатных ситуаций сотрудник технической поддержки согласно установленному порядку может обратиться к экспертному составу в лице специалистов ИТО. Каждый специалист, работающий с заявками, должен иметь представление о существующей иерархии, согласно которой инциденты рассматриваются как родительские или дочерние (подчиненные). В зависимости от типа инцидента определяется нотификация, при этом все оповещения выполняются с помощью систем автоматизированной рассылки.
# Масштабный инцидент
В случае возникновения самого плохого варианта, когда происходит масштабный инцидент, требуется высокая срочность принятия решения. При таких событиях, как правило, поступает большое количество заявок и главным остается лишь одно: выбранная стратегия и поведение ответственного специалиста. Если, к примеру, он будет обрабатывать обращения каждого клиента, все усилия пойдут не на решение высокоприоритетного инцидента, а на бюрократическую работу. Поэтому специалисты сервисдеск при поступлении заявки на уже имеющуюся проблему подвязывают ее к существующему тикету, а ответственный сотрудник продолжает заниматься решением проблемы, не отвлекаясь на новые запросы.
В системе ServiceNow при работе над групповыми инцидентами, когда затрагивается большое количество участников, предусмотрена синхронизация всех статусов и комментариев. Если, к примеру, меняется статус родительского инцидента, дочерний меняет состояние на аналогичное. То есть при решении основной проблемы и закрытии родительского тикета ассоциированные с ним дочерние заявки будут также закрыты и переведены в статус «решены», а каждый участник получит соответствующее уведомление.
# Рядовой инцидент
В этом случае затрагивается незначительное количество пользователей, а жизненно важные сервисы компании продолжают функционировать в штатном режиме. Инцидент носит единичный характер и не представляет особой значимости. Если на возникшую проблему был создан инцидент, а позже аналогичное событие повторилась у кого-то еще, будет создан подчиненный инцидент и привязан к родительскому. Во втором варианте тоже будет выполнена работа над одним общим событием, и при успешном разрешении закроется как родительский, так и дочерний инцидент с отправкой соответствующих уведомлений всем участникам.
Оповещение об инцидентах
Специалисты технической поддержки «ИТ-ГРАД» всегда работают в связке с командой ИТ-отдела и при возникновении масштабных инцидентов информируют об этом инженеров ИТО. В случае необходимости экспертной поддержки и помощи в решении сложных задач специалисты высокого уровня всегда на связи. Инженеры ИТО, как и специалисты технической поддержки, работают согласно графику по будням и выходным.
Отметим, что при возникновении инцидента важным остается и механизм оповещения клиентов. На практике нередки случаи, когда отдельные поставщики уделяют этому вопросу недостаточно внимания. Что касается компании «ИТ-ГРАД», здесь выработана и активно используется стратегия информирования клиентов о любых предстоящих работах и инцидентах, которая реализуется удобным для каждого из них способом — начиная от звонков, заканчивая рассылкой и эскалацией на соответствующих специалистов.
Довольно часто на стороне заказчика имеется собственный штат сотрудников, обладающих достаточной компетенцией, но находящихся на разных уровнях иерархии. В зависимости от принадлежности к тому или иному уровню одни пользователи должны видеть все существующие запросы и иметь возможность создавать новые, тогда как другие ограничены в правах. Некоторые пункты должны быть доступны только отдельным авторизованным лицам в соответствии с иерархией на стороне поставщика.
В терминологии «ИТ-ГРАД» существует понятие «мастер-контактов», которые наделены расширенными возможностями и могут запрашивать гораздо больше обычных контактов. Последние, в свою очередь, имеют ограничения по запрашиваемой информации, однако они не должны мешать полноценной работе пользователя и взаимодействию со службой технической поддержки. Такое разделение полномочий достигается путем разграничения прав в ServiceDesk, а глобальные вопросы решаются через соответствующий approve уполномоченных сотрудников клиентов.
Помимо правильно выстроенной модели взаимодействия с клиентами, в работе технической поддержки важным остается вопрос постоянного развития и обучения сотрудников. Специалисты компании «ИТ-ГРАД» ежегодно проходят обучение и сертификацию, а также под чутким руководством старших коллег выполняют запланированные работы в рамках процесса управления изменениями.
Типовые запросы и портал самообслуживания
Еще одной немаловажной особенностью для поставщика облачных услуг является проработка механизмов управления запросами на обслуживание. Существует общепризнанная методика, когда все типовые запросы на обслуживание должны быть формализованы в описании услуг и иметь целевые параметры времени решения согласно SLA. В этом вопросе сегодня помогают специализированные порталы самообслуживания, которые по своей сути являются удобным инструментом для взаимодействия с потребителем услуг.
Портал самообслуживания, внедряемый специалистами «ИТ-ГРАД», представляет собой простое, наглядное и интуитивно понятное решение для взаимодействия с клиентами. Оно позволяет формировать запросы по интересующим услугам, получать информацию о ходе обработки запроса и выполнении SLA, иметь доступ к справочным материалам из базы знаний, оценивать работу службы поддержки, качество услуг и многое другое.
Рисунок 3. Общий вид портала самообслуживания
Портал самообслуживания позволяет снизить затраты на предоставление ИТ-услуг, освобождая специалистов поддержки от рутинной работы, минимизировать количество ошибок со стороны как клиента, так и поставщика, обеспечивая предоставление полной информации по запросу, и прочее.
Рисунок 4. Этапы выполнения типового запроса
При этом клиент может видеть, на каком этапе выполнения находится запрос, каков статус согласования, кто из специалистов занимается задачей. Конечный пользователь видит полную картину происходящего, а если возникает необходимость каких-либо дополнений, создает новое обращение в контексте существующего запроса.
В завершение
Значимость службы технической поддержки действительно трудно переоценить. Являясь важным функциональным компонентом ITIL, техническая поддержка считается не только лицом компании, но и важнейшей составляющей сервисной структуры, где качество оказываемых услуг, сработанность команды и оперативность принятия правильных решений выносится на первый план. Вот почему на этом «облачном звене» не стоит экономить!
