Архитектура для SLA ≥ 99.99%

Числовой ориентир. SLA 99.99% ≈ 0.01% простоя. Для 30-дневного окна: 30×24=720 часов → 720×60=43 200 минут; 0.0001×43 200 = 4.32 минуты простоя в месяц. Такой уровень требует системных решений по избыточности, быстрому failover и автоматизации.

Основные принципы проектирования

• Eliminate single points of failure на всех уровнях (network, compute, storage, control plane).

• Избыточность N+1 / active-active по зонам отказа; multi-region для защиты от катастроф.

• Разделение state и compute: приложения stateless, состояние — в управляемых, отказоустойчивых хранилищах.

• Автоматизация recovery: fast failover, health checks, autoscale, автоматические откаты.

• Измеримость: SLI/SLO, error budget, burn-rate алерты.

Компоненты и паттерны (практика)

1. **Edge / глобальная точка входа
   **

   • CDN + Global Load Balancer (latency/geo routing, health aware).

   • DDoS/WAF на границе.

2. **Региональные уровни (active-active по регионам)
   **

   • Global LB → региональные LBs → автоскейлинг группы инстансов / k8s кластеры.

   • Health checks + connection draining при выводе инстанса.

3. **Приложение
   **

   • Дизайн stateless (любой экземпляр обрабатывает запрос).

   • Session state вынесен в внешние store (Redis Cluster, managed session store) или JWT.

   • Idempotent endpoints и корректная обработка ретраев + exponential backoff.

4. **Данные и БД
   **

   • Для сильной согласованности: распределённые транзакционные СУБД с консенсусом (Spanner/CockroachDB) или leader + synchronous replicas для критичных writes.

   • Для высокой доступности с приемлемым RPO: асинхронные реплики + quick failover + регулярные тесты promote.

   • Архитектурные паттерны: read replicas, sharding, multi-region replication с учётом latency и конфликтов.

5. **Кэширование и очередь
   **

   • Кластеры Redis/Memcached с репликацией и автоматическим failover; распределённые очереди (Kafka с multiple brokers и replication).

   • Backpressure и rate limiting — чтобы зависимые системы не падали лавинообразно.

6. **Сеть и DNS
   **

   • Anycast / GSLB для быстрого маршрута; низкий TTL при DNS fallback (использовать осторожно).

   • Приватные сети, multi-AZ subnets, мониторинг сетевого health.

7. **CI/CD и релиз-стратегии
   **

   • Canary / blue-green и автоматический rollback по SLO-гейтам.

   • Миграции БД backward/forward compatible (expand/contract pattern).

Наблюдаемость и операции

• Full observability: metrics (Prometheus), traces (OpenTelemetry/Jaeger), logs (structured + centralized).

• SLO dashboards & error budget — видимость burn-rate и автоматические ограничения релизов.

• Synthetic checks + RUM — external probes и пользовательский опыт.

• Alerting на симптомы и burn-rate, не на шумные low-level сигналы.

• Runbooks, on-call, playbooks и регулярные drills (failover drills, chaos).

Backup, DR и recovery

• Политика 3-2-1: 3 копии, 2 разных носителя, 1 offsite.

• Immutable backups (WORM) для защиты от ransomware.

• Документированный DR-plan с RTO/RPO и проверками (test restores).

Тестирование и валидация

• Load testing, chaos engineering (network partition, AZ kill), failover drills и регулярные проверки readiness.

• Регулярная верификация автоматических failover сценариев и промоушена реплик.

Безопасность и соответствие

• KMS для ключей, centralized secrets (Vault/Cloud KMS), RBAC, аудит доступа.

• Защита control plane и CI/CD, изоляция управления от data plane.

Трэйд-оффы и экономия

• 99.99% требует затрат: multi-AZ/region ресурсы, репликация, лицензии и сложность. Оценить бизнес-импакт просто: сравнить стоимость реализации vs потенциальные потери при простое.

Операционные договорённости

• Чёткие SLO, поддерживаемые runbooks и SLA в контракте.

• Политика maintenance windows и прозрачные уведомления.

(Дизайн должен быть итеративно протестирован и верифицирован: метрики → тесты → автоматизация → обновления процедур.)