Disponibilidade está cheia de falsas dicotomias
("velocidade vs confiabilidade", "chaos em prod vs
staging só") e de práticas que parecem boas mas
degeneram em teatro (postmortem sem action items,
game days que ninguém repete). Cada decisão abaixo
força a articular o trade-off real.
SLO conservador ou agressivo?
SLOs conservadores (99% quando você sustenta
99.9%) geram error budget farto mas sinalizam
baixa ambição ao time. SLOs agressivos (99.99%
quando você mal atinge 99.9%) criam ansiedade
permanente, freeze de mudanças, e postmortems
de todo micro-incidente. O alvo correto é
ligeiramente mais difícil que o histórico —
o suficiente para sentir pressão, não o
suficiente para paralisar. Regra prática: comece
com o percentil 95 da disponibilidade histórica
como SLO inicial. Revise a cada trimestre. O
SLA para o cliente deve ter buffer de pelo menos
0.1% abaixo do SLO interno.
Chaos engineering em produção ou só em staging?
Staging nunca replica produção com fidelidade
suficiente para ser o único ambiente de chaos.
Tráfego real, dependências reais, dados reais —
só prod tem isso. O caminho maduro é começar
por staging para calibrar experimentos (acertar
blast radius, validar abort conditions), depois
graduar para prod com escopo mínimo: um
servidor de um pool, uma porcentagem de tráfego,
horários de baixo risco. Netflix, Amazon e
Google rodam chaos em produção continuamente.
O critério de maturidade para migrar para prod
é: "sabemos observar o steady state e temos
rollback automático confiável".
Feature flags: centralizado (LaunchDarkly) ou por serviço?
Centralizado (LaunchDarkly, Flagsmith, Unleash)
ganha em visibilidade — um lugar para ver todos
os flags ativos, quem os ligou, quando. Perde
em latência de lookup (SDK faz chamada externa
ou mantém cache local) e em dependência de
terceiro. Por serviço (flags em banco de dados
ou config do próprio serviço) é simples de
operar mas vira bagunça em escala: 20 serviços
com flags em 20 lugares diferentes. A decisão
muda conforme tamanho: <5 serviços, flags
locais são aceitáveis; >5 serviços, um
sistema centralizado amortiza o custo de
coordenação.
Postmortem: quando fazer e quão formal?
Regra simples: todo incidente que violou SLO ou
que, se repetido, violaria — merece postmortem.
Nível de formalidade proporcional ao impacto:
incidente menor com resolução óbvia → postmortem
de 1 página (timeline + 2 action items);
incidente P0 com impacto a cliente → postmortem
completo com seção de contributing factors,
owner por action item, e data de entrega.
O erro mais comum é fazer postmortem de tudo
de forma igualmente pesada — o time esgota, a
qualidade cai, e o processo vira formulário.
Calibrar o esforço ao risco é parte da cultura.
RTO vs RPO: qual priorizar quando não dá para ter os dois?
Depende da natureza do sistema. Sistemas
financeiros (banco, e-commerce, billing) têm
RPO baixo como requisito inegociável — perder
dados de transação é catastrófico; aceita-se
downtime maior (RTO mais alto) em troca de zero
perda de dados. Sistemas de mídia, conteúdo
ou logging têm tolerância maior a RPO (perder
alguns eventos é aceitável) mas RTO precisa
ser baixo — usuário sem acesso é pior que dado
levemente desatualizado. A regra: RPO é ditado
pela tolerância do negócio à perda de dados;
RTO é ditado pela tolerância à indisponibilidade.
Ambos devem ser SLOs formais, não intuições.