Контекст и исходная проблема
Мы модернизировали бэк-офис оператора, развивающего несколько брендов. Основные задачи — устранить ограничения разрозненной системы, упростить обновления и централизовать управление.
Задачи и ограничения
При работе над проектом мы учитывали следующие задачи и ограничения.
- Общий код не означает общие права доступа. Разделение данных и полномочий брендов должно сохраняться при запросах, фоновых задачах и выгрузках.
- При обновлении общей платформы меняется основа сразу нескольких продуктов. Поэтому совместимость и управляемый выпуск важнее скорости отдельной сборки.
- Конфигурация бренда должна иметь понятные границы. Если каждое исключение превращается в отдельную копию кода, стоимость развития снова растёт.
Архитектура и взаимодействие модулей
Общие сервисы платформы обслуживают несколько брендов с раздельными настройками и правами доступа. Процессы CI/CD и Kubernetes обеспечивают воспроизводимый выпуск и управление сервисами.
Раздельные настройки и контекст
Общее ядро платформы
CI/CD и Kubernetes
Контекст бренда сопровождает операции в общих сервисах. Обновления проходят единый процесс выпуска с проверками совместимости.
Работу мы начали с карты зависимостей: кто читает данные, кто их изменяет и какие операции выполняются между сервисами. Контекст бренда необходимо проверять на каждом доверенном входе. Kubernetes помогает управлять размещением и жизненным циклом сервисов, но сам по себе не обеспечивает изоляцию бизнес-данных или корректность прав сотрудников.
Работы и этапы внедрения
Мы объединили процессы сборки и развёртывания, выделили общие сервисы и настройки брендов. Обновления платформы проходят единый процесс выпуска с проверками совместимости.
Этапы работы над проектом
Работы разделены на последовательные этапы с проверкой ключевых сценариев.
Построить карту зависимостей
Зафиксировать сервисы, репозитории, владельцев и критичные операционные процессы.
Определить границы брендов
Описать настройки, данные и полномочия, которые должны оставаться изолированными.
Переносить функции управляемо
Выбирать последовательность по рискам и зависимостям; сохранять критерии совместимости и возврата.
Унифицировать выпуск
Собрать проверки, конфигурацию и развёртывание в воспроизводимый процесс для нескольких брендов.
Тестирование и подготовка к запуску
Проверки охватывают ключевые пользовательские и операционные сценарии проекта.
| Сценарий | Что проверяем |
|---|---|
| Изоляция брендов | Пользователь одного бренда не получает чужие данные через интерфейс, API или выгрузку. |
| Права сотрудников | Проверяются разрешения на просмотр, изменение и экспорт, включая привилегированные операции. |
| Совместимость релиза | Изменение общего модуля проходит проверки на конфигурациях нескольких брендов. |
| Восстановление сервиса | Проверяется сохранность состояния и понятность диагностики после перезапуска или отката версии. |
Для каждого сценария нужны исходные данные, ожидаемый результат и способ фиксации фактического поведения. Допустимую нагрузку, время восстановления и условия остановки запуска определяют вместе с оператором; универсальных значений для всех платформ здесь нет.
Результаты проекта
- Общий бэк-офис
- Команда управляет несколькими брендами через единые инструменты.
- Управляемые обновления
- Общие процессы сборки и развёртывания упрощают сопровождение платформы.
Итоги проекта
Единый бэк-офис связывает настройки брендов, права сотрудников и выпуск обновлений. Разделение данных сохраняется при работе общих сервисов и операционных инструментов.