Você fez deploy na sexta-feira às 17h. Sabia que a migration não tinha rodado em staging — staging sendo a cópia do ambiente de produção onde você testa as coisas antes dos usuários reais verem. Disse pra si mesmo que já tinha feito isso centenas de vezes. Às 17:47, o banco de dados travou. Às 18:12, seu celular tocou. Você passou o sábado inteiro consertando o que uma verificação de dois minutos teria evitado. 📋

Eu sei disso porque já fui essa pessoa. E porque toda retrospectiva de ops que eu já li conta a mesma história: alguém pulou um passo que sabia que existia.

Um piloto, um rio e um checklist

Em 15 de janeiro de 2009, o Capitão Chesley Sullenberger pousou o voo 1549 da US Airways no Rio Hudson. Os dois motores falharam depois de atingir um bando de gansos. Todas as 155 pessoas sobreviveram. Quando os repórteres perguntaram como, ele não disse "experiência" nem "instinto". Disse que sua tripulação seguiu os checklists. O checklist de falha dupla de motor. O checklist de pouso na água. Passo a passo, sob pressão máxima.

A aviação faz isso desde 1935, quando um voo de teste do Boeing Model 299 caiu porque o piloto esqueceu de destravar uma trava de controle. O avião — um protótipo de bombardeiro com quatro motores — era literalmente complexo demais para a memória de uma pessoa. A resposta da Boeing não foi "contratar pilotos melhores". Foi um checklist simples num cartão de índice. A taxa de acidentes caiu. A indústria nunca mais olhou pra trás.

Seu deploy em produção — o processo de enviar código novo para os servidores que seus usuários realmente usam — não é menos complexo que o preflight de um bombardeiro de 1935. Sua resposta a incidentes não é menos crítica que um pouso de emergência na água. Mas você ainda está confiando na memória, na experiência e no "sempre fizemos assim".

Por que pessoas inteligentes pulam passos

Isso não é sobre inteligência. É sobre como o cérebro funciona.

Cirurgiões que usam checklists reduzem complicações em 35% e mortes em 47%, segundo um estudo marco de 2009 da OMS publicado no New England Journal of Medicine. São pessoas com uma década de formação médica. Elas não pulam passos porque são descuidadas — pulam porque a memória de trabalho humana cede sob pressão sequencial.

Atul Gawande, o cirurgião que escreveu The Checklist Manifesto, identificou dois tipos de falha:

Falhas de ignorância: Você não sabe o que fazer. Essas estão diminuindo conforme o conhecimento se espalha online.

Falhas de inaptidão: Você sabe exatamente o que fazer, mas falha na execução. Essas estão crescendo porque os sistemas ficam cada vez mais complexos. O conhecimento existe. A execução desmorona.

Em tech, quase todo incidente de produção que investiguei foi uma falha de inaptidão. Alguém sabia que deveria rodar a database migration — um script que atualiza a estrutura do banco para corresponder ao código novo — antes do deploy. Alguém sabia que deveria conferir o plano de rollback — os passos documentados para reverter à versão anterior caso tudo quebre. Alguém sabia que deveria verificar a feature flag — um toggle que mantém funcionalidades novas escondidas até você estar pronto.

Eles sabiam. Esqueceram. Às 23h, depois de um dia de 10 horas, pularam o passo 7 de 12 porque o cérebro sussurrou "já fiz isso centenas de vezes". 🫶

Três checklists que todo time de tech precisa

Aqui está o sistema. Três checklists. Cada um mira um momento específico onde a memória humana falha com mais força.

Checklist 1: O checklist de deploy

Esse roda antes de cada deploy em produção. Todo item é binário — sim ou não. Sem julgamentos subjetivos. Se qualquer item for "não", você para. Na aviação, um único "não" impede a decolagem. Seus deploys merecem o mesmo respeito.

## Pré-Deploy

- [ ] Todos os testes passam em staging
- [ ] Database migrations testadas em staging
- [ ] Plano de rollback documentado e testado
- [ ] Feature flags verificadas (funcionalidades novas desligadas por padrão)
- [ ] Dashboards de monitoramento abertos
- [ ] Engenheiro de plantão confirmado disponível
- [ ] Janela de deploy confirmada (não sexta às 17h)
- [ ] Mudança anunciada no canal do time
- [ ] Métricas do deploy anterior estáveis por 24h+

## Verificação Pós-Deploy

- [ ] Health check endpoints retornando 200
      (200 = o jeito do servidor dizer "tô de boa")
- [ ] Taxa de erros não elevada vs. baseline
- [ ] Fluxos-chave do usuário testados manualmente
- [ ] Métricas de performance dentro do range normal
- [ ] Deploy registrado no changelog

Meu time adotou esse checklist 18 meses atrás. Incidentes relacionados a deploy caíram de aproximadamente um a cada duas semanas para um a cada três meses. Não porque ficamos mais espertos. Porque paramos de pular passos. ⚙️

Checklist 2: O checklist de resposta a incidentes

Quando a produção quebra, seu cérebro entra em modo luta-ou-fuga. A adrenalina dispara. Você quer consertar AGORA. É exatamente quando checklists mais importam — porque o córtex pré-frontal, a parte responsável pelo pensamento sequencial, é a primeira coisa que a adrenalina desliga.

## Minuto 0-5: Avaliar
- [ ] Confirmar que o incidente é real (não um alarme falso do monitoramento)
- [ ] Severidade: S1 (queda total), S2 (parcial), S3 (degradado)
- [ ] Definir comandante do incidente (uma pessoa toma as decisões)
- [ ] Abrir canal dedicado ao incidente

## Minuto 5-15: Comunicar
- [ ] Status page atualizada
- [ ] Clientes afetados notificados (se S1/S2)
- [ ] Stakeholders internos notificados
- [ ] Previsão da próxima atualização comunicada
      (mesmo que seja só "estamos investigando")

## Minuto 15+: Corrigir
- [ ] Causa raiz identificada OU escalação acionada
- [ ] Correção testada em staging primeiro (se possível)
- [ ] Correção deployada em produção
- [ ] Monitoramento confirma resolução

## Pós-Incidente
- [ ] Post-mortem agendado em até 48 horas
- [ ] Timeline documentada enquanto a memória está fresca
- [ ] Action items atribuídos com donos e prazos
- [ ] Checklist atualizado se faltava algum passo

Esse último item é o motor silencioso de todo o sistema. Cada incidente vira feedback pro checklist. Falta algo? Adiciona. Algo redundante? Remove. O checklist é vivo — ele aprende com cada falha, pra você não precisar repetir. 🧘

Checklist 3: O checklist de code review

Code review — quando um colega lê seu código antes de ir pra produção — sem checklist é ler e torcer. Com checklist, é verificação sistemática de que categorias específicas de problemas não existem.

## Segurança
- [ ] Sem credenciais, API keys ou tokens hardcoded
- [ ] Input do usuário validado e sanitizado
- [ ] Queries no banco usam parameterized statements
      (previne SQL injection — um ataque onde alguém
       injeta comandos de banco num formulário de login)
- [ ] Autenticação verificada em todos os endpoints protegidos
      (endpoint = uma URL específica que seu app responde)

## Confiabilidade
- [ ] Tratamento de erros cobre os casos de falha
- [ ] Chamadas a APIs externas têm timeouts definidos
      (API = uma forma de programas se comunicarem)
- [ ] Queries no banco têm indexes pra tabelas grandes
      (index = um atalho de busca, tipo o índice de um livro)
- [ ] Sem queries N+1 (buscar dados relacionados
      um registro por vez em vez de numa batch eficiente)

## Manutenibilidade
- [ ] Funções fazem uma coisa só
- [ ] Nomes de variáveis descrevem o que guardam
- [ ] Lógica complexa tem comentários explicando o PORQUÊ
- [ ] Testes cobrem os novos caminhos de código

Como fazer checklists pegarem

Criar checklists é fácil. A parte difícil — a parte que ninguém comenta — é evitar o abandono. Quatro regras:

Torne obrigatório, não opcional. Integre o checklist no seu pipeline de deploy — a sequência automatizada de passos que compila e envia seu código. O botão de deploy fica cinza até cada item ser marcado. Um checklist "recomendado" é usado 80% das vezes, o que significa que falha justamente quando mais importa: sob pressão, de madrugada, quando você está cansado.

Mantenha curto. Pesquisas na aviação mostram que checklists com mais de 9 itens têm queda dramática na adesão. Se o seu tem 30 itens, divida em fases. Cada fase: 5-9 itens. Um checklist curto que é seguido bate um longo que é ignorado.

Revise trimestralmente. Remova itens que nunca pegam nada. Adicione itens de incidentes recentes. Um checklist desatualizado gera desprezo — as pessoas param de levar a sério quando metade dos itens parece irrelevante pro stack atual.

Deixe visível. Fixe no canal do time. Coloque na interface da ferramenta de deploy. Imprima e cole do lado dos monitores. O melhor checklist é aquele que você vê sem precisar procurar.

Quanto isso custa

Vamos ser honestos sobre os tradeoffs. Checklists adicionam fricção. Um checklist de deploy adiciona 5-10 minutos a cada deploy. Um checklist de resposta a incidentes parece agonizantemente lento quando a produção está pegando fogo. Checklists de code review fazem reviews demorarem mais.

Essa fricção é o objetivo. É lentidão deliberada em momentos onde velocidade causa dano. Um piloto não apressa o preflight porque os passageiros estão embarcando. Você não deveria apressar um deploy porque o PM pediu pra hoje.

O outro custo é manutenção. Um checklist sem manutenção é pior que nenhum checklist — ele ensina seu time que processo é teatro. Alguém precisa ser dono de cada checklist, revisar trimestralmente e atualizar depois de cada incidente. Isso dá trabalho de verdade.

Agora você é perigoso

Lembra daquele deploy de sexta? Aquele em que você pulou a verificação de staging e passou o sábado reconstruindo um banco de dados?

Agora você tem três checklists que previnem exatamente esse tipo de falha. Não por disciplina, não por força de vontade — por um sistema que assume que seu cérebro vai falhar sob pressão e pega antes que importe.

Checklists não são sobre disciplina. São sobre humildade. Um reconhecimento de que seu cérebro — afiado como é — não consegue executar 15 passos sequenciais sob estresse de forma confiável sem pular um. Pilotos sabem disso. Cirurgiões sabem disso. Astronautas sabem disso.

Tech é a única indústria onde profissionais experientes ainda dizem "não preciso de checklist, já fiz isso mil vezes". Isso não é confiança. É a frase que antecede todo incidente evitável.

Escreva o checklist. Siga o checklist. Atualize o checklist. Seu ambiente de produção vai agradecer. E a pessoa que é acionada às 2 da manhã também — e essa pessoa pode ser você. 🛁