Добрый день, меня зовут Владимир Павлунин, я архитектор технологической платформы в ИТ-команде «Северстали». В компаниях часто складывается такая ситуация, что каждая команда управляет проектом по-своему: пишут код, строят системы исходя из своего опыта. В итоге — куча похожих решений, которые никак не связаны друг с другом. Происходит увеличении энтропии, сложно понять, что где сделано, еще сложнее это связать между собой. То, что можно было сделать один раз и потом переиспользовать в других проектах, делается каждый раз с нуля во всех проектах, и по-разному.
Год назад наша компания столкнулась с проблемой, знакомой многим крупным организациям. Разные команды, работая над похожими сервисами, каждый раз решали одни и те же задачи: настраивали CI/CD, поднимали окружения, интегрировали мониторинг и управляли зависимостями. В результате мы получили дублирование усилий, фрагментированность подходов и значительное замедление стартовой фазы проектов.
Платформа, как и правила дорожного движения, нужна для создания единого стандарта, который обеспечивает порядок, безопасность и удобство взаимодействия всех участников. Без неё возникает хаос: каждый действует по своим правилам, что приводит к конфликтам, рискам и неэффективности. Например, когда на дорогах появились ГИБДД, водители стали соблюдать правила только в присутствии инспекторов, а при их отсутствии часто позволяли себе нарушения. С внедрением автоматизации, таких как камеры контроля скорости и светофоры с датчиками, соблюдение правил стало постоянным, так как система работает всегда и везде, а не только "при виде инспектора". Это показывает, что платформа упрощает взаимодействие, делает его предсказуемым и позволяет легко адаптироваться к новым условиям, сохраняя баланс между старыми и новыми участниками системы.
Цель одна — чтобы все работали в одном направлении, помогали друг другу, а бизнес получал нужные решения быстро и без лишней головной боли. И для этого нам нужна своя платформа.
Почему собственная платформа?
На рынке много готовых платформ, разработанных для управления бизнес-процессами, интеграций систем и развития IT. Все они состоят плюс минус из одних и тех же компонентов. Единственная сложность вместе с новыми инструментами нужно внедрять и новые процессы.
Чтобы такая система заработала, приходится перестраивать процессы под логику платформы, обновлять инфраструктуру и организовывать постоянную техническую поддержку. Это не мелкая доработка, а серьёзная трансформация которая требует времени, денег и внимания. В результате компания становится зависима от поставщика. Любые изменения исправления или доработки возможны только с его участием.
Ещё один важный минус — это нехватка гибкости системы из коробки. Большинство платформ завязаны на собственные компоненты, которые могут вообще не подойти для нетипичных решений. Попытки их адаптировать под нужные конкретной компании требования, часто приводят к дорогостоящим и трудоемким изменениям, что делает проект экономически невыгодным.
Поэтому перед выбором платформы важно оценить не только текущие потребности, но и долгосрочные цели компании. Иногда эффективнее развивать собственные решения и выбирать более гибкие архитектурные подходы. Но если вы готовы вкладывать и инвестировать в изменения ландшафта и не готовы растить команду у себя, то да — вариант, когда к вам придут специалисты и сделают платформу «под ключ», самый оптимальный.
Что было не так?
На текущий момент архитектура приложений в компании сталкивается с несколькими проблемами:
Дублирования решений: команды часто реализуют одни и те же функции самостоятельно, так как не знают о существовании готовых решений внутри компании.
Сложность интеграций: разнородные технологии, протоколы и отсутствие стандартизации приводят к длительным интеграционным проектам.
Низкая скорость разработки: разработчики вынуждены тратить время на типовые задачи (настройку окружений, CI/CD, мониторинг), которые могли бы быть автоматизированы.
Высокие затраты на поддержку: множество решений, каждое из которых требует индивидуального подхода и отдельной команды поддержки, увеличивает совокупную стоимость владения.
Архитектура предлагаемой платформы
При проектировании платформы мы выбрали модульную архитектуру, чтобы дать командам максимальную свободу в разработке, сохраняя целостность и согласованность всей системы. Такой подход позволяет нам быстро внедрять новые функции, интегрировать сервисы и адаптироваться под меняющиеся требования.
В основе платформы набор взаимосвязанных, но автономных компонентов, каждый из которых решает свою задачу и может развиваться независимо.
Расскажем подробнее о ключевых частях.
1. Архитектурный репозиторий
Для унификации подходов к проектированию и документированию архитектурных решений мы используем внутренний архитектурный репозиторий. Он служит центральным хранилищем паттернов, лучших практик, контрактов между сервисами и рекомендаций по их использованию. Это помогает избежать дублирования решений и упрощает коммуникацию между командами.
2. Бизнес-процессы и оркестрация (Camunda + BPMN)
Для моделирования и автоматизации бизнес-процессов используется движок Camunda. Мы описываем процессы в стандарте BPMN, что даёт наглядное представление о последовательности действий, условиях и ответственных сторонах. Это особенно удобно для сценариев, где требуется координация между несколькими микросервисами или внешними системами.
3. Интеграция данных (Kafka, Apache NiFi, Debezium, Spark, Airflow)
Обмен данными между компонентами реализован через гибкий и отказоустойчивый стек:
Apache Kafka — шина событий, обеспечивающая надёжную доставку и масштабируемость потоков данных;
Debezium — захват изменений в базах данных (CDC) для синхронизации состояния между системами;
Apache NiFi — управление потоками данных, преобразование и маршрутизация;
Spark — обработка больших объёмов данных в batch и streaming режиме;
Airflow — оркестрация ETL-процессов и регулярных задач.
Такой набор инструментов позволяет строить гибкие конвейеры данных, которые легко масштабируются и поддерживают высокую степень отказоустойчивости.
4. Управление доступом и SSO (Keycloak)
За управление идентичностью и доступом у нас отвечает Keycloak. Он обеспечивает:
Аутентификацию и авторизацию пользователей и сервисов.
Поддержку SSO (единого входа) для всех компонентов платформы.
Интеграцию с LDAP/AD.
Гибкие настройки управления ролями и политиками.
Это позволяет нам иметь единую точку контроля за доступом, не привязываясь к конкретным приложениям.
5. Управление API (APISIX)
Для работы с API мы используем Apache APISIX как API-шлюз. Он обеспечивает:
маршрутизацию запросов,
аутентификацию и ограничение трафика (rate limiting),
логирование и мониторинг,
динамическое управление правилами на лету.
APISIX работает как единая точка входа в нашу систему микросервисов, обеспечивая безопасность и устойчивость.
6. Политики безопасности и контроль доступа (OPA)
Для централизованного управления политиками безопасности и контролем доступа используется Open Policy Agent (OPA). С его помощью мы определяем правила доступа в декларативном виде и применяем их к различным уровням от API до UI.
Пример использования: проверка, имеет ли пользователь право выполнять определённое действие над конкретным ресурсом, с учётом ролей, контекста и других факторов.
7. Портал самообслуживания для разработчиков
Мы создали портал самообслуживания, который предоставляет разработчикам:
автоматизированные среды разработки и тестирования,
CI/CD-пайплайны «из коробки»,
единый интерфейс api-management,
единый интерфейс для запуска, мониторинга и отладки сервисов,
шаблоны проектов и готовые рекомендации.
Это снижает порог входа для новых команд и ускоряет старт новых проектов.
8. Единая дизайн-система
Чтобы интерфейсы разных сервисов выглядели согласованно и были интуитивно понятны, мы разработали собственную дизайн-систему. Она включает:
компоненты UI (на базе React),
гайдлайны по стилям, цветам, типографике,
примеры использования и документацию,
автоматическое изменения стилей с помощью токенов из Figma.
Дизайн-система экономит время фронтенда и улучшает пользовательский опыт. Ранее мы уже рассматривали дизайн-систему в наших публикациях https://habr.com/ru/companies/severstal/articles/881082/ и тут https://habr.com/ru/companies/severstal/articles/885790/ .
9. DevX-инструменты
Для повышения производительности разработчиков мы внедрили набор DevX-инструментов:
ИИ-помощники (например, для генерации кода, написания документации),
Mock-сервисы для тестирования API без зависимости от внешних систем,
CLI-утилиты и SDK для упрощения взаимодействия с платформой.
Портал самообслуживания
Портал самообслуживания помогает быстрее предоставлять услуги за счет автоматизации и управления инфраструктурой через код. Это часть стратегии платформы для упрощения и ускорения процессов
Одним из ключевых направлений развития внутренней платформы для разработчиков является внедрение концепции self-service infrastructure. Она предусматривает предоставление разработчикам доступа к ресурсам, CI/CD-процессам и окружениям в режиме самостоятельного управления. Эта задача реализована нами через создание портала самообслуживания, который выступает унифицированным интерфейсом взаимодействия между командами разработки и платформенной инфраструктурой.
Проблематика
С ростом числа сервисов и распределённости команд возрастает сложность управления жизненным циклом приложений. Традиционные подходы, основанные на ручных процессах или зависимости от SRE/DevOps для выполнения типовых операций, становятся барьером на пути к высокой скорости доставки (delivery velocity). Решением стало внедрение портала самообслуживания.
Основные компоненты портала
1. Шаблоны проектов (Project Templates)
Для ускорения стартовой фазы разработки мы внедрили шаблоны, соответствующие корпоративным стандартам. Они включают:
структуру проекта,
настроенную CI/CD-цепочку,
Базовые практики обеспечения качества и безопасности (например, pre-commit хуки, линтеры, сканеры уязвимостей),
Документацию и чеклисты по запуску.
2. Мониторинг и алертинг
Каждый новый сервис автоматически получает минимальный набор метрик, логов и трейсов, собираемых в едином хранилище (Prometheus, Graylog, Jagger). Через портал можно:
настроить дашборды,
задать правила алертинга.
Такая модель позволяет избежать ситуации, когда мониторинг добавляется «по факту», а не проектируется как часть архитектуры сервиса.
3. Управление окружениями (Environment Management)
Мы реализовали концепцию environment as a service , где каждое окружение представлено как отдельная сущность, управляемая через UI/API. Возможности включают:
перенос сервисов между окружениями,
версионирование конфигураций,
обратную связь по состоянию среды (health check, drift detection).
Это обеспечивает воспроизводимость и предсказуемость поведения сервисов на разных этапах жизненного цикла.
Архитектурные принципы
При проектировании портала были учтены следующие принципы:
инфраструктура как код (IaC) — все действия над ресурсами должны быть воспроизводимыми и проверяемыми;
единая точка входа — портал служит единственным интерфейсом для создания и управления ресурсами;
автономность разработчика — команда может выполнять большинство операций без прямого обращения к платформенной группе;
безопасность по умолчанию — политики доступа, проверка на соответствие стандартам (compliance), ограничения ресурсов;
интеграция с платформой — портал тесно связан с системами мониторинга, CI/CD, реестром образов и другими компонентами платформы.
Управление доступом и безопасность API: когда контроль становится прозрачным
Одна из самых непростых задач при построении внутренней платформы — это обеспечение баланса между открытостью и безопасностью. Нужно дать разработчикам свободу действий, но при этом сохранить контроль над тем, кто, что и как может использовать. Именно поэтому управление доступом и защита API стали для нас критически важными компонентами платформы.
Единая система авторизации: Keycloak как центр управления идентичностью
Что даёт Keycloak:
единый вход (SSO) для всех пользователей,
поддержку различных провайдеров аутентификации (LDAP, OAuth2, SAML),
гибкое управление ролями и политиками доступа через RBAC,
возможность делегирования прав другим системам (например, через OIDC токены).
Теперь любой пользователь, обращающийся к порталу или API платформы, проходит централизованную проверку, а все права строго соответствуют его роли в организации. Это позволило нам значительно снизить риски несанкционированного доступа и упростить аудит.
Защита и маршрутизация API: APISIX как шлюз и менеджер взаимодействия
Портал самообслуживания — это не просто UI. Он также предоставляет мощное API, через которое интегрируются CI/CD, автоматизированные процессы и сторонние сервисы. Но API без контроля — это потенциальная дыра в безопасности и риск непредсказуемого поведения системы.
Для решения этой задачи мы выбрали APISIX — гибкий и производительный API-шлюз с открытым исходным кодом.
Основные возможности, которые он нам дал:
централизованную маршрутизацию API-вызовов,
лимитирование нагрузки (rate limiting),
аутентификацию через ключи, JWT, OIDC.
мониторинг и логирование всех вызовов,
поддержку Webhooks и обратной связи.
APISIX стал не только технической прослойкой, но и частью UX-стратегии: через него мы можем давать разным командам разный уровень доступа к функционалу портала, сохраняя при этом единую точку управления.
Политики как код: OPA как инструмент принятия решений
Но даже с Keycloak и APISIX оставалась одна проблема: политики доступа часто были жёстко завязаны на конкретные реализации, и их сложно было адаптировать под меняющиеся бизнес-требования.
Решением стало внедрение Open Policy Agent (OPA) — движка политик, который позволяет описывать правила доступа декларативно, вне зависимости от сервиса, где они применяются.
Как это работает:
Система формирует запрос к OPA с контекстом: кто пытается сделать, к чему обращается, в какой среде.
OPA анализирует политики (написанные на Rego) и возвращает ответ: разрешено или запрещено.
Результат используется APISIX или другими компонентами для принятия решения.
Это позволило нам централизовать логику принятия решений, быстро обновлять политики без изменения кода сервисов и применять одинаковые правила по всей платформе — от портала до Kubernetes.
Контроль изменений: уведомления и согласование через УИБ
Однако одного технического контроля недостаточно. Мы столкнулись с ситуацией, когда изменения в политике доступа или попытки расширения прав могли быть выполнены без явного одобрения ответственных лиц — например, владельцев сервиса или представителей информационной безопасности.
Чтобы избежать таких ситуаций, мы внедрили механизм уведомлений и согласования через подразделения информационной безопасности. Теперь любое изменение, связанное с доступом:
попадает в очередь изменений,
формирует событие, отправляемое в систему управления изменениями,
триггерит уведомление в чат или email ответственным лицам,
при необходимости блокируется до получения явного одобрения.
Такая модель даёт нам:
прозрачность изменений,
чёткое разделение ролей и зон ответственности,
возможность быстрой реакции на потенциально опасные действия.
Кроме того, если действие всё же было выполнено без одобрения, система может автоматически заблокировать изменение и откатить его — так мы минимизируем риск человеческой ошибки или злоупотребления полномочиями.
Портал как API-менеджер: всё в одном месте
Сегодня портал самообслуживания выполняет роль не только UI-интерфейса, но и полноценного API-менеджера. Через него разработчики могут:
запрашивать доступ к определённым функциям,
получать токены и ключи,
настраивать политики доступа для своих сервисов,
видеть статистику использования API.
Такой подход позволил нам создать не просто удобный интерфейс, а универсальную точку управления доступом и API , которая масштабируется вместе с платформой и остаётся простой в использовании.
Большая платформа и маленькая команда: что нужно учесть
Работа небольшой командой над крупной платформой неизбежно ставит нас перед вызовами:
Быстрая обратная связь важнее идеальности: мы постоянно адаптируем архитектуру и процессы на основе реального опыта команд.
Баланс между кастомизацией и стандартизацией: слишком много кастомизации усложняет поддержку, слишком мало — снижает удобство использования.
Важность вовлечения пользователей: только тесное взаимодействие с конечными пользователями гарантирует, что платформа будет полезной и востребованной.
Готовность быстро исправлять ошибки: важнее быстро реагировать на обратную связь и ошибки, чем пытаться предусмотреть все сценарии заранее.
В сухом остатке
Создание собственной технологической платформы — это не простое решение, но оно стратегически оправдано. Такая платформа позволяет избежать зависимости от внешних поставщиков, быстро адаптироваться под новые требования бизнеса и минимизировать затраты на поддержку.
Мы продолжаем развивать платформу, дополнять её новыми инструментами и активно вовлекать пользователей в её улучшение. Надеемся, наш опыт поможет коллегам, стоящим перед аналогичным выбором.
А какие инструменты и решения использует ваша компания?