Иллюзия контроля
Многие компании и сегодня живут с иллюзией, что для спокойствия и защиты от киберрисков нужен лишь хороший антивирус и резервная копия на диске. Но 2025 год разбил эти иллюзии, показав, что старые подходы больше не работают. Там, где на защиту бизнеса тратятся миллиарды, системы всё равно дают критические сбои, и происходит это далеко не всегда по вине внешних злоумышленников.
Примеров катастроф 2025 года довольно много. В октябре произошел глобальный сбой в одном из дата-центров Amazon Web Services. Причина — несинхронизированная работа двух автоматических программ в системе управления DNS.
Сервис базы данных DynamoDB стал недоступен, и последовал необратимый каскадный отказ, остановивший сервисы EC2 (те самые облачные сервисы Amazon) и сетевые балансировщики нагрузки. Пострадали не только мессенджеры и игровые сервисы, но и крупные финансовые учреждения Европы, критически зависимые от технических решений этого поставщика. Подобные «каскадные» сбои редки, но практически неизбежны в масштабных инфраструктурах из-за их колоссальной сложности и взаимозависимостей.
Российский бизнес в 2025 году столкнулся с не меньшими проблемами. В июле хакерские группировки атаковали Аэрофлот — более ста рейсов было отменено или задержано, а число пострадавших пассажиров составило несколько тысяч человек. Почти одновременно от действий злоумышленников пострадала аптечная сеть «Столички», где перестали работать кассы и системы учета. Не успели отзвучать новости об этих происшествиях, как масштабный сбой произошел у оператора экспресс-доставки СДЭК, оставив тысячи клиентов без возможности отслеживать грузы. По данным аналитиков, 65% компаний после таких инцидентов фиксируют потерю доверия клиентов, а средний ущерб от одного сбоя в России достигает уже 2 млн рублей.
Почему бизнес недооценивает риски и что с этим делать
Популярный инструмент защиты — страхование на случай перерыва в деятельности (Business Interruption) — покрывает лишь малую толику прямых финансовых потерь. Кроме того, многие компании экономят и не покупают страховые полисы непрерывности: страхование не компенсирует ушедших клиентов, репутационный урон и разрушенное доверие партнеров. Главная ловушка здесь — ошибка в расчете совокупной стоимости владения. Создание отказоустойчивой инфраструктуры с распределенными центрами обработки данных, гибкой архитектурой и регулярным тестированием планов непрерывности бизнеса может показаться непомерно дорогим. Но реальность такова, что эта цена почти всегда оказывается несопоставимо ниже, чем издержки от остановки производственной линии или потери рыночной доли.
Что же делать? Во-первых, четко определить критичные сервисы, от которых зависит само существование бизнеса, и защищать их в первую очередь. Использовать инструменты анализа рисков и угроз, применяя их к существующим процессам и IT-инфраструктуре.
Во-вторых, перестать гадать и начать измерять: зафиксировать целевое время восстановления после сбоя (RTO) и допустимый объем потери данных (RPO). В-третьих, проектировать устойчивую архитектуру. И, наконец, внедрять искусственный интеллект в управление рисками. ИИ способен постоянно мониторить системы, симулировать сценарии отказов и даже автоматически переключать нагрузку на работающие мощности в момент сбоя, сводя время простоя к нулю.
Статистика, кстати, здесь плохой помощник: в первом квартале 2025 года более половины сбоев в крупных российских компаниях произошли именно из-за технических отказов оборудования и ошибок при обновлениях. Это значит, что бизнес ломается не только из-за внешнего влияния, но и из-за собственной неготовности. Самый дорогой план — тот, что ни разу не тестировали.
Международные стандарты
Фундамент такой работы закладывается не интуицией, а проверенными мировыми стандартами. Главный для IT-компаний — это ISO 22301. Этот стандарт задает требования к системе менеджмента непрерывности бизнеса (BCMS). Он охватывает полный цикл: от политики и анализа рисков до разработки планов восстановления, регулярного тестирования и постоянного улучшения. Ключевое требование ISO 22301 — организация должна не просто иметь документы, но и доказывать, что система работает, например, через внутренние аудиты и учения.
Дополняют его два других стандарта. ISO 31000 дает общие принципы управления любыми рисками, включая идентификацию, оценку и обработку, и служит надстройкой для принятия решений на всех уровнях. ISO 27001, обновленный в 2025 году, фокусируется на информационной безопасности. В новой версии усилились требования к киберустойчивости, управлению инцидентами и защите данных в облаках. Вместе эти три стандарта образуют каркас: ISO 31000 определяет «как думать о рисках», ISO 27001 — «как защищать данные и IT-активы», а ISO 22301 — «как продолжать работать, когда что-то пошло не так».
Непрерывный цикл PDCA
Но стандарты — это лишь фундамент. Сама система непрерывности строится как последовательный и повторяющийся процесс, известный как цикл PDCA (Plan-Do-Check-Act), то есть «Планируй-Делай-Проверяй-Действуй».
Этап 1. Plan (Планируй). Здесь вы отвечаете на несколько главных вопросов.
Сначала проводите анализ рисков (Risk Assessment). Какие киберугрозы для вас реальны: DDoS, шифровальщик, утечка данных через подрядчика? Оцените вероятность и последствия. Не пытайтесь учесть всё — сфокусируйтесь на том, что может остановить бизнес или привести к огромным штрафам.
Затем проводите анализ воздействия на бизнес (Business Impact Analysis, BIA). Допустим, сайт или система приема заказов упала. Через какое время начнутся ощутимые потери? Сколько компания теряет в час? Именно BIA определяет для каждого критичного сервиса RTO и RPO. Например, для интернет-магазина RTO может быть 2 часа, RPO — 15 минут. Для бухгалтерской отчетности RTO — сутки, RPO — 1 час.
После этого вы разрабатываете сценарии конкретных инцидентов: сбой ЦОД, атака на Active Directory, ошибка при обновлении ERP. По каждому сценарию пишете план восстановления (BCP/DRP) — не общие фразы, а пошаговые инструкции: кто звонит, кто переключает трафик, у кого есть доступ к резервным ключам.
Этап 2. Do (Делай). Это реализация планов и регламентов. Вы закупаете оборудование, настраиваете резервные каналы, обучаете сотрудников. Но главное — вы не просто пишете документы, а внедряете их в повседневную практику: например, закрепляете ответственных, проводите первоначальное обучение, интегрируете планы в систему управления инцидентами.
Этап 3. Check (Проверяй). Это не про «посмотрели и успокоились» — речь о регулярных тестированиях. Начинайте с настольных учений: команды проигрывают сценарий за столом, выявляя нестыковки в инструкциях и коммуникации. Затем переходите к функциональным тестам: в изолированной среде проверяете, реально ли восстановить базу данных из резервной копии за заявленные RTO и RPO. И финальный уровень — полноценные практические учения, максимально приближенные к реальной атаке. После каждого теста фиксируйте, что не сработало и почему.
Этап 4. Act (Действуй/улучшай). На основе результатов проверок вы корректируете планы, меняете настройки, пересматриваете метрики. Например, если тест показал, что восстановление занимает 4 часа вместо целевых двух, вы ищете узкое место: допустим, неотработанные действия оператора, отсутствие доступа к резервному дата-центру. Вносите изменения и снова запускаете цикл. PDCA никогда не заканчивается — система должна жить и эволюционировать вместе с угрозами и бизнесом.
Только после нескольких полных циклов PDCA можно сказать, что вы выстроили устойчивую систему управления рисками.
