Всем привет! Не так давно я подробно рассказала в цикле статей о своей работе в команде поддержки GlowByte. Сегодня хочу разложить по полочкам для интересующихся этим видам деятельности, в чем же кроются различия между разными линиями поддержки.
Кстати, в работе эта тема тоже актуальна. Нередко на проектах мы сталкиваемся с вопросами заказчиков, в чем разница между второй и третьей линией поддержки, где граница одних и других и почему эту работу делают одни и те же люди, но разделение существует?
Прежде чем ответить на эти вопросы, давайте разберемся в видах заявок, которые бывают в нашей поддержке. Глобально разделить можно на инциденты и консультации.
Инцидент – это проблема в работе системы (или ее неработа). Если пользователь замечает что-то, что работает не так, как было раньше, не так, как он ожидает, то он заводит заявку для разбора проблемы. В результате он ожидает увидеть исправление своей “боли”. У инцидентов есть приоритеты и время на реакцию и решение заявки (SLA).
Консультация – это вопрос. Это не обязательно связано с проблемой, здесь пользователь не ожидает решения проблемы, потому что проблемы нет. У вопросов нет SLA, но есть приоритеты, как и в инцидентах. При разборе заявок служба поддержки сначала обращает внимание на критические инциденты, а потом на вопросы с высокой важностью.
С этим разобрались. Теперь посмотрим на виды заявок, а затем ответим на вопрос, какая линия поддержки за какие типы обращений отвечает.
Мы в GlowByte проанализировали большинство наших инцидентов и составили общую классификацию заявок, которые к нам чаще всего поступают. Классификация представлена на схеме:
Сгруппировав инциденты, мы представили их в такой классификации:
Проблемы с ресурсами серверов.
Некорректные пользовательские действия.
Проблемы во внешних системах.
Некорректные данные.
Баги (вендорские или в кастоме).
Некорректная/ устаревшая конфигурация/ настройка.
Проблемы с доступами.
Проблемы с соединениями.
Решением инцидентов всегда занимается 3-я линия поддержки. Однако она может делегировать административные задачи 2-й линии или передать ей задачи на сбор дополнительной информации, тестирование исправлений, воспроизведение кейса повторно. На части проектов третья линия сама вносит изменения для исправления проблемы, в других – дает рекомендации по исправлению.
Также 3-я линия общается с разработчиками и вендорами, если проблему нельзя решить самостоятельно. Разработчики и вендоры обычно требуют четкой постановки запроса с описанием всех деталей и проведенных мер по устранению проблемы. Им ты не можешь написать “не работает” – такое не примут в работу. Для них важно ПОДТВЕРЖДЕНИЕ, что проблема обязательно баг (баг его продукта) и этот кейс воспроизводится абсолютно на всех стендах при прочих равных условиях. Другими словами, на воспроизведение бага не влияет инфраструктура, специфическая среда заказчика, внешние интеграции и т. д. Третья линия всегда проводит первичный разбор и составляет полноценную заявку вендору, если такое требуется.
Вторая линия может первично исследовать причину возникновения инцидента, но чаще она собирает диагностическую информацию после того, как он произошел, а также предлагает пути его устранения, если подобное уже происходило и известно типовое решение: это может быть изменение конфигурации, увеличение ресурсов серверов, перезагрузка, исправление конфигураций и скриптов в базе данных и т. д.
На части проектов это может быть только рекомендация с подробным описанием, почему инцидент возник, какие у него шаги воспроизведения и какое целевое и временное решение (если для применения целевого решения требуется длительное время, разбор передается на 2-ю линию, а инцидент считается критическим).
Итак, 3-я линия поддержки решает инциденты, отвечает на сложные вопросы, а 2-я занимается сбором диагностической информации (логов, метрик мониторинга, конфигов), отвечает на вопросы 3-й линии о случившемся (когда случилось, что было до инцидента, как его повторить и т. д). Также вторая линия занимается административными задачами. Ниже классификация таких задач:
Перезагрузка:
полная перезагрузка всех компонент систем и особенности перезагрузки,
перезагрузка отдельных компонентов системы.
Резервное копирование:
создание полной или частичной резервной копии,
восстановление из резервной копии.
Работа с источниками данных:
добавление новых источников,
подключение к существующим источникам,
работа с типовыми SQL-запросами проекта,
работа с маппингом полей БД и приложения.
Работа с кастомными элементами:
подключение новых кастомных скриптов,
сборка кастомного кода,
деплой кастомного кода.
Работа с подключениями:
подключение к контурам заказчика,
подключение к интеграциям (очереди, внешние системы),
подключения к интерфейсам и приложениям.
Использование вендорских утилит:
работа с API,
работа с unix-утилитами вендорского приложения.
Анализ мониторинга:
анализ производительности системы,
анализ утилизации ресурсов,
анализ доступности системы,
анализ уведомлений по мониторингу.
Работа с лицензиями:
проверка срока лицензии,
продление лицензии.
Накаты и откаты обновлений и доработок:
накат обновления,
откат обновления.
Управление пользователями:
создание роли, группы и пользователя,
изменение роли, группы и пользователя,
удаление роли, группы и пользователя.
Обновление SSL-сертификатов.
Работа с логами:
просмотр и выгрузка логов разных компонентов,
изменение уровней логирования.
Расписания:
постановка служебных процессов и кампаний на расписание,
снятие служебных процессов и кампаний с расписания,
изменение расписаний,
анализ и контроль выполнения расписания.
Импорт и экспорт объектов:
перенос объектов между контурами,
создание объектов импорта и экспорта.
Управление конфигурацией:
изменение основных конфигурационных файлов,
работа с интерфейсами конфигурации.
Таким образом, на 2-й линии также лежит много задач. На практике в поддерживаемой нами системе функционалом второй линии может заниматься заказчик, самостоятельно администрируя систему и предоставляя информацию по запросу, а можем заниматься мы – команда поддержки GlowByte. Так или иначе зачастую на проекте всегда есть и 2-я, и 3-я линия поддержки, и, как я упомянула выше, одни и те же люди могут заниматься задачами как одной линии, так и другой. Иногда проще самому собрать всю информацию, выполнить административные задачи, применить решения. Если же заказчик выбирает только третью линию нашей поддержки при оформлении договора, то весь немалый объем задач второй линии ложится на его плечи.
