Em 2015, a plataforma de pagamentos Stripe sofreu um incidente que durou 66 minutos. O postmortem revelou um detalhe perturbador: o sistema que falhou havia sido construído 18 meses antes por um engenheiro que havia saído da empresa. Nenhum membro atual do time sabia como o componente funcionava internamente. Não havia runbook, não havia documentação de arquitetura, e o código tinha comentários mínimos. O incidente foi resolvido por um engenheiro que passou a primeira hora lendo código fonte para entender o que o sistema deveria fazer — enquanto clientes não conseguiam processar pagamentos.
Dia 1 é o lançamento: o PR mergeou, o deploy foi para produção, os primeiros usuários começaram a usar. Dia 2 é tudo que vem depois: patches de segurança, upgrades de versão, rotação de certificados e chaves, capacity planning à medida que o sistema cresce, incidentes de madrugada, e a pergunta constante "o que acontece quando alguém que não construiu esse sistema precisar operá-lo?". A qualidade do dia 2 é determinada durante o dia 1 — pelas decisões de design, documentação, e observabilidade tomadas antes do lançamento.
O custo oculto de software não-operável
Software que "funciona mas ninguém sabe operar" tem custos que aparecem lentamente e se compõem:
- Concentração de conhecimento: apenas 1-2 pessoas conseguem resolver incidentes. Elas ficam sobrecarregadas, não tiram férias, e quando saem, levam o conhecimento com elas.
- Incidentes mais longos: sem runbook, a resolução depende de análise do zero durante o incidente — quando a pressão é máxima e o raciocínio é mais difícil.
- Upgrades impossíveis: ninguém quer atualizar uma dependência em um sistema que ninguém entende — o risco percebido é alto demais. O software envelhece sem patches de segurança.
- Toil acumulado: workarounds manuais que se tornam parte do "processo" sem nunca serem automatizados.
- Dívida de on-call: engenheiros acordados às 3h para resolver problemas que poderiam ter sido prevenidos ou documentados — e que saem da empresa por esgotamento.
A métrica mais honesta de operabilidade é: "quanto tempo leva para alguém que nunca viu esse sistema antes diagnosticar e resolver o incidente mais comum?" Se a resposta é "horas" ou "depende de quem está de plantão", o sistema tem um problema de operabilidade, independente de quantas features tem ou qual é sua uptime histórica.
Runbooks — documentação operacional viva
Um runbook é um documento que descreve como realizar uma operação específica ou responder a um alerta específico. Ao contrário de documentação de arquitetura (que descreve como o sistema funciona), um runbook descreve o que fazer em uma situação concreta.
A distinção entre runbook e playbook é importante: um runbook é alerta-específico ("o que fazer quando esse alerta dispara"); um playbook é tipo-de-incidente genérico ("o que fazer em qualquer incidente de banco de dados"). Runbooks são mais acionáveis; playbooks são mais gerais. Ambos têm lugar, mas o runbook por alerta é o ponto de partida.
Estrutura de um runbook eficaz:
# Runbook: Alta Latência em meu-servico
## Gatilho
Este runbook é acionado quando:
- Alerta "meu-servico-latencia-alta" dispara (p99 > 2s por 5 minutos)
## Impacto
- Usuários experimentam lentidão nas operações de X e Y
- Fluxo de pagamento pode ser afetado se latência > 5s
## Diagnóstico (5 minutos)
### 1. Verificar se é um pico de tráfego
kubectl top pods -n meu-servico
# Se CPU > 80%: escalar HPA (ver seção Mitigação)
### 2. Verificar latência do banco de dados
# Dashboard Grafana: meu-servico / DB Latency
# Se p99 > 100ms: problema está no banco
### 3. Verificar erros 5xx nos upstream
kubectl logs -l app=meu-servico -n meu-servico --tail=100 | grep "ERROR"
# Se há erros de conexão: problema pode ser no downstream
## Mitigação
### Caso 1: Pico de tráfego
kubectl scale deployment meu-servico -n meu-servico --replicas=20
# Verificar em 2 minutos se latência normalizou
### Caso 2: Lentidão de banco de dados
- Abrir Runbook: Banco de Dados Lento
- Não reiniciar pods sem autorização do on-call lead
## Escalação
- Se não resolvido em 15 minutos: escalar para #oncall-backend no Slack
- Se impacto em pagamentos: escalar para #oncall-payments imediatamente
## Histórico de incidentes relacionados
- INC-2024-0312: causa foi query sem índice após migration — ver postmortem
- INC-2024-0801: causa foi memory leak em nova versão — rollback resolveuO detalhe crítico é o histórico de incidentes relacionados: cada incidente adiciona contexto que torna o próximo mais rápido de resolver. Um runbook que não é atualizado após incidentes envelhece e se torna enganoso — às vezes pior que não ter runbook, porque gera confiança falsa.
O runbook como produto, não artefato
Runbooks que ninguém lê em produção não ajudam. Para que um runbook seja usado:
- Link direto no alerta: o PagerDuty/OpsGenie deve incluir o link do runbook no corpo da notificação — não "procure no Confluence"
- Testado regularmente: game days e chaos engineering são oportunidades para executar runbooks e verificar se ainda são válidos
- Atualizado como parte do postmortem: cada incidente termina com "o runbook precisa ser atualizado?" como item obrigatório
- Curto o suficiente para ser lido às 3h: se um runbook tem 10 páginas, ele não será lido — é documentação de arquitetura disfarçada de runbook
On-call saudável — princípios
On-call é inerentemente perturbador. O objetivo não é eliminar o on-call — é torná-lo sustentável para que as pessoas possam fazê-lo por anos sem burnout. Times que tratam on-call como secundário em relação à entrega de features acabam com alta rotatividade dos melhores engenheiros — que têm opções e escolhem empresas com on-call saudável.
Rodízio justo: nenhuma pessoa deve fazer on-call primário mais do que 1 semana a cada 4 semanas como regra geral. Times menores que 4 pessoas têm on-call insustentável por design — a solução é crescer o time ou reduzir a superfície de on-call, não pedir que as pessoas façam mais.
On-call com shadow: alguém novo em on-call passa a primeira rodada acompanhando ("shadowing") alguém mais experiente antes de ser on-call primário. Reduz a ansiedade e garante transferência de conhecimento organizada em vez de ad hoc durante incidentes.
Alertas com alta relação sinal-ruído: se metade dos alertas de on-call são falsos positivos ou não-acionáveis, o on-call se torna insensível a alertas reais. A qualidade dos alertas é tão importante quanto sua existência. Ver Módulo 10 · Alertas e On-call.
Compensação por on-call: on-call fora do horário de trabalho deve ser compensado — seja com folga adicional, bônus, ou horas em banco. On-call não-compensado é exploração e sinaliza que a empresa não leva a sério a saúde do time.
Post-mortems blameless: quando algo dá errado, a análise deve focar em sistemas e processos, não em pessoas. Se a culpa recai em indivíduos, as pessoas escondem erros em vez de reportar — e os problemas sistêmicos não são corrigidos. Ver Módulo 08 · Blameless Postmortem.
Pager documentation — o que o on-call precisa saber
Quando um alerta dispara às 3h da manhã, o engenheiro de plantão precisa ter acesso imediato a:
- O que esse serviço faz: uma frase. Se o engenheiro não sabe para que serve, não sabe o impacto do incidente.
- Quem é o dono: nome do time e canal do Slack. Para quem escalar se não resolver em 15 minutos.
- Como acessar logs e métricas: links diretos para o dashboard correto, não "está no Grafana".
- Como fazer rollback: o processo exato, com comandos. Não "reverse the deploy" — qual comando, qual namespace, qual verificação de saúde.
- O runbook do alerta: link direto para o runbook específico do alerta que disparou.
Ferramentas como PagerDuty e OpsGenie permitem anexar runbooks diretamente ao alerta — quando o pager toca, o link para o runbook específico já está na notificação. Essa integração é o que separa "documentação que existe" de "documentação que é usada".
Capacity planning — antecipar antes de escalar em pânico
Capacity planning é o processo de antecipar necessidades de recursos antes que se tornem um problema. A ausência de capacity planning se manifesta em dois padrões igualmente custosos:
- Over-provisioning crônico: sempre ter "memória suficiente para qualquer cenário" — o que resulta na fatura de cloud discutida em FinOps
- Under-provisioning em crescimento: o sistema fica lento ou cai porque o crescimento de usuários não foi antecipado, resultando em incidentes de alto impacto
O processo de capacity planning em cinco etapas:
- Medir o baseline atual: CPU, memória, e throughput médio e no pico — por serviço, não apenas por cluster
- Projetar crescimento: se o número de usuários cresce 20%/mês, quais recursos crescem proporcionalmente? (nem todos: dados podem crescer mais rápido que requests; requests podem crescer mais rápido que CPU se o caching melhorar)
- Identificar limites: onde o sistema vai saturar? Com quantos usuários o banco de dados vai precisar de read replicas? Quando o Redis vai precisar de clustering?
- Planejar com antecedência: mudanças de arquitetura significativas (sharding de banco, migração de Redis para cluster) levam meses — precisam ser planejadas com 6-12 meses de antecedência
- Load test periódico: validar as projeções com testes de carga antes que o tráfego real chegue; o resultado vira o novo baseline
Rotação de certificados e chaves — não deixar para a crise
Certificados TLS que vencem causam outages evitáveis. Chaves de API que nunca são rotacionadas são um risco de segurança que piora com o tempo — cada mês adicional é um mês a mais que uma chave comprometida pode estar em uso sem que ninguém saiba.
Automação é a única solução que escala:
- TLS: cert-manager com Let's Encrypt renova automaticamente 30 dias antes do vencimento. Para certificados gerenciados fora do Kubernetes, um alerta com 60 dias de antecedência — não 7 dias, que não é tempo suficiente para resolver um problema de DNS validation em uma organização grande com change management
- Secrets: HashiCorp Vault com dynamic secrets gera credenciais de banco com TTL de horas — a rotação é automática porque cada credencial tem vida curta. Para secrets estáticos, uma política de rotação trimestral automatizada via Vault, AWS Secrets Manager, ou Kubernetes External Secrets
- SSH keys: políticas de no maximum age com rotação automática via ferramentas como Teleport ou AWS SSM Session Manager — que eliminam SSH keys permanentes inteiramente, substituindo por sessões com auditoria
- API keys de terceiros: inventário centralizado de todas as keys externas com data de criação — alerta 30 dias antes da expiração, com owner responsável pela renovação
O incidente de certificado vencido é quase sempre anunciado pela ferramenta de monitoramento 30-60 dias antes. O problema não é falta de aviso — é que o alerta vai para um channel que ninguém monitora com frequência suficiente, ou a rotação "vai ser feita quando tiver tempo". A correção é tornar a rotação automática ou atribuir ownership explícito com accountability.
Toil — o inimigo da maturidade operacional
Google SRE define toil como trabalho operacional com quatro características: manual, repetitivo, automatizável, e que não agrega valor proporcional ao esforço. Exemplos clássicos:
- Reiniciar manualmente um processo que falha com regularidade conhecida
- Aplicar patches manualmente em múltiplos servidores quando poderia ser um pipeline
- Responder a um alerta que é sempre falso positivo mas não foi desabilitado porque "ninguém tem tempo"
- Processar tickets manuais de aprovação de acesso que poderiam ser self-service com RBAC adequado
- Copiar dados entre sistemas porque a integração nunca foi automatizada
Toil não é zero — sempre haverá algum trabalho manual. O problema é quando toil ocupa >50% do tempo do time de operações: não sobra tempo para automação, melhorias de confiabilidade, ou trabalho de engenharia que reduziria o toil futuro. O time fica preso em um loop de "estamos muito ocupados com incidentes para corrigir o que causa os incidentes".
A métrica prática: em cada retrospectiva de on-call (semanal ou quinzenal), identificar os três alertas mais frequentes. Se o mesmo alerta aparece mais de 2x, ou o mesmo toil aparece mais de 3x, é candidato para automação ou eliminação. O SRE que reduz a frequência de um alerta de 10x/semana para 1x/semana liberou 9 interrupções noturnas — esse é o trabalho de maior valor operacional.
Times com alta maturidade operacional entregam mais features, têm menor turnover, e têm menos incidentes — não apesar de investir em operação, mas por causa disso. O investimento em runbooks, automação de toil, e on-call saudável libera tempo de engenharia que estava sendo consumido por trabalho reativo. A equação é contraintuitiva: gastar 20% do tempo em melhorias de operabilidade resulta em mais capacidade de entrega, não menos, porque o trabalho não-planejado (incidentes, toil) se reduz proporcionalmente. Empresas como Google, Netflix e Spotify publicam seus modelos de SRE precisamente porque maturidade operacional se traduz diretamente em velocidade de entrega.
Decisões de engenharia
Use runbook por alerta quando o alerta é recorrente e o procedimento de resposta é estável. Use wiki para documentação arquitetural, contexto histórico, e onboarding. O erro mais comum: colocar runbooks no Confluence onde ficam desatualizados e são difíceis de encontrar às 3h. Runbooks devem estar integrados ao sistema de alertas (PagerDuty runbook URL) — não em uma wiki que requer login e busca.
Regra prática: se não tem um link direto do alerta para o runbook, o runbook não será usado em produção.
Compensação financeira (adicional de sobreaviso, bônus por incidente) é mais simples administrativamente mas pode criar incentivos perversos — engenheiros que preferem incidentes noturnos por serem rentáveis. Folga compensatória (day-in-lieu após semana de on-call intensa) é mais sustentável e respeitosa do impacto biológico do sono interrompido.
Regra prática: use folga compensatória como padrão; adicione compensação financeira para on-call acima de um threshold (ex.: >3 páginas noturnas na semana).
Automatize toil quando: ocorre >3x/mês, leva >15 minutos por ocorrência, tem procedimento estável (não muda a cada vez), ou bloqueia outra pessoa. Aceite como manual quando: é incerto (requer julgamento humano), ocorre raramente (<1x/trimestre), ou o custo de automação excede o custo do toil em 12 meses.
Regra prática: se você executou o mesmo procedimento manual três vezes, na quarta escreva a automação antes de executar.
"Blameless" não significa "sem consequências" — significa que o foco é em falhas de sistema, não falhas de pessoa. Se alguém violou um processo deliberadamente e repetidamente, há responsabilização individual; isso é diferente de erro humano em sistema mal-projetado. O erro mais comum: usar postmortem blameless como escudo para evitar qualquer feedback individual, o que protege comportamentos problemáticos.
Regra prática: postmortem pergunta "o que no sistema tornou esse erro possível?" — não "quem errou?" nem "por que ninguém detectou antes?".
Perguntas de entrevista
Qual a diferença entre runbook e playbook, e quando usar cada um?
Um runbook é alerta-específico: descreve exatamente o que fazer quando um alerta específico dispara — com comandos concretos, verificações, e escalação. Um playbook é tipo-de-incidente genérico: descreve o processo geral para uma categoria de problema (ex.: "playbook de incidente de banco de dados" cobre vários cenários possíveis).
Runbooks são mais acionáveis às 3h da manhã porque eliminam a necessidade de julgamento sobre "por onde começar". Playbooks são úteis para situações novas onde não existe runbook. Em prática: começar com playbooks para categorias gerais, e criar runbooks específicos para os alertas mais frequentes — especialmente os que acordam pessoas.
O critério de qualidade de um runbook: um engenheiro que nunca viu o sistema consegue executá-lo sem perguntar a ninguém.
Como você estrutura on-call sustentável em um time de 3 engenheiros?
Com 3 engenheiros, on-call primário resulta em 1 semana de 3 — acima do limite saudável de 1 semana de 4. As opções são:
- Reduzir a superfície: identificar quais alertas realmente requerem resposta fora do horário comercial versus quais podem esperar até de manhã. Muitos alertas noturnos são sobre problemas que não afetam usuários naquele momento.
- On-call com horário comercial apenas: se o produto não tem SLA 24/7, on-call só durante o expediente é uma opção legítima — com escalação automática para o time de operações se algo crítico acontecer fora do horário.
- Crescer o time antes de assumir mais sistemas: a responsabilidade de on-call deve crescer proporcionalmente ao time, não ao número de sistemas.
O anti-padrão mais perigoso: aceitar on-call insustentável como "temporário" — ele se torna permanente enquanto os melhores engenheiros saem.
O que é toil segundo Google SRE e como você o mede no seu time?
Google SRE define toil como trabalho operacional que é: manual (requer intervenção humana), repetitivo (acontece regularmente), automatizável (poderia ser feito por uma máquina), tático (reativo, não estratégico), e que não tem valor duradouro (não melhora o sistema, apenas o mantém funcionando).
Para medir no time: retrospectiva de on-call quinzenal onde o time registra cada tarefa operacional com tempo gasto. Ao final do mês, calcular a porcentagem do tempo operacional vs. tempo de engenharia (melhoria de sistemas). Meta do Google SRE: manter toil abaixo de 50% do tempo do time de operações.
Métricas concretas: número de alertas por semana (tendência), tempo médio para resolver cada tipo de alerta, lista de "tarefas manuais recorrentes" atualizada a cada sprint. Qualquer item que aparece 3x na lista é candidato imediato para automação.
Como você implementa postmortem blameless na prática sem que vire reunião sem conclusão?
Postmortem blameless tem estrutura definida e entregáveis obrigatórios — não é uma conversa informal. Estrutura que funciona:
- Timeline factual: o que aconteceu, quando, em ordem cronológica. Sem julgamentos ainda — só fatos observáveis.
- Análise de causa raiz com 5 Whys: para cada falha na timeline, perguntar "por que isso foi possível?" até chegar à causa sistêmica. O resultado deve ser falhas de processo, design, ou ferramental — não "o engenheiro errou".
- Action items com owner e data: cada insight do postmortem vira um action item específico, com uma pessoa responsável e uma data de entrega. Sem action item, o postmortem foi uma conversa, não uma melhoria.
- Compartilhamento amplo: postmortems devem ser lidos por mais pessoas do que participaram do incidente — cada postmortem é aprendizado que pode prevenir o próximo incidente em outro time.
O critério de sucesso: após o postmortem, os action items reduzem a probabilidade do mesmo tipo de incidente acontecer novamente. Se não há action items concretos, o postmortem falhou.
Como você faz capacity planning para um serviço que vai crescer 10x em 6 meses?
Um crescimento 10x em 6 meses é diferente de 10x em 3 anos — requer ação imediata em vez de planejamento gradual. O processo:
1. Perfil de carga atual: medir CPU, memória, IOPS de disco, throughput de rede, e conexões de banco — por serviço, no pico atual. Identificar qual recurso satura primeiro (o "gargalo primário").
2. Projeção linear vs. não-linear: requests de usuário crescem linearmente? Dados crescem mais rápido (acúmulo)? Cache hit rate vai cair (usuários novos = cold cache)? A maioria dos serviços tem componentes que escalam linearmente e componentes que escalam não-linearmente.
3. Identificar o "cliff": em que ponto o banco precisa de read replicas? Em que ponto o Redis precisa de cluster mode? Em que ponto o sharding de banco se torna necessário? Essas mudanças levam 2-4 meses para implementar com segurança — precisam ser iniciadas antes de chegarem ao limite.
4. Load test imediato: com crescimento 10x em 6 meses, fazer um load test de 5x agora é prioritário — para descobrir o gargalo com tempo de agir, não durante um incidente de produção.
Exercícios práticos
Identifique o alerta que mais acorda seu time (ou que mais gera tickets manuais). Escreva um runbook completo seguindo a estrutura: gatilho, impacto, diagnóstico (passos numerados com comandos exatos), mitigação por caso, escalação, e histórico. Publique o link do runbook no campo correto do seu sistema de alertas (PagerDuty, OpsGenie, ou equivalente) para que apareça na próxima notificação.
Critério: um colega que nunca resolveu esse alerta executa o runbook sem fazer perguntas e resolve ou escala corretamente em menos de 15 minutos. Valide com um game day ou pair on-call.
Colete dados das últimas 4 semanas de on-call: número de páginas por semana por pessoa, horário de cada página (dentro vs. fora do expediente), tempo médio de resolução por tipo de alerta, e alertas que aparecem mais de 2x. Calcule a carga de on-call per capita. Se o on-call primário excede 1 semana de 4, identifique os 3 alertas que mais contribuem para a sobrecarga e proponha um plano de redução (automação, remoção de alerta de baixo valor, ou melhoria do sistema).
Critério: apresentação para o time com dados, top-3 alertas por frequência, e pelo menos um action item por alerta com owner e data de entrega.
Faça um inventário completo de certificados TLS, chaves de API de terceiros, e credenciais de banco do seu time: para cada item, registre data de criação, data de expiração, owner responsável, e se a rotação é automática ou manual. Para qualquer item manual: implemente alertas com pelo menos 60 dias de antecedência. Para o certificado TLS mais crítico: configure ou valide que cert-manager (ou equivalente) renova automaticamente e emita um alerta se a renovação automática falhar.
Critério: nenhum certificado ou chave vence nos próximos 90 dias sem alerta configurado, e pelo menos um certificado crítico tem renovação automática com alerta de falha verificado em staging.
Escolha um incidente das últimas 8 semanas (pode ser um incidente menor). Conduza um postmortem com estrutura completa: timeline factual com timestamps, análise de causa raiz com 5 Whys até chegar à causa sistêmica, e action items com owner e data. Execute pelo menos 2 dos action items. Compartilhe o postmortem com um time além do seu para maximizar o aprendizado.
Critério: o documento de postmortem tem pelo menos 3 action items concretos (não "monitorar melhor", mas ações específicas como "adicionar alerta para X com threshold Y"), 2 já concluídos, e o documento foi compartilhado além do time imediato.
Escolha um serviço que você opera. Meça o baseline atual de CPU, memória, e throughput no pico. Projete os recursos necessários para 3x de tráfego. Identifique em que ponto cada componente satura (banco, cache, pods). Escreva um capacity plan com: projeção de crescimento por componente, identificação do gargalo primário, ações necessárias (e quando precisam ser iniciadas para estar prontas a tempo), e um load test validando a projeção atual.
Critério: o plan identifica o componente que satura primeiro (com evidência do load test), e tem pelo menos uma ação de melhoria de infraestrutura agendada com antecedência suficiente antes do limite previsto.
Referências
- book Betsy Beyer et al. — Site Reliability Engineering
- book Google SRE Book — Chapter 5: Eliminating Toil
- book Google SRE Workbook — Chapter 8: On-Call
- article Alice Goldfuss — Build a Runbook
- article Increment Magazine — On-Call
- article PagerDuty — Postmortem Templates and Best Practices
- docs HashiCorp Vault — Dynamic Secrets
- docs cert-manager — Automatic Certificate Renewal
- book Matthew Skelton & Manuel Pais — Team Topologies
- article Netflix Tech Blog — Chaos Engineering
- article Charity Majors — On-Call Shouldn't Suck
- book Liz Fong-Jones & Steven Thurgood — Practical Guide to SRE