A pergunta que ninguém responde até serem 23h40 de uma sexta-feira
A automação leva oito meses a funcionar e ninguém voltou a falar dela. É exatamente isso que se comprou. O problema é que esse silêncio se confunde com uma resposta a uma pergunta que nunca se fez: se isto cair, quem é que pega nela? E a pergunta responde-se sozinha, mal, na primeira noite em que o fluxo de encomendas deixa de criar guias de remessa: alguém escreve no grupo de WhatsApp da equipa, outro alguém responde às sete da manhã, e pelo caminho ficaram por processar catorze encomendas que ainda ninguém sabe que existem.
A prevenção e o suporte das automações são a parte do dia dois que quase ninguém compra porque não se vê na demo. Não é um serviço 24×7 com central telefónica. São quatro decisões tomadas a frio —o que é grave, a quem se liga, o que faz essa pessoa quando chega e o que se faz entretanto— escritas num sítio onde as encontre alguém que não sejas tu. Sem elas, o teu plano de contingência é a tua memória, e a tua memória vai de férias em agosto.
Severidades a sério: o que justifica ligar a alguém e o que espera até amanhã
A primeira decisão não é a quem ligas: é quando é que se liga a alguém. Sem essa linha escrita, acontecem as duas coisas más ao mesmo tempo. Tudo parece urgente —e a equipa aprende a ignorar os avisos porque saltam por tudo e por nada— ou nada parece urgente, e a falha que custava dinheiro descobre-se na segunda-feira.
A indústria de operações leva décadas a resolver isto com níveis de severidade, e a prática estabelecida é sensata: a PagerDuty recomenda mapear cada nível diretamente na política de escalonamento e aviso, e avisa que seis ou sete níveis que ninguém sabe distinguir produzem paralisia de classificação: entre três e cinco é o ponto ideal. Numa empresa que não tem equipa de prevenção, três chegam e sobram.
| Nível | O que significa cá em casa | O que se faz |
|---|---|---|
| Grave | Está a perder-se dinheiro ou compromisso com cliente neste momento: não saem encomendas, não se cobram faturas, não se responde a ninguém. | Avisa-se a pessoa de prevenção na hora, seja a hora que for. Ativa-se o plano manual. |
| Maçador | O processo funciona a meias ou só para uma parte: uma integração em baixo com saída alternativa, um lote que não foi processado mas que se pode reprocessar. | Regista-se e pega-se nele logo à primeira hora do dia útil seguinte. Não se liga a ninguém de noite. |
| Feio mas pode esperar | Alguma coisa está mal e não tem consequência imediata: um relatório que não foi gerado, um campo que chega vazio num sítio que ninguém olha até ao fecho do mês. | Entra na fila de manutenção da semana. |
O critério que faz esta tabela funcionar não é técnico, é de negócio: a severidade define-se pelo dano que faz cada hora que passa, não pelo estado em que o sistema está. Um fluxo completamente morto que só move um relatório interno é «feio mas pode esperar». Um fluxo que funciona a 90% mas está a mandar propostas com o preço errado é grave. Escreve a tabela com essa lógica e com os teus processos pelo nome —«encomendas web», «faturação», «avisos a clientes»— e não com categorias abstratas. Uma severidade que é preciso interpretar às 23h40 não serve para nada.
A prevenção que cabe numa empresa pequena (não copies o modelo de uma big tech)
É aqui que a maioria dos artigos se torna inútil: descrevem rotações semanais, escalonamentos de três níveis e pagers. Tu tens duas pessoas que sabem mexer nos fluxos e uma delas és tu. A prevenção realista a essa escala tem quatro peças e nenhuma custa dinheiro.
- Um nome por semana, escrito. Não «a equipa», não «quem vir primeiro». Uma pessoa concreta por semana, num calendário partilhado, com as semanas já distribuídas até ao fim do trimestre. O valor não está na rotação: está em que às 23h40 ninguém tenha de decidir quem é que vai incomodar.
- Um canal que interrompa mesmo. O email não acorda ninguém e um canal de Slack silenciado também não. O aviso de severidade grave tem de chegar por algo que toque: uma chamada, um SMS, uma notificação configurada como exceção ao modo «não incomodar». O resto pode ir pelo canal do costume.
- Um suplente, e só um. Se quem está de prevenção não responder dentro de um prazo que tu decides —quinze minutos é razoável—, avisa-se o suplente. Sem cadeia de quatro níveis: numa empresa de vinte pessoas, o terceiro nível é sempre a mesma pessoa.
- Uma regra de compensação explícita. Se alguém atende um incidente num sábado, isso paga-se ou compensa-se com descanso. A prevenção que assenta na boa vontade dura exatamente até à segunda vez que alguém perde um jantar.
E uma decisão honesta antes de montar o que quer que seja: precisas mesmo de prevenção noturna? Se os teus processos críticos só têm consequência em horário comercial —faturação, encomendas B2B, avisos internos—, a resposta certa é não ter prevenção de noite e dizê-lo em voz alta, em vez de ter uma prevenção informal que ninguém aceitou. O que precisas sempre é de que a falha fique registada e visível logo à primeira hora. No n8n isso monta-se com um fluxo de erro único ligado a todos os outros: a documentação oficial descreve como um só Error Workflow com nó Error Trigger se reutiliza em todos os fluxos de produção, sem construir o aviso um a um. O Make e o Zapier têm equivalentes próprios.
O runbook de uma página: a única coisa que faz outra pessoa responder
Prevenção sem runbook é um telefone que toca para avisar alguém de que não pode fazer nada. Um runbook é a ficha de uma página —uma, não doze— que transforma «o fluxo de encomendas está em baixo» numa sequência que pode ser executada por quem não o construiu. A PagerDuty di-lo sem adornos: os incidentes de severidade alta devem apontar para um runbook para que quem responde não improvise.
Um por fluxo crítico. Não por fluxo: por fluxo crítico, que numa empresa normal são três a cinco. Cada ficha responde a seis perguntas e mais nada:
- O que faz este fluxo e o que acontece se estiver parado. Duas linhas de negócio, não de técnica. «Cria a guia de remessa no ERP quando entra uma encomenda web. Se estiver parado, as encomendas entram mas não se preparam.»
- Como se verifica em trinta segundos se está vivo. O link exato para o histórico de execuções, e o que se olha lá.
- As três causas que já aconteceram antes, e o respetivo arranjo. Credencial caducada, quota do fornecedor esgotada, campo que chega vazio. Com o clique concreto, não com a teoria.
- Como se para por completo. O botão, o interruptor, o sítio. Parar é uma ação legítima e muitas vezes a certa: um fluxo parado faz menos estragos do que um fluxo que decide mal.
- O que se faz entretanto (o plano manual, secção seguinte).
- A quem se escala se nada disto resultar, com nome e telefone.
O runbook é primo direito da documentação do fluxo, mas não é a mesma coisa e convém não os misturar: documentar as tuas automações serve para que alguém as possa manter e alterar com calma; o runbook serve para os quinze minutos a seguir à queda. Um lê-se sentado, o outro de pé. Se tentares que o mesmo documento faça as duas coisas, acabas com doze páginas que ninguém abre às 23h40.
O plano manual: continuar a faturar à mão não é um fracasso, é o plano
Esta é a peça que mais gente salta, e a que mais dinheiro salva. Enquanto a automação está em baixo, o negócio continua. As encomendas continuam a entrar, os clientes continuam a escrever e as faturas continuam a vencer. A pergunta não é «quando é que arranjamos isto?», é «como é que continuamos a operar até estar arranjado?».
Há aqui um reflexo cultural que atrapalha: voltar ao processo manual vive-se como uma derrota, como admitir que a automação não valia nada. É ao contrário. Um sistema sério tem modo degradado; o que não o tem não é mais automático, é mais frágil. Escreve, para cada fluxo crítico, a versão à mão do processo: quem a executa, onde aponta o que vai fazendo e qual é o volume máximo que aguenta antes de ser preciso começar a dizer que não.
Essa última parte é a que quase ninguém escreve e a que decide o resto: o plano manual tem um teto. Doze encomendas por dia metem-se à mão; quatrocentas não. Saber o teu número de antemão muda a conversa durante a queda, porque transforma «aguentamos» em «aguentamos até às duas da tarde, a partir daí paramos de aceitar encomendas web». E o registo paralelo do que se fez à mão não é burocracia: é o que torna possível a reconciliação posterior sem duplicar nada, um trabalho com mecânica própria que está desenvolvido em recuperar os dados perdidos numa automação que caiu.
O postmortem de três linhas: porque é que sem ele a mesma queda volta em março
O incidente termina, toda a gente respira e ninguém escreve nada. Três meses depois volta a acontecer o mesmo e a pessoa que o arranjou da primeira vez já não se lembra de como. É esse o custo real de saltar o postmortem, e não se paga no momento: paga-se na repetição.
Não é preciso o documento de dez páginas de uma empresa de milhares de pessoas. O livro de SRE da Google —onde nasceu boa parte desta prática— insiste em duas coisas que escalam para baixo: que seja sem culpados, centrado em porque é que o sistema permitiu a falha e não em quem a cometeu, e que se possa começar com um procedimento muito básico e ir afinando. À tua escala isso são três linhas, escritas no próprio dia, no sítio onde vive o runbook:
- O que aconteceu e desde quando. Com hora de início real, não de deteção. A diferença entre as duas é, quase sempre, a descoberta mais útil de todo o exercício.
- O que o arranjou. A ação concreta. Isto vai direto para a secção de causas conhecidas do runbook, e é o que faz com que a segunda vez demore dez minutos em vez de três horas.
- O que mudámos para não voltar a acontecer. Uma só coisa, com dono e data. Se não houver nenhuma, escreve isso também: «aceitamos que pode repetir-se» é uma decisão válida e consciente; «logo se vê» não é.
Quando essas três linhas se acumulam durante um ano, deixas de ter anedotas e passas a ter um mapa: que fluxo cai mais, que fornecedor te custou mais horas, que arranjo aplicaste seis vezes sem resolver a causa. Esse mapa é o que transforma a manutenção reativa em manutenção a sério, a que se antecipa.
O que montar esta semana
Tudo isto cabe numa tarde se o fizeres por esta ordem e não tentares fazê-lo perfeito: a tabela de três severidades com os teus processos pelo nome; o calendário com um nome por semana e um canal que toque; o runbook de uma página dos teus dois fluxos mais críticos; a versão manual desses dois processos com o teto escrito; e o hábito das três linhas depois de cada queda. Nada disto exige ferramenta nova. Exige que alguém o decida a frio e o deixe escrito onde se encontre.
A fronteira honesta: isto está pensado para quem tem uns quantos fluxos e quer dormir descansado sem montar um departamento. Quando o que está por baixo são dezenas de processos, várias equipas e agentes que decidem sozinhos, a resposta a incidentes deixa de ser uma ficha e passa a ser uma função com turnos, acordos de nível de serviço e mecânica de escalonamento própria: isso é gestão de incidentes de agentes de IA. E se o que queres é que as severidades, a prevenção, os runbooks e o plano manual fiquem montados sobre os teus fluxos atuais e operados por alguém que não és tu, isso é automação de operações: o dia dois, feito, em vez de uma intenção escrita num guardanapo.