Инженерные риски в продуктах с кастомными фреймворками

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

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

Где лежат реальные риски?

Bus-factor и зависимость от узких экспертов. Главный операционный риск — когда знание устройства фреймворка сосредоточено у 1–2 авторов. Их отпуск, уход или перераспределение задач превращают любую доработку в «раскопки» без документации. 

Российские команды на Habr не раз описывали кейсы, когда после ухода автора «самописца» было дешевле переписать систему на массовый стек, чем поддерживать уникальный код, — классический bus-factor = 1 → 0.

Найм и онбординг дорожают. С готовыми экосистемами (Spring, .NET, Django, React) нанять и адаптировать специалистов проще: документация, курсы, готовые библиотеки. Свой фреймворк требует месяцев, чтобы «въехать», а значит — рост time-to-productivity и бюджета. 

Комментарии на Habr подчёркивают: для нетривиальных хотелок в популярном фреймворке обычно уже есть модули/плагины, в «самописе» — придётся писать и поддерживать самим.

Отсутствие экосистемы и технический долг. Кастомный стек редко имеет «рынок» библиотек, готовых интеграций и best practices. Любая интеграция (S3-совместимое хранилище, очереди, observability, безопасная аутентификация) превращается в мини-R&D. 

Отсюда — лавинообразный технический долг и скорость релизов ниже, чем у команд на массовых платформах. Мы видим это в РФ особенно часто у внутреннего «корп-платформостроения» в банках/ритейле.

Безопасность и соответствие 152-ФЗ/ГОСТ/ФСТЭК. С «самописом» вы берёте на себя весь DevSecOps: SAST/DAST, dependency-scanning, патчи, процесс управления уязвимостями, аудит исполнения требований ИБ. В популярных фреймворках часть уязвимостей закрывает комьюнити и вендоры, у вас — только ваша команда. 

Подход «security-by-design + автоматизированные проверки» обязателен, иначе накопление уязвимостей в приватном коде неизбежно. Осмысленную критику слепой автоматизации (и важность процессов поверх инструментов) хорошо сформулировали российские практики: «любая автоматизация требует процессного подхода».

Вендор-локин — только теперь вы сами себе вендор. Мы привыкли говорить о lock-in к внешним вендорам, но lock-in к собственному фреймворку ничуть не мягче: исчезает возможность быстрой миграции и повторного использования кадрового рынка. 

Российские статьи и обзоры подчёркивают: привязка (lock-in) — это про барьер смены платформы и стоимость выхода, не важно, внешний это поставщик или внутренний.

Управленческие иллюзии экономии.  Аргумент «свой фреймворк бесплатен, лицензий нет» оборачивается CAPEX/OPEX на годы: постоянная доработка, QA, релизная инфраструктура, обучение. Гайдлайны Gartner про build vs buy vs blend прямо предупреждают: «строить всё самим» увеличивает сроки и риски; здравый баланс — смешанная модель.

Когда «самопис» оправдан

Разместите
тендер бесплатно

Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.

Заполнить заявку 13203 тендера
проведено за восемь лет работы нашего сайта.

Мы не против кастома как класса решений — мы против кастома «по умолчанию». Уместные сценарии:

• Дифференциация ядра бизнеса. Где скорость/уникальность критичны и готовых стеков нет (например, низкоуровневые оптимизации, специфические регуляторные процессы, проприетарные алгоритмы). Российская практика тоже показывает: иногда «велосипед» рождает прорыв — но это осознанное исключение, а не правило.
• Жёсткие требования к latency/footprint/изолированности. Встраиваемые решения, HFT-сценарии, критические промышленные контуры, где «тяжёлый» фреймворк невозможен.
• Регуляторные/суверенные ограничения. Импортозамещение, офлайн-контуры с повышенными требованиями ИБ, где стек должен быть полностью контролируемым и проверяемым.

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

Как снизить риски?

1) Архитектура и границы.

• Выберите ядро кастома (где создаётся ценность) и окружите его массовыми технологиями: БД, брокеры сообщений, observability-стек, API-шлюзы — всё на индустриальных решениях. Это снижает lock-in и облегчает найм.
• На входах/выходах фреймворка используйте открытые протоколы и спецификации (HTTP/REST/JSON:API/AsyncAPI, OpenTelemetry). Так вы сохраните совместимость.
• Регуляторные/суверенные ограничения. Импортозамещение, офлайн-контуры с повышенными требованиями ИБ, где стек должен быть полностью контролируемым и проверяемым.

2) Модель разработки и качества.

• Обязательные пайплайны CI/CD с SAST/DAST/Dependency-scan, unit/интеграционными тестами и политиками «невозврата уязвимостей».
• Введите дизайн-ревью (ADR/RFC) до реализации: зачем модуль, альтернативы, стоимость владения на 3 года, план удаления/замены.
• Заложите observability by default (логирование, метрики, трейсинг) своего фреймворка — без этого эксплуатация будет дорогой.

3) Документация и DX (developer experience).

• Полные Developer Guides + Reference + примеры.
• Шаблоны проектов (cookiecutter/yeoman), CLIs и «happy path» для типовых сервисов.
• KPI на DX: «время до первого успешного билда», «время внедрения типовой фичи».

4) Управление знанием и кадровые риски.

• Минимум две независимые команды умеют разворачивать и менять фреймворк.
• Обязательная ротация мейнтейнеров между продуктами.
• Внутренняя «мини-комьюнити-модель»: лид-мейнтейнеры, выпуск релиз-нотов, публичный бэклог, SLA на инциденты фреймворка.

5) Право на выход (exit-strategy).

• Договоритесь о порогах миграции: когда TCO и скорость разработки начинают проигрывать рынку — запускаем план отхода.
• Поддерживайте адаптеры к популярным фреймворкам (например, слой совместимости с Spring Boot/Express/FastAPI), чтобы не «цементировать» зависимость.
• Периодически проводите benchmark-сравнение с массовыми стеками: производительность, стоимость, найм.

6) Финансы и портфель.

• Считайте полный TCO: разработка, тесты, инфраструктура, безопасность, обучение, найм, документация, релизы. Сравнивайте с «blend-подходом» (ядро — кастом, остальное — готовые продукты). Ровно это советуют модели build/buy/blend.
• Поддерживайте адаптеры к популярным фреймворкам (например, слой совместимости с Spring Boot/Express/FastAPI), чтобы не «цементировать» зависимость.
• Периодически проводите benchmark-сравнение с массовыми стеками: производительность, стоимость, найм.

Российские примеры

• Осмысленный кастом. Российские продуктовые команды иногда приходят к «самописному слою», когда готовые инструменты не покрывают доменную специфику (напр., внутренние тест-фреймворки под узкие процессы) — и это может быть успешно при наличии процессов и дисциплины.
• Переоценка «уникальности». Противоположные кейсы на Habr: автор ушёл — проект завис; итогом становилась миграция на известные фреймворки. Это типовая для РФ история в корпоративном секторе и аутсорсе.
• Lock-in как управляемый риск. Российские материалы по vendor lock-in призывают рассматривать привязку прагматично: важны прозрачный TCO, SLA и план выхода — а не идеологический отказ. Мы совпадаем с этим подходом.

Немного с нашей колокольни

Кастомный фреймворк — это управляемый риск, а не инженерская «гордость». На рынке РФ он оправдан в ядре ценности (алгоритмы, уникальные процессы, регуляторные ограничения), при условии что всё вокруг — на стандартных рельсах. 

Если у вас нет чётких ответов по архитектуре, безопасности, DX, кадровому покрытию и exit-стратегии — вероятность, что кастом «съест» продукт, слишком высока. 

Используйте blend-стратегию: строим там, где зарабатываем конкурентное преимущество; покупаем/берём open-source там, где рынок уже всё сделал лучше и дешевле. Это экономит TCO, ускоряет релизы и делает вас устойчивее к кадровым и технологическим шокам.