Привет! С вами Антон Тарабрин, заместитель начальника отдела эксплуатации в РТЛабс. Хочу поделиться опытом организации работы команды инженеров, занятой на поддержке 60+ информационных систем (ИС) и взаимодействующей с разными командами разработчиков — от внутренней до внешней разработки.
Расскажу, как мы сделали организационные задачи более прозрачными, и, надеюсь, наш опыт будет полезен.
В статье использованы термины, применяемые во многих компаниях: Jira как таск-трекер, Confluence для архива документации и календарей команд. Как частный случай можно использовать Telegram.
Проблема
В определённый момент роста команд мы столкнулись с проблемами «серой зоны» нагрузки — когда есть процессы, тикеты и другие артефакты, но на текучку уходит всё больше человеко-часов. Большинство запросов сводилось к оформлению документации с часто задаваемыми вопросами.
«Высветить» и проанализировать «серые зоны» по нагрузке оказалось непросто, потому что заказчики привыкли обращаться напрямую к конкретным инженерам. В итоге одни исполнители оказывались перегружены, а другие — загружены мало. Из-за этого возникали проблемы:
команда не видела, какие запросы уже обработаны
ответственность распределялась неравномерно
при уходе сотрудников в отпуск часть информации терялась
Крупных и важных запросов это не касалось — они покрывались релизами или запросами на изменения
Часто большой объём текущих запросов формировался при появлении новой системы или новых команд, начинающих работать с инженерами эксплуатации. Сложности добавляло огромное количество функциональных и организационных чатов. Самый простой способ, казалось, — объединить чаты с одними и теми же людьми и удалить лишние чаты. Однако разделение некоторых чатов было оправдано организационно, в некоторых случаях этого требовали и другие обстоятельства.
Я пытался вручную классифицировать запросы, но из-за их большого количества и множества источников это оказалось неэффективным. Тогда решил автоматизировать процесс работы с текущими запросами. После поисков доступных или лёгких в реализации решений — без дополнительного беспокойства сотрудников или кардинального изменения подходов — сформировались следующие требования:
организация единой точки входа по текущим и быстрым запросам
сбор статистики — метрик нагрузки, классификация запросов. Раньше у нас не было возможности собирать статистику и анализировать нагрузку от текучки по направлениям, поэтому в перспективе организация сбора статистики давала дополнительный плюс
создание вспомогательной функциональности для более лёгкого встраивания нового инструмента трекинга в работу инженеров
В итоге решили встроить простую тикет-систему в мессенджер и дополнительно решить вспомогательные задачи.
Вывод прототипа бота
Разработали бот и его функциональность. Одной из задач было использовать простые и доступные к программированию подходы, чтобы развивать бота могли сами инженеры. Техническую детализацию пропускаю, ибо сам инструмент относительно прост, написан на python и зависит условно от api используемого мессенджера.
Обсудив требования к решению, нарисовали схему прототипа бота.
На начальном этапе этот подход решал проблему единой точки входа, сразу писал статистику запросов и историю в базу данных и сохранял запросы.
Как видно на схеме, для хранения состояний и логов используется база данных — в нашем случае это Postgres. В ней логируются и хранятся данные и состояния запросов. База данных состоит из таблиц, в которых содержатся:
отдельно записанный whitelist чатов — о нём расскажу чуть позже
история запросов, включая ссылки на сообщения, время смены состояний и статус запроса
страница сопоставления идентификаторов чата, например в телеграм, и внутренних учётных записей
Это позволило бы при правильно сконструированных запросах получать статистику нагрузки по отдельным чатам с логической привязкой чатов к ИС, например статистику нагрузки по направлениям.
В ходе проработки решения получилась простая ролевая модель, включающая пользователя, инженера эксплуатации и владельца дежурного бота. Пользователю доступен только условный «фронт» бота — обращение через тег, инженеру — внутренний чат, где бот складывает запросы от разных чатов, и возможность менять статус запроса.
Роль владельца более административная: ему доступны действия инженера и возможность регистрировать бота в нужных чатах — добавлять в whitelist. Сделано это как условный спам-фильтр от нежелательного добавления в чаты: после добавления владелец бота должен дать команду боту на регистрацию чата. Хоть бот и предназначен для удобства работы со множеством чатов, но их количество лучше не увеличивать.
Таким образом получили whitelist чатов для обработки ботом, который с ним сверяется, если эта опция включена.
Настроили приём запросов. Обдумав принципы работы инженера и бота, мы решили настроить функциональность, когда запросы будут поступать в отдельную группу, а не в личные сообщения инженерам. Это позволяло членам команды обсуждать запросы, обмениваться опытом и понимать общий поток запросов.
Эту функциональность обеспечивает python-скрипт, получающий по api мессенджера информацию о тегировании. Он «причёсывает» сообщение с запросом, очищает от тега и отправляет с клавиатурой обработчиков в чат с дежурствами. Handler в python обрабатывает смены статуса и кладёт информацию в базу данных. Под каждую команду поднимается отдельный инстанс со своими настройками и метаданными — имя команды и список авторизованных пользователей ролей владелец и инженер.
Перестроили работу команды. Это техническое решение привело к организационным изменениям. В командах ввели день дежурства. Выходы инженеров на поток текучки стали расписываться на неделю вперёд. При большом объёме информационных систем на поддержке, компетенции, как правило, сильно фрагментируются, и обмен знаниями затруднён. С новым инструментом и введённым днём дежурства при разборе потока почти автоматически происходит обмен компетенциями между инженерами. Первое время дежурный задавал вопросы коллегам, обнаруживал пробелы в документации, из-за чего команда испытывала дополнительную нагрузку. Но в итоге повысился общий уровень качества поддержки команды и уменьшился риск перегрузки отдельного сотрудника.
Как вы можете заметить, тут появилась новая функция — «Преобразовать в тикет Jira». Дополнительная трекинговая работа для инженера эксплуатации — не особо приятная задача и возможность упростить эту обязанность приветствуется. С инженерами условились, что если отработка запроса занимает больше 15 минут, нужно создавать тикет.
Дальнейшее развитие
Мы выбрали наиболее инициативные команды разработчиков, внедрили бота и новый подход. Дальше стали отслеживать реакции заказчиков на появление единой точки входа и дополнительную «прокладку» между ними и инженерами. Команды развития поначалу недоумевали от лишнего условия работы с эксплуатацией, но после мини-презентаций, коротких встреч и наработки опыта высоко оценили нововведение.
Внедрив прототип в наиболее лояльные команды и обкатав его функциональность, мы дополнили его новыми фичами.
Что добавили
Напоминание про задачи
Бот напоминает:
каждый день в 18:00 — о незакрытых запросах
каждое утро в 9:30 — о тикетах в Jira
каждую пятницу — gently reminder о необходимости подбить долги и списать время
Уведомление по тикетам в Jira существенно облегчило лидам команд отслеживание задач и упростило их ранжирование по просрочке, срокам и другим параметрам. Фильтры запроса настраиваются все сразу и индивидуально по желанию в дополнение к стандартным доскам.
Интеграцию со спейсами команд в confluence
Напоминать инженерам о дежурствах стал уже бот по календарю, составленному заранее. Прикрутив ответы по статистике, мы создали позитивный соревновательный настрой. Инженеры в конце недели с удовольствием запрашивают рейтинговую таблицу по количеству запросов. Это превратилось в неформальный челлендж:
команды обсуждают итоги и шутят о рейтингах
лучшему инженеру недели вручают символические награды
В планах — добавить геймификацию с бонусами за активность.
Словарь предопределённых ответов
Интересная реализация, не занявшая много ресурсов, но повысившая клиентский опыт, — словарь с шаблонами сообщений. Его мы создали для формирования ответов, чтобы уйти от однообразия. А у некоторых сотрудников есть персональный набор шуточных ответов, например «ваш запрос очень важен для вас» или «инженеры тушат восстание ботов, но скоро освободятся». Такие ответы помогают ненавязчиво сообщить пользователю, что запрос принят.
Ещё немного улучшения пользовательского опыта
Был докручен дополнительный обработчик автоответа. Если в команде больше 10 запросов в незакрытом статусе, то он сообщает заказчику, что команда загружена, и время ответа может быть увеличено. Это помогло повысить лояльность со стороны пользователей, переживающих за сроки.
И немного приятного для инженеров — помощник в работе с тикетами Jira
Есть также и частные случаи обработки сообщения-запроса. Например, автоматическое создание ссылки-перехода в Jira или другую внутреннюю систему по номеру тикета или идентификатору внутренней системы. Эта приятная мелочь позволяет экономить драгоценные секунды в период сильных авралов.
В итоге
Задача по выводу «серых зон» по нагрузке на команды в прозрачную статистику была выполнена с минимальными затратами: на программирование решения и вывод прототипа потрачено 5 часов, подходы и процессы не сломались, а само решение органично вписалось в работу. Бонусом повысилась лояльность смежных подразделений, взаимодействующих со службой эксплуатации.
Команда инженеров получила полезную функциональность, а мы, руководство, — повышение отзывчивости сотрудников и качества работы службы в целом, улучшение показателей и оздоровление культуры ведения рабочей документации.