Чем занимается инженер техподдержки облачного провайдера

Илья Осянин

Руководитель группы технической поддержки #CloudMTS

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

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

Специалисты техподдержки работают на трёх линиях

Первая линия — L1. Дежурная смена. Она отслеживает состояние виртуальной инфраструктуры по уведомлениям в системе мониторинга, решает сервисные запросы и инциденты. Если появляются технические проблемы, команда старается работать на опережение, оповещать L2 и L3 . Чаще всего проблему устраняют до того, как начнут поступать запросы от клиентов.

Как правило, дежурный проверяет нагрузку на виртуальных серверах клиента, формирует отчётность по ней, обновляет ОС на ВМ, по запросу изменяет вирутальные ресурсы — например, увеличивает количество оперативной памяти на виртуальных серверах клиента — и активирует/деактивирует услуги: подключает или отключает виртуальную инфраструктуру и другие сервисы и продукты #CloudMTS.

Первая линия обрабатывает примерно 70% заявок от клиентов.

Вторая линия — L2. Если решить инцидент не получается — например, нет сетевого доступа к виртуальной машине — то дежурный проводит диагностику, собирает логи от клиента и передаёт информацию на вторую линию.

Инженеры L2 занимаются поддержкой клиентской инфраструктуры, каждый по своему направлению: сети, виртуализация или системы резервного копирования. Каждый день дежурные собирают и отрабатывают обращения для своей группы, обучают дежурную смену или занимаются другими важными задачами, например, решают менее срочные кейсы с невысоким приоритетом, которые не успели закончить вчера, готовят отчёты.

Третья линия — L3. Её специалисты отвечают за архитектуру железа и эксплуатацию, работают с внутренней инфраструктурой, проводят технические работы, плановые и экстренные обновления, формируют рабочие инструкции для L2.

Примерно 50% задач у нас автоматизированы, например, виртуальная инфраструктура заводится с помощью скриптов. Но основная часть: обработка обращений, реагирование на события мониторинга и так далее — делаются вручную.

Мы используем систему мониторинга, написанную на базе C, PHP и Java. В ней фиксируются все инциденты с физических серверов.Для мониторинга инфраструктуры используем комбинацию из двух решений. Первое позволяет формировать отчёт за определенный промежуток времени, строить графики потребления ресурсов и поведения системы. Второе фиксирует все действия пользователей и администраторов: вход в систему, подключение машин, создание снапшотов. Можно открыть события по отдельной виртуальной машине и отследить, что с ней происходило.

Для инженеров техподдержки важны hard skills и сертификация

Для дежурного специалиста на первой линии важны сетевые hard skills: знания, как устроена сеть и что такое TCP/IP, DNS, — и базовые навыки системного администрирования: диагностика, проверка нагрузки, обновления систем, работа с каталогом пользователей. Сертификация не обязательна, но если есть, это плюс: с ней проще погружаться в процессы.

Из софтов полезны ответственность, умение общаться с клиентами и быстро реагировать.

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

Хард скилы зависят от направления, в котором хочет развиваться инженер. Это могут быть:

• опыт работы с виртуализацией и сертификация по вендорам, которые управляют системами виртуализации;
• расширенные знания сетевого стека (например, знание BGP), наличие сертификации по сетевым технологиям;
• навыки работы с системами резервного копирования.

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

Инженеры L3 также должны быть сертифицированы по одному из направлений и иметь навыки работы с системами на уровне архитектора:

• написание ТЗ;
• развёртывание систем виртуализации;
• работа с железной инфраструктурой;
• развёртывание систем резервного копирования;
• кластеризация, обновление систем на уровне инфраструктуры.

Инженеры техподдержки постоянно учатся внутри компании и у вендоров

Любой инженер L1 и L2, придя в компанию, проходит первичное обучение процессам: ITSM, ITIL-процессы, управление инцидентами, управление запросами, управление запросами на изменения, работа с базой знаний. Параллельно инженеры получают тестовый доступ к инфраструктуре. Так сотрудники учатся работать с новыми для себя системами. Погружение в процессы идёт первые два месяца.

Для проверки мы раз в пару месяцев проводим промежуточные аттестации: по знаниям, которые инженеры получили в начале обучения, по обновлениям в регламентах и спецификациях, по новым вендорам, продуктам и системам.

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

Ещё раз в неделю проходят совещания группы — service review. На них мы смотрим статистику обращений по всему техническому блоку и анализируем кейсы, по которым были серьёзные отклонения от SLA: почему нарушение возникло, на каком этапе и так далее.

Наконец, специалисты могут пройти дополнительное профильное обучение. Инженер сам ищет курс — от вендора или тот, что поможет ему в профессиональном развитии. А компания оплачивает расходы и освобождает от работы на некоторое время. Если на время учёбы нужно уехать, компания оформляет командировку.

Если сотрудники изучают все системы, находят своё направление и понимают, что готовы получить спецификацию у вендора (или уже имеют такую), то могут перейти на линию выше. В моей практике были случаи, когда инженеры из L1 переходили на L2 за год-полтора.

Мы обрабатываем по 400 обращений в неделю и разбираем сложные случаи

Так, один крупный клиент — из массмедиа — обратился к нам с инцидентом: повышена нагрузка, и не работают внутренние сервисы на виртуальных машинах. С нашей стороны всё работало штатно.

Это был неординарный случай — мы разбирались, что генерирует нагрузку и почему скорость интернет-канала падает. Пришлось подключить несколько линий, чтобы провести ряд диагностик и исключить проблемы на нашей стороне.

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

Другой случай: у клиента была стопроцентная утилизация сетевого канала из-за внутренних процессов. Мы провели расширенную диагностику, заметили, что-то генерирует нагрузку — но не видели, что именно. Сначала расширили пропускную способность маршрутизатора — но проблема вернулась. Тогда решили увеличить скорость на уровне каналов связи — и решили проблему.

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

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

***

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

В нашей поддержке такого нет. Большая часть работы — это нетиповые кейсы и постоянная практика, так что скучно не будет.

Кстати, сейчас мы расширяем Managed Services — управление ИТ-услугами и системами виртуализации, потому что увеличилось количество клиентов. Ищем инженеров уровня L1 и L2, которые будут поддерживать сервис.