Контекст: с чем пришёл бизнес

К нам обратилась глобальная фармацевтическая компания, работающая более чем в 50 странах. IT-ландшафт компании уже насчитывал сотни приложений, а стратегическая цель заключалась в масштабировании интеграций до ~2000 связей между системами.

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

Ключевые проблемы до старта проекта

• Отсутствие прозрачности интеграций и их владельцев
• Нестабильность и инциденты в смежных системах
• Сложность координации автономных федеральных команд
• Отсутствие единых стандартов и повторного использования решений

По сути, каждая команда решала задачи по-своему, а интеграции постепенно превращались в «чёрный ящик», где сложно было понять текущее состояние, риски и зависимости.

Федеральная модель: автономия + общая платформа

Организация работала по федеральной модели: бизнес-юниты и продуктовые команды были автономны и ориентированы на собственные домены — исследования, производство, разные ИТ-проекты.

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

Это позволило сохранить автономность команд, но при этом обеспечить единые стандарты, управляемость и масштабируемость.

Роль нашей команды

Мы выступали как лидер консалтинга и архитектурный партнёр. Ключевые архитектурные и процессные решения принимались совместно с владельцем продукта и группой архитекторов со стороны заказчика.

Наша роль заключалась не в «исполнении по ТЗ», а в:

• архитектурных рекомендациях и дизайн-решениях
• построении платформенного подхода
• внедрении лучших практик CI/CD, управления и прозрачности
• балансировке требований бизнеса и инженерной устойчивости

Команда и организация работ

Проект длился около 2,5 лет. Состав команды менялся, но в пике в проекте было 8–12 человек:

• DevOps-инженеры
• Архитектор решения
• Бизнес-аналитик
• QA-инженер
• Разработчики

Команды заказчика были разделены по критичности для бизнеса:

• Критичное для бизнеса/миссии (при недоступности 2-4 часа бизнес начинает терять деньги)
• Обычное (ожидается в активном состоянии, но простой до 12 часов погоды не делает)
• Не критичное (доступность приложения/интеграции никак не влияет на работы команд/бизнеса)

В зависимости от критичности определялись SLA, требования к Disaster Recovery и уровню отказоустойчивости.

Платформенный и технологический сетап

Платформа была развёрнута в fully-managed Kubernetes и CloudHub-режиме, с поддержкой альтернативного сетапа для legacy-сценариев.

CloudHub изначально рассматривался с осторожностью из-за вопросов security и compliance, однако после пересмотра критичности данных и рисков было принято решение использовать его для снижения DevOps-overhead и упрощения управления.

Стандартизация и управление

• Единые CI/CD пайплайны и шаблоны
• API governance
• Централизованный логинг и мониторинг (ELK → Argus)
• Изоляция команд и масштабируемый-подход

Мы также внедрили единый дашборд платформы, который показывал:

• Использование ресурсов и лицензий
• Статус и версии CI/CD пайплайнов в использовании, статистика запусков
• Приложения их версии и интеграции, задеплоенные на платформе, статусы, объем данных

Самое сложное: тестирование как бутылочное горлышко

Основным ограничением проекта стало тестирование. При активной разработке и регулярном выпуске фич один AQA-инженер физически не успевал покрывать всё тестами, а клиент не был готов расширять команду. 

Часть тестов автоматизировали, часть выполнялась вручную, а собственные сервисы покрывались unit-тестами, но именно тестирование стало bottleneck’ом всей системы.

Это важный урок, который мы честно фиксируем в кейсе.

Результаты проекта

• Снижение количества инцидентов примерно на 30%
• Онбординг новой команды сократился с ~2 недель до ~1 часа
• Повышение прозрачности и управляемости интеграций
• Рост повторного использования решений и стандартов

Бизнес и IT-руководство особенно отметили качество платформы, стабильность CI/CD и инженерный подход команды.

Ключевые уроки

• Платформа — это не продукт, а экосистема
• Стандарты важнее технологий
• Недооценка AQA\QA быстро становится системным риском
• Федеральная модель требует прозрачности, а не контроля

Что бы мы сделали иначе сегодня

Сейчас мы бы сразу предложили более простой и полностью managed-подход с акцентом на CloudHub и расширенную команду тестирования.

Это позволило бы сократить сложность сетапа, уменьшить поддержку и ещё быстрее масштабировать платформу.

Почему такие проекты невозможны без консалтинга

Подобные инициативы — это не просто внедрение платформы. Это изменение подхода к интеграциям, ответственности и работе команд.

Консалтинг здесь — это не про технологии, а про архитектурное мышление, зрелые практики и умение выстроить баланс между бизнесом и инженерией.

Нужна подобная трансформация?

Если вы планируете внедрение интеграционной платформы, работаете в федеральной модели или сталкиваетесь с ростом сложности интеграций — мы готовы помочь выстроить архитектуру, процессы и командную работу.