SRE cultura e engenharia

1) O que é a cultura SRE

A cultura SRE é um conjunto de valores e práticas que tornam a confiabilidade administrável, como metas SLO → erros-orçamento → riscos de mudança conscientes → estabilização rápida → treinamento em incidentes.
O paradigma chave é a velocidade ≠ o inimigo da confiabilidade. A velocidade de lançamento é possível quando os riscos são dosados e automatizados.

• User-centric: Identificamos a confiabilidade como o usuário a vê (SLI/SLO).
• Automation-first: qualquer ação repetível → script/política/controlador.
• Blamelessness: erros são de sistema, investigamos as causas, não as pessoas.
• Data-driven: soluções baseadas em métricas e orçamentos de erros.
• Simplicidade: mecanismos simples, verificáveis> soluções mágicas.

2) Princípios básicos de engenharia SRE

1. O SLO/SLI e o orçamento de erros são a base das prioridades e do alerting.
2. O incidente estabilização RCA - primeiro os sintomas, depois as causas.
3. Reduzir o trabalho manual (toil) é o objetivo de ≤ 50% do tempo de SRE, com o tempo abaixo.
4. Prod-pronto - «producition readiness» é obrigatório antes do tráfego externo.
5. Simplicidade e isolamento - menos interconexões, mais restrições ao blast radius.
6. Observabilidade padrão - métricas/logs/pistas, widgets SLO, sintético.
7. As alterações são controladas - progressive delivery, canários, auto-rollback.
8. Security by design - segredos, acessos, auditorias, privilégios mínimos.
9. Ciclos de aprendizagem - drills, jogos de caos, pós-mortem, retrospectivas.
10. A consciência FinOps é o «preço das donzelas».

3) Rituais e processos

3. 1 Production Readiness Review (PRR)

• SLI/SLO, dashboard e alertas (fast/slow burn).
• Health-endpoint '/healthz ', '/readyz', '/startupz '.
• Runbook/playbook incidentes, owner/on-call, escalation chain.
• Backups/DR., limites de recursos, cálculos orçamentários.
• Testes de resistência a falhas (bandeiras de fich, cenários rollback).

3. 2 Reunião semanal SLO

Status de error-boodget por serviço.
Incidentes em uma semana, progresso CAPA.
Risco de lançamento: onde é permitido/limitado pelo depósito (orçamento).

3. 3 Vamos fazer isso sem acusações

Factos e timeline, influência do usuário, o que ajudou/atrapalhou.
Causas do sistema (processos/ferramentas), não «culpado».
CAPA específico com proprietários e prazos, publicidade dentro da empresa.

3. 4 Jogos de caos e drible

Injeções programadas de falhas (rede, BD, dinheiro, nódulos) + SLO alvo.
«Game day»: tempo para estabilização, medição de MTTR, correção de playbooks.

4) Alerting e ruído

• Alert only on symtoms: SLO ou caminho do usuário violado.
• Multi-window, multi-burn: canais rápidos e lentos.
• Quorum/anti-flapping: atrasos 'for', supressão em maintenance.
• «CPU> 80%» é um tipo de sinal para os palcos, não para o pager.

• A proporção de actionable ≥ de 80%.
• Median time-to-ack ≤ 5 minutos (P1).
• Redução de «Pager fatigue»: ≤ 1 page por semana por engenheiro.

5) Gerenciamento de alterações

Progressive delivery: canary → 10% → 25% → 50% → 100%.
Auto-rollback por SLO (erros/latência).
Função-flags e kill-switch em vez de retração global.
Change policy by risk: fast lane для low-risk; O FAB é apenas high-risk.

yaml steps:
- setWeight: 10
- analysis: { template: "slo-check" } # fail ⇒ rollback
- setWeight: 25
- analysis: { template: "slo-check" }

6) Redução do toil (trabalho manual rotineiro)

Exemplos de fontes toil: deploies manuais, reiniciações, tíquetes de acesso, limpeza de filas.

• Inventário de tarefas repetitivas → automação/auto-uso.
• KPI:% do tempo de toil, «etapas automáticas/incidente», «minutos antes da self-service».
• Catálogo de serviços de plataforma (namespaces, BD, filas, dashboards, alertas).

7) Observabilidade e SLO-primeiro design

Golden Signals (latency, traffic, errors, saturation).
Cartões SLO em cada equipa: alvo, janela, orçamento, burn-alerts.
Drilldown: de métricas em logs/pistas; 'trace _ id' nos logs padrão.
Sintético: blackbox + guiões headless (login/deposit/checkout).

8) Gestão de capacidade e sustentabilidade

Capacity planning: RPS/concorrência alvo, estoque AZ/região.
Bolkhead/shedding: isolamento de pool, falha de funções secundárias primeiro.
Backpressure e filas: controle de linha, DLQ, concorrência adaptativa.
Failover e DR.: RPO/RTO, DR-drilly regular.

9) Segurança como parte da confiabilidade

Segredos, gerenciador de segredos, JIT, auditoria.
WAF/DDoS-guard no perímetro, limites por cliente/tenante.
PII-Minimização, DSAR/Legal Hold em incidentes.
Suply chain security: assinatura de artefatos, política de imagens básicas.

10) Saúde do Coll

Roteiros sem «solitários», janelas de descanso claras.
O limite de despertar à noite é apenas P1/P2 SLO.
Psicogigiene, a escassez de sono é detectada como risco operatório.
Métricas: pagie/ned, pacs noturnos/engenheiro, tempo de recuperação.

11) Métricas de maturidade SRE

SLO coverage: proporção de caminhos críticos com SLO/alertas ≥ 90%.
Error-boodget governance: existem regras freeze e aplicáveis.
Toil: ≤ 30% a 40% do tempo, tendência de baixa.
MTTD/MTTR: Medianos em dinâmica trimestral.
Auto-mitigation rate:% dos incidentes com ação automática.
PRR pass-rate: proporção de lançamentos pré-prontos.
Postmortem SLA: SEC-1 - ≤ 48 horas.

12) Documentação e conhecimento

• Runbooks/playbooks (cenário top: 5xx spike, DB lag, Kafka lag, NodeNotReady, TLS).
• Cartões SLO e dashboards.
• folhas de cheque PRR e modelos de lançamento.
• Catálogo de serviços de plataforma e OLAs/SLAs.
• Material didático SRE 101, Chaos 101, On-call 101.

13) Anti-pattern

Hero-cultura: «salva-vidas» em vez de fixação de sistemas.
Alerting barulhento CPU/disco no pager, centenas de sinais desnecessários.
«O DevOps é humano», responsabilidade esvaziada, sem proprietários.
Falta de SLO, «manter tudo verde» → caos de prioridade.
Pós-mortem e caça às bruxas.
Recalls globais sem canários.
Segredos em configh/repo; não há auditoria de ações.
Observabilidade como «gráficos bonitos» sem sinais actionable.

14) Modelos de artefatos

14. 1 Carta SRE (fatia)

yaml mission: "Make reliability manageable and economical"
tenets:
- "User - SLI/SLO Center"
- "Automation-first, minimizing toil"
- "Blameless & learning"
governance:
error_budget:
freeze_threshold: 0. 8 # 80% of the budget burned ⇒ release frieze review_cadence: "weekly"
oncall:
paging_policy: "SLO-only, P1/P2 at night"
health_metrics: ["pages_per_week", "night_pages_per_engineer"]

14. 2 Folha de cheque mini-PRR

• SLI/SLO e burn-alerts configurados
• Health-endpoint e sintéticos
• Runbook/playbook + dono/on-call
• Rollback/bandeiras fichas/canário
• Dashboards latency/errors/traffic/saturation
• Limites/quotas/guardas de segurança
• Plano DR. e bacapes testados

15) Implementação por etapas (4 sprint)

Sprint 1 - Fundações

Definir caminhos críticos do usuário e SLI.
Articular SLO e iniciar burn-alerts.
Digite PRR e playbooks mínimos.

Sprint 2 - Gerenciamento de alterações

Canários, auto-rollback SLO.
Self-service operações, catálogo de serviços.
Inventário toil e plano de automação.

Sprint 3 - Ciclos de treinamento

Um ritual pós-mortem, um calendário de jogos de caos.
Dashboards SLO + incidentes, relatórios errados-budet.

Sprint 4 - Otimização e zoom

Portfólio SLO, FinOps «per 9».
Introdução de disciplina Dr., auditoria de segurança.
KPI-call, prevenção de queimadas.

16) Mini-FAQ

SRE = «consertar tudo»?
Não. O SRE controla sistemas de confiabilidade, como SLO, alerting, processos, automação e treinamento.

Como convencer o negócio a investir em confiabilidade?
Mostre o RI: redução do MTTR, aumento da conversão, menos crédito SLA, menor custo-to-serve, lançamentos estáveis.

Os comandos SRE individuais são necessários?
Modelo híbrido: SRE estratégico na plataforma + embedded-SRE em produtos críticos.

Resultado

A cultura SRE não é um cargo, mas uma forma de lidar com o risco: SLO → orçamento de erros → mudanças gerenciadas → automação → treinamento. Fixe os princípios, estabeleça rituais (PRR, pós-mórtemos, jogos de caos), retire toil, construa a observabilidade padrão e cuide dele. Assim você terá uma velocidade de desenvolvimento sustentável, lançamentos previsíveis e uma plataforma confiável e econômica.