В июле 2025 года сотни вылетающих из аэропортов пассажиров оказались в затруднительном положении — хакеры парализовали ИТ-инфраструктуру российской авиакомпании. По оценкам ущерб мог составить не менее 250 миллионов рублей только от отмены рейсов, не считая затрат на восстановление систем и репутационных потерь. Казалось бы, любая крупная система должна быть готова к сбоям, но на практике часто обнаруживается разрыв между отказоустойчивостью и катастрофоустойчивостью.
Разобраться, как отличать отказоустойчивость от катастрофоустойчивости и почему эти подходы нельзя подменять друг другом, помогает Владимир Маракшин, директор департамента стратегического развития компании «Киберпротект».
Два подхода: в чем разница
Современные ИТ-системы работают в режиме 24/7. Даже один час простоя способен обернуться серьезными финансовыми потерями и репутационными рисками. Ошибка в понимании различий между отказоустойчивостью и катастрофоустойчивостью создает ложное ощущение защищенности: компания уверена в надежности инфраструктуры, пока не сталкивается с реальным кризисом.
Хакерская атака может наступить внезапно и способна парализовать все бизнес-процессы, принеся в итоге сотни миллионов рублей убытков. Чтобы подготовиться к таким «черным лебедям», важно различать два подхода.
Отказоустойчивость
Так называют свойство системы продолжать работу после отказа одного или нескольких компонентов. Отказоустойчивость обеспечивает бесперебойность работы в моменте, служит чем-то вроде «подушки безопасности» для локальных сбоев.
Пример: один из серверов базы данных крупного интернет-магазина в пиковый час продаж внезапно выходит из строя из-за аппаратного или программного сбоя. Но покупатели этого не замечают, так как система автоматически переключает нагрузку на резервный узел в кластере. Это происходит либо моментально, либо с незначительным простоем. Заказы продолжают обрабатываться, платежи проходят, бизнес не теряет ни минуты.
Отказоустойчивая архитектура призвана нивелировать единичные сбои.
Катастрофоустойчивость
Это способность системы возобновить работу после разрушительного воздействия, затронувшего всю инфраструктуру или же значительную ее часть. Здесь речь не о моментальном, но все же быстром восстановлении работы с минимальными потерями.
Пример: основной дата-центр логистической компании в Москве полностью выходит из строя после масштабной кибератаки. Локальные резервные копии тоже повреждены, но месяц назад ИТ-директор запустил резервный ЦОД в Казани с полной репликацией данных. Через два часа система возобновляет работу с резервной площадки. Клиенты временно потеряли доступ к данным, но ключевые процессы были восстановлены в допустимые для бизнеса сроки.
Таким образом, отказоустойчивость предотвращает остановку от единичного сбоя, а катастрофоустойчивость обеспечивает восстановление после полного уничтожения основной инфраструктуры.
Комбинация подходов: как подготовиться к худшему сценарию
Чтобы инфраструктура выдерживала инциденты, отказоустойчивость и катастрофоустойчивость должны работать как взаимодополняющие уровни защиты.
Первый обеспечивает бесперебойность в моменте, второй — восстановление при масштабном сбое или полном отключении значимой логической единицы ИТ-ландшафта. Без одного из уровней система реагирует на локальные сбои простоем, без другого — крупный инцидент оборачивается длительной недоступностью сервисов, а также, возможно, потерей данных, которая окажется невосполнимой. В связке оба подхода формируют стратегию непрерывности бизнеса.
Аудит, классификация критичных систем и оценка рисков
Начинать нужно с инвентаризации. Определите, какие бизнес-процессы, системы и наборы данных критичны для компании: ERP, CRM, интернет-платежи, процессинг, системы управления производством — ориентируйтесь на влияние на выручку, обязательства перед клиентами и регуляторные требования.
Присвойте уровень критичности: высокий, средний, низкий. Для высокого уровня час простоя уже несет существенные потери; для среднего — допустима кратковременная деградация; для низкого — возможно плановое восстановление. Зафиксируйте две целевые метрики:
- RTO — максимально допустимое время простоя (например, для онлайн-платежей — минуты, иначе страдают доход и доверие клиентов).
- RPO — максимально допустимая потеря данных. Для транзакционного контура в финансах она стремится к нулю, для аналитики — допустимы часы.
Эти параметры переводят риски в требования к архитектуре. После фиксации метрик — обязательно наладить процесс по их регулярной верификации фактически, подтверждая готовность ИТ-инфраструктуры отвечать требованиям бизнеса.
Назначьте команду восстановления с ролями, зонами ответственности и уровнями доступа. Обеспечьте доступ к управлению, независимые каналы связи, резервные учетные записи, бумажные инструкции на случай недоступности сервисов идентификации и почты. Команда должна иметь доступ к средствам восстановления даже при отказе базовой инфраструктуры.
Планирование отказоустойчивости
Базовый принцип тут — избыточность. Кластеризация компонентов инфраструктуры распределяет нагрузку между несколькими узлами, либо же резервирует определенные узлы для обработки сбоя: отказ одного узла в таком случае не мешает обработке запросов.
Балансировщики на сетевом и прикладном уровнях направляют трафик на доступные узлы и выравнивают перегрузки. Дублируйте критичные компоненты: источники питания и вводы, сети и провайдеров, системы охлаждения — все с физическим разнесением трасс, чтобы избегать единой точки отказа.
Виртуализация упрощает миграцию нагрузок в случае сбоя: виртуальные машины переносятся между хостами, новые серверы легко развернуть из заранее подготовленных шаблонов и образов.
Резервное копирование должно работать непрерывно и незаметно, со связкой «immutable-копии + геораспределенное хранение для снижения риска компрометации при различного рода атаках, в том числе программ-вымогателей («шифровальщиков»). Частота задач по каждой системе определяется ее RPO: для критичных данных — чаще, для вспомогательных — реже, а также иными способами обеспечения этих метрик и спецификой ИТ-решения.
Планирование катастрофоустойчивости
Катастрофоустойчивость нужна, когда недоступна вся площадка. Резервный дата-центр в другом регионе проектируется с достаточной емкостью (RCO — Recovery Capacity Objective) для поднятия критичных сервисов в заданные RTO.
Пример: если основной центр в одном городе недоступен из-за киберинцидента, пользовательский трафик и работа бизнес-пользователей переносится на резервную площадку исходя из заданных приоритетов и критичности.
Репликация данных между регионами в большинстве случаев асинхронная — это обеспечивает приемлемую производительность при RPO>0. Когда для отдельных контуров нужен близкий к нулю RPO, реализуют геораспределение сервисов в рамках одного города или ближайших городов и используют синхронную репликацию, требовательную к малой сетевой задержке. Многоуровневое резервное копирование дополняет репликацию:
- локальные копии для быстрого восстановления;
- удаленные/облачные — от локальных катастроф;
- офлайн-носители — от компрометации цепочки бэкапа.
План аварийного восстановления (DRP) — это алгоритм, учитывающий, кто и в какой последовательности действует в первые минуты, какие сервисы поднимаются первыми, как переключается трафик, как проводится проверка целостности и отката. Документ должен регулярно проверяться практикой — в реальном прогоне всплывают организационные и технические «узкие места».
Интеграция подходов
Эффект достигается при объединении мер в единую операционную модель. Единый мониторинг охватывает основные и резервные площадки и четко различает сценарии локальных отказов и катастроф. Автоматизация переключения между площадками позволяет укладываться в целевые RTO — от минут до десятков минут, в зависимости от класса системы и заданных уровней обслуживания.
Централизованное управление дает целостную картину состояния и ускоряет принятие решений. Совместимость решений обязательна: мониторинг должен «видеть» сигналы всех компонентов, резервное копирование — корректно работать с виртуальной и физической инфраструктурой, процедуры восстановления — учитывать особенности каждой системы.
Постоянный мониторинг, контроль и тестирование
Однако даже идеальная схема не работает без проверки. Минимальный регламент: ежеквартально проверять механизмы отказоустойчивости (падение узлов, отказ сети, деградацию дисков), раз в год — полноформатный DR-тест с переключением на резервный ЦОД и обратным возвратом.
Для контуров повышенного риска частоту увеличивают в соответствии с внутренними SLA. В тестах намеренно создавайте отказные ситуации и проверяйте: время переключения, целостность данных, корректность приложений после фейловера.
Круглосуточный мониторинг отслеживает ключевые метрики: загрузку ресурсов, задержки и ошибки приложений, состояние сетевых подключений, объемы хранилищ, статус резервного копирования. Любые отклонения должны быстро эскалироваться ответственным. После каждого инцидента составляйте post-mortem — подробный отчет с информацией об инциденте, причинах, следствиях и наборе превентивных мер. Обновляйте процессы и документацию вместе с изменениями инфраструктуры и сервисов — иначе в критический момент план окажется устаревшим.
Резюме
История с кибератакой на крупные компании в этом году показывает, что даже компании с многомиллиардными бюджетами на ИТ могут оказаться беззащитными перед масштабными угрозами. Комплексное внедрение инструментов для обеспечения отказо- и катастрофоустойчивости требует значительных инвестиций и системного подхода. Но цена бездействия может оказаться куда выше — полная остановка бизнеса, потеря клиентов, репутационный крах.
Современные российские решения для резервного копирования и защиты данных позволяют построить надежную защиту от большинства угроз. Системы поддерживают работу с инфраструктурами любых размеров и сложности, что делает защиту доступной как для крупных корпораций, так и для средних компаний.
Главный принцип: надейтесь на лучшее, но готовьтесь к худшему. Отказоустойчивость защитит от ежедневных проблем, катастрофоустойчивость — от кошмарных сценариев. Только объединив оба подхода, можно создать действительно надежную ИТ-инфраструктуру, способную выдержать любые испытания.