Pular para o conteúdo

Toil

Iniciante10 min de leituraorganizacao

Toil é um termo específico, e a precisão importa — porque “trabalho chato” e “trabalho de operação” não são sinônimos dele, e confundir os três leva a automatizar a coisa errada.

Toil é o trabalho que reúne estas características:

  • Manual — alguém executa passo a passo.
  • Repetitivo — já foi feito antes, será feito de novo.
  • Automatizável — uma máquina poderia fazer.
  • Reativo — responde a um evento, não a um plano.
  • Sem valor duradouro — o serviço não fica melhor depois.
  • Cresce com o sistema — dobra de tamanho quando o sistema dobra.

Esse último critério é o mais importante. Trabalho que escala linearmente com o crescimento é o que impede o time de crescer sem contratar na mesma proporção.

  • Investigar um incidente novo. É reativo, mas exige julgamento e produz aprendizado.
  • Escrever automação. Tem valor duradouro, por definição.
  • Revisar arquitetura, planejar capacidade. Proativo e estratégico.
  • Trabalho chato mas único: uma migração grande, feita uma vez.
  • Overhead administrativo: reuniões, relatórios. É outro problema, com outra solução.

A pergunta que separa: se o sistema dobrar de tamanho, esta tarefa dobra? Se sim, é toil.

Sem número, a conversa vira opinião — e a resposta padrão da liderança é que “sempre foi assim”. Duas semanas de registro resolvem:

tarefa | vezes | min/vez | total | automatizável?
------------------------------|-------|---------|-------|---------------
liberar acesso a namespace | 14 | 12 | 168 | sim
reiniciar serviço travado | 9 | 8 | 72 | sim (corrigir a causa)
criar ambiente de teste | 6 | 45 | 270 | sim
rodar relatório mensal | 1 | 120 | 120 | sim
investigar alerta falso | 22 | 10 | 220 | não: apagar o alerta

Ordene por vezes × minutos. O topo é o seu backlog de automação, e a tabela é o argumento objetivo para reservar tempo de engenharia.

A referência do livro de SRE do Google é um teto de 50% do tempo em toil. O número exato importa menos que ter um teto declarado: sem limite, o toil ocupa todo o espaço disponível, porque é sempre urgente.

O reflexo é automatizar tudo, e ele erra com frequência. Antes de escrever script, considere:

Eliminar. Por que o serviço trava toda semana? Corrigir a causa vale mais que automatizar o reinício. Automatizar um problema recorrente é institucionalizá-lo.

Simplificar. Talvez a tarefa exista por causa de um processo que ninguém revisita. Um alerta falso que dispara 22 vezes deve ser apagado, não automatizado.

Delegar ao autoatendimento. Nem tudo precisa de automação sofisticada: um template, uma permissão bem configurada ou uma página de documentação eliminam a fila sem código.

Aceitar. Tarefa de dez minutos, uma vez por trimestre, não vale um script para manter. Automação também é código: tem bug, dependência e manutenção.

E há uma armadilha conhecida: automação frágil vira toil de segunda ordem. O script quebra a cada mudança e alguém passa a manter o script em vez de fazer a tarefa — trabalho igual, com uma camada a mais.

Reduzir toil a zero não é meta realista nem desejável. Sempre haverá trabalho operacional, e parte dele é como o time aprende sobre o sistema — quem nunca opera perde o contato com a realidade do que escreveu.

O objetivo é mantê-lo abaixo de um limite acordado, e garantir que ele não cresça na mesma proporção do sistema. Se o time dobra de tamanho a cada vez que o número de serviços dobra, o problema não é falta de gente: é toil não endereçado.

Por fim, cuidado com o uso político do termo. “Isso é toil” às vezes vira eufemismo para “não quero fazer”. Toil é definido pelos critérios acima, não pelo gosto de quem executa.