Last Updated on 2020-06-06 by admin
Скорость и денежный интерес. Сражаясь за каждого нового клиента и сохранение существующих, банки запускают все новые и новые продукты. Раньше на это в норме уходило несколько месяцев. Сегодня же быстрое реагирование становится обязательным требованием конкуренции. В основе любого банковского сервиса, будь то начисление кешбэка на карту или автоматическая оплата услуг ЖКХ, всегда лежит какое-то программное обеспечение. В банках разработка ПО часто ведется собственными силами, и под ее нужды постоянно создаются и настраиваются различные элементы инфраструктуры. Поэтому в идеале IT-инфраструктура должна предоставлять возможность быстро разворачивать новые сервисы по запросам разработчиков. Цель использования облачных технологий — выполнять такие запросы в максимально короткие сроки. В итоге процессы разработки и тестирования ускоряются в разы. Именно облачные технологии позволяют банкам быстрее тестировать и выводить новые продукты, анализировать рынок и работать с данными, выдерживать максимальную нагрузку в периоды повышенного спроса или проведения акций. Кроме того, IT-инфраструктура должна иметь богатые возможности по масштабированию и гибко меняться под задачи бизнеса. Использование облаков — как раз один из действенных способов достижения нужной скорости, гибкости и масштабируемости.
Облачные технологии помогают банкам сделать затраты на IT прозрачными: они дают возможность точно рассчитать объем и стоимость IT-услуг, потребленных каждым бизнес-подразделением. В этом случае IT-департамент трансформируется из центра затрат в подразделение, способное получать эффект от инвестиций в IT. Продолжением выхода из тени расходов на информационные технологии становится оптимизация ресурсов. Как только затраты на IT-инфраструктуру оказываются исчислимы и понятны внутренним заказчикам, бизнес-подразделения начинают очень аккуратно подходить к заказу новых услуг и использованию IT-ресурсов.
Отраслевая остринка. Использование облачных технологий для банков объективно сложнее, чем для предприятий других отраслей. У них довольно «тяжеловесная» IT-инфраструктура, разделенная на фрагменты с различными требованиями безопасности. Например, основные банковские системы должны быть защищены в соответствии с требованиями ЦБ, а процессинг и другие участвующие в карточных операциях системы обязаны отвечать стандартам PCI DSS. Участки, взаимодействующие с торговыми площадками, живут по своим правилам безопасности. Это серьезно усложняет создание облака внутри банка. Но если все эти нюансы учтены и нашли отражение в создании облака, многочисленные требования к инфраструктуре соблюдаются автоматически. Таким образом, упрощается эксплуатация, повышается уровень информационной безопасности и снижаются риски несоответствия требованиям регуляторов.
В банках использование публичных облаков допустимо только для определенного типа систем, где нет коммерческой тайны, персональных данных и пр. Поэтому основной вариант использования облачных технологий в любой крупной финансовой организации — это строительство собственного частного облака.
Безупречный переезд. Обычно банки трепетно относятся к тому, чтобы допускать до своего IT людей извне, но миграция в облако становится исключением из этого правила. Устройство облаков нетривиально, и даже сильные IT-команды не всегда умеют правильно организовать работу с ними. Вот свежий пример из нашей практики. Банк внедрил систему, которая относится к классу критических приложений. Систему разместили в облаке, а через некоторое время выяснилось, что она располагается только в одном дата-центре. Значит, если ЦОД «упадет», банк не сможет обслуживать своих клиентов в отделениях по всей стране. Разместив систему в облаке, специалисты не до конца учли особенности его внутреннего устройства и его возможности катастрофоустойчивости. Чтобы избежать подобных ситуаций в будущем, наша команда разработала комплект архитектурных стандартов для всех задействованных инфраструктурных компонентов: СУБД, серверы приложений и др. Система была перепроектирована и развернута в соответствии с ними.
Банковские системы обычно сложны и глубоко интегрированы друг с другом. Поэтому так важно при их миграции максимум внимания уделить аудиту и изучению их устройства, а также спроектировать сам перенос. Наш опыт показывает, что выполнить такой сложный процесс силами исключительно своей команды крайне ресурсоемко. Миграция требует сбора сведений об информационных системах, а часто это несколько десятков или даже сотен приложений. Это огромный пласт работы, который обычно передается IT-партнеру. Во-вторых, во многих банках наиболее критичные IT-системы создавались задолго до всяческих облаков и оптимизаций. Их архитектура часто очень самобытна, поэтому чтобы понять ее принципы работы и особенности устройства, нужно приложить колоссальные усилия. Ну и в-третьих, миграция в облако — хороший повод привести такие системы к современным стандартам и практикам, чтобы обеспечить нужный уровень доступности. В то же время редизайном систем не стоит сильно увлекаться: он удлиняет и удорожает проект миграции, а еще влечет за собой дополнительные риски простоев.
В целом общее правило для упрощения миграции гласит: «Вноси как можно меньше изменений». Мы часто видим, какой соблазн у банка в процессе миграции решить разом все проблемы, накопившиеся в инфраструктуре. Переписать на чистовик. Но этот подход коварен. С гарантией в 99,99% можно утверждать, что срок выполнения таких проектов «никогда-нибудь». Одни улучшения влекут за собой другие — и так до бесконечности.
Точно не стоит «тащить» в облако все возможное. Унаследованные системы и те, которые давно не поддерживаются, лучше оставить за бортом. Следование принципу «бритвы Оккама» сэкономит много денег в облачном проекте. Облако, охватывающее весь парк IT-систем, стоит дорого и может не оправдать себя в дальнейшем.
Поэтому отличная практика — развертывание в облаке приложений «с нуля». Это хороший выход для замены устаревших систем. В облаке обычно разворачиваются их современные «собратья», построенные по новым принципам и отвечающие новым реалиям.
Миграцию банки редко делают сами — слишком много подводных камней и нюансов. Непосредственно для проектирования и планирования переноса систем привлекается IT-партнер, а специалисты банка уже вносят необходимые изменения, настраивают или перенастраивают ПО в соответствии с разработанными «рамками». Да и в самом процессе есть точки, требующие подстраховки со стороны. Например, необходимость дополнительной экспертизы в технически сложных моделях «железа» или разновидностях «софта». Кроме того, миграция всегда дает колоссальную нагрузку на штат IT банка, чревата простоями. Внутренних администраторов, которых относительно немного и достаточно в «мирное» время, в этот период катастрофически не хватает. Поэтому часто на этот блок привлекаются дополнительные руки, чтобы справиться с обрушившейся лавиной изменений.
Кредит и вклад из облака. Идеальная миграция — когда клиенты и сотрудники банка не ощутили на себе «переезда» информационных систем. В этом случае сотрудник уходит домой, а утром садится за свой ПК и работает, даже не подозревая, что приложения и данные уже находятся в облаке.
Эта «магия» вполне рукотворная. Миграции планируются так, чтобы не допускать ни на минуту простоя систем, а все работы, требующие их выключения, выполняются в рамках технологических окон. В случае переноса критичных систем процесс переезда предварительно тестируется. Параллельно с планом миграции разрабатывается и план отката, если что-то пойдет не так.
Облачные технологии пронизывают всю деятельность банка, но явный эффект от них на уровне пользователей не заметен. В масштабах банка он складывается в увеличенную производительность и отказоустойчивость IT-систем, а также способность организации быстро адаптироваться к новым вызовам.
Мнение автора может не совпадать с мнением редакции
