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

Однако распространять на другие отделы то, что было написано кем-то на коленке, слишком накладно. Нужен системный подход и отдельный стек, который лучше подходит для подобных вещей.

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

О какой автоматизации идет речь? Тут бескрайнее поле: начиная от создания документации к продуктам и релизам, внутреннего документооборота, сопровождения проектов и заканчивая сотнями мелких задач, упрощающих рутинные процессы.

Автоматизация: с чего мы начинали

Для начала расскажу, как мы выстраивали автоматизацию. Если вам больше интересны идеи, что и как можно автоматизировать, — самое «мясо» для вас во второй части статьи.

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

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

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

Один из первых вопросов — какой язык разработки выбрать? 

Классический вариант — Python. Он отлично подходит для разовых скриптов и MVP, то есть проверки гипотез. Казалось бы, отличный вариант, тем более что 80% из сделанного на тот момент уже было написано на Python. 

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

Часть того, уже было на Python, мы постепенно переписали на Go, но что-то оставили по принципу «работает — не трогай». Архитектура изначально получилась микросервисная, так что все состыковать можно простыми запросами по REST или gRPC. А «хвост» скриптов на Python мы продолжаем поддерживать. Кроме того, по-прежнему используем Python для отдельных задач и MVP. 

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

Приоритизация задач

В итоге пару лет автоматизация поддерживалась моими силами. Я, например, выделил под автоматизацию отдельный проект в Jira. Начал использовать простую систему оценки поступающих обращений. В ней всего два параметра:

— ценность, которую принесет эта фича (оценка от 1 до 10, определяющая важность задачи для компании);
— трудозатраты — сколько часов у разработчика уйдет на реализацию. 

Первое делим на второе и ранжируем задачи в очереди. Получается что-то среднее между продуктовым подходом и приоритизированной канбан-очередью.

Вот формула с пояснениями:

W — итоговый вес, BV — ценность, SP — трудозатраты. I — индикаторы (1 или 0):
I_critical = 1, если критический баг
I_blocker = 1, если это блокер
I_needFix = 1, если найден баг в задаче при тестировании

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

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

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

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

Что нам это дало? Теперь все коллеги могут сами заявить о потребностях в автоматизации — только они видят ту рутину, которую можно передать скрипту. 

Также сделали специальную группу поддержки в Telegram, где можно задавать вопросы о работе микросервисов. Ведь не всегда удается досконально написать доку и возникают вопросы: «Это баг или фича?» или «А как эту штуку мне применить вот тут?». Плюс группы в том, что иногда отвечают на вопросы и наши коллеги, которые с этим уже сталкивались. 

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

Что сейчас автоматизируем 

Сформулировали для себя вот такие направления:

• документация и отчеты (именно на них был фокус с самого начала);

• мониторинг и напоминания для поддержки;

• боли, повторяющиеся действия, рутина и типовые запросы;

• узкие горлышки процессов;

• новые сервисы и боты-помощники.

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

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

В общей сложности за время существования отдела решили более 1200 задач. Правда, эта цифра мало что говорит об общих трудозатратах, потому что одна задача может занимать пять минут, а следующая — две недели.

Кому и как помогаем

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

В каждой задаче идем итерациями — бьем идеи на мелкие части, собираем на коленке MVP, чтобы оценить целесообразность. Пользователь может его пощупать и сказать, то ли он вообще хотел. Как правило, на старте нет еще видения, как сделать правильно. Есть только «хочу, чтобы работало». В этот момент просто нет смысла городить много функционала.

MVP закрывает базовые потребности, но оставляет многое на «ручном приводе». Если идея оказалась годной и востребованной, команда собирает обратную связь и дорабатывает идею. А пользователи, «потрогав» продукт, лучше осознают, чего хотят на самом деле, что им уже удобно, а что стоит скорректировать. Когда становится понятно, что все используется так, как предполагалось, ручные действия постепенно заменяются на автоматизацию. 

Код сразу создается с кастомизацией и описанием, как и что можно настроить, чтобы нам, разработчикам, не пришлось потом отвечать на вопросы, как работает сервис. При этом стараемся делать максимально просто. Например, автодокументация, которая создается в Confluence, кастомизируется в том же Confluence, а не где-то в YAML-файлах. Не приходится лезть в незнакомые интерфейсы или отказываться от автоматизации из-за того, что средства незнакомы.

Конечно, недопонимания и поломки все равно происходят — не все читают документацию. Чинит все тот же наш отдел.

Что интересного уже сделали

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

Для HR

Наши HR’ы давно мечтают о внутреннем портале. Мы смотрели сторонние решения — ни одно из них не подошло. Нужно либо существенно дорабатывать что-то готовое, либо писать свое. Пока на такой масштабный проект мы не решились, но кое-что сделали.

• Telegram-бот Галина. Через Галину реализован электронный документооборот: можно написать заявление на отпуск или отгул, взять больничный. Налету по шаблону формируется документ с нужными ФИО и датами и передается в бэк-офис. Сама подпись работает не через Telegram — специалист по документообороту подписывает их вручную с помощью ЭЦП и передает готовый документ обратно боту. 

• Карта сотрудников. У нас довольно специфическая иерархическая структура — не всегда с порога понятно, кто у кого руководитель, к кому можно пойти с вопросом. С ростом компании это стало проблемой, поэтому сделали карту сотрудников с автоматически подгружаемой информацией: должность, положение в иерархии, ФИО и контактные данные. В первый же рабочий день сотрудник появляется на карте, в день увольнения исчезает с нее.

Карта здорово помогает ориентироваться в компании. А еще этот проект стал отличным примером задачи, где наступили на грабли с оценкой времени. Изначально это звучало как «давайте за два дня быстро сделаем». Но с момента появления идеи до ее выхода в прод прошло почти девять месяцев. Много времени потратили на то, чтобы вытащить из инициатора идеи его видение, как все это должно работать. А еще долго взаимодействовали с фронтендом, ведь кому-то надо было нарисовать-таки саму карту. 

• Random lunch — telegram-бот для случайного выбора напарника на обед (из перечня зарегистрировавшихся). Строго говоря, бот появился еще до формирования нашего отдела. Но мы тоже приложили руку: добавили возможность выбрать локацию для обеда и простенькую анкету, чтобы можно было предлагать коллегам интересные места. Целый год коллектив активно знакомился и тимбилдился таким образом, но в какой-то момент волна интереса к боту стихла.

JiraЖест

У Jira очень мерзотный своеобразный подход к уведомлениям по задачам. Они шлют сообщения на почту по одному на каждое изменение. И их, конечно же, никто не читает.

Поэтому мы сделали спешиал-алгоритм, сохраняющий все события, которые происходили в Jira, и по ним раз день собирает дайджест со всеми важными изменениями для любого желающего в одном сообщении в телеге. 

Автоматическая документация

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

Чтобы не заставлять писать эти доки вручную, сделали сервис — автодоку. С ним связано много всяких деталей, включая шаблоны, сегментацию и упорядочение данных. Если интересно, у нас есть про это отдельный пост на Хабре.

Изначально сервис закрывал базовые потребности флагманского продукта. Но появляются новые продукты, потребности которых не закрыты, — планируем расширять автодоку и на них. Да и во флагманском продукте еще много работы.

Release Notes

Отдельное направление автоматизации — формирование Release Notes — перечня изменений в очередной поставке. Скрипт сам дергает информацию из задач Jira, чтобы не пришлось вручную все это собирать. С учетом того, что у нас 24 релиза в год плюс есть особенности по поставке релизов конкретным заказчикам, без автоматизации на такую ретроспективу уходило очень много времени. Кстати, о нашем подходе к Release Notes рассказывали в этой статье.

Уведомления, дайджест Jira и двери в офисе

В каждый рабочий чат мы добавляем telegram-бота Валеру. Он помогает быстро получить доступ к задачам в Jira. Например, кто-то в беседе упомянул номер задачи, а бот сразу подтягивает ее ссылкой (чтобы можно было перейти и посмотреть описание). Точно так же это работает и в Confluence.

Через Валеру работают все рабочие уведомления. Техподдержке Валера несколько раз в сутки скидывает напоминания о письмах от заказчиков, чтобы не пропустить SLA, разработчикам по утрам пишет об изменениях в Jira за вчерашний день и т. п.

А еще Валера открывает дверь в офис по нажатию кнопки в чате (электронные замки подключены через микроконтроллеры). Благодаря этому большая часть коллектива не носит карточки. Их продолжают носить только несколько человек на случай отключения мобильного интернета или еще каких-то проблем. 

Быстрый парсинг логов

Совсем недавно под юрисдикцию отдела автоматизации перешел telegram-бот Марвин. Зародился он в одном из флагманских продуктов, чтобы техподдержка быстрее разбирала логи от заказчика. Фактически он предоставляет быстрый доступ к сервису стандартизации данных через чат.

А еще у нас есть бот Долорес. Со стороны продукта при возникновении проблем можно в несколько кликов собрать стандартный Zip-архив с данными, позволяющими поддержке на стендах воспроизвести ошибку. Этот Zip-архив можно переслать боту, чтобы тот через Kubernetes сам поднял стенд с нужными продуктами — версиями и зависимостями. Это экономит много времени ребятам из поддержки. Также архив содержит контекст и входные данные, которые вызвали ошибку.

Задачи на основе переписки

Если переслать кусок переписки telegram-боту Осетру, он создаст задачу в Jira (уточнив пару вещей). Автоматически он прикладывает к задаче документы, скриншоты и оформляет, кто какое сообщение писал, чтобы важные идеи не терялись.

Как рассказать коллегам об автоматизации

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

• в Confluence ведем раздел с последними изменениями;

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

• максимально оперативно сообщаем о полезных штуках в еженедельных новостях;

• примерно раз в полгода проводим внутреннее демо, где рассказываем, что крутого сделано.

А еще наши telegram-боты умеют самопрезентоваться. 

Ретроспектива и некоторые задумки

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

Со временем некоторые сервисы выходят из оборота. До недавнего времени мы понимали это, когда к нам переставали приходить с багами и запросами на улучшения. Но сейчас идет настройка мониторинга всех сервисов через Grafana. В отчетах будет видно, как часто идут запросы к сервису. Те, которые не используются год и больше, будем отключать (или придумывать, как им дать вторую жизнь с учетом текущих запросов коллег).

Можно сказать, что это следующая стадия развития внутренней автоматизации: мы доросли до необходимости следить за всей этой инфраструктурой 24/7, чтобы наши инструменты работали всегда.

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

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

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

Вместо итогов

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

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