Окружения
Назначение Dev, Stage и Prod и правила продвижения изменений.
Окружения
Платформа использует три основных окружения. Они разделены по назначению, инфраструктуре, endpoints, конфигурации и уровню контроля изменений.
| Окружение | Назначение | Размещение | Каноническая DNS-зона |
|---|---|---|---|
| Dev | Разработка и ранняя интеграционная проверка | AWS | dev.esb.mtb.ua |
| Stage | Приёмочные и интеграционные проверки bank-side | Bank on-premise | stage.esb.mtb.ua |
| Prod | Рабочий банковский контур | Bank on-premise | prod.esb.mtb.ua |
Каноническая модель DNS
Публичные API используют шаблон api.<env>.esb.mtb.ua. Внутренние и административные сервисы размещаются в отдельных DNS-зонах и не должны смешиваться с consumer-facing endpoints.
Dev
Dev предназначен для разработки платформенных компонентов, API, flows и адаптеров. В проектной архитектуре допускается размещение внутри существующего AWS Kubernetes-кластера с изоляцией через отдельные node group и namespace.
В Dev разрешена более высокая скорость изменений, но остаются обязательными:
- версионирование артефактов;
- отсутствие production secrets и production data;
- базовые health checks и observability;
- воспроизводимое развёртывание через pipeline.
Stage
Stage проверяет не только функциональность API, но и банковский путь поставки, конфигурацию, сетевые доступы, secrets, сертификаты и эксплуатационные процедуры.
Переход в Stage требует:
- готового артефакта из контролируемого репозитория;
- согласованной environment configuration;
- работающего pipeline через MTB GitLab;
- end-to-end проверки прямого или оркестрируемого потока;
- проверенных логов, метрик, трассировки и rollback procedure.
Prod
Prod обслуживает рабочие интеграции. Изменения допускаются только после прохождения release gate и подтверждения операционной готовности.
Перед выпуском должны быть определены:
- владелец релиза и согласующие стороны;
- версия API и совместимость контракта;
- точный набор конфигурационных изменений;
- критерии успешности и наблюдаемые сигналы;
- rollback или recovery plan;
- support ownership и escalation path.
Продвижение артефактов
Банковская поставка в Stage и Prod выполняется через MTB GitLab и bank-side runners. Прямая ручная поставка из внешнего контура не является штатным delivery path.
Что различается между окружениями
- DNS names и ingress endpoints;
- credentials, keys, certificates и secrets;
- Kafka topics и подключения;
- URLs и учётные данные целевых систем;
- WSO2 applications, subscriptions и policies;
- Kestra configuration и flow variables;
- объёмы ресурсов, retention и monitoring thresholds.
Не копируйте конфигурацию вслепую
Между окружениями продвигается версия артефакта, а environment-specific значения подставляются контролируемо. Production credentials, endpoints и сертификаты не должны попадать в Dev-конфигурацию или репозиторий.
Readiness gates
| Gate | Результат |
|---|---|
| Architecture baseline | Согласованы целевая схема, роли, стандарты и открытые вопросы |
| Dev ready | Компоненты развёрнуты, pipeline и базовая наблюдаемость работают |
| Stage ready | Проверены bank-side delivery и reference end-to-end flows |
| Production ready | Подтверждены ресурсы, release, rollback, runbooks и handover |
Готовность окружения должна подтверждаться чек-листом и фактическими проверками. Наличие запланированного gate в roadmap само по себе не означает, что gate пройден.