Один переезд как два пожара?

Нет, всего лишь полбеды. 😉 Вторая половина — сделать так, чтобы процессы не встали, а админы в панике не прыгали за борт.

Сегодня в эфире Яна Шаклеина, руководитель проектов в Outlines Tech. Она расскажет, как вместе с командой и клиентом перевозила часть банковского продукта в облако. При подготовке материала ни одна ипотека не пострадала.

Как до этого дошло?

Раньше софт работал на серверах банка, сотрудники сопровождали его вручную. Руководители захотели тратить на процесс меньше денег и труда, а также высвободить коллег для других задач. Нужно было снять с них поддержку БД и сервисов, которые обеспечивали доступ данных к базе.

Кроме того, важно было делегировать задачи по масштабированию, когда объём потребляемых архитектурных и инфраструктурных ресурсов сокращается или растёт.

Продукт — промежуточная система, в которой банк хранил критически значимые данные клиентов. В базу поступали разрозненные сведения: приложения, банковские карты, личные кабинеты. Их нужно было аккумулировать и унифицировать, чтобы другие системы могли с ними работать по стандарту. Эту базу и сервисы, которые обеспечивали работу с данными, мы и решили перенести в облако.

Специфика проекта в том, что данные применяли для real-time бизнес-процесса. Это значит, что информация актуальна лишь несколько часов, и переехать нужно было быстро и бесшовно. Промедление даже в день привело бы к большим потерям. Главное здесь — поддерживать потоки данных и их полноту.

Что оставалось делать?

Сперва выполнили архитектурную часть: развернули кластер в облаке. Затем определили достаточную историчность, чтобы запуститься — 20% от всей истории. На проектах, где критичностью данных высока, системы перевозят поэтапно. Мы определили объём контента для репликации и провели её. Попутно выявили лаг по времени и сделали дозаливку данных.

Затем включили облако, и данные стали попадать сразу в 2 контура: новый и старый — для проверки, что всё работает, вначале нужна была двухпоточная запись. Когда облако накопило достаточно данных, чтобы к ним могли обращаться сервисы, мы перешли к запуску в 3 этапа:

Полноценное тестирование инфраструктуры с максимальными нагрузками и постоянным чек-контролем.

Проверка на стабильность потока данных. Системы-потребители стали вычитывать поток из облака, а мы сверяли, насколько он соответствует тому, что поступает в базу. Тут же проверяли содержимое в потоке и то, насколько бизнес-процессы могут с ним работать. Убедились, что можем переключаться.

Опытно-промышленная эксплуатация: переключили процессы на новый облачный сегмент с опцией вернуться к старому контуру в случае чего, чтобы гарантировать SLA в 2 часа. Что-то вроде подушки безопасности.

И что дальше?

Полёт нормальный. Приступаем к оптимизации ресурсов, которая и была целью проекта, описываем процессы и готовим документы. Заказчик же планирует реорганизацию, чтобы завершить переезд поддержки. О финансовом результате проекта можно говорить через год, когда всё окончательно перестроят.

Этот проект — пример скорее параллельной миграции, но всё же, как правило, речь о гибриде. Дополнительной сложностью стало то, что процессы развивались уже во время проекта. Бизнес не стоит на месте, и параллельно с переездом запустил доработку из области change, не run. Пришлось немного сдвинуть сроки запуска, чтобы сделать всё аккуратно — клиент поддержал.

Важно помнить, что переезд в облако — сложная архитектурная задача, и в ней нужно обеспечить возможность в любой момент вернуться обратно. Как минимум, вы можете не сразу учесть все доступы, понадобятся пути отхода. Нельзя беспечно полагать, что вы уйдёте в облако, и сразу всё будет хорошо. Рекомендую всегда закладывать эту опцию — как инструкцию на случай критических ситуаций.

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

#облачный_кейс

Облакотека / Оставить «бусты»