Роль службы технической поддержки очень важна, особенно в случае поддержки облачного провайдера. Ведь именно облачный провайдер обеспечивает выполнение важных ИТ-процессов своих заказчиков.
Отсутствие своевременной техподдержки может повлечь за собой негативные последствия:
- Срыв заказов
- Задержка оплаты по счетам
- Потеря важных клиентов или поставщиков
- Ухудшение репутации компании
Именно поэтому облачные провайдеры относятся к организации службы технической поддержки очень ответственно. В этой статье расскажем об особенностях работы этой службы.
Квалифицированная служба технической поддержки должна отреагировать на обращение клиента так, чтобы не нарушить взятые на себя обязательства. Эти обязательства регулируют SLA и другие соглашения, заключаемые между клиентом и провайдером облачных услуг.
Сотрудники технической поддержки должны предоставить правильное решение для устранение проблемы в отведенные SLA сроки или правильно ответить на вопросы пользователей. Поэтому сотрудники технической службы поддержки должны быть высококвалифицированными и обладать хорошим ИТ-кругозором, большим опытом работы и уметь оперативно решать поставленные задачи.
Помимо этих профессиональных качеств, сотрудникам технической поддержки необходимо постоянно профессионально развиваться и обучаться.
Основные обязанности специалистов службы технической поддержки:
- Получение информации о сбоях в работе инфраструктуры
- Оповещение клиентов в случае возможных сбоев в работе инфраструктуры
- Оперативное исправление возникающих проблем на виртуальных серверах по запросу клиентов
- Защита персональных данных клиента
- Обеспечение оперативной обратной связи при обращении пользователей.
Рассмотрим подробнее эти обязанности.
Как сотрудники технической поддержки узнают о сбоях в инфраструктуре
Для максимально эффективной работы облачные провайдеры не только ориентируются на стандарты и лучшие мировые практики, но и строят собственную ресурсно-сервисную модель.
Ресурсно-сервисная модель и служба технической поддержки
Ресурсно-сервисная модель – это взаимосвязи между различными услугами и необходимыми элементами инфраструктуры. Каждый компонент такой модели определяется своим набором характеристик и связями с другими компонентами.
В состав облачных услуг IaaS или VPS входя следующие компоненты:
- виртуальная инфраструктура;
- интерфейс управления виртуальной инфраструктурой;
- сеть;
- резервное копирование виртуальных машин;
- служба поддержки.
Услуги IaaS или VPS зависят от работоспособности физических серверов, систем хранения, услуг Интернет-провайдеров и дата-центров, где размещается оборудование провайдера.
Каждый из этих компонентов зависит от других элементов инфраструктуры. Например, доступность файлового массива NetApp зависит от доступности контроллеров и виртуальных СХД, размещенных в хранилище NetApp. Доступ в Интернет в дата-центре зависит от работоспособности маршрутизаторов BGP, которые поддерживают связь с другими автономными системами (AS). Детализировать эти зависимости можно и дальше, в зависимости от задачи, которую нужно решить в рамках ресурсно-сервисной модели.
Ресурсно-сервисная модель нужна для правильной настройки мониторинга услуг, оценки влияния происшествий на другие компоненты, для правильного планирования рисков и угроз, и соблюдения выполнения SLA со стороны облачного провайдера.
Если ресурсно-сервисная модель правильно организована, то провайдер облачных услуг может предсказывать появление неполадок еще до появления инцидентов, а если авария все-таки произойдет, то узнать о ней вовремя и проинформировать клиентов.
Системы мониторинга
Облачные провайдеры облачных услуг постоянно производят поиск оптимальных систем и продуктов, способных лучше отслеживать состояние важных элементов в ресурсно-сервисной модели, и обычно используется сразу несколько систем для наблюдения за разными компонентами.
Система SCOM
Для мониторинга продуктов на базе Microsoft можно использовать продукт System Center Operations Manager (SCOM). SCOM позволяет объединять информацию о функционировании различных ИТ-компонентов, детализировать информацию по всем событиям через одну консоль управления . В случае каких-нибудь проблем SCOM может отправить оповещения администраторов по e-mail. Администраторы могут гибко настроить логику мониторинга. Например, можно получать информацию об системных событиях в одном журнале, а о прикладных программах – в другом. Можно настроить оповещения о работоспособности различных сервисов, чтобы узнавать о проблемах заранее. Например, можно настроить мониторинг службы DHCP или DNS, и устранять проблемы до того, как о них узнают пользователи, поскольку пользователи могут какое-то время пользоваться кэшированной информацией или их IP-адреса еще будут находиться в аренде.
Средства мониторинга Zabbix
Эта система распространяется под лицензией GNU, и позволяет наблюдать за сетевыми сервисами, серверами и сетевым оборудованием. Она поддерживает несколько видов мониторинга:
- Simple checks — может проверять доступность и реакцию стандартных сервисов, таких как SMTP или HTTP, без установки какого-либо программного обеспечения на наблюдаемом хосте.
- Zabbix agent — может быть установлен на UNIX-подобных или Windows-хостах для получения данных о нагрузке процессора, использования сети, дисковом пространстве и других ресурсах.
- External check — выполнение внешних программ, также поддерживается мониторинг через SNMP.
- IPMI – мониторинг за состоянием серверного оборудования посредством таких протоколов, как IPMI, HP iLO, Dell iDRAC, IMB SRA, Sun SSP и т.д.
В случае появления инцидента эта система мониторинга также позволяет немедленно информировать администраторов через e-mail или telegramm.
Оповещение клиентов о сбоях
При возникновении сбоя специалист следует своей инструкции. В этих инструкциях прописаны необходимые действия. Они могут быть или линейными, или ветвящимися, в зависимости от особенности проблемы. Можно выделить следующим типы инцидентов:
- родительские
- дочерние (подчиненные)
- инфраструктурные
- неинфраструктурные
- типовые
- нетиповые
- крупные
- незначительные
В зависимости от типа проблемы определяется метод ее решения. В случае сложных проблем сотрудник технической поддержки может обращаться к более опытным специалистам.
В случае масштабной проблемы, когда требуется высокая срочность принятия решений, ответственный за тот или иной компонент ресурсно-сервисной модели выбирает стратегию решения этой проблемы. Обычно при возникновении такой проблемы в службу поддержки поступает большое количество заявок, и эти заявки объединяются с основной (родительской) проблемой. Поэтому как только основная проблема разрешается, все связанные с этой проблемой заявки (дочерние) тоже автоматически закрываются.
При возникновении инцидента важно оповестить о произошедшем клиента. Провайдеры облачных услуг стремятся к информированию своих клиентов о всех проблемах всеми возможными способами - звонками, сообщениями по e-mail или SMS. Клиенты также оповещаются об изменениях статуса их заявок.
Help Desk и работа с запросами пользователей
Запросы пользователей могут приходить по различным каналам: телефону, e-mail, через форму обратной связи. Каждому обращению, как и в случае с инцидентами, присваивается номер и создается соответствующий тикет в системе Help Desk. Цель Help Desk системы, помимо исключения потери заявок от клиентов, максимально быстро решить возникшую проблему или выполнить запрос пользователя. Это в первую очередь влияет на конечную удовлетворенность клиентов. Если заявки решаются в соответствии с ожиданиями потребителей услуг, то клиенты будут довольны и не будет искать другого провайдера.
Таким образом, Help Desk система напрямую влияет на срок взаимодействия клиента с провайдером. Как показывают различные исследования, это критически важно, потому что:
- 66% клиентов перестали сотрудничать с поставщиками услуг, после того как столкнулись с плохим обслуживанием.
- Удержание 5% текущих клиентов может привнести в компанию дополнительно от 25 до 95% прибыли.
- В зависимости от отрасли, привлечение новых клиентов может стоить в 5-10 раз дороже, чем удержание существующих клиентов.
Клиентские запросы выполняются специалистами различных квалификацией, иногда привлекаются сторонние подрядчики, представители производителей и т.д. У процессов технической поддержки есть обязательные временные параметры решения, которые отражены в SLA.
Все системы Help Desk можно разделить на 3 основных класса:
- Решения для автоматизации процессов предоставления ИТ услуг внутри компании (ITSM-решения)
- Решения для автоматизации массовой поддержки конечных пользователей (Customer Service или Customer Support решения).
- Решения для автоматизации внешней поддержки (b2b поддержка)
Службы технической поддержки активно используют все три этих класса. ITSM-решения можно объединить с системой мониторинга. Такая комбинация позволяет создавать сложные правила, в которых тикеты создаются автоматически, и может выполняться привязка зафиксированных событий к уже существующим. Так же можно фиксировать такие ситуации, когда, например, средство мониторинга не получает регулярных сообщений от систем, что с ними все в порядке. Как только такие сообщения не поступают, в ITSM системе создается тикет о неполадке, или находится существующий тикет, к которому по аналогичному событию создается привязка.
Потребители облачных услуг могут взаимодействовать с провайдером через специализированные порталы самообслуживания. Портал позволяет формировать запросы по интересующим клиентов услугам, выяснять статус заявок, кто из специалистов занимается задачей, иметь доступ к справочным материалам, оценивать работу службы поддержки, получать доступ к панели управления облачными услугами и многое другое.
А для провайдера облачных услуг портал самообслуживания позволяет снизить затраты на предоставление ИТ-услуг, освобождая специалистов от рутинных операций, уменьшать количество ошибок со стороны как потребителей облачных услуг, так и поставщиков, обеспечивая и ту, и другую сторону необходимой информацией. Кроме того, типовые запросы на обслуживание также должны иметь параметры времени решения, согласно SLA. Портал самообслуживания позволяет эффективно решить эту задачу.
Несмотря на то, что служба поддержки находится на последнем месте в ресурсно-сервисной модели IaaS или VPS, без этой службы работа провайдера облачных услуг невозможна. В нашей статье мы рассмотрели не только принципы работы службы, но и пути повышения эффективности ее работы.