Fault Tolerance (Отказоустойчивость)

Fault tolerance — это свойство IT-системы сохранять работоспособность даже при частичном отказе оборудования, программных компонентов или каналов связи. Иными словами, отказоустойчивая система продолжает функционировать корректно, несмотря на сбои отдельных узлов или сервисов.

Это критически важная характеристика для бизнес-приложений с высокими требованиями к доступности: финансовые платформы, медицинские системы, облачные среды, дата-центры и любые сервисы, работа которых влияет на непрерывность бизнеса.

---

Как достигается отказоустойчивость:

• Дублирование компонентов — резервные серверы, диски, сетевые каналы, БП, кластеры;
• Автоматическое переключение (failover) — мгновенный переход на резерв при сбое основного;
• Механизмы самовосстановления (self-healing) — автоматический перезапуск, репликация, перемаршрутизация;
• Распределённая архитектура — отсутствие единой точки отказа (no SPOF);
• План управления отказами — мониторинг, SLA, recovery procedures, алерты.

---

Примеры реализации:

• В дата-центрах: серверы с резервными БП, RAID-массивами, двойными сетевыми интерфейсами, дублированными каналами связи;
• В Kubernetes: ReplicaSet, StatefulSet, node pools в разных зонах, PDB, autoscaling;
• В облаке: Multi-AZ развертывания, глобальные балансировщики нагрузки, отказоустойчивые базы данных (Aurora, Cosmos DB, Cloud Spanner);
• В приложениях: circuit breakers, retry-политики, graceful degradation.

---

Почему это важно:

• Непрерывность бизнес-процессов — даже при частичных сбоях пользователи не сталкиваются с недоступностью;
• Соответствие SLA и регуляторным требованиям — особенно в финансовом, телеком и госсекторе;
• Снижение потерь от простоев — каждая минута недоступности может стоить компании значительных убытков;
• Устойчивость к внешним и внутренним инцидентам — сбои оборудования, ошибки операторов, атаки, сбои в сети.

---

Отказоустойчивость — это не одно решение, а комплексная архитектурная стратегия. Она строится на избыточности, автоматизации и чётком понимании сценариев отказов. Именно на этой базе строятся системы, которые «не падают» — даже тогда, когда ломается всё вокруг.

---

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

Active-Passive

• Один узел активно обрабатывает трафик, другой находится в резерве.
• При сбое активного узла происходит автоматическое переключение (failover).
• Пример: PostgreSQL с Patroni + Etcd или AWS RDS Multi-AZ.

Active-Active

• Несколько узлов работают одновременно и равномерно распределяют нагрузку.
• Высокая производительность, горизонтальное масштабирование, балансировка нагрузки.
• Пример: Kafka в кластерной конфигурации, Kubernetes ReplicaSet, Redis Cluster.

Geo-Redundant

• Компоненты системы дублируются в разных регионах или странах.
• Защита от катастроф на уровне целых дата-центров.
• Пример: AWS Route 53 с geo failover, Azure GRS-хранилище, глобальные CDN.

---

Конфигурации отказоустойчивости

1. PostgreSQL (Active-Passive) с Patroni

• Patroni следит за состоянием leader’а;
• Etcd/Consul — источник кластерного состояния;
• HAProxy — переключает клиентов на актуального мастера;
• При сбое — failover за 2–10 секунд.

2. Kafka (Active-Active)

• Каждый partition имеет лидера и реплики;
• Продюсеры пишут в лидера, консюмеры читают по согласованным стратегиям;
• При падении лидера — Kafka автоматически переносит leadership на реплику.

3. DNS Failover (AWS Route 53)

Копироватьresource "aws_route53_record" "failover" {
  name    = "app.example.com"
  type    = "A"
  ttl     = 60
  records = [aws_instance.primary.public_ip]
  failover = "PRIMARY"
  set_identifier = "main"
  health_check_id = aws_route53_health_check.primary.id
}

📌 При недоступности IP по health check — Route 53 автоматически отдаёт вторичный IP.

---

Как тестировать отказоустойчивость (chaos engineering)

Chaos Engineering — практика преднамеренного создания сбоев для проверки реакции системы. Примеры:

• Kill pod:
  Копироватьkubectl delete pod <name>
  — проверка перезапуска и балансировки.
• Simulate node failure: выключение VM или физического узла.
• Chaos Mesh / Litmus: специализированные фреймворки для Kubernetes.
• Gremlin / Steadybit: коммерческие платформы для сценариев отказа, latency injection, потери пакетов и пр.

---