1.1 Monitoramento × observabilidade

1.2 O que é SRE

Site Reliability Engineering nasceu na Google (formalizado no livro de 2016) a partir de uma ideia: "o que acontece quando você pede a um engenheiro de software para projetar uma função de operações". Os princípios:

• Confiabilidade é a feature mais importante — um produto que não está no ar não tem features.
• Confiabilidade tem um alvo, não é "100%" — 100% é o alvo errado (caro, impossível, e o usuário não percebe a diferença acima de certo ponto). Define-se um SLO (Módulo 6).
• Error budget: a diferença entre 100% e o SLO é um "orçamento" de falha que o time pode gastar lançando features. Alinha dev (quer velocidade) e ops (quer estabilidade) num único número.
• Eliminar toil: trabalho manual, repetitivo, automatizável e sem valor duradouro deve ser reduzido com engenharia — meta clássica: ≤ 50% do tempo em toil.
• Postmortems sem culpa: incidentes são falhas de sistema/processo, não de pessoas; aprende-se, não se pune.
• Automação e release engineering como parte do trabalho.

1.3 SRE × DevOps × Platform

• DevOps é uma cultura/movimento (quebrar o muro entre dev e ops). SRE é uma implementação prescritiva dela, com práticas concretas (SLO, error budget, on-call estruturado). "SRE implementa DevOps."
• Platform Engineering constrói a plataforma interna (golden paths) que os times usam; SRE frequentemente contribui, e a observabilidade costuma ser um produto da plataforma (Módulo 9).

2.1 Os três (mais um)

2.2 Cardinalidade — o conceito que decide o custo

Cardinalidade = número de séries temporais distintas, dado pelas combinações únicas de labels. Uma métrica http_requests_total com labels method (5 valores), status (10), endpoint (50) = 2.500 séries. Adicione user_id (1 milhão) e você tem 2,5 bilhões de séries — o sistema de métricas colapsa.

2.3 Structured logging

// RUIM: log de texto livre — impossível de consultar bem
[2026-08-30 14:00:01] ERROR user ana@x.com failed to pay order o1 - card declined

// BOM: log estruturado — filtrável, agregável, correlacionável
{
  "ts": "2026-08-30T14:00:01Z", "level": "error", "msg": "pagamento recusado",
  "user_id": "u_123", "order_id": "o1", "reason": "card_declined",
  "service": "payments", "trace_id": "abc123", "span_id": "def456"
}

Sempre inclua trace_id e span_id nos logs — é o que liga log ↔ trace ↔ métrica (correlação).

2.4 A convergência

Os três pilares como silos separados (ferramenta de log, ferramenta de métrica, ferramenta de trace) geram troca de contexto constante durante um incidente. A tendência: telemetria unificada com o mesmo contexto (labels/atributos consistentes via semantic conventions), correlacionada, e frequentemente derivando métricas e logs a partir de eventos ricos ("wide events"). O OpenTelemetry (Módulo 4) é o padrão que viabiliza isso.

3.1 Tipos de métrica

3.2 O modelo Prometheus

• Pull: o Prometheus raspa (scrapes) um endpoint /metrics de cada alvo a cada X segundos. (Push existe via Pushgateway para jobs batch efêmeros, mas pull é o padrão.)
• Service discovery: descobre os alvos dinamicamente (Kubernetes, Consul, arquivos).
• TSDB local + armazenamento de longo prazo (Thanos, Mimir, Cortex) para retenção e escala horizontal.
• Alertmanager recebe alertas do Prometheus e cuida de roteamento, agrupamento, silenciamento, deduplicação.
• Grafana para visualização; exporters (node_exporter, cAdvisor, blackbox) para infra que não expõe métricas nativas.

# PromQL essencial
rate(http_requests_total[5m])                          # req/s nos últimos 5 min
sum by (endpoint) (rate(http_requests_total[5m]))      # agregado por endpoint

# taxa de erro (%)
sum(rate(http_requests_total{status=~"5.."}[5m]))
  / sum(rate(http_requests_total[5m]))

# latência p95 a partir do histograma
histogram_quantile(0.95, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))

3.3 RED, USE e os Golden Signals — o que medir

3.4 Boas práticas de métrica

• Nomes consistentes com unidade no sufixo (_seconds, _bytes, _total para counters) — seguir as semantic conventions do OpenTelemetry.
• Recording rules para pré-calcular queries caras e frequentes.
• Exemplars: anexar um trace_id de exemplo a um bucket de histograma — clicar no pico de latência e pular para um trace real daquele momento.
• Instrumentar na borda (middleware HTTP/gRPC) para o RED sair "de graça"; instrumentação de negócio (pedidos/min, receita/min) além do técnico.

4.1 O modelo de trace

trace (id = abc123)  ── uma requisição do usuário, ponta a ponta
 └─ span: GET /checkout          [gateway]        0──────────────────────520ms
     ├─ span: auth               [auth-svc]       5──25ms
     ├─ span: carregar carrinho  [cart-svc]       30──90ms
     │   └─ span: SELECT ...     [postgres]       35──85ms
     ├─ span: antifraude         [fraud-svc]      95──400ms   ← o gargalo
     └─ span: criar pedido       [order-svc]      410──515ms
         └─ span: INSERT ...     [postgres]       420──510ms

• Um span = uma unidade de trabalho, com nome, tempo de início/fim, atributos (chave-valor), eventos, status, e o span_id do pai.
• Todos os spans de uma requisição compartilham o trace_id.
• Propagação de contexto: o trace_id + span_id do pai viajam entre serviços num header padrão (traceparent — W3C Trace Context). Sem propagação, você tem spans soltos, não um trace.

4.2 OpenTelemetry (OTel) — o padrão

OpenTelemetry (projeto CNCF, resultado da fusão de OpenTracing + OpenCensus) é o padrão vendor-neutral para gerar telemetria (traces, métricas, logs). Componentes:

4.3 Amostragem (sampling)

4.4 O trace como ferramenta de debug

• "Onde foi o tempo?" — o span mais longo no caminho crítico salta aos olhos.
• "Qual serviço falhou?" — o span com status de erro, com o stack/mensagem nos eventos.
• Comparar traces lentos vs rápidos do mesmo endpoint para achar a diferença (uma chamada extra, um lock, um cache miss).
• Exemplars ligam o pico de um histograma de métrica a um trace real (Módulo 3).
• Service map gerado a partir de traces: quem chama quem, com latências e taxas de erro nas arestas.

5.1 Níveis e disciplina

• ERROR: algo falhou e precisa de atenção (ou já virou métrica/alerta). WARN: anormal, mas tratado. INFO: eventos de negócio significativos (pedido criado, deploy). DEBUG: detalhe para desenvolvimento — desligado em produção, ou ligável por serviço/temporariamente.
• Um evento, um log estruturado com todo o contexto (Módulo 2), não cinco linhas de texto solto.
• Sempre trace_id e span_id no log — a ponte para o trace.
• Nunca logar segredos, tokens, PII sem necessidade e sem redação; logs vão para sistemas com acesso amplo.
• Log em stdout (o coletor recolhe); não gerencie arquivos de log na aplicação (12-factor).

5.2 O custo dos logs

5.3 Backends de log

5.4 O Collector como ponto de controle

# pipeline conceitual do OTel Collector
receivers:  [otlp, filelog, prometheus, kafka]
processors: [
  batch,                     # eficiência
  memory_limiter,            # não estourar
  attributes/redact-pii,     # remover email, cpf, tokens
  filter/drop-health-checks, # cortar ruído
  tail_sampling,             # só traces interessantes
  transform/derive-metrics,  # log de erro -> contador
  resourcedetection          # enriquecer com região, cluster, versão
]
exporters:  [prometheusremotewrite, otlp/tempo, loki, otlp/vendor]

Ter o Collector no meio significa que políticas de custo, privacidade e roteamento vivem num lugar central, versionado como código — não espalhadas por 30 apps.

6.1 As três siglas

6.2 O que faz um bom SLI

• Voltado ao usuário: mede o que o usuário sente (a requisição foi atendida rápido e sem erro?), não uma causa interna (CPU).
• Uma razão "bom / total", entre 0 e 100%.
• Medido onde o usuário está quando possível (no load balancer / gateway, não no fundo do backend — senão você ignora as requisições que nem chegaram).
• Categorias comuns: disponibilidade (% de sucesso), latência (% abaixo do limiar), qualidade/correção (% de respostas corretas), frescor (dados atualizados dentro de X), throughput, cobertura.

6.3 A matemática dos "noves" e o error budget

O error budget = 100% − SLO. Com SLO de 99,9% num mês, você "pode" falhar 0,1% das requisições (ou ~43 min de indisponibilidade). Esse orçamento é gasto por incidentes, deploys ruins, degradações.

6.4 Burn-rate alerts

Alertar quando "o SLO foi violado" é tarde demais. Alerte pela velocidade de consumo do orçamento (burn rate): burn rate = 1 significa consumir o orçamento exatamente no ritmo que o esgota ao fim do período; burn rate = 14,4 esgota o orçamento de 30 dias em ~2 dias.

Multi-window, multi-burn-rate (recomendação do SRE Workbook):

  PÁGINA (acorda alguém) se:
    burn rate > 14,4 na janela de 1h  E  burn rate > 14,4 na janela de 5m
    (queima rápida — 2% do orçamento mensal em 1h)
  OU
    burn rate > 6 na janela de 6h    E  burn rate > 6 na janela de 30m

  TICKET (não acorda) se:
    burn rate > 3 na janela de 24h   E  ... na janela curta
    burn rate > 1 na janela de 3d    E  ...

A janela curta em conjunto evita alertar por um pico já resolvido; a janela longa evita ignorar uma degradação lenta e persistente.

6.5 SLO como contrato entre times

Quando o serviço A depende do serviço B, o SLO de B (e seu histórico de cumprimento) informa quanto A pode prometer. SLOs publicados criam uma linguagem comum: "seu serviço precisa de 99,95% para eu conseguir dar 99,9%". E evitam o "over-delivery" perigoso (um serviço que sempre entrega 99,999% cria dependência oculta e some quando finalmente cai).

7.1 O que merece um alerta que acorda alguém

• Alerte por sintoma, não por causa: "taxa de erro do checkout acima do SLO" (sintoma, sempre relevante) > "CPU do pod X a 92%" (causa, pode ser normal). Causa vira contexto no runbook, não alerta.
• Baseie no error budget / burn rate (Módulo 6) quando possível — é o alerta mais alinhado ao que importa.
• Dois níveis: page (urgente, acorda) e ticket/warn (importante, horário comercial). Não pague tudo.

7.2 Fadiga de alerta

O maior inimigo do on-call. Sintomas: alertas que sempre se auto-resolvem, alertas que ninguém investiga, "isso é normal, ignora". Consequências: a pessoa perde a confiança e ignora o alerta importante. Combate:

• Toda página deve gerar um pós-fato: foi útil? Se não, ajustar o limiar, agrupar, ou deletar.
• Métrica de saúde do on-call: páginas por turno (alvo típico ≤ 2), % de páginas acionáveis, % fora do horário.
• Agrupamento e deduplicação no Alertmanager/PagerDuty (um incidente = uma página, não 40).
• Silenciamento durante manutenções planejadas.
• Revisão periódica de todos os alertas ("alert review") — deletar os mortos é trabalho legítimo.

7.3 Runbooks

Todo alerta que página tem um runbook linkado: o que este alerta significa, como confirmar o problema, os primeiros passos de mitigação (reverter deploy, escalar, drenar tráfego, ligar feature flag de degradação), quando e para quem escalar. Runbook bom é executável às 3h por alguém sonolento — específico, com comandos, sem "investigue".

7.4 On-call sustentável

• Rotação com gente suficiente (mínimo ~6–8 pessoas para não sobrecarregar); turnos de duração razoável (semana); follow-the-sun entre fusos elimina plantão noturno.
• Compensação (folga, pagamento) pelo tempo de plantão — não é "de graça".
• Primário + secundário (backup se o primário não responde).
• Handoff documentado entre turnos: o que está aberto, o que observar.
• Tempo protegido para trabalho de confiabilidade (corrigir as causas dos alertas) — senão o plantão só apaga incêndio e nunca melhora.
• Ferramentas: PagerDuty, Opsgenie, Grafana OnCall, incident.io.

7.5 Dashboards que servem

• Um dashboard por serviço com RED + saturação + versão em deploy + links para runbooks — o primeiro lugar que o on-call abre.
• Um dashboard de SLO por serviço: SLI atual, orçamento restante, burn rate.
• Evitar "wall of graphs" (50 gráficos que ninguém lê) e vanity metrics. Cada painel responde a uma pergunta.

8.1 O ciclo de um incidente

DETECTAR ──► TRIAR ──► MITIGAR ──► RESOLVER ──► APRENDER
(alerta/SLO)  (severidade,  (parar a dor    (corrigir a   (postmortem
              declarar,     do usuário:     causa)         sem culpa,
              acionar)      reverter,                      ações)
                            failover,
                            feature flag)

8.2 Papéis

Em incidentes pequenos, uma pessoa acumula papéis; o importante é que alguém é o IC e todos sabem quem.

8.3 Severidade e comunicação

• Níveis (ex.: SEV1 = indisponibilidade total / perda de dados / impacto grave; SEV2 = degradação séria; SEV3 = impacto menor) — definem quem é acionado, a cadência de comunicação e se há postmortem obrigatório.
• Comunicação em cadência fixa (ex.: a cada 30 min), mesmo que seja "ainda investigando" — o silêncio gera pânico e enxame de gente perguntando.
• Status page externa honesta e rápida; clientes perdoam falha, não perdoam sentir que foram enganados.

8.4 Postmortem sem culpa (blameless)

• Premissa: as pessoas agiram com boa intenção e com a informação que tinham. Se alguém "errou", a pergunta é por que o sistema/processo permitiu esse erro e não o pegou — não "quem foi".
• Conteúdo: resumo do impacto (quanto tempo, quantos usuários, error budget gasto), timeline detalhada, análise da causa (raiz e contribuintes), o que correu bem, o que correu mal, e ações concretas com dono e prazo.
• Além dos "5 whys": incidentes complexos têm múltiplas causas contribuintes e nenhuma "raiz" única. Técnicas melhores: análise de fatores contribuintes, "e se" na timeline, olhar o sistema sociotécnico (por que a detecção demorou? por que o rollback foi difícil?).
• Métricas de aprendizado: MTTD (tempo para detectar), MTTR/MTTM (tempo para mitigar/resolver), % de ações de postmortem concluídas. Um postmortem cujas ações nunca são feitas é teatro.

8.5 Testar a resiliência de propósito

• Chaos engineering: injetar falhas controladas em produção (matar instâncias, adicionar latência, particionar rede) para validar que a resiliência projetada funciona antes do incidente real. Ferramentas: Chaos Mesh, Gremlin, LitmusChaos, o clássico Chaos Monkey.
• Game days: exercícios simulados de incidente para treinar o processo, os runbooks e as pessoas.
• DiRT (Disaster Recovery Testing): testar failover de região, restauração de backup — "backup não testado não é backup".

9.1 Toil e sua eliminação

• Toil = trabalho operacional manual, repetitivo, automatizável, tático, sem valor duradouro, que escala linearmente com o serviço (reiniciar um serviço travado, aprovar um acesso, aplicar um certificado, responder o mesmo alerta).
• Meta clássica do SRE Google: ≤ 50% do tempo em toil; o resto é engenharia (automação, melhorias de confiabilidade).
• Medir o toil (pesquisas, tracking de tickets) e atacar os maiores geradores com automação e self-healing (o sistema se recupera sozinho: auto-restart, auto-scaling, auto-failover, auto-remediação de alertas conhecidos).

9.2 Release engineering e progressive delivery

Ferramentas: Argo Rollouts, Flagger, Spinnaker; LaunchDarkly/Unleash para flags. Deploy frequente e pequeno reduz o risco por deploy — é contraintuitivo mas é o que os dados de DORA (DevOps Research) mostram: quem entrega mais vezes tem menos incidentes e recupera mais rápido.

9.3 Capacity planning

• Previsão de demanda (orgânica + eventos: Black Friday, campanhas) × capacidade atual × headroom de segurança.
• Load testing / stress testing para conhecer o ponto de quebra e a curva de degradação.
• Autoscaling cobre a variação; o planejamento cobre o crescimento estrutural e os picos previsíveis.
• Cruza com FinOps (a apostila irmã) — capacidade ociosa é custo, capacidade insuficiente é incidente.

9.4 O modelo organizacional de SRE

• Central / consultivo: um time de SRE que define práticas, ferramentas e faz onboarding de serviços; os times de produto operam com apoio.
• Embedded: SREs dentro dos times de produto.
• Platform: SRE contribui para a plataforma interna que provê observabilidade, CI/CD, runtime e SLOs "de fábrica" — o golden path. O time de produto ganha observabilidade por padrão, sem montar do zero.
• You build it, you run it (Amazon): quem escreve, opera — SRE ajuda a capacitar, não assume o pager de todo mundo.

9.5 Temas atuais

• eBPF: instrumentação no kernel Linux sem tocar a aplicação — visibilidade de rede, syscalls, latência, profiling contínuo "de graça". Ferramentas: Cilium/Hubble, Pixie, Parca, Grafana Beyla. Reduz a necessidade de instrumentação manual.
• Observabilidade de IA/LLM: traces de chamadas a modelos, tokens, custo, avaliações online, drift — cobre-se na apostila de LLMOps & Avaliação; o OTel tem semantic conventions para GenAI.
• AIOps: ML aplicado à operação — detecção de anomalia, correlação de alertas, agrupamento de incidentes, sugestão de causa provável. Útil como copiloto; não substitui o julgamento.
• Observabilidade como código: dashboards, alertas e SLOs versionados (Terraform providers, Grafana as code, OpenSLO) — revisáveis, reproduzíveis.
• Custo de observabilidade como disciplina própria (ver FinOps): a telemetria pode custar uma fração significativa da infra.

10.1 Os perfis que contratam

10.2 Roadmap de estudo (8–10 semanas)

Base: Linux, redes, um provedor de nuvem, Kubernetes, um pouco de código (Go/Python), IaC (Terraform), CI/CD.

10.3 Banco de perguntas de entrevista (com a resposta que aprova)

10.4 Projetos de portfólio que geram entrevista

1. Stack de observabilidade completa (âncora): um conjunto de microserviços de exemplo, instrumentados com OpenTelemetry (traces + métricas + logs correlacionados), OTel Collector com tail sampling e redação de PII, Prometheus+Grafana com painéis RED, Loki, Tempo/Jaeger. README explicando as decisões e os custos.
2. SLOs e burn-rate alerts: definir SLIs/SLOs para os serviços acima, implementar alertas multi-window multi-burn-rate, e um dashboard de error budget. Bônus: OpenSLO / SLO as code.
3. Game day documentado: injetar uma falha (chaos), conduzir o incidente com papéis, e publicar o postmortem blameless com timeline e ações.
4. Canary automatizado: Argo Rollouts/Flagger comparando SLIs canary vs baseline, com rollback automático — demonstrado com um deploy "ruim".
5. Otimização de custo de observabilidade: um "antes/depois" de fatura com sampling, retenção e métricas derivadas de logs.

10.5 Fontes para continuar

• Livros SRE (Google, gratuitos online): Site Reliability Engineering, The Site Reliability Workbook, Building Secure & Reliable Systems.
• Observabilidade: Observability Engineering (Majors, Fong-Jones, Miranda — Honeycomb); Distributed Systems Observability (Cindy Sridharan).
• Incidentes: o material do Learning from Incidents e de John Allspaw sobre postmortems; Seeking SRE (coletânea).
• Prática: a documentação do OpenTelemetry e do Prometheus; o "PromLabs" para PromQL; DORA reports para métricas de entrega; o "Google SRE" YouTube.