Monitoramento de SLA e SLO

1) Termos e papéis

SLA é uma obrigação contratual externa com o cliente (reservas penais, empréstimos).
O SLO (Service Level Objectiva) é o nível interno de destino do serviço que suporta a execução do SLA.
O SLI (Service Level Indicator) é um indicador medido com base no SLO/SLA.
Error Budet - uma proporção válida de «indisponibilidade/erro» durante o período: 'Budget = 1 - SLO'.
Scope: medido pelos olhos do usuário (end-to-end). Em microsserviços - ao nível do componente e do caminho de passagem.

2) Seleção de SLI: exatamente o que medir

Critério - correlação com experiência do usuário e valor de negócio.

• Disponibilidade: proporção de pedidos bem sucedidos. 'SLI = sucesso/tudo'.
• Latência: proporção de solicitação mais rápida que o limite T. 'SLI = P (latency ≤ T)'.
• Qualidade: proporção de respostas corretas (sem 5xx/função. erros).
• Atualidade dos dados: atraso na replicação/ETL ≤ X minutos.
• Desempenho do processo de negócios: proporção de pagamentos e registros bem sucedidos.

Anti-pattern: considerar apenas 200 ki como «sucesso», ignorando erros empresariais; medir na rede de testes em vez da rede de usuários.

3) Fórmulas e janelas de observação

• `Availability = (OK_requests / All_requests) × 100%`.

• 'P95' T ' melhor como uma participação:' SLI =% de solicitações T '.
• Exemplo: «99% das pesquisas ≤ 300 ms em 28 dias».
• Janela deslizante: 28 ou 30 dias (equilíbrio de sensibilidade e estabilidade). Para incidentes, mais janelas: 1h, 6h, 24h.

4) Erro Budet e controle de velocidade

Cálculo: em 'SLO = 99. 9% 'orçamento =' 0. 1% de erro/indisponibilidade durante o período.

• Orçamento> 50%, lançamentos e experiências de plano.
• O orçamento é de 10% a 50%, só lançamentos de baixo risco.
• Orçamento <10%: congelamento de lançamentos, causa raiz, melhoria da confiabilidade.
• Conexão com lançamentos progressivos: canary/função-flags «comem» o orçamento de forma dosada, com auto-retração em caso de degradação.

5) Políticas alert: de liminares para burn rate

Porque não o'SLO - levanta o alert "? É tarde demais. Preciso de proatividade.

• 'BR = (erro observado em uma janela curta/erro válido por esta janela)'.
• Se 'BR> 1', o orçamento é mais rápido que o normal.

• Alert rápido (ruído sensível, apanhando desastres): janela 5-10 min, limite BR 14-20 x.
• Alert lento (pega degradação rasteira): janela 1-6 h, limite BR 2-4 x.
• Condições de combinação: rápido ou lento - paging on-call.
• Níveis: pager para SLO personalizado, tíquetes/notificações para as degradações cinzentas do SLI interno.

6) Observabilidade e fontes da verdade

O logi é um diagnóstico das causas.
As métricas são SLI numérico (sucesso/erro, percalços de latência, lóbulos, contadores).
Trailers - caminhos de passagem, localização de segmentos quentes.
Sintéticos - amostras ativas da periferia (region-aware).
Eventos reais - RUM/telemetria clientes, métricas de negócios (conversão, pagamentos bem sucedidos).

Requisitos: um único quadro em dashboards de lançamentos e incidentes, anotações «versão/canário/bandeira».

7) Projetar SLO: modelo passo a passo

1. Descreva o caminho crítico (por exemplo, «depósito com cartão»).
2. Defina o SLI: sucesso/erro, limite de latência, abrangência.
3. Alinhar SLO: meta para 28 dias + exceções (janelas programadas).
4. Vincule-se à SLA: obrigação legal ≦ SLO real.
5. Nomeue o dono (service owner), o RACI e o canal de alertas.
6. Defina políticas de alert (BR de duas janelas) e reversões de carro.
7. Introduza os relatórios, as revisões semanais do orçamento, os revezamentos pós-incidentes.
8. Reveja o SLO trimestralmente (mudança de carga/arquitetura).

8) Exemplos de SLO (modelos)

• Disponibilidade: '≥ 99. 95% '(28d, excluindo as janelas anunciadas ≤ 30 min/m).
• Latência: '≥ 99% das respostas' ≤ 400 ms '.
• O sucesso das operações de negócios. 5% 'autorizações de sucesso (filtros fraud).

• Latência: '≥ 99% dos pedidos' ≤ 300 ms '.
• A relevância do cachê é '5 min' de atraso em 99% das vezes.

• Entrega: '≥ 99. 9% 'durante' ≤ 60 c '(end-to-end, com retraias).
• Perda: '≤ 0. 01% 'de mensagens (idempotação/dedução incluída).

9) Multi-região e multi-tenente

SLO «por cômodos», país, provedor de pagamentos, segmento VIP, dispositivo.
SLO local na borda: métricas dos pontos mais próximos do usuário (edge/PoP).
Agregação: o SLO compartilhado não deve esconder falhas em cômodos importantes.
Alternando provedores: rotas fallback automáticas ao nível de gates SLO.

10) Dashboards e relatórios

Dashboard de lançamento: versão, canário (% do tráfego), SLI (sucesso/latência), BR, anotações de bandeiras.
Dashboard de operações, orçamento burn-down por dia, incidentes de topo, MTTR, cômodos problemáticos.
Relatórios semanais: saldo do orçamento, tendências BR, dívida técnica (estreitos), planos de melhorias.

11) Processos: incidentes, RCA e melhorias

Gestão de Incidente: alert avaliação BR escala canarinhos/bandeiras reversão/fix.
RCA (causa raiz): factos/timeline/hipótese/correção/verificação do efeito SLI.
As lições aprendidas são pós-mortems, action items obrigatórios com proprietários e prazos.
Circuito de circuito: alterações nos testes, bandeiras de fique, limites, caixas, retalhos, quotas.

12) Complaens e auditoria

SLO/SLI como artefactos de controle (policy-as-código, logs imutáveis).
Vincular a requisitos (por exemplo, disponibilidade de pagamentos).
Provas de alertas, relatórios de orçamento, registros de lançamentos e saques.

13) Erros frequentes e como evitá-los

“99. 99% ou morte": alvos inalcançáveis → ruído permanente. Escolher SLO realista.
Os médios globais escondem falhas locais → introduzir cômodos.
As métricas não são e2e: SLO alto quando a degradação real no cliente → adicionar RUM/sintético.
Alerts de um limiar → passar para burn rate de duas janelas.
Não há relação com as alterações → os lançamentos não foram anotados, não há reversão automática.

14) Miniclube folha de implementação

• São descritos caminhos críticos e seus SLI/SLO.
• A janela de observação e exclusão foi definida.
• As alertas BR de duas janelas (rápidas e lentas) estão configuradas.
• Dashboards de lançamentos e operações com anotações de versões/bandeiras.
• A Política de Erro Budget afeta os lançamentos.
• Revisões regulares do orçamento e RCA pós-incidente.
• Documentação e proprietários de indicadores.

15) Exemplo de cálculo (específico)

O SLO de disponibilidade API é 99. 9% para 28 dias → orçamento = 0. 1%.
Em 7 dias, acumulou-se 0. 06% dos erros foram gastos 60% do orçamento semanal.
Há 2% de erros em uma janela curta de 15 min. É válido nesta janela: '0. 1% x (15 min/40320 min) ≈ 0. 000037%`.
Burn Rate ≫ 1 (dezenas x) → executa um pager rápido, o canário recua até 1%, a bandeira «degrade-payments-UX» é ativada pela RCA.

16) Resultado

O monitoramento do SLA/SLO não são apenas números do relatório, mas sim um mecanismo de gerenciamento de risco e qualidade do serviço. O SLI correto, o SLO realista, o gerenciamento de error budget, as alertas de burn-rate de duas janelas e observabilidade e2e transformam as métricas em soluções de trabalho para liberar valor mais rapidamente e manter a experiência do usuário previsível.