На конференции
DevOpsConf 2025 прошёл
круглый стол, посвящённый подходу Platform Engineering, развитию внутренних инженерных платформ и их влиянию на производственные процессы в крупных технологических компаниях.
Участники дискуссии:
- Александр Коротков, Т-Банк — ведущий круглого стола;
- Татьяна Зуева, Банк Точка;
- Артём Науменко, ex-Head of Infra в Skyeng, CTO HyperUnison;
- Дмитрий Гаевский, продуктовый лидер платформы Spirit, Т-Банк;
- Александр Лукьянченко, руководитель разработки платформы в Авито.
Список вопросов, обсуждавшихся на круглом столе:
- Что в каждой компании является платформой и как она устроена?
- Кто является пользователем платформы и кто заказчиком?
- Как компании привлекают команды к платформе и обеспечивают распространение практик?
- Как работать с командами и критичными сервисами, которые не хотят переходить на платформу?
- Как распределяются затраты на платформу и кто отвечает за стоимость?
- Как внедрять обязательные технические и регуляторные решения, которые воспринимаются негативно?
- Как избежать роли контролирующего органа и не нарушить инженерную культуру?
- Кому внутри компании продают платформу и какое ценностное предложение формируют?
- Какая аудитория продуктовых команд является основной для платформы?
- Насколько платформы должны быть открыты и кто может в них контрибьютить?
- Кто опасается, что платформа сократит их функции, и как с этим работать?
Основные выводы по каждому вопросу:
1. Что является платформой и как она устроена:
- В Точке платформа — внутреннее облако и интерфейс для команд;
- В Авито — единый продукт, закрывающий весь SDLC и абстрагирующий инженеров от инфраструктуры;
- В Skyeng — автоматизация окружений, деплоя, логирования, мониторинга;
- В Т-Банке — объединение IDP и внутреннего облака.
2. Пользователи и заказчики:
- Пользователи — разработчики, QA, аналитики, продакты, дизайнеры;
- Заказчик — бизнес подразделения, финансирующее платформу;
- Бенефициар — бизнес, которому важны скорость, стабильность и снижение технологических рисков.
3. Привлечение команд к платформе:
- Применяются два подхода: эволюционный и директивный;
- Т-Банк: за 4 месяца переведено 2500 разработчиков и 15 000 репозиториев;
- Авито: постепенное внедрение — около 1 года на устранение узких мест, затем хвост, где 15-20% сервисов доводились точечно;
- Skyeng: поощрение перехода через ценность и улучшение новых пайплайнов.
4. Работа с командами, которые не хотят переходить:
- Наличие критичных легаси систем требует гибких решений;
- В Skyeng одна команда оставалась в AWS 2 года, пока экономический аргумент (расходы в 10 раз выше) не стал решающим;
- Точка допускает автономные решения для нестандартных стеков, не пытаясь построить универсальное решение;
- Авито акцентирует важность полного перевода ключевых доменов для достижения эффекта платформы.
5. Стоимость и управление затратами:
- В Точке действует модель внутреннего билинга: стоимость распределяется по сервисам пропорционально потреблению, суммы достигают сотен тысяч рублей в месяц;
- В остальных компаниях стоимость платформы отображается в P&L, что мотивирует оптимизацию;
- Платформа должна предоставлять инструменты управления стоимостью (выбор уровней сервиса, отказоустойчивости и режимов работы).
6. Внедрение обязательных технических решений:
- Наиболее сложные элементы: безопасность, лицензии, регуляторные проверки, контрактные системы.
- В Авито внедрение контрактной системы требовало 100% покрытия, иначе она не выполняла свою роль;
- Эффективный подход: пилоты, поэтапная раскатка, поддержка команд, автоматизация, скрывающая сложность.
7. Как избежать роли контролирующего органа:
- Платформа не должна забирать инженерную инициативу, а должна снижать операционную нагрузку;
- Истинный контролирующий орган — регулятор и команда безопасности, а не платформа;
- Платформа должна обеспечивать продуктивность, несмотря на обязательные требования.
8. Кому продают платформу и какое предложение формируется:
- Основная продажа идет разработчикам через упрощение работы и устранение рутины;
- Бизнес получает устойчивость, скорость поставки и прозрачность расходов;
- Ошибочно позиционировать платформу как замену команд разработки или специалистов по инфраструктуре.
9. Целевая аудитория внутри продуктовых команд:
- Разработчики — ядро аудитории;
- QA получают пользу через упрощённое создание окружений и запуск тестов;
- Аналитики и продукты используют сервисы, например: автоматические окружения, временные стенды, доступ к данным.
10. Открытость платформы и вклад команд:
- Все компании поддерживают разный уровень открытости;
- В Т-Банке половина сервисов создаётся не платформенной командой, а смежными подразделениями.
- В Skyeng значимая часть библиотек создавалась сообществом разработчиков.
11. Опасения относительно потери функций:
- Опасения возникают у команд, выполняющих ранее инфраструктурные или ручные задачи;
- Платформа перераспределяет инженерную нагрузку: рутинные задачи переходят внутрь платформы, а продуктовые команды получают пространство для архитектурной работы;
- Правильная коммуникация и прозрачность ролей снимают напряжение.
Подробнее в записи обсуждения на круглом столе по Platform Engineering: