Привет, Хабр! Я Елена Журавлева, системный аналитик в Т-Банке в команде импортозамещения АБС. Внедрять новые платежные методы в условиях санкций и одновременно менять ядро АБС — вызов для любой команды. Расскажу, как профессия стала инфраструктурой и как эта инфраструктура помогает аналитику менять проекты, не теряя в перформансе.
Моя история — часть проекта «20 в 20» в честь 20-летия компании: 20 специалистов из 20 городов делятся своими историями в серии статей, чтобы показать ИТ-хабы в разных городах и рассказать о людях, которые в них выросли.
Почему профессия — это инфраструктура
В Т-Банке развит институт профессий — это система, определяющая принципы развития профессий, чтобы обеспечить максимальную пользу от них для сотрудников и компании.
Профессия — сообщество специалистов с общей профессиональной экспертизой. Она обеспечивает:
Профессиональное развитие сотрудников независимо от команды.
Поддержку руководителей в найме и составлении ИПР. А еще помогает руководителям понять, нужен ли им на проекте СА.
Путь развития от джуна до эксперта или лидера.
Связь целей бизнеса и профессии.
До формирования единых стандартов процессы были хаотичными: непонятно, какие критерии требовались для перехода на следующий грейд. Специалисты одного грейда могли иметь неконсистентный уровень скиллов, а это вызывало сложности при ротациях. Не было общего и единого пространства для обсуждения проблем профессии. Сейчас процесс роста стандартизирован и прозрачен для каждого СА: есть четкие матрицы скиллов и критерии перехода. Профессия помогает найти задачки по навыку, если где-то не набирается баллов для следующего грейда.
Основная цель роли лидера профессии в том, чтобы эффективно развивать определенную область знаний и умений во всей группе компаний. Роль лидера профы предполагает участие в двух направлениях: продуктивность и технологии. Недостаточно просто собрать сильную команду — важно обеспечить ее правильными инструментами и практиками. Это позволит сосредоточиться на ключевых задачах, избегая потери времени на рутину или уже решенные проблемы. Важно взаимодействовать с другими профессиями и находить лучшие решения.
Метрики анализа на каждом проекте и в каждой команде определяются индивидуально, так как у нас много разных по типу команд и чесать всех под одну гребенку было бы неверно. У нас есть дашборды с количеством аналитиков, распределением их по отделам. Каждый аналитик может посмотреть ближайшего к себе лидера профессии как по оргструктуре, так и по локации.
Как мы внедряли IBAN-переводы — кейс системного анализа как инженерной роли
IBAN-переводы — новый продукт, которого еще не было в Т-Банке. IBAN (International Bank Account Number) — международный номер банковского счета клиента. Он состоит из букв и цифр и является частью банковских реквизитов.
Изначально IBAN использовали для стандартизации межбанковских расчетов на территории Европейского союза, но затем к этому стандарту присоединились и другие страны. Используя стандартизированный банковский номер, банкам из разных стран проще обмениваться информацией. Так деньги из одной точки мира можно перевести в другую, указав международный номер банковского счета. Сейчас IBAN используют более 80 стран. Стандарт IBAN разработала Международная организация по стандартизации — International Organization for Standardization, или ISO.
Все началось с фразы «Да там копипаст со Свифта». SWIFT-код идентифицирует банк — это как адрес отделения почты. IBAN идентифицирует конкретный счет клиента — это полный адрес с номером квартиры:
SWIFT: SBERRUUMM (банк).
IBAN: TR33 0006 1005 1978 6457 8413 26 (конкретный счет в банке).
IBAN содержит:
Код страны (2 буквы).
Контрольные цифры (2 цифры).
BBAN — национальный номер счета (до 30 символов).
Если клиент ошибется в одной цифре IBAN, перевод уйдет не туда и вернуть его может быть невозможно. Поэтому валидация на нашей стороне критически важна.
Точкой входа стал новый экран в нашем мобильном приложении.
Слой 1: мобильное приложение. Для меня как для аналитика интересным вызовом стала реализация механизма по безрелизному добавлению новых полей на экран. Так как разные страны по своим законам могут требовать дополнительную информацию для идентификации перевода, необходимо было обеспечить определение страны перевода до открытия экрана и загрузку на экран нужных полей.
На первом этапе мы не могли реализовать определение страны до открытия экрана и решили эту проблему по-другому: мы определяли страну перевода по введенному IBAN получателя. В соответствии с ISO 13616 формат представления банковских реквизитов состоит из обязательных элементов, в том числе и кода страны — первые два символа номера IBAN. После ввода пользователем первых двух символов мы определяем страну перевода и выводим на экран дополнительные поля, если таковые есть.
Задача: создать новый экран перевода по IBAN, который удобно вписывается в текущий UX, не требует обновления приложения для будущих изменений и обрабатывает ошибки ввода в реальном времени.
Решение: Feature flags + конфигурация с бэкенда. Вместо хардкода логики в приложении мы вынесли все правила в конфигурацию:
Список доступных стран.
Форматы IBAN для каждой страны (длина, структура).
Лимиты, комиссии.
Дополнительные поля для идентификации.
Вынесение правил помогло нам добавлять новые страны без релиза приложения.
Пример структуры валидации { "bankInfo": { "country": "TR", "currency": "949" }, "limits": { "maxAmount": 999999.99, "minAmount": 9.99 }, "extraFields": [ { "id": "birthDate", "title": "Дата рождения", "mask": "dd.mm.yyyy", "regExp": "^(0[1-9]|[12]\\d|3[01])\\.(0[1-9]|1[0-2])\\.\\d{4}$", "minLength": 10, "maxLength": 10, "hint": "Введите дату рождения в формате дд.мм.гггг", "placeholder": "Дата рождения получателя" } ] }
Клиент проверяет: соответствие длины, формат (regex по стране) и контрольные цифры (алгоритм mod-97).
Разные магазины приложений имеют разное время модерации. Решение с конфигом позволило нам выпускать новые фичи независимо от релизного цикла.
Слой 2: middleware. За экраном мобильного приложения стоит огромный банк с большим количеством сервисов. Мне, как аналитику, пришлось нырять на всю глубину процесса обработки операций. Нужно было научить все банковские системы работать с новым идентификатором переводов: по аналогии с российским 20-значным номером счета, как с номером телефона. Для этого пришлось изучить существующие способы перевода, чтобы понять архитектуру и органично вписать новый способ перевода.
Задача: проверить валидность IBAN и существование счета до того, как перевод уйдет в обработку. Это критично, потому что переводы могут идти несколько дней. Если IBAN невалиден, клиент узнает об этом постфактум, а деньги зависнут или уйдут не на тот счет.
Решение: интеграция с платформой IBAN, которая дает в формате «ПО как услуга» (SaaS) производить проверку и расчет международного банковского номера счета IBAN. Автоматическая проверка банковских реквизитов позволяет избежать дополнительных затрат и потерявшихся платежей.
Слой 3: платежный шлюз. На платежном шлюзе стоило настроить:
1. Конвертацию валют.
2. Фиксацию курса валют.
3. Расчет комиссии.
4. Роутинг — определение страны получателя и банка-корреспондента.
Именно эти работы и заняли большую часть времени и задействовали больше всего команд. Важно было обеспечить точный курс и его отображение клиенту: клиент может начать перевод и отвлечься на звонок, после чего курс уже будет другой.
Слой 4: ядро и АБС. Самый важный, сложный и непонятный этап — процесс учета движения денежных средств, процесс регистрации проводок и изменения балансов. Это самая зарегулированная часть процесса, цена ошибки велика: штрафы регуляторов как на нашей стороне, так и на стороне получателя и остановка процесса вообще
Задача: корректное отражение операций в бухгалтерском учете. Нужно было продумать и согласовать проводки и счета для комиссий, для перевода клиентов.
Процесс ежедневных сверок с банками-корреспондентами нужен для правильных взаиморасчетов и комиссий. В процесс входит:
Выгрузка всех прошедших переводов.
Сравнение с нашими данными.
Выявление расхождений (недошедшие, отклоненные).
Проблема: разные форматы выгрузок у разных корреспондентов. Решение — унифицированный парсер с адаптерами под каждый банк.
Сферы в комплаенсе и регуляторке, которые нужно было закрыть перед релизом, чтобы новый способ перевода соответствовал нашим правилам и законам РФ:
Требования ЦБ — валютный контроль: для переводов свыше $10,000 требуется проверка документов.
Интеграция с внутренней системой комплаенса — проверки клиента перед переводом.
Во время реализации пришлось решить еще несколько проблем между командами:
1. Разное понимание термина «готово». Мобильники говорили: «Кнопка нарисована», бэкенд: «API отвечает 200», ядро: «Проводки еще не готовы», а решение: «Definition of Done на уровне всего продукта, а не отдельной команды».
2. Зависимости по интеграциям. Команда шлюза не могла начать тестирование, пока middleware не готово.
Помогли mock-сервисы для раннего старта тестирования — это специальный программный инструмент или компонент, который заменяет реальный внешний сервер, базу данных или API. Он принимает запросы и возвращает заранее заготовленные ответы, повторяя поведение настоящей системы. Mock-сервис позволяет заранее договориться о контрактах, но не ждать завершения разработки.
3. Разные приоритеты. Для комплаенса важнее проверки, чем скорость. Для мобильного приложения — наоборот. Помогли переговоры. В Т-Банке все настроены на результат, и мы просто договаривались, декомпозировали.
Результаты внедрения
Метрики запуска: первый месяц, одна страна | Технические метрики |
Доля успешных переводов: 96% Время обработки: от 6 минут до 2 дней | Время валидации IBAN: < 500ms Доступность API: 99,9% Количество ручных вмешательств: < 1% |
Что сработало хорошо:
Вынос конфигурации в бэкенд — сэкономили месяцы на будущих обновлениях.
Двухэтапная валидация — снизили количество ошибочных переводов.
Контрактное тестирование — команды могли работать параллельно.
Что сделали бы иначе:
Раньше вовлекли бы комплаенс: в конце пришлось переделывать часть логики.
Добавили бы больше мониторинга на старте: первые баги ловили по жалобам.
Внедрение IBAN-переводов оказалось сложнее, чем «скопипастить со Свифта. Но именно такие задачи самые интересные: с неопределенностью в начале и измеримым результатом в конце.
Главный инсайт: когда никто не знает точно, как должно быть. Важно начать с малого, получить обратную связь и итеративно улучшать. Мы запустились на одной стране, отладили процессы и теперь масштабируемся на другие направления.
Импортозамещение АБС — аналитик как архитектор стыков
Автоматизированная банковская система, или АБС, с точки зрения аналитика — огромная база данных. Это место, куда приходит любая операция, совершенная в банке: от оплаты коммуналки до оформления ипотеки.
Помните, как раньше в СССР, после каждой продажи колбасы или конфет, продавец в большую книгу записывала «номер, дата, колбаса 1 кг, 5 рублей»? Суть АБС именно в этом: записать в книгу номер операции, дату, сумму. Со временем только немного усложнилось: появились счета, дебет, кредит, остатки, баланс, налоги. И это все АБС.
Наша АБС — набор модулей, которые обеспечивают разные направления банка: обслуживание клиентов, работу с ценными бумагами и финансовыми инструментами, кредитование и работу с депозитами, выпуск отчетности.
АБС использовала СУБД Oracle. Oracle как вендор ушел с российского рынка, появилась необходимость реализовывать миграцию на Postgres. Но АБС — это фактически сердце банка. Нельзя просто его выключить и сказать: «Теперь ходим сюда», потому что там гигабайты данных клиентов. Например, клиенту может понадобиться выписка за последние пять лет, на сотни и тысячи записей по операциям. А мы не можем это предоставить, потому что выключили старое ядро. Чтобы этого не произошло, прорабатываются сценарии миграций данных.
Миграция с Oracle на PostgreSQL — сложный процесс, который затрагивает не только данные, но и схему базы, хранимые процедуры, триггеры и код приложения. Это не просто «копирование», а скорее «переезд» с изменением архитектуры. Миграция — это определение, какие данные нужны, создание карт соответствия полей из старой базы в новую, правила трансформации, описание логики очистки и изменения формата данных, проверка корректности перенесенной информации совместно с тестировщиками и бухгалтерами.
В параллели с миграцией данных идет процесс разработки новых механизмов их обработки: новые API, топики, сценарии интеграций, новые сервисы. Все то, что раньше было частью монолита, становится отдельным сервисом. Когда таких сервисов десятки, важно не задублировать и не упустить логику, обеспечить согласованность данных между сервисами.
В проекте с АБС я работаю с созданием сервисов отвечающих за регистрацию проводок. Проводка в АБС — аналог той самой записи в книге в магазине.
Например, мы пришли в банкомат и положили 5 000 рублей наличными на свою карту.
В этот момент под капотом происходит:
Запрос: Банкомат принимает 5 000 рублей и отправляет зашифрованный ISO-запрос в Процессинг.
Проверка: Процессинг определяет тип операции (Cash-In) и проверяет карту/счет на блокировки и лимиты.
Холд (Обновление баланса): Процессинг мгновенно увеличивает доступный баланс карты. Вы видите +5 000 рублей в приложении, банкомат выдает чек.
Этап клиринга и проводок в АБС (в конце дня)
Файл: Процессинг выгружает реестр операций за день и передает его в АБС (бухгалтерию).
Контроль: АБС определяет дату операции (Value Date) и проводит скрытые комплаенс-проверки (AML/финмониторинг).
Проводка: АБС фиксирует операцию на балансе банка дебет и кредит. Дебет: Балансовый счет кассы банкоматов (физические деньги пришли в устройство). Кредит: Личный карточный счет клиента (официальное обязательство банка перед вами).
Я изучаю каждый флоу, как это работает сейчас, какие есть комплаенс-контроли, какая нагрузка и так далее. Проектирую для операций обработку с учетом новой архитектуры: все то, что раньше могло быть захардкожено в монолите, нужно вынести в конфиги и сервисы. Все то, что выполнялось логикой в монолите, нужно вынести в другие сервисы и интегрироваться с ними
Для каждого процесса отдельно выбирается тип и стратегия миграции. Основная задача — не потерять данные и не уронить процессы. Самые распространенные типы миграций:
Поэтапная миграция. Миграция происходит по модулям, таблицам или схемам. Часть данных остается в Oracle, часть — в Postgres. Этот тип используется для больших модулей, которые трудно остановить целиком.
Миграция с репликацией. Настраивается репликация изменений из Oracle в Postgres в реальном времени. Когда данные синхронизированы, сервис переключается на Postgres. Этот способ выбирается для высоконагруженных частей и модулей, где простой недопустим.
Параллельная запись. Данные одновременно пишутся и в Oracle, и в Postgres. Этот способ используется как временное решение при переходе на микросервисы
Мы не выбираем один тип миграции, мы действуем гибко, в зависимости от условий. Если недопустим простой — поэтапная миграция. Если нужно проверить, что новая и старая логики совпадают, и еще раз убедиться, что все ок, — параллельная запись.
Как мы развиваем профессию — инженерные практики
Развитие профессии имеет два вектора: полечить, где болит, и внедрить новое, упрощающее жизнь. Процесс роста стоит отдельно, уверенным столпом.
Например, профессия активно переходит на процесс ведения документации doc-as-code и использование ИИ-агентов. Для этого нужно установить и настроить IDE. Ничего сложного, но рутинно и отнимает какое-то время.
Я несколько раз меняла ноутбуки и очень раздражалась, когда приходилось одно и то же настраивать несколько раз. Я подумала, что не одна такая и если мне пришлось повторить это упражнение несколько раз, то стоит его автоматизировать. Так родилась задача по созданию готовой сборки для VS Code, которая сразу будет содержать нужные плагины. Готовая сборка ускоряет онбординг, сокращает время на поиск нужных плагинов, делает универсальным ведение документации, повышает адопшн использования ИИ, а еще делает работу безопасной (все плагины апрувнуты ИБ).
У нас есть регулярные митапы: каждую неделю ребята делятся своим опытом на коммьюнити СА. Темы как софтовые, так и хардовые. Запилили крутой фреймворк на проекте — велком, расскажите. Нам не приходится ходить с микроскопом и искать кто бы выступил на митапе.
Чтобы рассказать о своем опыте, я записалась в марте на выступление в июле. Желающих очень много, и это очень круто. На июльском митапе я делилась своим опытом проведения реверс-инжиниринга использования агентов. Я показала, что удалось, чего не удалось, чего опасаться, пошарила промт, который у меня получился после многих итераций. Такие выступления помогают:
Шарить знания. Все примерно понимают, как использовать агентов, реверс-инжиниринг — это один из вариантов их использования.
Снижение порога входа. По итогу я скинула промпт, который можно брать и использовать в работе, и это позволит кому-то начать делать, если раньше не знали, с чего начать.
Укрепление комьюнити.
В этом году появился отдельный трек, который разрабатывает методологию оценки влияния СА, качества анализа и подходов по его улучшению.
Каждая команда настраивает под себя, под свой проект и свои нужды шаблоны и чек-листы, общий от профессии есть рекомендованный шаблон «ОкиДоки». Это сборник шаблонов на все случаи жизни: если ты единственный аналитик на проекте, если проект новый, если пришла нетривиальная задача в ОкиДоки ты можешь найти шаблон, по которому составишь свое описание. Этот набор помогает справиться с синдромом чистого листа, не забыть добавить в описание неочевидные вещи и сделать полную документацию. Мы не ограничиваем команды и не навязываем единые правила, так как понимаем, что документация — это для команды и команда сама может определить набор документов, способ ведения документации, глубину проработки и т. д.
Единственный стандартизованный шаблон — это документация в приложении банка. Мобильное приложении — наша основная точка касания с клиентом, поэтому там самые строгие и формализованные правила.
В 2024 году прошла большая работа: более 500 человек обучили новым требованиям работы с документацией мобильного приложения. Ежеквартально проводится большой аудит документации на соответствие стандартам. В самом плохом сценарии может быть наложен даже запрет на релизы для команды до устранения всех замечаний аудита.
Для джунов у нас есть четкая матрица каждого этапа. У каждого джуна есть ментор, который следит за выполнением этой матрицы. Методологию и приемы выбирает ментор сам, мы не настаиваем на каком то определенном сценарии. У нас есть общебанковский Практик-аб, где приводятся бест-практикс по различным профессиям, направлениям, кейсам, навыкам, и любой желающий может почерпнуть оттуда нужную информацию.
У нас на 90% открытая Вики и есть Nestor Serch — умный ИИ-поиск. Вся информация открытая и доступная. Я зачастую просто гуглю по вики, и мне даже не приходится дергать команды «а где у вас, а че у вас, а скиньте почитать», что сильно сокращает время на работу.
Инфраструктура хаба: как среда влияет на инженерию
Среда Саратовского хаба помогает и объединяет специалистов разных направлений, так же, как делает это профессия системных аналитиков. У нас нет центров компетенции по каким-то направлениям, профессии и направления перемешаны, и это делает нас сильнее. Например, всегда можно попасть на разгон какой-то темы прямо на кухне или сходить на круглый стол или митап.
А еще к нам часто приезжают коллеги из других регионов на стратсессии или проведать родственников. И так получаются классные коллаборации и обмен опытом.
На наших митапах чаще всего обсуждается что-то практическое. Ребята внедрили что-то у себя на проекте и рассказывают об этом. Из последнего — мобильное тестирование. Нам рассказали про стратегии мобильного тестирования на разных платформах и версиях (вебвью, PWA, нативное приложение). Это было полезно и интересно и как обычному пользователю приложения, и как инженеру. После доклада у меня родилась идея, как своему стажеру доступно и понятно объяснить разницу между версиями, и мы это проработали с ним.
В рамках образовательных программ мы выступаем перед школьниками и студентами. Этим летом случилось очень трогательное для меня событие: в 2023 году мы выступали перед школьниками, рассказывали о Т-Банке и об олимпиаде по анализу данных (DANO). Один из тех ребят стал победителем олимпиады и этим летом он вышел на стажировку к нам 🤗
Заключение
За четыре года работы над проектами IBAN и импортозамещения АБС я убедилась: системный анализ — это не только инженерная дисциплина, которая снижает риски.
Системный аналитик — это фильтр, который помимо принятия технических решений фильтрует вредные решения, он — контрольная точка сомнения. Зачастую на аналитике держится настроение команды, потому что софты аналитика — это его харды.
Главный инсайт: профессия становится инфраструктурой, когда стандарты измеряются, инструменты автоматизируются, а знания передаются системно. Неважно, где вы работаете — в Саратове, Москве или удаленно. Важно, чтобы процессы позволяли принимать инженерные решения, а не просто закрывать задачи.
Что в планах:
Расширять IBAN на новые страны (сейчас в работе две страны)
Завершить миграцию первого модуля АБС на PostgreSQL
Развивать внутренний трек ИИ в системном анализе
Продолжать менторить студентов и стажеров
Развивать наш телеграм-канал InSAйт
Выступить на конференции в Чебоксарах с докладом как системным аналитикам правильно говорить «Нет» на невыполнимые требования
А как вы решаете проблему согласованности данных при миграции legacy-систем? Какие метрики качества анализа используете в своих командах? Делитесь опытом в комментариях — буду рада обменяться практиками.
