«Высокая доступность часто сводится к резервному железу, но её суть — протоколы согласования между компонентами. Это архитектурная философия, где каждый элемент должен быть готов к выходу из строя. В России к этому добавляется слой регуляторных требований, где техническое решение не имеет смысла без доказуемого соответствия. Проектирование в этой среде требует двойной экспертизы: инженерной и юридической.»
Устранение единых точек отказа
Основу проектирования составляет методичный поиск единых точек отказа (SPOF). Часто опасность скрыта не в серверах, а в сервисных зависимостях. Единый сервер Kerberos для аутентификации, один источник времени NTP, централизованное хранилище секретов для контейнеров — всё это потенциальные точки сбоя. Риск возникает и на организационном уровне, когда восстановление зависит от знаний одного человека.
Решение — внедрение избыточности, но не простое дублирование. Необходимы функционально завершённые, независимые пути. Например, подключение к двум разным операторам связи через физически разделённые вводы в здание, с автоматическим переключением через BGP. Или использование распределённой СУБД с синхронной репликацией между дата-центрами, где каждый может обслуживать полный поток запросов.
Для систем, попадающих под 152-ФЗ, отсутствие резервирования становится не архитектурным просчётом, а нарушением закона. Требования к непрерывности прямо прописаны в нормативных документах, устанавливающих конкретные уровни резервирования. Здесь избыточность — юридическая обязанность, проверяемая при аттестации.
Отказоустойчивость: сбой как штатная ситуация
Отказоустойчивость — это свойство системы поглощать внутренние сбои без видимой для пользователя потери функциональности. Её реализация строится на нескольких ключевых паттернах:
- Кластеризация с автоматическим failover: узлы обмениваются сигналами жизни. При отказе активного узла резервный автоматически перенимает его функции, минимизируя время восстановления.
- Балансировка с проверками здоровья: балансировщик отправляет health checks к backend-серверам. Инстанс, не отвечающий на запросы, немедленно исключается из ротации.
- Устойчивые шаблоны на уровне приложения: retry-логика с экспоненциальной отсрочкой, асинхронные очереди для развязки компонентов, Circuit Breaker для изоляции проблемных зависимостей.
- Декомпозиция на независимые сервисы: переход от монолита к сервис-ориентированной или микросервисной архитектуре позволяет локализовать сбой.
Для объектов критической информационной инфраструктуры (КИИ) эти паттерны закреплены нормативно. Требуется «горячее» резервирование с регламентированным временем переключения, которое проверяется на регулярных учениях. Показатели RTO и RPO должны быть формализованы и привязаны к бизнес-процессам.
Устойчивость к деградации и атакам
Если отказоустойчивость отвечает за внутренние сбои, то устойчивость — за сопротивление внешним нагрузкам: DDoS-атакам, физическому повреждению или масштабным сетевым сбоям. Она строится на принципах дисперсии, избыточности и изоляции:
- Географическая и административная дисперсия: узлы размещаются в разных регионах, на площадках с независимыми источниками питания и каналами связи. Это защищает от локальных катастроф.
- Сетевой запас и многоуровневая фильтрация: резерв пропускной способности, scrubbing-центры, DDoS-защита на уровнях сети и приложения.
- Регулярное тестирование планов аварийного восстановления: сценарии должны отрабатываться в условиях, максимально приближённых к реальным, включая отключение целых площадок.
- Жёсткая сегментация сети: разделение на сегменты (DMZ, внутренняя сеть, сегмент БД) со строгими ACL. Взлом одного сегмента не должен открывать доступ ко всей инфраструктуре.
С точки зрения регулятора, устойчивость требует формализованного процесса управления инцидентами. План реагирования (IRP), интегрированный с системами мониторинга SIEM/SOC, является обязательной частью системы защиты информации по 152-ФЗ и проверяется при аттестации.
Интеграция с требованиями ФСТЭК и 152-ФЗ
Проектирование под регулирование — это параллельная разработка технической архитектуры и пакета доказательной документации. Каждое техническое решение должно иметь нормативное обоснование.
| Область проектирования | Техническая реализация | Нормативное требование / обоснование |
|---|---|---|
| Размещение инфраструктуры | Оборудование в аттестованном ЦОД не ниже 2-го класса защищённости. Контроль физического доступа с журналированием. | Требования к защите помещений для КИИ (Приказ ФСТЭК № 17, РД 06-82-2016). Обязательно для систем 1-2 ГИС. |
| Документирование архитектуры | Детализированные диаграммы потоков данных и резервирования. Формализованные показатели доступности (SLA), RTO, RPO. | Состав эксплуатационной документации по РД 06-82-2016. Необходимо для аттестации и анализа рисков по 152-ФЗ. |
| План восстановления и непрерывности | «Живой» документ с runbook, интегрированный с системами оркестрации. Регулярные тесты с отчётами. | Обязательный элемент СЗИ по ст. 16 152-ФЗ. Проверяется при аттестации и плановых контролях. |
| Обеспечение связи | Минимум два независимых канала от разных операторов, с разделёнными вводами. Мониторинг и автоматическое переключение. | Требование по резервированию каналов связи (п. 15 Приказа ФСТЭК № 714). Критерий при оценке мер защиты. |
| Управление доступом и аудит | Централизованное управление учётными записями с двухфакторной аутентификацией для привилегированных доступов. Полное журналирование. | Требования к разграничению доступа и регистрации событий (Приказ ФСТЭК № 21). Основа для выявления инцидентов. |
Соответствие — не статичный статус, а циклический процесс. Внутренний контроль должен регулярно проверять работоспособность механизмов failover, актуальность документации и проводить учения по восстановлению.
Итоги
Высокая доступность в регулируемой среде — это синтетическая дисциплина, где инженерия встречается с бюрократией. Архитектура, лишённая единых точек отказа, обладающая отказоустойчивостью и устойчивостью к внешним угрозам, служит двойной цели: обеспечивает непрерывность бизнеса и формирует фундамент для успешного прохождения проверок.
Итоговый результат — инфраструктура, которая воспринимает сбои как штатный режим работы. Поддержание такого состояния требует постоянных инвестиций: в оборудование и софт, в регулярное тестирование, обновление документации и обучение персонала. В конечном счёте система высокой доступности превращается из центра затрат в ключевой актив, страхуя бизнес от простоев и финансовых потерь.