Всем привет! Меня зовут Дарья Андреева, я руковожу командой бэкенда Биллинга и B2B‑платформы Яндекс 360. Наша команда, чтобы сократить TTM и освободить разработчиков от рутины, создаёт удобные внутренние инструменты. Сегодня я хочу поделиться своим опытом и порассуждать о внутренних инструментах.
Начну с контекста. Яндекс 360 — это виртуальный офис для работы и личных дел, куда входят Диск, Почта, Календарь, Телемост, Мессенджер, Документы и другие сервисы. В течение четырёх лет команда растёт больше чем в два раза каждый год. Растёт нагрузка на сервисы, и вместе с ней бэклог. Поэтому автоматизация и ускорение процессов для нас вопрос выживания: без этого мы не смогли бы двигаться с той скоростью, которая нам нужна.
Эта статья — попытка собрать наш опыт, чтобы вы избежали наших грабель и могли быстро отвечать на главный вопрос: как реализовать тот или иной внутренний инструмент. Расскажу, какой критерий считается основным при выборе подхода к разработке внутренних инструментов, какой тип админок будет самым подходящим в той или иной ситуации и чем могут помочь готовые инструменты.
Разберёмся с терминами
Давайте, чтобы не запутаться, начнём с определений. Под «внутренним инструментом» может скрываться всё что угодно:
ПО для решения внутренних задач;
различные тулы;
админки;
вспомогательные домены (если вы придерживаетесь DDD).
Но у всех этих сущностей есть общий знаменатель: внутренние инструменты автоматизируют рутинную работу, освобождая руки для решения новых, сложных и интересных задач. Мы, инженеры, хотим заниматься именно этим, а не бесконечно разгребать sustain.
Сразу уточню, о чём не пойдёт речь: я не говорю о Яндекс Трекере или его аналогах, IDE или любых инструментах для совместной работы. Речь пойдёт именно о том, что команды разрабатывают внутри компании, чтобы ускорять бизнес.
Как внутренние инструменты помогают продукту
Раз уж мы заговорили про ускорение, давайте разберём пример, близкий нам как команде Биллинга. Одна из наших задач — запуск акций. Чтобы пользователям Яндекс 360 какое‑то время показывался специальный скидочный тариф, например на «чёрную пятницу», нужно просто завести соответствующие сущности в базе.
Когда мы только запускались, это выглядело так: разработчик садился, разбирался, какие сущности нужны, писал большую и потенциально багоёмкую миграцию, выкатывал её, помогал тестировать и релизить. На всё уходил фактически спринт: сначала разбор, потом час на написание миграции, потом несколько итераций правок. Очень быстро стало понятно, что разработчик не должен тратить на такую задачу две недели, — нужен инструмент, который позволит запускать акции без его участия.
Так родилась админка акций — наш первый инструмент ускорения. Красивый интерфейс, в котором менеджер может накликать всё за час.
Две недели труда разработчика превратились в час работы менеджера. Акции подешевели, запускать их можно чаще — всё прекрасно. Но если посчитать полную стоимость разработки — бэкенд, фронтенд, тестирование, — получается примерно полгода человеко‑дней. Инструмент окупился где‑то за девять акций, что означает как минимум год.
Почему внутренние инструменты могут оказаться проблемой
Представим типичную ситуацию: аудитория продукта растёт, поддержка захлёбывается, и становится очевидно — нужна админка для поддержки. В биллинге это, скорее всего, админка подписок: чтобы можно было посмотреть данные, нажать нужные кнопки, выполнить базовые операции, например продлить или отозвать подписку.
За задачу одновременно берутся два человека: разработчик и менеджер. Разработчик действует быстро, менеджер — методично. Разработчик за вечер поднимает админку подписок. База у нас в порядке, и разработчик просто собирает из этого интерфейс — и вот инструмент готов, им уже можно пользоваться. Менеджер же хочет полноценную, безопасную и продуманную админку, которая раз и навсегда решит проблемы поддержки. Поэтому идёт собирать требования: проводит встречи, выясняет сценарии, подключает дизайнера, чтобы всё было аккуратно и правильно.
Пока менеджер собирает информацию и планирует работу, админка, сделанная разработчиком «на коленке», живёт своей жизнью. Её начинают использовать, и она постепенно обрастает функциональностью — иногда довольно опасной. Всё, что может потребоваться поддержке, постепенно добавляется туда.
И заканчивается всё в обоих сценариях одинаково плохо: разработчик выдаёт доступ новому сотруднику поддержки, тот нажимает что‑то лишнее — и по худшему сценарию это приводит к большому инциденту. Менеджер тем временем тоже не сидел без дела. Спустя полгода он наконец зарелизил свою продуманную, аккуратно собранную админку. Но за эти полгода мы успели разработать шесть новых видов подписок, и его инструмент их просто не поддерживает. ��тог тот же: ничего не работает.
В итоге неясно буквально всё:
как вообще подступаться к задаче;
кто за неё должен отвечать;
как развивать инструмент;
нужно ли относиться к нему как к продукту или как к временной поделке.
Чтобы перестать наступать на те же грабли, нам нужно было ответить на главный вопрос...
Как разработать внутренние инструменты, чтобы они помогали, а не создавали проблемы
И чтобы ответить на этот вопрос, нужно вначале понять, что именно мы делаем. Поэтому мы решили вывести классификацию внутренних инструментов. Для классификации нужен параметр — и мы выбрали слово «импакт». Под импактом мы понимаем, насколько широко инструмент будет использоваться, то есть какую аудиторию он затрагивает и насколько сильно влияет на процессы.
Мы рассмотрим три уровня инструментов:
Те, что делаются для самой команды разработки.
Инструменты для смежных команд, которые погружены в домен и часто с нами взаимодействуют.
И самые широкие — внутренние инструменты, которые, по сути, становятся продуктом для всей вертикали, отдела или даже компании.
Инструменты для команды разработки
Начнём с самого ближнего слоя — инструментов, которые мы делаем для себя. Хороший пример — та самая техническая админка из истории про разработчика и менеджера. Штука, которую разработчик поднял для себя, вывернув наружу данные и добавив минимальный набор кнопок. Такая админка вполне может использоваться нами же, чтобы ускорять собственные задачи. Дежурный может нажать нужную кнопку, посмотреть состояние сущности, вместо того чтобы идти грепать базу.
Ещё пример — Datafix‑тула, которая добавляет валидации к SQL‑скриптам, которые мы запускаем вручную. Такие инструменты решают обычно две простые и понятные задачи:
Автоматизация ручных действий. Чтобы разработчик или дежурный не делал одно и то же руками из раза в раз.
Снижение риска человеческой ошибки. Если вместо ручного SQL‑скрипта есть кнопка, шанс ошибиться становится значительно ниже.
К инструментам, которые мы делаем для себя, требования довольно специфичные. Во‑первых, нам не важно, как они выглядят. Мы и так погружены в домен, понимаем данные, понимаем связи и не нуждаемся в человекопонятном UI. Во‑вторых, критичен низкий показатель Time to Market. Такие инструменты должны обновляться сразу после изменений в коде и не успевать протухать. Если инструмент отстаёт от реального состояния сервиса, он моментально теряет смысл.
Поэтому подход здесь простой: пишем сами и поднимаем сами. Приведу пример: в какой‑то момент нам в биллинге понадобилась динамическая админка для каталогов. Нужно было:
отображать каталог целиком;
редактировать данные;
выполнять операции над сущностями.
Каталог у нас уже был описан в коде. Значит, оставалось описать типы данных, поля и доступные действия, а потом вернуть всё это из ручки в виде, который можно шаблонизированно отрисовать на фронте. Мы попросили фронтенд‑разработчиков собрать универсальный шаблон, и получилась динамическая админка, которая сама строит UI из описаний в коде и показывает все сущности, связанные с биллингом.
Что это нам дало:
поиск данных по типовым сценариям стал намного быстрее;
рутинные действия выполняются за секунды;
вероятность человеческой ошибки уменьшилась;
польза — максимальная.
Но самое главное — внесение изменений занимает часы, а не дни. Обновили код → выкатили → и новая структура данных уже автоматически отображается в админке.
В итоге мы выделили два основных правила, как делать инструменты для себя:
Не делегировать такую разработку. Нельзя заказывать внутренние инструменты у другой команды — это не их домен, а ваш, и только вы понимаете данные и сценарии.
Не выпускать инструмент за пределы команды, не подумав о последствиях.
То, что работает для разработчиков, может быть слишком опасным для других ролей.
Внутренние инструменты для смежных команд
Практика показывает: чаще всего нам нужна админка, которую можно отдать в использование маркетингу, тестированию или любой другой смежной команде. В биллинге таких примеров довольно много. Для маркетинга это админки управления каталогом и продуктами — через них можно заводить маркетинговые активности быстрее и без участия разработки. Для тестировщиков — инструменты для создания тестовых данных: вместо того чтобы дёргать дежурных или разработчиков, можно зайти в админку, навесить нужные тестовые подписки — и всё работает согласованно и предсказуемо.
Что решают такие инструменты? По сути — проблему кросс‑командного взаимодействия. Чем проще и понятнее админка, тем меньше запросов в разработку и тем меньше ручной работы на стыках процессов.
При этом требования к реализации смещаются. UI/UX становится заметно важнее: инструмент передаётся людям, которым нужно в нём ориентироваться без погружения в код. Но при этом скорость разработки всё ещё критична — нам важно, чтобы такие инструменты появлялись с низким Time to Market.
Когда мы впервые столкнулись с этой задачей, было очевидно: наверняка на рынке уже есть готовые решения, которые можно использовать. Мы начали исследование, но перед этим определили критерии, по которым будем отбирать фреймворки.
Во‑первых, нам нужны опенсорсные, бесплатные и self‑hosted‑решения — это обязательные требования, чтобы фреймворк можно было безопасно завести во внутреннюю инфраструктуру. Во‑вторых, подд��ржка интеграции с нашей ролевой моделью: мы хотим использовать ту же систему ролей, что и остальные внутренние сервисы. Далее — работа с API как основным источником данных, потому что именно так устроены наши внутренние интерфейсы. Ну и конечно, мы смотрим на то, как именно во фреймворке генерируется UI.
Результатом стал большой сравнительный обзор.
Из всех решений, что мы перебрали, два действительно подошли под наши требования: Vaadin и Appsmith.
Vaadin — это backend‑driven UI‑фреймворк на Java. Он позволяет описывать интерфейсы и лейауты прямо в Java‑коде, а затем запускать и получать готовый UI. По сути, это удобный инструмент для бэкенд‑разработчиков, которым нужно быстро и эффективно собирать админки.
Второе решение, которое мы рассмотрели, — Appsmith. Концептуально он устроен совсем иначе, чем Vaadin. Это скорее UI‑конструктор: drag‑and‑drop wizard, в котором вы буквально мышкой раскладываете элементы интерфейса, подключаете к ним свои ручки, настраиваете обработку данных — и затем просто нажимаете кнопку деплоя. После этого приложение улетает в прод.
Когда мы взяли оба решения — Vaadin и Appsmith — и начали разбираться, что нам стоит их внедрение и дальнейшая эксплуатация, обнаружилось неожиданное: по трудозатратам они оказались почти идентичны. Appsmith оказался удобнее для нас, потому что с ним могут работать не только Java‑разработчики. А значит, его можно использовать в смешанных командах.
Вот так Appsmith выглядит у нас:
На скриншоте — та самая админка акций, которую мы когда‑то делали полгода силами разработки. Теперь она собрана за час на тех же самых API, что уже существовали. Разница очевидна: с таким фреймворком мы можем поднимать внутренние инструменты и админки не за кварталы продуктового цикла, а за недели. Сделали новый проект — сделали к нему админку.
Поддержка таких интерфейсов тоже упрощается. Это инструмент, с которым команда разработки может работать сама: чтобы пофиксить баг, не нужно идти к отдельным фронтенд‑командам и заводить запросы — просто исправляем сами. Обычно это дни или недели, а не месяцы.
Всегда стоит помнить, что на рынке почти наверняка есть готовые решения. Перед тем как писать свой велосипед, полезно посмотреть, что уже существует, и выбрать то, что действительно подходит вашей команде и вашей инфраструктуре.
Внутренние инструменты как продукт
Хороший пример такого подхода — инструмент, который мне однажды довелось разрабатывать. Это была внутренняя тула для команды hosted managed services — разработчиков, сидящих в onsite‑поддержке и закрывающих самые горячие инциденты. Им нужна была система, способная массово выполнять большое количество датафиксов, батчевых операций и быстрых исправлений, когда прод внезапно падает и его приходится разгребать в реальном времени.
Такие инструменты появляются тогда, когда нам нужно централизованно решить проблему для большого числа команд и снизить затраты на поддержку и развитие.
Когда в компании появляется всё больше команд, каждая начинает решать похожие задачи по‑своему. В результате растут десятки локальных решений, которые сложно поддерживать и невозможно развивать централизованно. Поэтому в какой‑то момент становится логичным делать единый внутренний инструмент, который можно масштабировать, поддерживать и развивать в одном направлении.
Тут требования заметно меняются. Во‑первых, UI/UX становится критически важным: инструментом будут пользоваться десятки команд и у вас не будет физической возможности лично обучать каждого нового пользователя. Значит, интерфейс должен быть понятным «из коробки».
Во‑вторых, нужны инструкции, тренинги, документация — всё, что помогает людям быстро включиться в работу. Это уже полноценный продукт, просто внутренний.
В‑третьих, кардинально меняется отношение к Time to Market. Любое изменение автоматически разойдётся по всем командам, которые используют вашу тулу, поэтому каждую правку приходится рассматривать под лупой. Нужна стратегия развития продукта — и дисциплина, чтобы придерживаться её.
В этот момент вы уже делаете продукт со всеми атрибутами. Формируется полноценная команда:
Product manager / technical product owner — собирает требования, работает с пользователями, отвечает за направление развития.
Бэкенд, фронтенд, тестирование — прокладывают технические рельсы, на которых инструмент будет работать и дальше масштабироваться.
Да, это требует времени. Но и отдача другая: инструментом пользуются не одна‑две команды, а десять, двадцать — сколько угодно. Появляется единая поддержка (одна команда держит весь стек), единое развитие (технический лидер двигает продукт по стратегии), а скорость изменений становится уже недельной или месячной. И это нормально: каждое изменение затрагивает всех пользователей инструмента.
Самое главное — фокус на развитии продукта. Очень часто приходит команда с запросом «нам срочно нужен вот такой фичреквест, иначе мы не можем жить». Но такие запросы не всегда ложатся в стратегию развития. И если идти на поводу у каждого запроса, инструмент начнёт разъезжаться, терять целостность и превращаться в тот же набор велосипедов, только внутри одной кодовой базы.
Поэтому приходится держать баланс: корректировать ожидания, объяснять, искать альтернативные решения — и при этом сохранять курс. В итоге все эти решения — от маленьких тул для себя до полноценных внутренних продуктов — образуют непрерывный спектр. На одном полюсе — локальные утилиты, которые делают скорость. На другом — платформенные инструменты, которые дают импакт.
Часто приходится работать на стыке: комбинировать самостоятельную разработку и готовые фреймворки вроде Vaadin, искать гибридные варианты, думать про эволюцию, а не про разовые решения. И вот здесь как раз начинается самое интересное: как собирать решения на пересечении подходов.
Решения на пересечении подходов
Помните динамическую админку — такой CRUD «на стероидах»? Тогда UI нам собирали фронтендеры. Но если использовать Vaadin, то большую часть работы можно делать прямо в Java‑коде. Мы можем взять сущность, завернуть её в UI через bind, описанный в коде, и фактически просто прочитать этот bind — получив визуализацию интерфейса.
Такой подход одновременно даёт гибкость бэкенд‑разработки — из кода можно описать почти всё поведение данных — и возможности кастомизации UI, которые идут в комплекте с Vaadin. Поэтому Vaadin отлично подходит для тех команд и сервисов, где основной фокус — на бэкенде и где много инструментов создаётся локально, своими силами. Бэкендер пишет привычный Java‑код, а результат — рабочая админка, которую можно быстро менять и поставлять в прод.
Посмотрим в другую сторону — на Appsmith, тот самый drag‑and‑drop UI wizard. Он позволяет быстро накидать внутренний инструмент или админку и проверить гипотезу. Например, собрать первый вариант админки для акций, понять, что она действительно закрывает наши задачи, и чуть её довести.
Если решение оказывается полезным, можно развивать его в полноценный внутренний продукт: подключить дизайн, проджекта, собрать требования, сформировать полноценную команду. Appsmith позволяет быстро закрыть критическую функциональность «здесь и сейчас», чтобы всем стало легче уже сегодня. А пока эта версия работает, можно параллельно строить более серьёзный продукт.
Это хорошо отражает то, что разработка — живой процесс. Продукты эволюционируют: сделали маленькую админку для себя, а вдруг выяснилось, что она нужна всем командам. Или сделали внутреннюю тулу и поняли, что она настолько хороша, что её можно выводить наружу. Комбинируя инструменты и подходы, эту эволюцию можно проходить довольно безболезненно.
Выводы
Мы часто упираемся в вопрос создания внутренних инструментов просто потому, что не понимаем, как правильно к ним подступиться. У каждого инструмента есть свой подходящий способ реализации. Чтобы его выбрать, нужно понимать:
кто будет пользоваться инструментом;
какова стратегия его развития;
какие ограничения и грабли есть в каждом конкретном подходе.
И в конце хочется поделиться цитатой, которая хорошо отражает суть:
И хочется, конечно, делать хорошо. Спасибо, что дочитали! Напишите в комментариях, пользовались ли вы готовыми решениями для внутренних админок.
