Привет, Хабр! Меня зовут Григорий Иванов, я работаю ведущим специалистом команды MM.SUP в GlowByte. Сегодня хочу рассказать про работу команды технического сопровождения, или, как её ещё называют, поддержки. Эта статья позволит взглянуть на многие процессы изнутри и примерить на себя роль матёрого специалиста сопровождения.
Для понимания скажу несколько слов о продукте, который мы сопровождаем. Его основа – это система аналитического CRM с уникальными особенностями конкретного внедрения для каждого заказчика, а также набор систем, которые включают в себя витрины данных и инструменты BI.
Какие факторы влияют на работу сопровождения?
С одной стороны, это:
- техническая сложность системы, - несколько десятков заказчиков с уникальными внедрениями,
- отсутствие доступов к исходникам базового ПО.
С другой стороны (и это положительные факторы):
- пользователями системы являются 5-10 человек,
- достаточно высокий уровень IT-грамотности пользователей,
- накопленный опыт по огромному количеству решённых проблем.
Кроме того, мы считаем, что сотрудник сопровождения должен уметь решать не только технические проблемы, но и понимать термины маркетинговых систем, чтобы разговаривать с заказчиком на одном языке.
Линии сопровождения
Мы разделяем процесс сопровождения на линии, используя определённые критерии для каждой из них.
Под первой линией сопровождения понимаем сбор первичной диагностической информации, классификацию инцидента, применение известных решений. Эти действия выполняются на стороне заказчика – пользователем или сотрудником IT.
Если анализ первой линии определил, что проблема заключается в работе нашей системы, то в системе учёта заявок Jira создаётся инцидент для второй линии. Для каждого инцидента автоматически назначается исполнитель и выставляется SLA на реакцию и на решение в соответствии с критичностью. При запросе сотрудником сопровождения уточняющей информации у заказчика “таймер” SLA останавливается. Это мотивирует его формулировать проблему максимально полно, сразу сообщать всю информацию по инциденту, то есть выполнять контроль за действиями первой линии.
У многих заказчиков есть стремление к росту собственных компетенций в сопровождении систем, и вторая линия может быть реализована его силами. Как правило, эту роль выполняют IT-специалисты, имеющие опыт сопровождения схожих систем или прошедшие обучение у вендора или у нашей команды. Задача второй линии – закрывать простые инциденты своими силами, основываясь на технической документации, базе знаний, собственных умениях.
Третья линия решает всё, что не смогла решить вторая. Если же наша команда реализует сопровождение ещё и второй линии, то внутри команды разделения на линии нет, но есть более опытные сотрудники, к которым можно обратится за помощью в сложных ситуациях.
В случае если проблема заключается в дефекте базового ПО, предоставляемого вендором, то наша задача вести с ним коммуникацию, собирать диагностическую информацию и применять рекомендации до тех пор, пока проблема не будет решена.
Чрезвычайно удачным решением считаю использование единой для всех заказчиков системы учёта заявок. Это позволило работать с ней как с одной точкой входа для инцидентов, создать гибкую систему оповещений, в том числе с помощью различных ботов.
Время, за которое происходит реальное назначение исполнителя и реакция на инцидент, в среднем составляет не более 15 минут, несмотря на реальные SLA в 1–2 часа, которые фиксируются в договоре с заказчиком. Это является великолепным показателем!
Культура и команда
Очень важным для нас является культура единой команды профессионалов, качество работы которых не зависит от конкретного исполнителя. При этом мы стараемся быть в контакте с заказчиком, погружаться в его процессы и решать задачу именно как проблему, минимизируя возможность повторения инцидентов.
Так кто же он – идеальный сотрудник, и почему сопровождение – это сложно и интересно?
Существует стереотип о том, что сотрудник сопровождения не способен на решение технически сложных задач и что в сопровождение идут работать те, кого не взяли на должность разработчиков.
Специфика нашей компании заключается в том, что существует множество команд, которые разрабатывают и внедряют уникальные решения для наших клиентов, и только малая часть из команд остаётся на проектах и занимается развитием системы. Основная же работа по исправлению багов и помощи в эксплуатации системы ложится на плечи команды сопровождения.
В своей работе мы погружаемся во все аспекты системы. Вместе с пользователями разбираемся в настройке и запуске функциональных элементов и в анализе данных. Собираем требования для доработок системы, преобразовывая бизнес-требования в техническую документацию. Пишем код, используя накопленные знания.
Когда я начинал работать в компании джуном, на погружение в процессы системы и её архитектуру ушло более года. Фактически каждый день я узнавал что-то новое про ту или иную особенность. Если говорить прямо, то изучение технологий продолжается и сейчас, поскольку на проектах их множество и разобраться с ними полностью невозможно. Помимо этого, расширяется список направлений, технологий и вендоров, начинаются новые проекты, а старые развиваются.
Решение инцидентов
Так что же представляет из себя процесс решения инцидента и насколько интересным это может быть?
При получении инцидента начинается сбор анамнеза – истории инцидента: шаги воспроизведения ошибки, свежие изменения в скриптах, массовость проявления. После чего выдвигается гипотеза о причине этой ошибке, проверяется, выдвигается следующая, и так до тех пор, пока не будет найдена корневая причина. Иногда приходится анализировать логику разработчика, иногда структуру таблиц самых разных СУБД, порой ошибка кроется в недрах операционной системы.
Случается и такое, что закапываешься в дебри, а решение так и не приходит. Переключаешь мозг на другую задачу и, после передышки, находишь решение на поверхности.
В качестве примера хочу рассказать про ход решения одного из инцидентов.
Заказчик обратился с проблемой о высокой утилизации свободного места на сервере Linux Red Hat. На нём установлена одна из компонент сопровождаемой системы, и отсутствие свободного места грозило остановкой продуктивного контура.
Место заканчивалось стремительно, и IT-специалисты заказчика удалили объёмныё файлы, что и дало время на проведение анализа.
Наша команда обнаружила, что проблемный раздел фактически заполнен сильнее, чем суммарное количество находящихся в нем файлов. Оказалось, что при удалении объекта, который открыт на запись информации, происходит его "удержание" до завершения работы процесса.
Команда du просматривает файлы, подсчитывая их размер, а команда df обращается непосредственно к файловой системе, показывая реальное количество занятого пространства. Для определения проблемного файла и процесса, который его "удерживал", использовали команду lsof.
После нахождения проблемного процесса смогли разобраться, что дело заключалось в узком месте одного из алгоритмов. Он не предусматривал неточность при заполнении пользователем некоторого параметра, что приводило к бесконечному циклу и постоянной записи в лог одного и того же сообщения.
После исправления ошибки подготовили рекомендации для администраторов заказчика по созданию отдельного раздела для файлов логов, чтобы исключить возможность ситуации, когда внезапно закончившееся свободное место приведёт к остановке системы.
При решении задач наша команда технического сопровождения накапливает опыт, техническую экспертизу, которые позволяют развивать дополнительные сервисы, обучать сотрудников заказчика, проводить аудиты системы, а также внедрять системы мониторинга.