Экономика катастрофоустойчивости: как защитить ИТ-инфраструктуру без переплат
- 2 мин.
В одной из своих колонок на РБК я рассказывал о стратегическом подходе к катастрофоустойчивости бизнеса. Однако за рамками той публикации остался прикладной технический контекст, а ведь именно он определяет повседневные решения ИТ-директоров и руководителей инфраструктуры.
Масштаб проблемы сегодня измеряется конкретными цифрами. По оценкам аналитиков BI.ZONE, совокупный ущерб крупного бизнеса от одной критической аварии ИТ-систем составляет от 6 млн до 50 млн руб. В таких высоконагруженных отраслях, как финтех, ритейл и логистика, один час простоя может стоить до 21 млн руб. При этом наряду с финансовыми потерями в структуру убытков всегда входят штрафы за нарушение SLA, оплата простоя линейного персонала и экстренные бюджеты на ручное восстановление упавших систем.
Чтобы минимизировать эти риски, бизнесу необходимо точно просчитать экономику отказоустойчивости. Ниже я подробно разберу, как соотносятся между собой популярные технологии резервирования, и предложу готовый алгоритм внедрения облачного аварийного восстановления (DRaaS).
Как выбрать модель защиты для ИТ-инфраструктуры
Планирование ИТ-расходов должно быть прагматичным, для каждой системы подбирается свой уровень защиты и своя модель затрат. Распространенная ошибка — путать полноценную катастрофоустойчивость (Disaster Recovery) с обычным резервным копированием (бэкап). В условиях реальной аварии такая «экономия» оборачивается многодневным простоем.
- Классический бэкап: обеспечивает сохранность информации, но не гарантирует непрерывность работы ИТ-сервисов. При масштабном сбое ИТ-инфраструктуру приходится разворачивать и настраивать с нуля.
- Disaster Recovery: защищает от простоев, но требует от компании содержания второй физической площадки и закупки оборудования. Это превращает катастрофоустойчивость в тяжелую статью капитальных затрат (CAPEX).
- DRaaS: за счет непрерывной репликации сохраняет актуальные данные и держит в облаке готовую к запуску копию ИТ-среды, обеспечивая быстрое переключение процессов при отказе систем.
Сравнение ключевых параметров всех трех подходов приведено в таблице
| Резервное копирование (бэкап) | Disaster recovery | DRaaS | |
|---|---|---|---|
| Объект защиты | Только данные (файлы, базы) | Данные + конфигурация систем | Данные + конфигурация систем |
| Время восстановления (RTO) | От нескольких часов до дней | Минуты – часы | Минуты (автоматически) |
| Капитальные затраты (CAPEX) | Минимальные | Высокие (закупка оборудования) | Нулевые (модель OPEX) |
| Резервная площадка | Сервер бэкапа / СХД | Собственный резервный ЦОД | Российское облако |
| Аварийное переключение (Failover) | Вручную | Частично автоматизировано | По нажатию одной кнопки |
Как видно из сравнения, именно облачная модель позволяет минимизировать время простоя без замораживания капитала в физической инфраструктуре.
Когда DRaaS необходим, а когда избыточен
Внедрение полноценной модели DRaaS оправдано далеко не всегда. DRaaS необходим, если:
- Стоимость часа downtime превышает 100 тыс. рублей.
- Действуют жесткие регуляторные требования или внешние обязательства по SLA, ограничивающие допустимое RTO четырьмя часами и менее.
- Строительство собственного резервного дата-центра экономически нецелесообразно или неосуществимо в текущих реалиях.
- ИТ-команда испытывает дефицит кадров и не обладает ресурсами для круглосуточного мониторинга и администрирования резервной площадки.
DRaaS избыточен, если:
- Бизнес допускает простой систем на сутки и более без потери критической выгоды — в этом сценарии достаточно зрелой политики резервного копирования.
- Организация уже располагает двумя собственными геораспределенными ЦОД с настроенной синхронной репликацией на уровне СХД.
- Архитектура приложений изначально проектировалась как cloud-native, геораспределенная и отказоустойчивая на уровне кода.
Финансовая модель DRaaS
Главный экономический бенефит DRaaS — глубокая оптимизация совокупной стоимости владения (TCO) за счет перевода затрат из CAPEX в OPEX. Вместо авансовых инвестиций в покупку серверов и СХД компания переходит на прозрачную сервисную модель.
В штатном режиме функционирования ИТ-ландшафта бизнес оплачивает только базовые инфраструктурные компоненты:
- Дисковое пространство в облаке провайдера для хранения регулярно обновляемых реплик (холодное хранение).
- Фиксированную стоимость лицензий ПО репликации за каждую защищаемую единицу (VM или bare-metal сервер).
Наиболее ресурсоемкие и дорогие вычислительные компоненты — vCPU и RAM — в резервном облаке в штатном режиме не выделяются и не оплачиваются. Они активируются провайдером динамически по запросу и тарифицируются строго по факту потребления (модель Pay-as-you-go): либо в моменты проведения плановых проверок планов восстановления, либо непосредственно при наступлении аварийной ситуации и инициации процедуры аварийного переключения (Failover).
Анатомия DRaaS
Надежный DRaaS полностью исключает человеческий фактор и хаос в момент инфраструктурного сбоя. Современные специализированные платформы автоматизируют сквозной цикл защиты данных, который делится на три технологические фазы:
1. Непрерывная репликация (Continuous Replication)
На уровне ОС или гипервизора разворачиваются легковесные агенты/модули, которые без деградации основной площадки отслеживают измененные блоки данных и с заданным интервалом RPO (например, каждые 15 минут) передают их в изолированный репозиторий целевого облака.
2. Аварийное переключение (Failover)
При фиксации аварии на основной площадке система запускает оркестрированный план аварийного восстановления. Платформа DRaaS автоматически разворачивает виртуальные машины в резервном облаке, монтирует реплицированные диски, применяет сетевые топологии и запускает сервисы в строго определенном порядке с соблюдением зависимостей приложений.
3. Обратное переключение (Failback)
После устранения причин аварии на основном контуре платформа инициирует контролируемый возврат процессов. Важно, что обратно передаются только те данные, которые были изменены и накоплены за время работы систем в резервном облаке. Процесс failback завершается консистентно, без дублирования транзакций и скрытых потерь в базах данных.
Ключевое преимущество DRaaS — доступность безопасного тестирования. Платформа позволяет по заранее отработанному сценарию развернуть точную копию инфраструктуры в изолированном сетевом контуре, благодаря чему компания может регулярно проводить аудит и тренировки команды без рисков для «продукта».
Как устроен DRaaS на стыке разных платформ
Ограничения в поддержке зарубежного софта вынудили крупный бизнес страховать свои инфраструктурные риски. Главными площадками для размещения резервных систем стали российские облака (Yandex Cloud, VK Cloud, Cloud.ru, MWS и Selectel).
Но просто арендовать мощности у провайдера — еще не значит гарантировать непрерывность процессов. Сегодня ИТ-ландшафт большинства предприятий стал гетерогенным: Современный DRaaS должен связывать наследуемые VMware-контуры, отечественные решения (zVirt, KVM, OpenStack) и ведущие публичные облака (включая Yandex Cloud, VK Cloud и Selectel).
Современная архитектура DRaaS — это сложный узел, который должен бесшовно связать эти разнородные среды. Поэтому ключевым критерием выбора технологии становится универсальность (подход any-to-any). Система должна уметь конвертировать форматы дисков и конфигурации виртуальных машин из одной среды в другую.
Платформа «Хайстекс Акура» ориентирована на такие кросс-платформенные сценарии. Софт полностью независим от конкретного «железа» или типа виртуализации. Программа осуществляет фоновую репликацию данных в реальном времени, автоматически перенося рабочие нагрузки из унаследованных контуров в новые отечественные среды или напрямую в публичные облака.
Такой подход позволяет крупному бизнесу гибко группировать свои сервисы, задавать для каждого из них индивидуальные метрики RTO и RPO и автоматизировать процессы аварийного переключения (Failover) и обратного перехода (Failback). Как результат — компания минимизирует риски при миграции и избавляется от зависимости от проприетарного софта.
4 шага к построению отказоустойчивой архитектуры
Чтобы минимизировать риски для операционной деятельности компании, внедрение DRaaS проводят по четкому сценарию, поэтому внедрение системы делят на четыре ключевых этапа:
Аудит систем и оценка простоя
Разделите ИТ-сервисы по значимости для бизнеса, назначьте ответственных и посчитайте цену часа простоя. В первую очередь защищают критичные системы — те, чья остановка более чем на 4 часа парализует продажи, производство или клиентский сервис.
Расчет метрик RTO и RPO
Установите для каждой группы систем жесткие рамки: время восстановления (RTO) и допустимый объем потери данных (RPO). Это защитит компанию от переплаты за максимальную скорость там, где она не нужна.
Выбор облачной площадки
Оцените не только тарифы облака, но и его совместимость с вашими технологиями. Новая платформа должна бесшовно стыковаться с текущей виртуализацией компании.
Тестовый запуск
Проверьте копирование данных и сценарий экстренного переключения нужно на второстепенных, некритичных сервисах. Такой пилот позволит измерить реальную скорость восстановления и найти скрытые проблемы.
Грамотное аварийное восстановление превращает любой сбой из катастрофы в понятный рабочий процесс. А поэтапный пилотный запуск позволяет развернуть защиту без риска для текущих сервисов.
Критерий выбора между подходами предельно прост: если бизнес способен безболезненно пережить сутки простоя, компании хватит грамотно настроенного бэкапа. Если же каждая минута паузы бьет по выручке и репутации — DRaaS часто оказывается наиболее рациональной моделью.