11 октября 2026
Я подготовил эту стратегию вместе со Staff-инженерами платформенного направления. Нам нужно было согласовать приоритеты и ответственность инженерного руководства: какие архитектурные подходы сохраняем, что меняем и как продуктовые команды работают с платформой.
Доменные границы уже были определены, но в коде применялись не везде. Архитектурные стандарты внедрялись неравномерно и чаще попадали в инициативы по техническому долгу, чем в планы продуктовых команд. Объем функций рос после согласования MVP. Разработка оставалась сосредоточена в монолите, а для самостоятельных сервисов не хватало интерфейсов и инструментов.
Документ помогал обсуждать эти вопросы на общей основе. Он задавал приоритеты, принципы и действия для engineering managers и Staff-инженеров по архитектуре, разработке, эксплуатации и качеству. Подробные планы оставались у команд.
Ниже версия стратегии за 2025 год. В ней зафиксированы состояние организации на тот момент и намеченные действия. Планы по сервисам и AI описаны именно как планы, а не как результаты внедрения.
Отдельно описали целевую архитектуру и модель ответственности: как домены закрепляются за командами, где проходят границы платформы и как устроено взаимодействие внутри монолита и между сервисами. Эта модель помогала переводить общие принципы стратегии в конкретные архитектурные решения.
Текущее состояние
Что хотим сохранить и развивать
Доменная экспертиза
Продукт и разработка используют общий язык. Продуктовые решения реализуют команды, которые отвечают за свои домены и хорошо в них разбираются.
Нужно закрепить правила работы с этим языком: продукт и код должны описывать бизнес через одни и те же термины, сущности и границы. При выборе реализации предпочитаем соответствие бизнес-понятиям. Это относится к frontend, backend и другим частям системы. Удобные сокращения и абстракции, которые расходятся с моделью бизнеса, усложняют дальнейшую работу.
Модульный монолит как основа
Основное ядро сохраняем в виде модульного монолита. Он позволяет передавать домены между командами и поддерживать транзакционное взаимодействие там, где нужны гарантии ACID. При этом не все взаимодействие между доменами должно быть транзакционным: побочные эффекты могут обрабатываться асинхронно с eventual consistency.
Модульность требует явных доменных границ. Они должны позволять выделить часть системы в отдельный сервис, если появится необходимость: особые требования к производительности, изоляции разработки или языку реализации, например Python для ML.
Когда создавать или выделять сервис
Функциональность стоит реализовывать отдельным сервисом или извлекать из монолита, когда она представляет изолированный и самодостаточный домен.
Условия:
- Сервис работает самостоятельно через явно определенный однонаправленный API, без неявного знания об остальных частях системы.
- Ему не нужна транзакционная согласованность с основными бизнес-сценариями. Его безопасно выполнять асинхронно с eventual consistency.
- Он самостоятельно обслуживает свою нагрузку, не зависит от основной базы приложения и не создает нагрузку на нее.
- У него есть операционная автономия: независимые масштабирование, деплой, наблюдаемость и изоляция отказов.
Инженерные практики
Сохраняем сильную культуру CI/CD и непрерывного деплоя: быстрые и предсказуемые слияния, короткоживущие ветки и раннюю обратную связь на уровне PR. Код регулярно интегрируется и выпускается.
Цель: выпускать изменения без ручного регресса, опираясь на автоматические тесты и проверки качества. Ручное QA оставляем для исследовательского тестирования. Дисциплина code review и инженерные стандарты поддерживают качество и возможность развивать код.
Текущие проблемы
Архитектура и домены
Основные сквозные бизнес-домены и поддерживающие домены определены. Нужно провести эти границы через код, данные и интерфейсы, а зависимости между доменами свести к минимально необходимым синхронным и асинхронным интерфейсам.
Работа продолжается: границы пока применяются непоследовательно, общие слои все еще проникают в разные контексты.
Внедрение архитектурных подходов
Архитектурные стандарты и решения внедряются неравномерно. Подходы команд расходятся. Большая часть изменений идет через инициативы по техническому долгу, вместо того чтобы входить в обычные планы команд.
Рост объема задач
Договоренности о MVP не всегда сохраняются от discovery до delivery. Участники со стороны бизнеса и разработчики не поддерживают постоянное согласование объема, выполнение в согласованных границах не контролируется.
Особенно заметно это в крупных инициативах: функции выходят за первоначальный MVP, доставка замедляется, а полученная обратная связь становится менее полезной.
Масштабирование разработки
Основная разработка идет в монолите. У доменов не хватает определенных интерфейсов, поэтому их сложно выделять в сервисы.
Также не хватает инструментов для запуска сервисов: шаблонов, договоренностей, паттернов взаимодействия, транспорта и библиотек наблюдаемости. Масштабирование разработки ограничено и в основном зависит от найма Ruby-инженеров.
Принципы принятия решений
Не допускать взаимного блокирования продуктового и технического направлений
Инженерное руководство заранее готовит критичные задачи, чтобы техническое направление могло разработать необходимые решения. Критичные и блокирующие вопросы решаются внутри технического направления или непосредственно инженерным руководством.
Руководители регулярно синхронизируют приоритеты и общее направление работы. Если нужны согласованные действия продуктовых команд, им передаются подготовленные задачи: с ясным описанием, необходимыми инструментами и контекстом.
По умолчанию платформенную работу выполняет техническое направление. Небольшие улучшения, связанные с выпуском продукта, могут делать сами продуктовые команды при поддержке Staff-инженеров. В дальнейшем ответственность за них передается техническому направлению. Так уменьшаем блокирующие зависимости между продуктовой и технической работой.
Поддерживать самостоятельность продуктовых команд
Продуктовым командам нужны полномочия и экспертиза, чтобы отвечать за решения от начала до конца.
Команды должны уметь:
- Готовить MVP с участием DevOps, платформы, аналитики и других необходимых специалистов.
- Самостоятельно отвечать за технический дизайн ниже уровня high по принятой классификации и эскалировать решения, когда это требуется.
- Заранее обращаться к техническому направлению за помощью для критичных задач и предлагать варианты решений.
- Запускать изменения и оценивать продуктовые результаты и производительность с помощью наблюдаемости, продуктовых метрик и других данных.
По умолчанию команды работают максимально самостоятельно. Дополнительное согласование и эскалация нужны в исключительных случаях.
Согласованные действия
Ответственность за домены и взаимодействие с платформой
Платформенные Staff-инженеры работают с продуктовыми командами, чтобы архитектурные принципы применялись последовательно и соответствовали доменным границам. Продуктовые команды сохраняют полную ответственность за свои домены.
Соблюдение границ MVP
Основные ориентиры:
- Каждая инициатива сохраняет определение MVP от discovery до delivery, работа выполняется в согласованном объеме.
- Архитектурные подходы команд согласуются с платформой: общие паттерны применяются на ранних этапах, платформенный технический долг последовательно сокращается.
Backend
Доменные границы в модульном монолите
Разделяем домены внутри монолита через синхронные и асинхронные интерфейсы. Используем обычные средства языка и фреймворка, но проектируем интерфейсы так, чтобы их можно было вынести в самостоятельные сервисы без большого рефакторинга.
Монолит остается основным ядром. Явные доменные границы и контракты позволяют при необходимости преобразовать синхронные вызовы и асинхронные потоки в интерфейсы отдельных сервисов.
Подготовка сервисной архитектуры
Готовим инструменты, чтобы команды могли одинаково разрабатывать и эксплуатировать сервисы в production: контракты, стандарты транспорта, шаблоны сервисов и библиотеки наблюдаемости.
Поддержка Python
Инструменты должны поддерживать Python-сервисы с самого начала. Расширяем шаблоны, контракты, CI/CD и наблюдаемость. ML и другие домены с требованиями к языку могут стать первыми кандидатами на выделение.
Последовательность запуска сервисов
Фокус на год: пройти путь от первого сервиса в production до повторяемой и масштабируемой сервисной архитектуры.
Сначала запускаем реальный бизнес-сервис с полностью изолированным CI/CD. Закрепляем ответственность команды, независимый деплой и ответственность за эксплуатацию.
После проверки этого подхода в production постепенно развиваем инфраструктуру:
- Вводим масштабируемую шину событий для взаимодействия сервисов.
- Формализуем контракты сервисов и проверяем их соблюдение.
- Стандартизируем шаблоны.
- Определяем явные синхронные и асинхронные интерфейсы.
На раннем этапе монолит выполняет роль API Gateway: маршрутизирует запросы и отвечает за аутентификацию. Когда в production работают несколько сервисов, эти обязанности постепенно переносим в отдельный gateway.
По мере развития сервисной архитектуры планируем вводить sidecar и другие инфраструктурные компоненты для единообразного управления взаимодействием сервисов, наблюдаемостью и устойчивостью.
Frontend
Границы ответственности
Организуем код по областям ответственности с явными публичными интерфейсами. Убираем общие бизнес-компоненты, используемые напрямую разными областями. Повторное использование допускается через определенные интерфейсы.
Переход на дизайн-систему
UI-kit становится общей основой интерфейсов бизнес-функций. Заменяем устаревшие компоненты и убираем собственные реализации UI вне дизайн-системы.
Contract-first разработка
Генерируем статические типы из схем и приводим клиентский код в соответствие с контрактами backend. Если схема существует, перестаем писать DTO вручную.
Компонентные тесты
Соблюдаем принятую политику тестирования frontend, которая требует компонентных тестов. При необходимости отделяем код от сетевого слоя и глобальных зависимостей.
Внедрение AI
Давать возможности, не навязывать процесс
Помогаем разработчикам применять AI через полезные инструменты, которые входят в ежедневную работу. Не навязываем жесткий workflow.
Ревью с помощью AI и поиск flaky-тестов уже работают как POC благодаря команде SDET. Развиваем эти сценарии в переиспользуемые пайплайны.
Не задерживаем выделение бюджета, запускаем MCP там, где они нужны, и адаптируем процессы SDLC и инструменты для работы с AI.
Версии и пересмотр
Стратегия пересматривается поквартально вместе с циклом OKR компании. Каждая версия фиксирует общие приоритеты инженерного руководства. Документ согласуется Director of Engineering и платформенными Staff-инженерами с учетом общего направления, заданного CTO.
Если до следующего цикла происходят существенные организационные, архитектурные или регуляторные изменения, допускается промежуточное обновление.
Версия 2025-Q3
Связанные документы:
- OKR компании на 2025 год.
- Инженерное видение CTO.
- Отслеживание работы с техническим долгом, внедрения платформенных возможностей, обратной связи Staff-инженеров и качества технического дизайна.
- Общие инициативы по техническому долгу на третий и четвертый кварталы.
Версия 2025-Q4
Связанные документы:
- Подготовка к запуску сервисов.
- Разделение PR flow: быстрые коммиты и безопасные слияния.
- План первого этапа подготовки сервисной архитектуры и изменений PR flow на первый квартал 2026 года.
Следующий пересмотр, запланированный в этой версии документа: 2026-Q1.