====== Механизмы устойчивости и отказоустойчивые сценарии ======

Раздел описывает подходы к обеспечению **непрерывной устойчивости (resiliency)** и механизмам **самовосстановления** в программно-определяемых средах (SDE).  
Такая архитектура позволяет поддерживать доступность сервисов даже при аппаратных сбоях, ошибках ПО и кибератаках.

===== Концепция и цель =====
В программно-определяемом ЦОДе устойчивость измеряется не только временем безотказной работы, но и способностью системы:
  * предотвращать сбои на ранней стадии;
  * локализовать последствия отказа;
  * восстанавливаться автоматически без вмешательства человека.

Для этого используется подход **риск-корректированной эффективности** — оценка стоимости услуги учитывает вероятность сбоя и возможные потери:

<WRAP center>
$$
\text{Эффективность} = \text{Ценность услуги} - (\text{Стоимость сбоя} \times \text{Риск отказа})
$$
</WRAP>

<WRAP info>
Такой подход позволяет соотносить экономику ЦОДа с реальным риском недоступности и оптимизировать инфраструктуру не только по скорости и нагрузке, но и по устойчивости.
</WRAP>

===== Основные уязвимости и вызовы =====
<WRAP important>
  * **Многослойная виртуализация** усложняет контроль и делает традиционный мониторинг менее эффективным.  
  * **Динамическая привязка ресурсов** (создание и удаление виртуальных узлов «на лету») затрудняет аудит и отслеживание инцидентов.  
  * **Абстрагирование ресурсов** может скрывать реальные различия в их надёжности и безопасности.  
</WRAP>

===== Архитектура системы устойчивости =====
SDE реализует сквозную схему наблюдения и реагирования, основанную на машинном обучении, глубокой телеметрии и автоматической оркестрации.

<WRAP box round>
**Модель обеспечения устойчивости**
<mermaid>
flowchart TB
  classDef big font-size:12px,stroke-width:1.2px,padding:10px;

  ML["Модели поведения (обучение, прогнозирование)"]:::big --> Assurance["Модуль анализа и принятия решений"]:::big
  Assurance --> Orchestration["Оркестратор восстановления и защиты"]:::big
  Orchestration --> Workloads["Нагрузки и контейнеры (тонкая изоляция)"]:::big
  Workloads --> Deep["Глубокий анализ (агенты, мониторинг, телеметрия)"]:::big
  Deep --> ML
  Assurance --> Policies["Политики и правила реагирования"]:::big
  Policies --> Assurance
</mermaid>
</WRAP>

===== Основные механизмы =====
1. **Тонкая изоляция.**  
   Использование контейнеров и микросервисов позволяет ограничить зону сбоя. Ошибка одного сервиса не влияет на другие.

2. **Глубокий анализ.**  
   Внедрение агентов (зондов) для сбора телеметрии с гипервизоров, ВМ, приложений и сетевых компонентов.

3. **Моделирование поведения.**  
   На основе накопленных данных формируются модели нормального функционирования систем, пользователей и сетей. Отклонения выявляются до наступления отказа.

4. **Проактивное тестирование отказов.**  
   Используется «инъекция сбоев» (chaos engineering) для проверки способности среды выдерживать частичные отказы без потери доступности.

5. **Политико-ориентированное реагирование.**  
   Нарушения оцениваются по заранее заданным правилам — например, на основе требований SLA или нормативов по защите данных.

6. **Самовосстановление и коррекция.**  
   При выявлении инцидента система формирует гипотезу о причине, выбирает корректирующие действия и выполняет их автоматически (перезапуск, миграция, изоляция).

7. **Интеллектуальная оркестрация.**  
   Оркестратор управляет балансировкой, переключением потоков, обновлением контейнеров, перераспределением вычислительных ресурсов и сетевых маршрутов.

<WRAP tip>
Совокупность этих механизмов обеспечивает **самообучающуюся инфраструктуру**, где каждый инцидент повышает точность предсказаний и ускоряет восстановление при будущих сбоях.
</WRAP>

===== Отказоустойчивые сценарии =====
  * **Автоматическая миграция** нагрузок при сбое узла или зоны.  
  * **Изоляция заражённых контейнеров** без остановки системы.  
  * **Перезапуск микросервисов** при выявлении некорректного состояния.  
  * **Рандомизация сетевых маршрутов** для снижения вероятности атак.  
  * **Восстановление образов** при повреждении инфраструктуры.  
  * **Перенос нагрузки между площадками** при потере связи или отключении сегмента.

<WRAP info>
Сценарии реализуются в рамках заранее определённых политик — например, SLA по времени восстановления (RTO) и допустимой потере данных (RPO).  
Система анализирует контекст события и выбирает оптимальный план действий.
</WRAP>

===== Ключевые идеи =====
<WRAP tip>
- Устойчивость — это не свойство железа, а программно управляемый процесс.  
- Контейнеризация и микросервисы обеспечивают локализацию сбоев.  
- Машинное обучение помогает прогнозировать и предотвращать отказы.  
- Самовосстановление и оркестрация минимизируют человеческий фактор.  
- Цель — непрерывная работа ЦОДа при любых условиях.
</WRAP>