High Availability и SLA

High Availability и SLA

1) Termos e conexão com o negócio

O SLI (Service Level Indicator) é um indicador medível do serviço (por exemplo, o percentual de solicitações de sucesso 2xx/3xx ≤ T mc).
SLO (Service Level Objectiva) - Destino SLI (por exemplo, "99. 95% dos pedidos ≤ 300 ms").
SLA (Service Level Agreement) - obrigação contratual com o cliente (multas/créditos em caso de infração).
HA (High Availability) - Medidas arquitetônicas e operacionais que permitem a execução do SLO/SLA.

Princípio: SLA baseia-se em SLO e SLO em SLI observados. Não podes prometer no SLA o que não medes.

2) «Nove» e matemática de disponibilidade

Composição de disponibilidade

Cadeia sequencial (dependentes de «caminho vermelho»): 'A _ total = A _ i' (cada componente reduz o resultado).
Ativo-ativo paralelo de nódulos: 'A _ total = 1 -Joi (1 - A _ i)' (a reserva aumenta o resultado).

3) Exatamente o que medir (SLI correto)

Visão do usuário: concluir com sucesso as transações-chave (login, depósito, cheque-out) e sua latência p99.
Corredor horário: Aglomere por janelas deslizantes (5/30/60 min) e por região.
Exceções: «janelas programadas» são contabilizadas no SLO, e na SLA, apenas se for isso que diz o contrato.

• Disponibilidade: proporção de respostas bem sucedidas ≤ T.
• Qualidade: p95/p99 latency.
• Composto: «Taxa de depósitos bem sucedidos ≤ 5 c».

4) Error Budet e velocidade de combustão

Error Budget = `1 − SLO`. Para 99. 95% da janela mensal dá 0. 05% de erros/inatividade.
Burn-rate: velocidade de vazão do orçamento (4 x) significa que em 6 horas você come o limite do dia).
Política: com combustão rápida - parar lançamentos, foco de estabilização, função-freeze.

5) Arquitetura HA: de nó a região

5. 1 Nó/Serviço

N + 1: pelo menos uma réplica redundante (Deployment ≥ 2, PDB, anti-affinity).
Isolamento de recursos: limites CPU/RAM/IO, prioridades (PriorityClass).
Graceful shutdown/drain: não há acréscimo de solicitação no restarte.

5. 2 Zona/Região

Multi-AZ: réplicas em diferentes zonas, balanceamento cruzado, alimentação independente/rede.
Multi-region: ativo-ativo (mais difícil: dados/consistência) ou ativo-passivo (mais fácil: RPO superior).
Dados: COP para dinheiro/encomendas (quórum/RAFT), EC/AP para dinheiro/vitrines.

5. 3 Camada de rede e perímetro

L7-LB с health-checks, retry/timeout/circuit-breaking.
GSLB/DNS/Anycast para tráfego global, TTL curto.
Controle Egress e canais resistentes a falhas até PSP/provedores externos.

6) Degradação em vez de queda

Função kill-switch (bandeiras fichas): desliga o caminho vermelho e não-crítico.
Alterna para caminhos simplificados: sincronia, asinhrona/fila, «aceito em processamento».
Rate-limit/quotas: é melhor limitar o tráfego do que deixar cair todos.
Modos Stale: doar dados em dinheiro/estático quando o origin não estiver disponível.

7) Gerenciamento de dependências

Mapa de dependências (service map): direto/transitivo, criticidade, SLO de cada um.
Elos vulneráveis: provedor externo sem SLA - vira cachê/fila/duplicado.
Bulkhead-isolamento: diferentes pool de conexões/quotas para rotas lentas.
Timeouts> Retries: tempo curto, no máximo 1 retrai para operações idumpotentes.

8) Operações e alterações

Mudança de gestão: lançamentos por canarinhos/blue-green, gates SLO, reversão automática.
As janelas programadas normalizam - comprimento, frequência, comunicações.
Incidentes: rolos (IC/Comms/Tech/DB), runbook 'e, pós-mórtemas de ajustamento.
Hebraicos de segurança: Em caso de comprometimento, «modo-pânico» (read-only/tokens/rotação/bloqueio).

9) Observabilidade e alerting

Modelo RED (Rate, Errors, Duration) para cada trajeto.
SLI-dashboards: disponibilidade/latência na região e no segmento de clientes.
Alertas burn-rate: rápidos (1h, 14. 4 x), lentos (6h, 2 x) - sinal até o SLO ser quebrado.
Instâncias (Excempars): move-se de métricas para pistas em trace _ id.
Sintética: amostras de pontos externos (perímetro, flow de pagamento).

10) Testes de resistência a falhas

Game-days: cenários de desativação de AZ/regiões, degradação de BD/dinheiro, falha de provedores externos.
Ferramentas Chaos: folts de rede (latency/loss), kill-pods, CPU/IO superaquecido.
DR.-drills: trabalhar RTO/RPO para sistemas Tier-0 (consulte «Bacapes e DR.»).

11) Projeto de SLA

Definindo «disponibilidade»: o que é considerado um incidente (5xx, hora> T, erros de domínio).
Janela de cálculo: mês/trimestre; incluir/excluir os trabalhos programados.
Créditos/multas: escala (por exemplo, 99. 9–99. 99% X%, abaixo de Y%).
Responsabilidades do cliente: integração, retais dentro de limites razoáveis, limites.
Notificações e procedimentos de cliques: prazos, formato, base de provas (logs/métricas).
Força Maior, formulação legal e limites.

• "Disponibilidade de API SLI "≤ 500 ms" com sucesso não inferior a 99. 95% no mês do calendário. Janelas programadas (até 60 min/mes anunciadas em 48 h) estão excluídas. A 99. 90–99. 95% - crédito 5%; 99. 80–99. 90% — 10%; <99. 80% — 25%.»

12) Economia das donzelas

• Tier-0 (dinheiro/encomendas): 99. 95–99. 99%, multi-AZ, Dr. pronto.
• Tier-1 (fichas básicas): 99. 9–99. 95%, multi-AZ.
• Tier-2 (não-crítico): 99. 5–99. 9%, é permitido degradar/parar em incidentes.

13) Pattern HA por camadas

Perímetro: CDN/edge, multi-CDN ou GSLB, WAF, rate-limit.
Balanço: L7 com outlier-ejation, timeouts/retrai, sticky/consistent-hash.
Aplicativos: skale horizontal, readiness/liveness, PDB, topology spread.
Dados: líder + replicas, quorum para COP, dinheiro L2, idempotency, PITR.
Filas de espelho/multiclaster, deadup, DLQ.
Segredos/configs: GitOps, snapshots atômicos, rollback.

14) Anti-pattern

SLA sem ferramentas de medição e sintética externa.
Uma única zona/cluster como SPOF.
Retraias descontroladas → «si-DDoS».
Transações longas/mutex no caminho quente.
Migrações pesadas/lançamentos sem canarinhos ou plano de reversão.
Falta de runbook e comunicação com os steakholders no incidente.

15) Folha de cheque de implementação (0-60 dias)

0-15 dias

Definir SLI de usuário crítico, definir SLO por nível Tier-0/1/2.
Activar as alertas burn-rate, SLO-dashboard, verificações sintéticas do perímetro.
Remover SPOF: ≥2 frases, PDB, multi-AZ para frentes e BB críticos.

16 a 40 dias

Introduza lançamentos de canarinho com SLO-gating e auto-saída.
Mapa de dependências + quotas/pula/timeout/ST para cada «caminho vermelho».
Regulamento de janelas programadas e comunicações, modelos de mensagens de incidente.

41-60 dias

Game-day: desativação do AZ, fracasso do provedor externo, tráfego «burst».
Repasse de dados e créditos, publicação de relatórios aos clientes.
Revisão do valor do ↔ 9 e transferência de tiro.

16) Métricas de maturidade

≥ 95% das rotas críticas têm SLI/SLO e burn-rate alerts.
Os erros SLO são acompanhados de congelamento automático de lançamentos (policy).
Multi-AZ revestimento Tier-0 = 100%, DR-drills bem-sucedidos ≥ 1/trimestre.

Tempo de «detecção → mitigação» p50 <5 min, p95 <15 min

Correlação «lançamento ↔ incidentes» - em curso e reduzido (rollback rate↓).
Relatório público de incidentes/empréstimos - em dias úteis.

17) Exemplos e snippets

• Rápido, "SLO 99. 95%, janela 1h, burn ≥ 14. 4× → page on-call».
• Lento: «janela de 6 h, burn-2 x x card & monitoring».

yaml circuit_breakers:
thresholds:
- max_connections: 200 max_pending_requests: 100 max_requests: 1000 max_retries: 1 outlier_detection:
consecutive_5xx: 5 interval: 5s base_ejection_time: 30s max_ejection_percent: 50

yaml analysis:
templates:
- name: slo-burn metrics:
- name: error-rate successCondition: result < 0. 005 provider: prometheus

SLI: fraction_of_good_requests = good(HTTP 2xx/3xx ≤ 500ms) / all(requests)
SLO: ≥ 99. 95% per calendar month, per region

18) Conclusão

High Availability não é apenas clusters e réplicas, mas um conjunto coerente de arquitetura, processos e métricas: SLI/SLO claro, SLA realista, «nove» com economia, degradação em vez de queda, disciplina de times/quotas, lançamentos canários, exercícios regulares e comunicação transparente. Tornem a disponibilidade mensurável e controlada - e ela será uma vantagem competitiva, não uma loteria.