Заказчик – крупный российский банк. За интернет-продвижение сервисов банка отвечает отдельная диджитал-команда, которая поддерживает и развивает официальный сайт. Изначально хостинг сайта был организован в собственной инфраструктуре on-premise. В облаке DataLine “на всякий случай” хранились резервные копии.
Однажды из-за сбоя оборудования сайт оказался недоступен. Восстанавливать работоспособность нужно было вручную. Сначала инцидент поступил диджитал-специалисту, который не нашел проблем на программном уровне и передал информацию ИТ-специалистам. Служба ИТ выяснила причину сбоя, исправила проблемы с оборудованием и развернула резервные копии. Всего на перезапуск сайта потребовалось 2,5 часа.
Два с половиной часа – неплохой результат для восстановления систем вручную. Но все это время сервисы на сайте были недоступны: клиенты не могли оформить заявки на услуги банка и найти необходимую информацию. Простой принес не только финансовые потери из-за неполученных заявок, но и репутационные издержки: в соцсетях жаловались на недоступность, журналисты выпустили негативные публикации про банк. Заказчик обратился в DataLine за решением, которое обеспечит доступность сервисов при различных аварийных сценариях.
Гарантировать стабильность работы сайта. Заказчик понял, что на случай таких аварий нужен четкий план действий и резервная инфраструктура, где можно “поднять” сайт и перенаправить туда трафик.
Сократить время простоя при аварии. Даже в случае масштабной аварии нужно уменьшить срок восстановления сайта до нескольких минут.
Сделать процесс восстановления предсказуемым. Заказчику хотелось максимально избавиться от человеческого фактора при устранении проблем. За работу сайта отвечает несколько команд, и даже самая отлаженная коммуникация между ними могла давать сбой.
Изначально заказчик выбрал сервис послеаварийного восстановления на базе vCloud Director Availability (vCDA). В этом решении можно было в облаке создать копию виртуальной машины с сайтом и настроить регулярную репликацию данных. В случае аварии можно за несколько минут переключиться на реплику, и сайт снова будет доступен на облачной резервной площадке.
VCDA позволял сократить время восстановления (RTO) до 30 минут и нравился заказчику своей стоимостью. Но процесс восстановления все равно запускался бы вручную: кто-то должен был принять решение и нажать кнопку переключения. Снова был риск, что восстановление затянется из-за человеческого фактора.
Это решение построено на базе двух дата-центров DataLine – OST и NORD. На каждой площадке располагается кластер виртуализации с зарезервированными СХД и серверами, а связь дата-центров настроена через резервированные каналы связи. Между площадками организована синхронная репликация: вся информация одновременно записывается на локальную и удаленную СХД. Если СХД на площадке OST выйдет из строя, виртуальные машины продолжат работать и будут обращаться за данными к СХД на NORD.
Заказчик сравнил решения по показателям RTO и выбрал катастрофоустойчивое облако, так как в худшем сценарии выгода от более дешевого решения не покрывала бы убытки.
Решение | RTO |
---|---|
vCDA | 30 минут |
Катастрофоустойчивое облако | 2-2,5 минуты |
Однако архитектура катастрофоустойчивого облака не позволяла развернуть кластер между on-premise-площадкой и ЦОДом DataLine. Для перехода на это решение была нужна миграция. Заказчик опасался, что из-за переезда в облако сайт снова будет недоступен. Инженеры DataLine предложили использовать в качестве инструмента тот же vCDA. Это решение подходит для миграции и раньше уже помогало перевезти инфраструктуру заказчика в облако с минимальным простоем.
Инженеры DataLine настроили сетевую связность между облаком и инфраструктурой клиента. Для миграции выбрали время, когда нагрузка на сайт банка минимальная. Сначала в системе создали тестовое задание на перенос инфраструктуры и убедились, что сценарий работает корректно. Затем запланировали 15 минут на миграцию и недоступность приложения, предупредили пользователей и благодаря отработанному сценарию уложились в срок.
Архитекторы DataLine вместе с заказчиком разработали план для послеаварийного восстановления. В документе подробно описали порядок действий при аварии, согласовали последовательность восстановления сервисов и зафиксировали RTO, за который несут ответственность инженеры DataLine.
План помог зафиксировать ответы на возможные вопросы при сбое: как заказчик поймет, что произошла авария, кто и как займется восстановлением сервисов, кто и как будет информировать клиентов.
Затем провели тестирование DR-плана, чтобы убедиться в корректной работе всех служб.
В 60 раз сократилось время на восстановление. |
Система будет работать с минимальным простоем, даже если одна из площадок выйдет из строя. Финансовую ответственность за соблюдение RTO несет DataLine.
У сотрудников есть пошаговый сценарий действий для наиболее вероятных нештатных ситуаций.