Банку нельзя ждать, пока система сломается: эксперт Салават Каримов о том, как проектируются технологии на годы вперед
Поэтому в современной финансовой отрасли все большее значение приобретает архитектура, рассчитанная не только на текущую нагрузку и сегодняшние требования, но и на будущие изменения. Салават Каримов, архитектор решений по интеграции высоконагруженных банковских платежных систем, рассказывает, почему банковским технологиям опасно жить исключительно в режиме реакции, как заранее оценивать будущие риски и почему иногда выгоднее изменить систему до того, как в ней действительно появилась проблема.
– Салават, почему вообще банковской системе нужно готовиться к изменениям заранее? Разве не логичнее решать задачи по мере их появления?
Салават Каримов: Такой подход кажется рациональным, пока система относительно простая. Появилось новое требование – его реализовали, изменился формат – адаптировали интеграцию, понадобился новый сервис – добавили соответствующий модуль. Но в крупной банковской инфраструктуре каждое изменение происходит не в вакууме. Один новый элемент может быть связан с десятками других компонентов, и чем дольше система существует, тем больше становится таких взаимосвязей.
Поэтому задача архитектора значительно шире, чем реализация очередного требования. Разработчик в первую очередь отвечает на вопрос – как сделать то, что нужно сейчас. Архитектор должен задать следующий вопрос – что изменится через два-три года и позволит ли сегодняшнее решение пройти этот путь без полной перестройки? Это принципиальная разница. Мы не пытаемся предсказать конкретное событие или угадать, какой именно продукт появится через три года. Мы смотрим на направление, в котором развивается отрасль: регуляторные требования, платежные стандарты, информационная безопасность, объемы транзакций, количество интеграций. Если эти тенденции очевидны, их нужно учитывать уже на этапе проектирования. Именно поэтому хорошая архитектура для меня – это не просто способ решить сегодняшнюю задачу, это способ сделать будущие изменения управляемыми.
– Получается, архитектор должен постоянно думать о том, чего еще не произошло?
Салават Каримов: Именно так, причем речь идет не о футурологии, а о вполне прикладной работе с известными тенденциями. В финансовой отрасли изменения редко возникают совершенно неожиданно. Например, переход на ISO 20022 рынок обсуждал задолго до наступления конкретных сроков миграции. Банки понимали, что им придется работать с новым стандартом, и могли заранее оценить, насколько их текущая архитектура к этому готова.
Для одних организаций такая трансформация становилась частью плановой модернизации. Они могли постепенно менять отдельные компоненты, тестировать новые форматы, перестраивать интеграции и параллельно развивать продукты. Для других момент перехода превращался в большой срочный проект, потому что изменения начинали внедряться уже под давлением дедлайна. Это хороший пример общего принципа: одинаковое изменение для одной компании может стать плановой технологической трансформацией, а для другой – дорогим аварийным ремонтом. Разница зачастую появляется задолго до самого изменения, на этапе архитектурных решений.
– Почему ожидание до последнего обходится банкам настолько дорого?
Салават Каримов: Потому что со временем стоимость изменений растет нелинейно. Когда система только создается, архитектурное решение можно заложить в основу. Если же она несколько лет работает в промышленной эксплуатации, вокруг нее уже формируется множество интеграций, бизнес-процессов и зависимостей.
Представим, что в начале проекта есть десять компонентов, которые взаимодействуют между собой. Через несколько лет их может быть в разы больше. Появляются новые сервисы, каналы обслуживания, внешние системы, требования к безопасности. В результате изменение одного элемента начинает затрагивать целую цепочку. Именно поэтому решение, которое сегодня выглядит как небольшая архитектурная инвестиция, через несколько лет может оказаться способом избежать очень дорогой перестройки. Кроме того, есть еще один фактор – время. Когда изменение заранее предусмотрено архитектурой, его можно внедрять постепенно. Когда оно становится срочным, у команды уже нет возможности спокойно проверять гипотезы, проводить несколько итераций тестирования и выбирать оптимальный вариант. Возникает необходимость быстро менять работающую систему, а для банка это всегда связано с повышенными операционными рисками.
– То есть технический долг возникает не только из-за плохого кода?
Салават Каримов: Конечно, технический долг часто воспринимают исключительно как проблему разработки: где-то написали не очень качественный код, не сделали рефакторинг, отложили тестирование. Но в крупных системах он может появиться значительно раньше – на уровне архитектурных решений. Можно идеально реализовать функциональность, которая решает сегодняшнюю задачу, и при этом создать проблему для завтрашнего дня. Например, заложить жесткую связь между несколькими компонентами, хотя уже понятно, что количество интеграций будет расти. Или спроектировать систему под один формат данных, если отрасль движется к нескольким форматам. С точки зрения сегодняшнего дня такое решение может быть вполне корректным. Но через некоторое время бизнес столкнется с ограничением, которое было заложено еще на старте. Поэтому архитектурный долг я бы рассматривал как отложенную стоимость будущих изменений. Чем больше система становится связанной и чем больше зависимостей возникает между ее компонентами, тем дороже этот долг обслуживать.
– Как на практике понять, что архитектуру уже пора менять, даже если система пока работает?
Салават Каримов: Это один из самых сложных вопросов, потому что работающая система создает иллюзию, что все в порядке. Если платежи проходят, пользователи обслуживаются, бизнес получает необходимые функции, возникает естественное желание ничего не трогать. Но архитектура должна оцениваться не только по тому, насколько хорошо она выполняет текущую задачу. Нужно смотреть на то, насколько легко система изменяется.
Я бы предложил задавать несколько вопросов. Что произойдет, если объем транзакций вырастет в два или три раза? Сколько времени потребуется, чтобы подключить новый внешний сервис? Что будет, если регулятор изменит формат обмена данными? Можно ли заменить отдельный компонент, не затрагивая всю систему? Сколько независимых команд могут одновременно работать над разными частями решения? Если ответы требуют долгого анализа и большого количества ручных согласований, это уже сигнал. Система может продолжать работать, но ее способность к изменениям начинает снижаться. Для банков это особенно важно, потому что рост нагрузки и числа интеграций – не гипотеза, а естественная траектория развития отрасли.
– Вы много работаете с высоконагруженными платежными системами. Что происходит с архитектурой, когда речь идет об огромном количестве транзакций в реальном времени?
Салават Каримов: Здесь особенно важно не рассматривать нагрузку отдельно от бизнес-логики и регуляторных требований. Банковская система должна одновременно выдерживать поток операций, корректно обрабатывать каждую транзакцию и соблюдать все необходимые правила контроля. При небольшой нагрузке некоторые архитектурные решения могут выглядеть совершенно приемлемыми. Но при росте количества операций слабые места начинают проявляться очень быстро. То, что раньше занимало доли секунды, превращается в задержку, а локальная проблема может распространиться на связанные компоненты.
Поэтому высоконагруженную систему нельзя строить исключительно из расчета на сегодняшние показатели. Нужно понимать, как она будет вести себя при росте нагрузки и где находятся точки, которые потенциально станут ограничением. При этом масштабирование само по себе не является универсальным ответом. Можно просто увеличить вычислительные ресурсы, но это не всегда решает архитектурную проблему. Иногда необходимо изменить сам принцип взаимодействия компонентов, чтобы система могла продолжать работать при увеличении нагрузки.
– Можно ли добиться такого запаса прочности без бесконечной модернизации и роста бюджета?
Салават Каримов: В этом и заключается смысл грамотной архитектуры. Хорошее решение не должно означать, что банк постоянно перестраивает свою IT-систему «на всякий случай». Задача как раз обратная: заранее определить изменения, которые действительно вероятны, и подготовить архитектуру именно к ним. Не нужно закладывать бесконечный запас на все возможные сценарии. Нужно понимать направление движения и создавать достаточную гибкость там, где она действительно понадобится.
В моей практике архитектурные решения позволяли снижать ежегодные расходы на поддержку примерно на 70%. И это происходило не за счет отказа от функций или сокращения возможностей системы. Экономия достигалась благодаря тому, что архитектура позволяла обслуживать и развивать решение значительно эффективнее. Это важный момент: архитектура – не только про технологические возможности. Она напрямую влияет на стоимость владения системой.
– Получается, иногда дешевле потратить деньги на проблему, которой еще нет?
Салават Каримов: Да, хотя с точки зрения финансового планирования это одна из самых сложных для объяснения вещей. Когда вы предотвращаете проблему, результат часто выглядит как отсутствие события: ничего не сломалось, не пришлось останавливать систему, не возник аврал. Поэтому может казаться, что инвестиции были необязательными.
Но если посмотреть на альтернативный сценарий, становится понятно, что профилактическое решение может быть значительно дешевле экстренной модернизации. В последнем случае одновременно растет стоимость разработки, увеличивается давление на команды, сокращается время на тестирование и возникают дополнительные операционные риски. Кроме того, у банка есть стоимость упущенного времени. Если изменение архитектуры занимает месяцы, бизнес не может нормально развивать продукт в этот период или вынужден ограничивать планы. Поэтому я бы оценивал архитектурные инвестиции не только по стоимости самой разработки, но и по тому, какую цену они позволяют не заплатить в будущем.
– Насколько сильно на архитектуру банков сегодня влияет развитие цифровых платформ и API?
Салават Каримов: Очень сильно, ведь финансовый бизнес становится все более связанным с внешними сервисами, партнерами и внутренними цифровыми продуктами. Количество интеграций растет, и архитектура должна это учитывать. Крупные финансовые организации переходят к более модульным подходам, используют API, микросервисные архитектуры и другие инструменты, которые позволяют отделять компоненты друг от друга. Причина не в том, что монолитная система обязательно плоха. Монолит может быть стабильным и эффективным. Проблема появляется тогда, когда сама структура системы начинает мешать изменениям. Если для запуска одного нового сервиса необходимо затронуть большую часть существующей инфраструктуры, скорость развития бизнеса становится зависимой от архитектуры. Модульность в этом смысле дает не столько технологическую красоту, сколько управляемость изменений. Можно развивать отдельные части системы, не заставляя каждый раз перестраивать все целиком.
– А что происходит с архитектурой, если бизнес развивается быстрее, чем IT-система?
Салават Каримов: Это довольно типичная ситуация. Бизнесу необходимо быстро запускать новые продукты, выходить в новые каналы, подключать партнеров. IT при этом должно обеспечить надежность и соответствие требованиям. Если архитектура не рассчитана на такой темп, появляется постоянный конфликт между скоростью и безопасностью изменений. Каждая новая задача становится отдельным проектом, а команды начинают тратить все больше времени на согласование зависимостей и исправление последствий предыдущих решений.
Поэтому архитектор должен понимать не только технологическую сторону, но и бизнес-контекст. Я всегда считаю важным держать в голове одновременно три вещи: что требуется бизнесу, как устроена банковская система и какие ограничения задает регулирование. Нельзя оптимизировать только одну из них.
Можно построить технически красивое решение, которое не соответствует бизнес-процессу. Можно сделать удобную для бизнеса систему, которая окажется слишком дорогой в сопровождении. Можно решить задачу технически и бизнесово, но нарушить обязательные требования. Архитектура должна удерживать эти три измерения одновременно.
– Вы говорите о работе «на опережение». А где проходит граница между предусмотрительностью и избыточным проектированием?
Салават Каримов: Это действительно важная граница. Если пытаться предусмотреть абсолютно все, архитектура станет чрезмерно сложной и дорогой. Поэтому я не сторонник подхода «давайте заложим возможность для любого сценария, который когда-нибудь может произойти». Нужно отделять вероятные изменения от фантазий. Если мы видим устойчивый тренд – рост нагрузки, увеличение количества интеграций, изменение стандартов, усиление требований к безопасности, его имеет смысл учитывать. Если речь идет о гипотетическом сценарии без признаков того, что он когда-либо станет реальностью, не стоит усложнять систему только ради него. По сути, архитектура – это постоянная работа с вероятностями. Мы не знаем будущее во всех деталях, но можем достаточно хорошо понимать направление движения.
– Насколько в этой работе важен опыт? Можно ли научиться проектировать такие системы исключительно по книгам и документации?
Салават Каримов: Теория необходима, но в банковской архитектуре очень многое приходит именно с практикой. Когда вы видели, как система ведет себя под реальной нагрузкой, как изменение одного компонента неожиданно влияет на другой, как бизнес-задача сталкивается с регуляторным ограничением, вы начинаете иначе оценивать архитектурные решения. Важен и исторический контекст. Многие проблемы, которые сегодня кажутся новыми, на самом деле уже возникали в другой форме. Индустрия проходит циклы: растет нагрузка, появляются новые интеграции, меняются стандарты, затем возникает необходимость модернизации.
Поэтому хороший архитектор должен уметь смотреть одновременно назад и вперед. Назад, чтобы понимать, почему система стала такой, какой она является сейчас. А вперед, чтобы не повторять те же архитектурные ошибки в новых условиях.
– Какой главный принцип вы бы сформулировали для банков, которые сегодня строят или обновляют свои IT-системы?
Салават Каримов: Я бы сказал так: не проектировать систему только под требования сегодняшнего дня. Это не означает, что нужно пытаться угадать будущее. Наоборот, нужно научиться видеть закономерности. Если объемы операций растут, количество интеграций увеличивается, стандарты постепенно унифицируются, а требования к безопасности становятся строже, архитектура должна позволять системе двигаться вместе с этими изменениями.
Самая дорогая ошибка – не обязательно неправильное техническое решение. Иногда гораздо дороже оказывается правильное решение, которое было принято слишком узко и слишком поздно. В банковской сфере технологическая зрелость проявляется не только в том, насколько быстро система решает сегодняшнюю задачу. Она проявляется в том, насколько спокойно банк способен встретить завтрашнюю. И если архитектуру приходится полностью переделывать каждый раз, когда меняется внешний мир, значит, проблема возникла не в момент нового требования. Она появилась гораздо раньше – тогда, когда систему проектировали без запаса на изменения.
Василий Черный
