Как спасти сайт банка от простоев с помощью катастрофоустойчивого облака

Как мы помогли сократить недоступность официального сайта банка с 2,5 часов до 2,5 минут.

Как спасти сайт банка от простоев с помощью катастрофоустойчивого облака

Задача

Заказчик – крупный российский банк. За интернет-продвижение сервисов банка отвечает отдельная диджитал-команда, которая поддерживает и развивает официальный сайт. Изначально хостинг сайта был организован в собственной инфраструктуре on-premise. В облаке DataLine “на всякий случай” хранились резервные копии. 

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

Два с половиной часа – неплохой результат для восстановления систем вручную. Но все это время сервисы на сайте были недоступны: клиенты не могли оформить заявки на услуги банка и найти необходимую информацию. Простой принес не только финансовые потери из-за неполученных заявок, но и репутационные издержки: в соцсетях жаловались на недоступность, журналисты выпустили негативные публикации про банк. Заказчик обратился в DataLine за решением, которое обеспечит доступность сервисов при различных аварийных сценариях.

Что нужно было сделать
  • Гарантировать стабильность работы сайта. Заказчик понял, что на случай таких аварий нужен четкий план действий и резервная инфраструктура, где можно “поднять” сайт и перенаправить туда трафик.

  • Сократить время простоя при аварии. Даже в случае масштабной аварии нужно уменьшить срок восстановления сайта до нескольких минут.

  • Сделать процесс восстановления предсказуемым. Заказчику хотелось максимально избавиться от человеческого фактора при устранении проблем. За работу сайта отвечает несколько команд, и даже самая отлаженная коммуникация между ними могла давать сбой.

Как решили задачу
Сравнили решения для резервирования инфраструктуры

Изначально заказчик выбрал сервис послеаварийного восстановления на базе vCloud Director Availability (vCDA). В этом решении можно было в облаке создать копию виртуальной машины с сайтом и настроить регулярную репликацию данных. В случае аварии можно за несколько минут переключиться на реплику, и сайт снова будет доступен на облачной резервной площадке.  

VCDA позволял сократить время восстановления (RTO) до 30 минут и нравился заказчику своей стоимостью. Но процесс восстановления все равно запускался бы вручную: кто-то должен был принять решение и нажать кнопку переключения. Снова был риск, что восстановление затянется из-за человеческого фактора.

Архитекторы DataLine предложили рассмотреть катастрофоустойчивое облако

Это решение построено на базе двух дата-центров DataLine – OST и NORD. На каждой площадке располагается кластер виртуализации с зарезервированными СХД и серверами, а связь дата-центров настроена через резервированные каналы связи. Между площадками организована синхронная репликация: вся информация одновременно записывается на локальную и удаленную СХД. Если СХД на площадке OST выйдет из строя, виртуальные машины продолжат работать и будут обращаться за данными к СХД на NORD.

Заказчик сравнил решения по показателям RTO и выбрал катастрофоустойчивое облако, так как в худшем сценарии выгода от более дешевого решения не покрывала бы убытки.

РешениеRTO
vCDA30 минут
Катастрофоустойчивое облако2-2,5 минуты
Спланировали переход в облако

Однако архитектура катастрофоустойчивого облака не позволяла развернуть кластер между on-premise-площадкой и ЦОДом DataLine. Для перехода на это решение была нужна миграция. Заказчик опасался, что из-за переезда в облако сайт снова будет недоступен. Инженеры DataLine предложили использовать в качестве инструмента тот же vCDA. Это решение подходит для миграции и раньше уже помогало перевезти инфраструктуру заказчика в облако с минимальным простоем.

Провели миграцию

Инженеры DataLine настроили сетевую связность между облаком и инфраструктурой клиента. Для миграции выбрали время, когда нагрузка на сайт банка минимальная. Сначала в системе создали тестовое задание на перенос инфраструктуры и убедились, что сценарий работает корректно. Затем запланировали 15 минут на миграцию и недоступность приложения, предупредили пользователей и благодаря отработанному сценарию уложились в срок.

Разработали DR-план и все протестировали

Архитекторы DataLine вместе с заказчиком разработали план для послеаварийного восстановления. В документе подробно описали порядок действий при аварии, согласовали последовательность восстановления сервисов и зафиксировали RTO, за который несут ответственность инженеры DataLine. 

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

Затем провели тестирование DR-плана, чтобы убедиться в корректной работе всех служб.

Что получил клиент
В 60 раз сократилось время на восстановление.
Сервисы работают стабильно

Система будет работать с минимальным простоем, даже если одна из площадок выйдет из строя. Финансовую ответственность за соблюдение RTO несет DataLine.

На случай аварии есть план

У сотрудников есть пошаговый сценарий действий для наиболее вероятных нештатных ситуаций.

Запрос консультации по услуге "Катастрофоустойчивое облако"

Есть похожая задача? Хотите попробовать услугу "Катастрофоустойчивое облако"?

Оставьте заявку — мы свяжемся и обсудим, чем можем вам помочь

Катастрофоустойчивое облако
  • Географически разнесенный кластер виртуализации: все элементы кластера продублированы на площадках OST – на востоке и NORD – на севере Москвы.
  • Полное резервирование всех элементов кластера: серверов, СХД, сетевого оборудования и оптоволоконных трасс между площадками OST и NORD.
  • Синхронная репликация и сохранность данных при переключении на резервную площадку.
  • При полном выходе из строя одной площадки старт виртуальной машины на второй площадке – от 2 минут.

Другие кейсы

Как мы помогли клиенту добиться высокой доступности систем и минимальной потери данных с помощью сервиса DRaaS и резервного копирования.

Аварийное восстановление (DR)

В рамках сервиса DBaaS помогли клиенту ускорить базу данных на MS SQL Server и оптимизировали потребляемые ресурсы.

Платформенные сервисы

Организация удаленной работы для внештатных разработчиков с защитой корпоративных данных от копирования.

Виртуальные рабочие места