20.07.2020

Роль технической поддержки в работе облачного провайдера

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

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

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

Квалифицированная служба технической поддержки должна отреагировать на обращение клиента так, чтобы не нарушить взятые на себя обязательства. Эти обязательства регулируют 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, и позволяет наблюдать за сетевыми сервисами, серверами и сетевым оборудованием. Она поддерживает несколько видов мониторинга:

В случае появления инцидента эта система мониторинга также позволяет немедленно информировать администраторов через e-mail или telegramm.

Оповещение клиентов о сбоях

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

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

В случае масштабной проблемы, когда требуется высокая срочность принятия решений, ответственный за тот или иной компонент ресурсно-сервисной модели выбирает стратегию решения этой проблемы. Обычно при возникновении такой проблемы в службу поддержки поступает большое количество заявок, и эти заявки объединяются с основной (родительской) проблемой. Поэтому как только основная проблема разрешается, все связанные с этой проблемой заявки (дочерние) тоже автоматически закрываются.

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

Help Desk и работа с запросами пользователей

Запросы пользователей могут приходить по различным каналам: телефону, e-mail, через форму обратной связи. Каждому обращению, как и в случае с инцидентами, присваивается номер и создается соответствующий тикет в системе Help Desk.  Цель Help Desk системы, помимо исключения потери заявок от клиентов, максимально быстро решить возникшую проблему или выполнить запрос пользователя. Это в первую очередь влияет на конечную удовлетворенность клиентов. Если заявки решаются в соответствии с ожиданиями потребителей услуг, то клиенты будут довольны и не будет искать другого провайдера.

Таким образом, Help Desk система напрямую влияет на срок взаимодействия клиента с провайдером. Как показывают различные исследования, это критически важно, потому что:

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

Все системы Help Desk можно разделить на 3 основных класса:

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

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

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

Несмотря на то, что служба поддержки находится на последнем месте в ресурсно-сервисной модели IaaS или VPS, без этой службы работа провайдера облачных услуг невозможна. В нашей статье мы рассмотрели не только принципы работы службы, но и пути повышения эффективности ее работы.