Tentei tirar férias em março de 2024. Durei quatro dias.

No segundo dia, respondi "só uma perguntinha rápida" no Slack. No terceiro, estava no lobby do hotel debugando um problema em produção — um problema nos servidores que atendiam clientes reais. No quarto dia, minha parceira disse: "Volta pro trabalho logo. Isso não é férias." Ela tinha razão.

O problema não era meu time. Eles eram competentes. O problema era que meu cérebro guardava a única cópia de metade das operações da empresa. Procedimento de deploy? Na minha cabeça. Fluxo de escalonamento de cliente? Na minha cabeça. Como reiniciar o serviço de billing quando ele trava? Também na minha cabeça. Eu não era indispensável porque era brilhante. Era indispensável porque não tinha documentado nada.

Seis meses depois, em setembro de 2024, tirei duas semanas inteiras. Sem notebook. Sem Slack. Sem "ligações rápidas". Nada quebrou.

Aqui está o que eu fiz nesses seis meses.

Passo 1: Descubra seu bus factor

"Bus factor" — uma métrica mórbida, mas útil: quantas pessoas do seu time precisam sumir para um processo parar completamente? Se a resposta é "uma", e essa uma é você, você não tem um sistema. Você tem uma situação de refém.

Listei todas as tarefas recorrentes que eu fazia e fiz uma pergunta: "Se eu sumisse amanhã, quem conseguiria fazer isso?"

Tarefa Bus factor Quem mais sabe?
Deploys em produção 1 (eu) Ninguém
Problemas de billing 1 (eu) Ninguém
Resposta a alertas de monitoramento 1 (eu) Ninguém
Planejamento de sprint 2 Co-lead
Code reviews 3 Qualquer dev sênior
Entrevistas de contratação 2 Co-lead

Três processos críticos com bus factor de 1. Três coisas que parariam completamente se eu comesse um sushi duvidoso no almoço. Isso não é operação. É um show solo vestido de equipe.

O conceito vem da cultura de software open-source, onde projetos vivem ou morrem pela quantidade de contribuidores. A página da Wikipedia sobre bus factor lista exemplos de grandes empresas de tecnologia — mesmo problema, escala maior.

Passo 2: Escreva runbooks, não documentação

Essa distinção importa. Documentação explica como algo funciona. Um runbook — um documento de procedimento operacional, uma receita passo a passo para lidar com uma situação específica — explica o que fazer.

Documentação: "O serviço de billing usa Stripe webhooks (notificações automáticas que o Stripe envia quando um evento de pagamento ocorre) para processar pagamentos. Eventos são enfileirados no Redis e processados pelo billing worker."

Runbook: "Quando o billing travar: 1) Verifique o tamanho da fila no Redis: redis-cli llen billing_queue. 2) Se a fila > 100, reinicie o billing worker: systemctl restart billing-worker. 3) Se o restart não limpar a fila em 5 minutos, verifique o dashboard do Stripe para webhooks com falha."

Percebe a diferença? Documentação exige entendimento. Runbook exige seguir instruções. Qualquer pessoa que consiga digitar comandos em um terminal — a interface de texto onde você digita comandos diretamente — pode seguir um runbook. Ela não precisa entender por que o Redis (um banco de dados em memória usado como fila de mensagens) está envolvido. Precisa saber o que digitar.

A PagerDuty, empresa que construiu seu negócio inteiro em torno de resposta a incidentes, publicou um ótimo guia sobre como escrever runbooks que cobre o mesmo princípio: otimize para ação, não para compreensão.

Escrevi runbooks para os três processos com bus factor 1. Cada um levou de 30 a 60 minutos. Aqui está o formato:

Runbook: Deploy em Produção

Quando usar:
Ao fazer merge na main e deploy em produção.

Pré-requisitos:
- Acesso SSH ao servidor de produção (peça ao time de infra se não tiver)
- Acesso ao canal #deploys no Slack

Passos:
1. Faça merge do PR na main
2. Aguarde os checks de CI passarem (GitHub Actions, ~5 min)
3. Conecte via SSH: ssh [email protected]
4. Execute: bash /srv/app/deploy.sh
5. Verifique a saúde: curl -s http://localhost:8080/health | jq .
6. Se o health check falhar: bash /srv/app/rollback.sh
7. Poste o resultado no #deploys

Se algo der errado:
- Script de deploy falhou → verifique os logs em /var/log/deploys/
- Health check retorna 503 → verifique qual subsistema falhou na resposta JSON
- Não consegue conectar via SSH → contate infra, verifique VPN
- Rollback falhou → ligue para o Capitan. Não pelo Slack. Telefone.

Escalonamento:
Se travou por mais de 15 minutos, ligue para o Capitan. Telefone, não Slack.

Sem teoria. Sem diagramas de arquitetura. Só: "quando isso acontecer, faça isso."

Passo 3: A semana-sombra

Escrever runbooks não é suficiente. Você precisa testá-los em seres humanos reais.

Fiz uma "semana-sombra" — uma semana onde fiquei disponível mas não encostei em nenhum dos três processos. Outra pessoa seguiu o runbook. Eu observei.

Resultados:

  • Runbook de deploy: Funcionou de primeira. A pessoa encontrou um erro de digitação no passo 4 (caminho de arquivo errado). Corrigiu em dois minutos.
  • Runbook de billing: Falhou no passo 3. Eu tinha escrito "verifique o dashboard do Stripe" mas nunca expliquei como fazer login. As credenciais estavam no meu gerenciador de senhas pessoal, não no compartilhado. Adicionei acesso compartilhado — problema resolvido.
  • Runbook de monitoramento: Funcionou parcialmente. Os passos estavam corretos, mas a interface da ferramenta de monitoramento tinha mudado desde que escrevi o documento. Atualizei os screenshots.

Todo runbook precisou de pelo menos uma correção. Isso é normal. Quando você escreve de memória, pula passos que parecem "óbvios" porque você já fez aquilo 500 vezes. A semana-sombra expõe essas falhas antes que elas importem às 3 da manhã de um sábado.

O time de SRE do Google — o grupo responsável por manter a infraestrutura do Google funcionando — aborda esse princípio no livro gratuito Site Reliability Engineering: documentação que não foi testada em condições reais é ficção.

Passo 4: A reunião de transferência de conhecimento

Para cada runbook, fiz uma sessão de 30 minutos de transferência de conhecimento. Não treinamento — transferência. Treinamento ensina habilidades. Transferência ensina contexto.

Estrutura:

  1. Percorram o runbook juntos (10 min) — a pessoa segue cada passo enquanto eu observo. Sem ajudar, a menos que esteja travada.
  2. Explique o "porquê" dos passos críticos (10 min) — não é necessário para executar, mas ajuda nas decisões de julgamento. "Reiniciamos o billing worker antes de investigar porque downtime custa $X por minuto. Velocidade primeiro, causa raiz depois."
  3. Perguntas e respostas (10 min) — as perguntas revelam exatamente o que você esqueceu de documentar.

Depois da reunião, a pessoa é dona do processo. Não "ajuda no processo". Dona. Eu me torno o backup, não o responsável principal.

Passo 5: O teste das férias

Dois meses depois da semana-sombra, tirei um feriadão prolongado sem notebook. Nenhuma emergência. Nenhuma "perguntinha rápida". Os runbooks seguraram.

Um mês depois, uma semana inteira de folga. Um problema menor: o runbook de monitoramento não cobria um caso específico — disco cheio em uma partição fora do padrão. A pessoa de plantão improvisou corretamente e adicionou o caso ao runbook depois. O sistema se melhorou sozinho sem mim. Esse é o sinal de que está funcionando.

Um mês depois: duas semanas completas. Zero incidentes que precisaram da minha participação. O time me mandou uma foto de um quadro branco que dizia: "Dia 9: Capitan não ligou. Achamos que o sistema funciona."

A parte que ninguém fala

Se tirar dos processos parece se tornar dispensável. E é. Esse é o ponto.

Mas isso ativa algo desconfortável — a parte da sua identidade que é amarrada a ser "a pessoa que sabe tudo". Aquela que todo mundo liga. Aquela que salva o dia.

Vou ser honesto: foi estranho quando deploys aconteceram sem mim. Quando problemas de billing foram resolvidos sem uma mensagem. Quando o alerta do servidor disparou e outra pessoa resolveu em 8 minutos. Parte de mim queria ser necessário.

Aqui está o que eu ganhei no lugar: liberdade. Não só liberdade de férias — liberdade no dia a dia. Parei de ser gargalo — o ponto único onde todas as decisões se acumulavam, esperando. Trabalho que antes ficava em fila atrás de mim agora acontecia em tempo real. O time ficou mais rápido. Eu passei a focar em decisões que realmente exigiam meu julgamento, em vez de tarefas que só exigiam minha memória.

Sua lista de ação

Em março de 2026, já repeti esse processo em três organizações diferentes. O padrão se mantém toda vez. Se você não consegue tirar duas semanas de folga sem que tudo desmorone, você não tem um sistema — você tem um hábito de estar sempre ocupado.

Aqui está seu checklist:

  1. Audite seu bus factor — liste toda tarefa recorrente, marque quem mais sabe fazer
  2. Escreva runbooks para tudo com bus factor = 1 (reserve 30–60 minutos por runbook)
  3. Faça uma semana-sombra — outra pessoa executa, você observa e corrige a documentação
  4. Faça reuniões de transferência de conhecimento — 30 minutos por processo, estruturada
  5. Teste com férias de verdade — feriadão prolongado primeiro, depois uma semana, depois duas

Escreva o runbook. Faça a semana-sombra. Tire as férias.

Você vai voltar descansado, e o time vai estar mais capaz do que quando você saiu. Isso não é ser dispensável. Isso é boa engenharia.