![](https://webcf.waybackmachine.org/web/20220826103755/https://habrastorage.org/getpro/habr/upload_files/74f/e8f/77e/74fe8f77e254a8958eb358edc38071af.png)
Привет, Хабр! Меня зовут Григорий Иванов, я работаю ведущим специалистом команды MM.SUP в GlowByte. Сегодня хочу рассказать про работу команды технического сопровождения, или, как её ещё называют, поддержки. Эта статья позволит взглянуть на некоторые процессы изнутри и примерить на себя роль матёрого специалиста сопровождения.
Для понимания скажу несколько слов о продукте, который мы сопровождаем. Его основа – это система аналитического CRM с уникальными особенностями конкретного внедрения для каждого заказчика, а также набор систем, которые включают в себя витрины данных и инструменты BI.
Какие факторы влияют на работу сопровождения?
С одной стороны, это:
техническая сложность системы,
несколько десятков заказчиков с уникальными внедрениями,
отсутствие доступов к исходникам базового ПО.
С другой стороны (и это положительные факторы):
пользователями системы являются 5-10 человек,
достаточно высокий уровень IT-грамотности пользователей,
накопленный опыт по огромному количеству решённых проблем.
Кроме того, мы считаем, что сотрудник сопровождения должен уметь решать не только технические проблемы, но и понимать термины маркетинговых систем, чтобы разговаривать с заказчиком на одном языке.
Линии сопровождения
Мы разделяем процесс сопровождения на линии, используя определённые критерии для каждой из них.
![](https://webcf.waybackmachine.org/web/20220826103755/https://habrastorage.org/getpro/habr/upload_files/5ed/d0a/f68/5edd0af683ccea39d44e4975654b63f0.png)
Под первой линией сопровождения понимаем сбор первичной диагностической информации, классификацию инцидента, применение известных решений. Эти действия выполняются на стороне заказчика – пользователем или сотрудником IT.
Если анализ первой линии определил, что проблема заключается в работе нашей системы, то в системе учёта заявок Jira создаётся инцидент для второй линии. Для каждого инцидента автоматически назначается исполнитель и выставляется SLA на реакцию и на решение в соответствии с критичностью. При запросе сотрудником сопровождения уточняющей информации у заказчика “таймер” SLA останавливается. Это мотивирует его формулировать проблему максимально полно, сразу сообщать всю информацию по инциденту, то есть выполнять контроль за действиями первой линии.
У многих заказчиков есть стремление к росту собственных компетенций в сопровождении систем, и вторая линия может быть реализована его силами. Как правило, эту роль выполняют IT-специалисты, имеющие опыт сопровождения схожих систем или прошедшие обучение у вендора или у нашей команды. Задача второй линии – закрывать простые инциденты своими силами, основываясь на технической документации, базе знаний, собственных умениях.
Третья линия решает всё, что не смогла решить вторая. Если же наша команда реализует сопровождение ещё и второй линии, то внутри команды разделения на линии нет, но есть более опытные сотрудники, к которым можно обратится за помощью в сложных ситуациях.
В случае если проблема заключается в дефекте базового ПО, предоставляемого вендором, то наша задача вести с ним коммуникацию, собирать диагностическую информацию и применять рекомендации до тех пор, пока проблема не будет решена.
Чрезвычайно удачным решением считаю использование единой для всех заказчиков системы учёта заявок. Это позволило работать с ней как с одной точкой входа для инцидентов, создать гибкую систему оповещений, в том числе с помощью различных ботов.
Время, за которое происходит реальное назначение исполнителя и реакция на инцидент, в среднем составляет не более 15 минут, несмотря на реальные SLA в 1–2 часа, которые фиксируются в договоре с заказчиком. Это является великолепным показателем!
Культура и команда
Очень важным для нас является культура единой команды профессионалов, качество работы которых не зависит от конкретного исполнителя. При этом мы стараемся быть в контакте с заказчиком, погружаться в его процессы и решать задачу именно как проблему, минимизируя возможность повторения инцидентов.
Так кто же он – идеальный сотрудник, и почему сопровождение – это сложно и интересно?
Существует стереотип о том, что сотрудник сопровождения не способен на решение технически сложных задач и что в сопровождение идут работать те, кого не взяли на должность разработчиков.
Специфика нашей компании заключается в том, что существует множество команд, которые разрабатывают и внедряют уникальные решения для наших клиентов, и только малая часть из команд остаётся на проектах и занимается развитием системы. Основная же работа по исправлению багов и помощи в эксплуатации системы ложится на плечи команды сопровождения.
В своей работе мы погружаемся во все аспекты системы. Вместе с пользователями разбираемся в настройке и запуске функциональных элементов и в анализе данных. Собираем требования для доработок системы, преобразовывая бизнес-требования в техническую документацию. Пишем код, используя накопленные знания.
Когда я начинал работать в компании джуном, на погружение в процессы системы и её архитектуру ушло более года. Фактически каждый день я узнавал что-то новое про ту или иную особенность. Если говорить прямо, то изучение технологий продолжается и сейчас, поскольку на проектах их множество и разобраться с ними полностью невозможно. Помимо этого, расширяется список направлений, технологий и вендоров, начинаются новые проекты, а старые развиваются.
Решение инцидентов
Так что же представляет из себя процесс решения инцидента и насколько интересным это может быть?
![](https://webcf.waybackmachine.org/web/20220826103755/https://habrastorage.org/getpro/habr/upload_files/62b/e75/a1a/62be75a1a0bc0d1c15e1a0c5eb50b0ab.png)
При получении инцидента начинается сбор анамнеза – истории инцидента: шаги воспроизведения ошибки, свежие изменения в скриптах, массовость проявления. После чего выдвигается гипотеза о причине этой ошибке, проверяется, выдвигается следующая, и так до тех пор, пока не будет найдена корневая причина. Иногда приходится анализировать логику разработчика, иногда структуру таблиц самых разных СУБД, порой ошибка кроется в недрах операционной системы.
Случается и такое, что закапываешься в дебри, а решение так и не приходит. Переключаешь мозг на другую задачу и, после передышки, находишь решение на поверхности.
В качестве примера хочу рассказать про ход решения одного из инцидентов.
Заказчик обратился с проблемой о высокой утилизации свободного места на сервере Linux Red Hat. На нём установлена одна из компонент сопровождаемой системы, и отсутствие свободного места грозило остановкой продуктивного контура.
Место заканчивалось стремительно, и IT-специалисты заказчика удалили объёмныё файлы, что и дало время на проведение анализа.
Наша команда обнаружила, что проблемный раздел фактически заполнен сильнее, чем суммарное количество находящихся в нем файлов. Оказалось, что при удалении объекта, который открыт на запись информации, происходит его "удержание" до завершения работы процесса.
Команда du просматривает файлы, подсчитывая их размер, а команда df обращается непосредственно к файловой системе, показывая реальное количество занятого пространства. Для определения проблемного файла и процесса, который его "удерживал", использовали команду lsof.
После нахождения проблемного процесса смогли разобраться, что дело заключалось в узком месте одного из алгоритмов. Он не предусматривал неточность при заполнении пользователем некоторого параметра, что приводило к бесконечному циклу и постоянной записи в лог одного и того же сообщения.
После исправления ошибки подготовили рекомендации для администраторов заказчика по созданию отдельного раздела для файлов логов, чтобы исключить возможность ситуации, когда внезапно закончившееся свободное место приведёт к остановке системы.
При решении задач наша команда технического сопровождения накапливает опыт, техническую экспертизу, которые позволяют развивать дополнительные сервисы, обучать сотрудников заказчика, проводить аудиты системы, а также внедрять системы мониторинга.