Миграция с Oracle WebLogic за 30 дней: как банк из топ-3 перестроил управление Java-инфраструктурой

Работа в условиях фрагментированного мира

Программный комитет ещё не принял решения по этому докладу

Целевая аудитория

Ядро аудитории — технические лидеры и архитекторы Java-платформ: Solution / Enterprise Architects Lead-разработчики и Technical Team Leads Инженеры платформенных команд (Platform Engineers) Ключевой профиль слушателя — работает в компании с гетерогенной Java-инфраструктурой (100+ серверов, одновременно Tomcat и WildFly), отвечает за унификацию деплоя, конфигурации и мониторинга, ищет архитектурные паттерны для абстракции инфраструктурных деталей без переписывания приложений. Также будет полезно: DevOps/SRE-инженерам — как построить асинхронный конвейер операций с очередями и пулом исполнителей, интегрировать с K8s и CMDB. Инженерам по эксплуатации — как централизовать безопасность (JWT/RBAC) и отказаться от прямого доступа к каждому серверу приложений.

Тезисы

Почему сервер приложений нельзя заменить «один к одному». Сервер приложений — базовый компонент трёхуровневой архитектуры: сбой одного экземпляра влияет сразу на несколько систем. Формального запуска приложений на новой платформе недостаточно: администраторам нужны управление инстансами, контроль состояния JVM, сбор метрик, анализ журналов, работа с конфигурациями и сценарии восстановления. Поэтому миграция быстро превращается в проект по перестройке всей модели управления прикладной средой. Исходная точка. Прикладные Java-системы банка работали на Oracle WebLogic. Каждый домен администрировался отдельно — собственная консоль на каждый экземпляр, десятки разрозненных точек администрирования со своими регламентами и ручными операциями. Двухэтапная стратегия миграции. Этап 1 — функциональная замена: перенос настроек и метрик управления, сохранение привычных сценариев эксплуатации через единую панель. Миграция промышленного контура уложилась в 30 дней — сегодня это стандартный срок типового проекта перехода. Этап 2 — развитие под требования эксплуатации: проект импортозамещения перешёл в режим совместного развития продукта. Что дорабатывали под реальную эксплуатацию: профилирование и мониторинг состояния приложений, дашборды с метриками JVM, управление потоками и анализ блокировок, снятие дампов потоков (Thread Dump), принудительная сборка мусора (Run GC / Run Full GC), приоритеты запуска приложений. Цифры эффекта. Типовая диагностика инцидента раньше начиналась с подключения к конкретному серверу, ручного сбора дампов и сверки конфигураций — около часа; сейчас диагностические данные собираются из единой панели за несколько минут. Типовые операции (перезапуск приложения, снятие дампа, проверка конфигурации) — в два-три клика вместо последовательности консольных команд на каждом узле. Одна точка входа вместо отдельных консолей каждого домена; упростилась ротация дежурных инженеров. Масштабирование результата. Разовая миграция превратилась в повторяемую модель: платформа применяется более чем в шести проектах, включая внедрения в двух банках из топ-10. Практическая методика — применима к любой миграции между серверами приложений: проверяйте совместимость до миграции: версия Java, библиотеки, JDBC-драйверы, источники данных, внешние интеграции; особое внимание — настройкам, зависящим от прежнего сервера; переносите не только приложение, но и его настройки: параметры JVM, пулы соединений, тайм-ауты, сертификаты, логирование; зафиксируйте базовую линию: CPU, память, время ответа, число потоков, частота ошибок — иначе после переноса каждое отклонение выглядит одинаково пугающе; настройте последовательность запуска: сначала инфраструктурные сервисы и источники данных, затем прикладные модули — иначе каскадные ошибки после перезапуска; собирайте диагностические данные до перезапуска: перезапуск лечит симптом, но уничтожает информацию о причине сбоя; контролируйте конфигурационный дрейф: если проблема проявляется только на одном экземпляре — сравнение конфигураций должно быть одним из первых шагов.

Всеволод Котик

Диасофт

Бизнес-аналитик продуктовых решений для финансового сектора

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

Затем я ушёл вглубь — в разработку и тестирование сложных бэкенд-систем. Став Lead QA, я отвечал за качество микросервисной архитектуры в финтехе и госсекторе. Я научился выстраивать процессы, видеть риски на этапе проектирования и понимать, как технические решения влияют на бизнес-показатели: отказоустойчивость, скорость транзакций, время вывода продукта на рынок.

Сегодня я совмещаю эту экспертизу в роли бизнес-аналитика продукта в Диасофт. Моя задача — не просто фиксировать требования, а проектировать решения, которые будут устойчивы к нагрузкам, безопасны и экономически оправданы.

Один из ключевых проектов — миграция с Oracle WebLogic на платформу Digital Q.AppServer для банка из топ-3 (подробности в статье). На этом проекте я видел всю цепочку: от бизнес-потребности заказчика до архитектурного решения и его реализации. Мы сократили время диагностики инцидентов с часа до минут, а главное — создали продукт, который стал повторяемой моделью для управления критической инфраструктурой ещё в пяти проектах.

Моя суперсила — говорить на одном языке с бизнесом, разработкой и эксплуатацией. Я знаю, как устроен продукт от кода до кошелька пользователя, и умею превращать сложные технические задачи в понятные бизнес-решения.