- PVSM.RU - https://www.pvsm.ru -
На календаре май, а значит – «серая зона» праздников. Каждый, у кого выходил из строя сервис в праздники, знает, что такое две недели, в которых выходных больше, чем рабочих дней. По такому случаю рассказываем, как устроена наша техподдержка и что происходит с заявками, пришедшими в ночь с субботы на воскресенье. В конце статьи – небольшой чек-лист по составлению запроса в техподдержку. Чтобы на том конце провода вас правильно поняли и быстро смогли помочь.
Все клиентские обращения сначала поступают операторам по телефону или почте. Они в круглосуточном режиме обрабатывают и регистрируют их. Оператор – своего рода “нулевой километр”, откуда заявка в зависимости от профиля, сложности и критичности попадает на нужный уровень техподдержки. Всего таких уровней три.
Дежурные инженеры. [1] Монтируют и демонтируют оборудование, прокладывают СКС, сопровождают клиентов в дата-центре, следят за системой мониторинга. Работают в режиме 24x7.
Дежурные администраторы. Разбираются в поддержке физической, виртуальной, сетевой инфраструктуры, ОС и ПО, но могут решать только типовые задачи по инструкции. Работают в режиме 24х7.
Инженеры профильных групп: виртуализация, сеть, hardware, эксплуатация инженерной инфраструктуры ЦОД, информационная безопасность, СУБД, Microsoft, Linux/Unix, AIX, SAP-базис, мониторинг. Решают задачи по системам, за которые они отвечают, в режиме 8х5. Ежедневно в каждом отделе назначается дежурный. Инженер профильной группы подключается, если задача нетривиальная, и знаний дежурного администратора не хватает. В критичных ситуациях его могут привлечь к решению задачи ночью и в выходные.
Дежурные по инженерной инфраструктуре. Отвечают на запросы, связанные с основными инженерными системами (энергоснабжение, холодоснабжение, мониторинг и пр.), в нерабочее время. На каждой площадке вахту круглосуточно несет один дежурный. При возникновении сложных инцидентов привлекают дежурного из отдела эксплуатации инженерной инфраструктуры ЦОД.
Старшие инженеры профильных групп. Более опытные инженеры. Решают задачи, которые невозможно выполнить по инструкции.
Ведущие инженеры профильной группы. Отвечает за наиболее сложные задачи.
Руководитель группы. Контролирует критичные обращения (потеря сетевой связности, выход оборудования из строя или отказ сервисов) и аварии на уровне всей инфраструктуры.
Получается вот такая схема:
Источника запросов два – клиенты и информация о сбоях из системы мониторинга. Все клиентские обращения делятся на штатные запросы и инциденты – заявки, связанные с недоступностью сервиса. Вот какой путь проходит заявка от клиента:
Регистрация обращения. При регистрации обращения в тикетной системе оператор делает следующее:
На регистрацию обращения оператору отводится 5-15 минут в зависимости от приоритета обращения. Обращению присваивается уникальный шестизначный идентификатор, по которому клиент сможет отслеживать статус своей заявки.
Назначение исполнителя. Если обращение приходит в рабочее время, оператор передает его дежурному инженеру или инженеру профильной группы. В нерабочее время заявкой занимается дежурный инженер или дежурный администратор.
Схема назначения исполнителя в зависимости от того, когда поступило обращение.
Разрешение обращения. Дежурные администраторы обрабатывают клиентское обращение по инструкции. Если оно не имеет типового решения, администратор передает его на вторую линию поддержки. Бывают ситуации, когда обращение назначается на одну профильную группу, но для решения необходимо привлечь инженеров, отвечающих за другие системы. Информация об этом направляется оператору и аккаунт-менеджеру, а заявка переводится на соответствующую группу.
Если инцидент невозможно закрыть за время, установленное по SLA, он эскалируется на вторую и третью линии поддержки. В случае аварии подключается дирекция для анализа инцидента. Когда невозможно самостоятельно устранить проблему, мы привлекаем подрядчиков.
Закрытие обращения. После выполнения запроса или устранения инцидента исполнитель готовит отчет и передает обращение аккаунт-менеджеру. Он получает подтверждение со стороны клиента о разрешении заявки, обращение закрывается и переводится в статус “Решено”.
Процесс управления инцидентами выглядит так.
Такой путь проходят обращения и уведомления из системы мониторинга. Теперь посмотрим, как разрешаются штатный запрос и инцидент на примерах.
Предположим, клиент в субботу хочет развернуть виртуальную инфраструктуру с двумя серверами MS SQL.
13:00. Клиент отправляет запрос в службу поддержки и уже через 4 часа планирует начать работу с новыми серверами.
13:05. Оператор регистрирует запрос в системе и передает на первую линию поддержки — профильному инженеру группы виртуализации.
13:30. Для клиента выделены виртуальные ресурсы, и он уже может работать с ними. Для создания SQL-серверов инженер виртуализации переводит запрос дальше на группу Microsoft.
15:30. Инженер группы Microsoft развернул виртуальные машины с MS SQL и подготовил серверы к работе: обновил версии ПО, расширил диски и протестировал службы. Создание и настройка ВМ заняла около 2 часов.
15:35. Аккаунт-менеджер подтвердил выполнение запроса у клиента.
Клиент может начинать работать на новых виртуальных серверах.
Так выполняются штатные запросы. Здесь нет спешки, хотя тоже есть норматив по времени. Но что делать, если происходит отказ сервиса и счет идет на минуты. На эту тему у нас есть реальная история, которая произошла не так давно.
У нас есть собственная оптоволоконная магистраль в Москве, соединяющая наши дата-центры и клиентские площадки. В середине марта случилась авария на участке между дата-центрами OST и NORD. Вот хронология событий и действия нашей технической поддержки.
02:00. Система мониторинга зафиксировала потерю связности OST – NORD. Дежурный администратор зарегистрировал инцидент и назначил его на сетевую группу. Так как обрыв связи затронул наши и клиентские трассы, инцидент был сразу эскалирован на ведущего инженера ВОЛС и руководителя сетевой группы.
02:15. Дежурный инженер сетевой группы связался с подрядчиком, обслуживающим ВОЛС.
04:00. Ведущий инженер сетевого отдела определил предполагаемое место обрыва со стороны дата-центра OST. Дежурный обслуживающей компании выехал на место для осмотра.
Также инженеры установили, что в результате аварии пострадали клиенты, арендующие темную оптику. Списки пострадавших клиентов передали аккаунт-менеджерам, чтобы они оповестили клиентов об аварии и собрали информацию об обрывах связи.
04:35. Сетевые инженеры совместно с дежурным инженером подрядчика установили, что обрыв произошел на участке Красносельского коллектора, и связались с ГУП “Москоллектор”. Диспетчер сообщил о возгорании на ПК-42 Красносельского коллектора и принял заявку на допуск ремонтной бригады, но предупредил, что доступ на коллектор закрыт до выяснения обстоятельств.
08:00. Отправлена телефонограмма в ГУП “Москоллектор” с повторной заявкой на аварийный допуск ремонтной бригады подрядчика на территорию коллектора.
08:15. ГУП «Москоллектор» сообщил об отключении силовых кабелей и локализации пожара. Но доступ в коллектор для операторов связи был по-прежнему закрыт до 16.03.2017 г., до восстановления общегородских коммуникаций, инженерных сетей и выявления причин аварии от СК РФ и сотрудников ГУП “Москоллектор”.
09:00. Инженеры начали переключать пострадавших клиентов на резервные маршруты. У некоторых клиентов были свои резервные оптические трассы, и их удалось переключить быстро. Клиентов, не имеющих резерва, переключали на свои собственные резервные трассы.
15:00. Все пострадавшие клиенты переведены на резервные маршруты.
09:00. Ремонтная бригада подрядчика наконец-то смогла попасть в коллектор и определить объем работ по восстановлению.
10:30. Установили, что в результате пожара повреждено 144 волокна. Было принято решение об организации кабельной вставки.
11:00. Приступили к прокладке кабеля в коллекторе.
16:00. Восстановили рабочие волокна на магистрали.
20:40. Монтажные работы завершены, магистральный кабель полностью восстановлен. Все клиенты переведены на основные трассы.
В итоге устранение аварии заняло 40 часов.
От скорости реакции и компетентности технической поддержки зависит многое. Но тот, кто пишет, тоже влияет на скорость решения запроса. Помните: точно описанный запрос полезен для здоровья администраторов и помогает решить проблему быстрее.
Мы составили предпраздничную памятку о том, как писать в техподдержку:
На сегодня это всё, ждем ваши вопросы в комментариях.
Автор: dataline
Источник [2]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/it-infrastruktura/254450
Ссылки в тексте:
[1] Дежурные инженеры.: https://habrahabr.ru/company/dataline/blog/323136/
[2] Источник: https://habrahabr.ru/post/327962/
Нажмите здесь для печати.