Банковское обозрение

Сфера финансовых интересов

  • Частное облако: точка примирения бизнеса и IT
20.09.2018 Best-practice
Частное облако: точка примирения бизнеса и IT

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



В эру стремительного развития технологий бизнес неизбежно сталкивается с растущими нагрузками, увеличением объема данных, расширением штата сотрудников, ростом количества новых подразделений, а в некоторых случаях и со слияниями и поглощениями. Исторически сложившаяся IТ-инфраструктура далеко не всегда готова ответить на новые вызовы: зоопарк оборудования и архитектурных решений требует все больших затрат на обслуживание, не принося должной эффективности, затраты на IТ становятся непрозрачными, что неизбежно вводит бизнес в состояние фрустрации. Решением этого комплекса проблем может стать переход на модель частного облака с последующей миграцией всех бизнес-критичных приложений на новую IТ-платформу. Такой подход имеет ряд преимуществ. В первую очередь мы говорим об эффективной аллокации затрат на владение частью IТ-ресурсов для каждого подразделения. Кроме того, эластичность облака дает возможность быстрого масштабирования. Помимо этого, апгрейд инфраструктуры позволяет вывести из эксплуатации целый парк «железа», поддержка которого с каждым годом дорожает. Частное облако унифицирует процесс предоставления ресурсов за счет типовых архитектурных решений, которые бизнес будет использовать на горизонте ближайших лет. Именно по такому пути решила пойти группа ВТБ.

Предпосылки

Возможно, я скажу сейчас очевидную вещь, но в таком крупном проекте как никогда важна правильная этапность: сначала нужно провести аудит, уделить достаточное время планированию и эскизному проектированию, затем строить базовую IТ-инфраструктуру, автоматизировать ее и только затем «переезжать». При этом в самом проекте необходимо выбирать такие решения, с которыми существующие системы действительно смогут работать: можно же построить прекрасную инфраструктуру на x86 процессорах, но, если у бизнеса до этого все приложения работали на RISC, перейти на «иксы» он не сможет. И будет тогда на выходе отличное современное частное облако в сферическом вакууме. Чтобы не допустить подобного, новые стандарты должны учитывать унаследованную реальность.

Частное облако — это всегда преодоление консервативного взгляда на IТ, потому что процесс унификации, понятно, понравится не всем, особенно когда речь идет о российском банке из топ-3. Предлагаемые технологии должны согласовываться с принятыми в корпорации IТ-стандартами. Любая крупная миграция в enterprise-сегменте — это всегда элемент социальной инженерии: важно проговорить со всеми участниками процесса цели и задачи, объяснить IT-подразделением, какие плюсы он несет, как упрощает работу сотрудников, иначе можно не найти понимания в команде и проект окажется нецелесообразным.

Миграция

Как правило, в частное облако «переезжает» очень разнородная старая архитектура, поэтому важнейшая задача заключается в корректном просчете сайзинг-модели новой инфраструктуры, чтобы, с одной стороны, не переплатить, а с другой — не промахнуться в производительности и обеспечить достаточный пул требуемых ресурсов. Миграция почти всегда сопровождается реинжинирингом всех бизнес-систем, поскольку, скорее всего, все решения под них были выбраны достаточно давно, роль и значимость каждого в компании могла измениться, поэтому бизнесу необходимо пересмотреть показатели RTO1 и RPO2 . Итак, переход в частное облако — это отличный повод «прошерстить» все IТ-ресурсы.

Для корректной миграции необходимо заранее предусмотреть множество факторов. Все их можно сформулировать так: «тщательно планировать и разделять зоны ответственности». По нашему опыту, очень важно согласовать весь стек задач, который стоит перед исполнителем. Каждая система требует детальной проработки и индивидуального переноса. Распределение ролей нередко приходится подстраивать под политику безопасности банка, так как часть работ могут проводить только его IТ-специалисты. Это создает новые трудности: необходимо убедиться, что у банка хватит собственных ресурсов для выполнения тех или иных работ.

Суть миграции бизнес-приложений из текущей инфраструктуры в новую заключается в том, чтобы изучить, как устроена система сейчас и понять, как ее нужно трансформировать, чтобы она корректно «вписалась» в частное облако

Процессу миграции предшествует серьезный этап подготовки: для каждой системы создается рабочая группа, определяется ответственный по каждому блоку приложений. Чтобы минимизировать риски, проводится полный аудит прикладных систем, собирается информация о существующем функционале и связности между системами. Для каждой системы техническое решение разрабатывается с использованием в облаке унифицированных архитектурных решений, которые могут обеспечить необходимые бизнесу RTO и RPO. После проектирования организуется детальный процесс согласования с заказчиком, идет сверка с требованиями безопасности. Чтобы работы прошли успешно и данные не были потеряны, мы делаем резервное копирование до начала всех работ. Все процессы проходят детальный контроль, все нюансы обговариваются с заказчиком, чтобы стороны понимали свои роли и знали, как действовать в случае непредвиденных обстоятельств. После утверждения плана и сроков осуществляется непосредственно сам перенос, результаты которого впоследствии должны быть одобрены заказчиком.

Итак, суть миграции бизнес-приложений из текущей инфраструктуры в новую заключается в том, чтобы изучить, как устроена система сейчас и понять, как ее нужно трансформировать, чтобы она корректно «вписалась» в частное облако.

Сроки

Для таких процессов требуется достаточно большая команда. Только от нашей компании задействованы 15 специалистов: системные архитекторы, проектировщики, менеджеры и технические эксперты. От самого банка также привлекаются IТ-специалисты на определенных этапах работы. Что касается временных рамок, то здесь все зависит от количества и сложности систем. Сам процесс миграции может занять всего лишь одни выходные при условии двух- или трехнедельной подготовки. Но бывают и сложные, поэтапные миграции, когда по ранее разработанному и согласованному со всеми участниками плану перенос систем происходит частями: сначала тестовые среды, а если с ними все прошло успешно, то сервера приложений, отдельным этапом идут базы данных — в таких случаях проект может длиться месяцами.

Итоги

Технические миграции финансовых систем имеют свои нюансы: помимо безопасности и зарегламентированности отраслевыми стандартами и требованиями регуляторов при построении необходимо учитывать не только работоспособность всех систем, но и то, как пользователь будет взаимодействовать с ними. Колоссальные объемы данных, сложные системы, критичный для банка бизнес-функционал — это все нужно переносить быстро и успешно, так как банки очень подвержены бизнес-рискам и не могут позволить себе ошибки, особенно если речь идет о крупном игроке, входящем в тройку или пятерку лидеров. Например, приняв решение о построении частного облака, Группа ВТБ сделала значительный шаг вперед навстречу своему технологическому преимуществу. Все системы были модернизированы, часть устаревшего функционала выведена из эксплуатации, упростилось администрирование приложений, что приблизило нас к достижению главных бизнес-целей Банка: повышению прозрачности расходов на IТ и созданию стримлайна в процессе выделения ресурсов под технологические проекты. Основные системы Группы уже консолидированы в облаке. Затраты на них внутри бизнеса разделяются по-разному: например, есть системы, с которым работает только одно подразделение. Бизнес сразу получает информацию о стоимости владения каждой IТ-системой с точки зрения обслуживания, содержания и модернизации, то есть затраты на IТ становятся прозрачными. И главное — при планировании новых систем их стоимость сразу становится очевидной. Можно сказать, что частное облако — это точка примирения бизнеса и IТ.


1. RTO (recovery time objective) — максимальный допустимый промежуток времени, в течение которого система может оставаться недоступной.
2. RPO (recovery point objective) —максимальный допустимый период времени, за который могут быть потеряны данные в результате инцидента.