«Быстрее для пользователей, удобнее для разработчиков». Как инженеры Halyk могут влиять на развитие супераппа
Несколько лет назад Halyk SuperApp уже обслуживал миллионы пользователей и работал под высокой ежедневной нагрузкой. По мере роста продукта стало ясно, что для дальнейшего масштабирования и сохранения стабильности нужны точечные инженерные решения в разных частях системы.
Инженеры Halyk начали усиливать свои направления. Эксперт по WebView Ильяс Сагимбеков повышал стабильность клиентского опыта и снижал риски при обновлениях. Айдос Бактаев отвечал за бэкенд поиска, оптимизируя его работу под рост трафика. Юрий Верьясов развивал DevOps-подходы и инфраструктуру. Все решения внедрялись на живом трафике, потому что стабильность напрямую влияет на опыт миллионов пользователей.
Digital Business выяснил у экспертов, как удалось масштабировать Halyk SuperApp без отключения сервиса, без армии разработчиков и без ночных авралов.
Рост нагрузки – вызов для архитектуры
Юрий Верьясов перешел в Halyk SuperApp из команды Onlinebank. Его привлекла задача на стыке технологий и менеджмента: на позиции начальника управления департамента Halyk SuperApp нужно было влиять не только на архитектуру супераппа, но и на организацию процессов разработки, чтобы продукт мог развиваться дальше.
Ильяс Сагимбеков пришел в Halyk 3 года назад как frontend developer. «Работал над проектом “Инвестиции”, где использовалась WebView-архитектура на Angular. Это позволяло быстро запускать новые продукты и параллельно глубоко заниматься производительностью и оптимизацией», — рассказал Ильяс.
Ильяс Сагимбеков
Айдос Бактаев присоединился к команде Halyk SuperApp в 2019 году сразу после университета, быстро адаптировался к работе с высоконагруженной системой и начал предлагать инженерные улучшения. «В Halyk ценят специалистов, которые берут на себя сложные задачи и думают о развитии системы, а не только о поддержке текущего функционала», — поделился Айдос.
«Практически сразу после перехода в SuperApp понял, что система перестает справляться с растущей нагрузкой. Это было видно благодаря мониторингу. Анализ архитектуры, метрик и поведения сервисов показал узкие места, которые могли стать критичными при росте трафика», — рассказал Юрий.
Специалисты отметили, что работали не обособленно, а с опорой на коллег в отделах аналитики, разработки и тестирования. С командой провели ревизию распределения ресурсов и SLA (договор между поставщиком услуг и клиентом, который определяет гарантированный уровень качества услуг – прим. Digital Business), оценили устойчивость системы к сбоям и начали формировать платформу микросервисов.
Первые улучшения поэтапно внедряли с ноября 2024 года. В числе прочего пересмотрели процессы доставки кода и внедрения изменений. «Стек был современный, но подходы к управлению платформой оказались недостаточно гибкими – масштабировать без риска для пользователей не получалось», — подчеркнул Юрий.
По мере развития супераппа нагрузка возрастала сразу в нескольких ключевых зонах. «В первую очередь это авторизация, переводы, платежи, кредитные операции и другие сервисы, — пояснил Айдос. — Вместо простого масштабирования мощностей мы сосредоточились на архитектурных изменениях, которые позволили системе работать стабильно и предсказуемо при росте трафика».
Два направления изменений
Команда решила, что в приоритете – обеспечить стабильность под нагрузкой.
«Начали с выявления узких мест: где сервисы упираются в CPU (центральный процессор), где запросы зависают в сетевых очередях, а хранилища не успевают обрабатывать пики. Параллельно выстроили систему метрик и алертов, чтобы видеть реальную картину нагрузки, а не работать интуитивно», — объяснил Айдос.
Айдос Бактаев
Дальше развивали систему одновременно в двух направлениях.
Первое – горизонтальное масштабирование: добавление новых серверов вместо усиления существующих. Для сервисов, архитектура которых это позволяла, увеличили количество реплик (одинаковых участков, работающих параллельно – прим. Digital Business) и оптимизировали распределение трафика.
Второе – архитектурная оптимизация. Там, где репликация не решала проблему, пересмотрели внутреннюю логику. Избавились от синхронных вызовов между сервисами, ввели очереди и брокеры сообщений, тяжелые операции вынесли в асинхронные пайплайны, разделили операционное ядро на продукты и усилили отказоустойчивость.
От реактивного подхода – к проактивному
Главной сложностью стала синхронизация изменений на разных уровнях системы: фронтенд, WebView, мобильное приложение, API, кеширование. Небольшая правка в одном модуле могла неожиданно затронуть соседние части SuperApp.
«Поэтому огромное внимание уделяли обратной совместимости и плавности обновлений, — рассказал Ильяс. — Дополнительная сложность – работа на живом трафике: миллионы пользователей, постоянные операции, в таких условиях нельзя допустить остановки».
По словам Ильяса, продукт состоит более чем из 800 микросервисов с разной динамикой нагрузки, зависимостью и критичностью. Каждый нужно было проверить, протестировать, адаптировать под новые стандарты. Специалисты столкнулись сразу с несколькими челленджами:
- Устранить скрытые точки связности, когда один перегруженный сервис тянул за собой целую цепочку зависимостей.
- Разделить критичные контуры, чтобы платежи, переводы, кредиты, ипотека, карточные продукты не конкурировали за одни и те же ресурсы.
- Перейти от реактивного подхода к проактивному: не тушить проблемы в моменте, а предотвращать их через архитектурные решения, метрики, алерты и отказоустойчивые паттерны.
- Синхронизировать изменения между командами, чтобы каждое обновление не нарушало работу других сервисов, – это требовало дисциплины, общих стандартов и зрелой инженерной культуры.
Команда стремилась потратить меньше времени.
За большим объемом технической работы стояла и внутренняя мотивация команды – она помогала выдерживать темп.
«Работали над системой, которая ежедневно обслуживает миллионы пользователей, дает мощный инженерный драйв и заставляет расти профессионально. От стабильности сервисов зависят платежи, переводы, кредитные процессы – любое улучшение напрямую влияет на комфорт и безопасность клиентов.
Отдельную роль играл фидбек пользователей. Когда после оптимизаций система начинает работать быстрее и стабильнее, это ощущается как реальный результат работы команды», — поделился Айдос.
Рецепт масштабирования без даунтайма
Конкретные изменения затронули всю разработку. Защищенную систему на фронтенде строили слой за слоем.
«Модульная архитектура SuperApp позволяла обновлять отдельные части приложения независимо друг от друга. Технология отложенной загрузки lazy-loading подгружала код только когда он нужен пользователю, а не весь сразу – это ускоряло запуск приложения. Оптимизация сборок фреймворка Angular сжимала код до минимума. Контейнер для встраивания веб-контента WebView давал возможность обновлять модули без полной перезагрузки приложения – пользователь мог продолжать работать. CDN (cеть доставки контента – прим. Digital Business) и кеширование ускоряли загрузку статических файлов», — рассказал Ильяс.
Но главное – как внедряли изменения. Сначала тестировали на ограниченной группе внутренних пользователей по программе Friends & Family – сотрудники банка проверяли обновления первыми. Потом запустили так называемое канареечное развертывание. Новую версию получала небольшая часть реальных пользователей, команда следила за метриками, и только если все работало стабильно, обновление раскатывали на всех.
«Смогли внедрять изменения постепенно, наблюдать за поведением системы и при необходимости откатывать без влияния на пользователей, — объяснил Ильяс. — Для банковского приложения отсутствие даунтайма – критичный фактор доверия».
Айдос рассказал, что на бэкенде тоже применяли стратегии развертывания без остановки – Zero-downtime деплойменты. Помимо канареечного, использовали метод Blue/Green: запускали новую версию сервиса параллельно со старой, проверяли, что все работает, и только потом переключали трафик.
Асинхронная архитектура и брокеры сообщений помогали переживать пиковые нагрузки: вместо того, чтобы обрабатывать тысячи запросов одновременно и падать, сервисы ставили задачи в очередь и разбирали их по мере возможности.
Инженеры внедрили паттерны отказоустойчивости, чтобы защитить систему от цепной реакции сбоев. Например, технология Circuit Breaker работает как автоматический выключатель – останавливает запросы к упавшему сервису, чтобы не перегружать его еще больше. Таймауты не дают запросам зависать бесконечно. Rate Limiter (ограничитель скорости) контролирует, сколько запросов может прийти за единицу времени. Так удалось избежать аномальных всплесков трафика.
AI встроили глубоко в инженерные процессы. «Теперь он анализирует каждый запрос на слияние кода (Merge Request): ищет аномалии в изменениях, выявляет потенциальные риски, дает подсказки по оптимизации. Генерирует технические описания изменений и другую документацию. Анализирует стиль кода и находит сложные участки, которые могут стать проблемой. А контрольные точки качества Quality Gateways автоматически оценивают качество каждого сервиса перед выкаткой в продакшн», — рассказал Юрий.
Все команды разработки осваивали эти технологии не отходя от «станка», то есть процесса написания кода. Однако обошлось почти без авралов. По словам Юрия, нововведения наоборот дали возможность выполнять критические изменения в рабочее время и снизить нагрузку на команды.
Доступность составила 99%, а экосистема растет
Трансформация длится уже год, и основные изменения внедрены. «Наша небольшая команда справилась с задачей, которая обычно требует гораздо больше людей, — говорит Ильяс. — С технической стороны – сделали систему более предсказуемой и устойчивой под большой нагрузкой. С личной – чувствую, что вырос в умении принимать решения быстро, сохраняя осторожность и инженерную дисциплину».
По словам инженеров, им удалось масштабировать систему без снижения качества сервиса. Команда нашла и устранила архитектурные узкие места, настроила процессы взаимодействия и обеспечила стабильную работу основных направлений – платежей, переводов, кредитов, депозитов, ипотеки и карточных продуктов – при росте нагрузки. Параллельно расширялся набор продуктов и интеграций.
«Кейс показал, что даже сложные и высоконагруженные решения можно развивать последовательно и системно, сохраняя надежность и предсказуемость работы продукта», — резюмировал Айдос.
Изменения отразились на пользовательском опыте. Отказоустойчивость системы выросла, а реагирование на инциденты стало быстрее – по данным управления департамента Halyk SuperApp, в большинстве критичных случаев удается обеспечить доступность выше 99%.
Глава HR Halyk: «Культура усиливает технологии»
В ходе трансформации отдельное внимание уделяли командной культуре. «Заряжал интерес к изменениям и возможность наблюдать их эффект на всей платформе, — поделился Юрий. — Редко где инженерные решения так быстро и масштабно отражаются на продукте».
Команда поддерживает внутреннее сообщество, проводит митапы, обсуждает улучшения и развивает кодовую базу. «Разрабатываем инхаус-решения и библиотеки, адаптированные под наши задачи. Используем юнит-тесты для проверки критичных частей кода и проактивно улучшаем качество продукта», — рассказал Айдос.
«Наша культура – про инженерную ответственность, адаптивность и готовность менять процессы, работу в условиях высокой нагрузки, стремление внедрять лучшие практики и AI-решения», — резюмировал Юрий.
HRD Halyk Индира Аширова прокомментировала рассказ коллег:
Индира Аширова
«История команды Halyk SuperApp – это сильный пример того, как инженерная культура, зрелые процессы и внутренняя мотивация людей напрямую влияют на устойчивость бизнеса. За каждым архитектурным решением стояли не только технологии, но и высокие стандарты ответственности, командного взаимодействия и лидерства. Для нас как для HR-функции важно создавать среду, в которой такие специалисты могут расти, предлагать смелые решения и видеть реальный эффект своей работы. Этот кейс показывает: когда в банке есть доверие к экспертам, гибкость процессов и поддержка изменений, инженерные команды могут повлиять на развитие продукта, которым ежедневно пользуются миллионы клиентов».
Фокус – на комфортной разработке
Недавно Ильяс перешел в команду платформы, которая отвечает за стабильность Halyk SuperApp и обеспечивает инструменты для всех продуктовых команд. Специалист планирует улучшать Developer Experience для коллег, которые создают фронтенд-модули в разных проектах. Под этим понимается все, что делает работу инженеров быстрее и комфортнее: сборки, тестирование, CI/CD, качество кода.
«Для меня это важный шаг – перейти от разработки конкретных модулей к работе над платформой, которая делает стабильными и быстрыми решения всех команд SuperApp», — говорит Ильяс.
Инженеры рассказали о технологических перспективах на ближайший год. Углубление автоматизации затронет системы непрерывной интеграции и доставки CI/CD, статический анализ, качество сборок, проверку зависимостей.
В тестировании планируют и дальше расширять покрытие unit-тестами и интеграции в пайплайны. Контроль качества кода значительно усилится благодаря внедрению Quality Gate в разные этапы процесса разработки: правила станут строже, метрики – точнее, а проверка кода полностью автоматизируется. Оптимизация пайплайнов поставки позволит новым фичам выходить быстрее, но без риска для стабильности.
Внедрение инструментов искусственного интеллекта в разработку продолжится: запустят автоматические подсказки, AI code review, анализ производительности и рекомендационные системы. Цель – сделать процессы эффективнее, улучшить клиентский опыт и расширить возможности команды. В этом должны помочь интеллектуальная автоматизация и более продуманный подход к принятию решений.