Toil: o Trabalho Invisível que Consome seu Time (e a Regra dos 50%)

Existe um tipo de trabalho que consome o dia inteiro de um time de operações sem deixar rastro de progresso. No fim da semana, todo mundo está exausto, os tickets foram resolvidos, os alertas foram atendidos, os acessos foram concedidos, os certificados foram renovados — e mesmo assim o sistema não ficou melhor do que estava na segunda. Nenhuma daquelas horas construiu algo que dure. Na semana seguinte, os mesmos tickets, os mesmos alertas, os mesmos acessos, os mesmos certificados voltam a bater na porta. Esse trabalho tem nome dentro da disciplina de SRE: chama-se toil, e reconhecê-lo é o primeiro passo para escapar da esteira que ele impõe.

Toil não é sinônimo de "trabalho chato" nem de "overhead administrativo", e essa confusão faz muita gente subestimá-lo. Toil é uma categoria precisa, com características bem definidas, e o motivo de a engenharia de confiabilidade se importar tanto com ele é econômico e humano ao mesmo tempo: toil que cresce sem controle sufoca a capacidade de melhorar o sistema, transforma engenheiros em operadores manuais e, no limite, quebra as pessoas. Este guia define toil com rigor, mostra como medi-lo, explica a famosa regra dos 50% e oferece um método para decidir o que automatizar primeiro — sem cair na armadilha de automatizar a coisa errada e criar um problema novo.

O que é toil, exatamente#

Toil é o trabalho ligado à operação de um serviço em produção que tem um conjunto específico de características. Quanto mais delas uma tarefa acumula, mais ela é toil:

• Manual. Exige que uma pessoa gaste seu tempo executando passos, em vez de uma máquina fazer.
• Repetitivo. Você faz a mesma coisa de novo e de novo. Não é um problema novo a cada vez; é o mesmo problema reaparecendo.
• Automatizável. Uma máquina poderia fazer isso. Se a tarefa exige julgamento humano genuíno, ela não é toil — é trabalho de engenharia. Toil é justamente o que não precisaria de gente.
• Reativo. Você responde a algo — um alerta, um pedido, um evento — em vez de agir de forma planejada e proativa. Correr atrás de interrupções é a assinatura do toil.
• Sem valor duradouro. Quando você termina, o serviço está exatamente onde estava. A tarefa não deixou o sistema melhor, mais rápido ou mais confiável. Você só o manteve funcionando por mais um instante.
• Escala linearmente com o serviço. Este é o critério mais traiçoeiro. Se dobrar o tamanho do serviço dobra a quantidade daquela tarefa, ela é toil. Trabalho que escala junto com o sistema é uma bomba-relógio: ele parece administrável hoje e engole o time amanhã.

Um exemplo torna concreto. Renovar um certificado que expira, manualmente, uma vez por serviço, é toil canônico: manual, repetitivo, automatizável, reativo (você faz quando vai expirar), sem valor duradouro (o serviço só continua funcionando) e linear (mais serviços, mais renovações). Compare com projetar um novo esquema de autoridade de certificação para a empresa: isso é trabalho de engenharia — exige julgamento, deixa um valor que dura, e não se repete a cada serviço. A mesma "área" (certificados) contém tanto toil quanto engenharia; o que os separa são as características, não o tema.

O que toil não é#

É igualmente importante saber o que fica de fora, para não rotular tudo de toil. Overhead administrativo — reuniões, relatórios, avaliações — é chato mas não é toil, porque não está ligado à operação do serviço e nem sempre é automatizável. Trabalho de resposta a um incidente agudo, com pessoas coordenando e tomando decisões sob pressão, também não é toil no sentido estrito: incidente é o evento agudo e imprevisível; toil é o desgaste crônico e previsível do dia a dia. E trabalho que exige julgamento real — analisar uma anomalia, decidir uma arquitetura, investigar um comportamento novo — é engenharia, por mais tedioso que às vezes pareça. Confundir "cansativo" com "toil" faz você tentar automatizar coisas que precisam de gente, e ignorar o toil de verdade que está te consumindo.

Medir toil: você não gerencia o que não mede#

Antes de combater toil, você precisa saber quanto dele existe, e a resposta quase sempre surpreende para pior. Há algumas formas práticas de medir. A mais simples é o survey periódico: pergunte ao time, com regularidade, que fração do tempo deles foi gasta em trabalho reativo e repetitivo versus trabalho de engenharia que deixa valor. A percepção agregada, mesmo imperfeita, já revela tendências. A mais rigorosa é o ticket accounting: categorizar os itens de trabalho (tickets, chamados, interrupções) e somar o tempo gasto na categoria toil. Se o seu sistema de tickets captura bem o trabalho operacional, ele é uma mina de dados sobre onde o toil se concentra — e quase sempre há um punhado de tarefas responsáveis pela maior parte da dor, o que é ótima notícia, porque atacar poucas fontes rende muito.

O número que você quer é uma porcentagem: quanto do tempo do time é toil? Sem essa medida, "estamos afogados" é uma sensação; com ela, é um fato acionável que você pode acompanhar ao longo do tempo e usar para justificar investimento em automação.

A regra dos 50%#

Aqui está a heurística mais conhecida do assunto, e ela é deliberadamente simples: o toil de um time não deveria ultrapassar metade do tempo dele. A outra metade — no mínimo — deve ir para trabalho de engenharia que reduz toil futuro e melhora o sistema. É um teto para o toil e um piso para a engenharia, ao mesmo tempo.

A regra parece arbitrária, mas a lógica por trás é sólida. Se um time gasta 100% do tempo apenas mantendo as luzes acesas, ele nunca constrói nada que diminua esse esforço — e como o toil escala com o crescimento do serviço, a carga só aumenta, até o time colapsar ou o serviço parar de crescer por falta de gente. Reservar metade do tempo para engenharia é o que quebra esse ciclo: é o investimento que, com o tempo, derruba o toil e liberta ainda mais tempo. Um time que respeita a regra dos 50% está, na prática, pagando dívida operacional em vez de só rolar os juros.

O que acontece quando a regra é violada cronicamente é previsível e triste. O time vira um NOC glorificado, apagando incêndios em looping. As pessoas mais capazes, que poderiam estar construindo, gastam os dias em trabalho manual que não usa suas habilidades — e é a receita clássica de burnout e de rotatividade. Ironicamente, quando a rotatividade acontece, o toil sobre quem fica só aumenta, acelerando o colapso. A regra dos 50% não é um luxo de times grandes; é um mecanismo de autopreservação.

O que automatizar primeiro#

Reconhecer toil e ter tempo para atacá-lo não basta; é preciso escolher o que automatizar, porque nem todo toil vale o mesmo esforço de eliminação. Um jeito prático de priorizar é pesar quatro fatores para cada fonte de toil:

• Frequência. Com que regularidade a tarefa aparece? Algo que acontece várias vezes ao dia paga a automação muito mais rápido do que algo trimestral.
• Esforço por ocorrência. Quanto tempo cada execução consome? Tarefas frequentes e demoradas são o alvo dourado.
• Risco de erro humano. Tarefas manuais propensas a erro carregam um custo escondido: quando alguém erra, vira incidente. Automatizá-las compra confiabilidade além de tempo.
• Custo de automatizar. Algumas fontes de toil são triviais de automatizar; outras exigem um projeto grande. O retorno é a economia esperada dividida pelo custo de construir a automação.

Multiplique frequência por esforço por risco, divida pelo custo de automação, e você tem um ranking grosseiro mas útil. As tarefas frequentes, demoradas e arriscadas, que são baratas de automatizar, vão ao topo — e é impressionante como poucas dessas costumam responder pela maior parte da dor.

Automatize o processo, não a tarefa#

Um erro sutil de quem começa a atacar toil é automatizar cada tarefa isoladamente, criando uma coleção de scriptzinhos que resolvem passos soltos mas ainda exigem uma pessoa para orquestrá-los. O objetivo maior é automatizar o processo inteiro, subindo por níveis de autonomia. O nível mais baixo é o runbook manual: a pessoa segue passos escritos. Um degrau acima, os passos viram scripts que a pessoa dispara. Mais acima, um sistema executa o processo todo mediante um gatilho, e a pessoa só aprova. No topo está o self-healing: o sistema detecta a condição e se corrige sozinho, sem humano no loop — o Pod que reinicia, o certificado que se renova, a réplica que se recupera. Cada degrau tira mais um pedaço de trabalho manual do caminho. Você não precisa chegar ao topo de tudo de uma vez, mas deve estar sempre subindo, transformando "alguém faz isso à mão" em "o sistema cuida disso".

A conexão com confiabilidade#

Vale amarrar toil ao resto da disciplina de confiabilidade. Times de SRE gerenciam o risco de mudança contra um orçamento de erro — a margem de falha que a meta de confiabilidade permite gastar. Quando esse orçamento é saudável, sobra espaço para investir em reduzir toil e melhorar o sistema; quando é estourado por instabilidade, a prioridade vira estabilizar. Toil e confiabilidade se retroalimentam: toil alto significa muita ação manual, que introduz erro humano, que consome orçamento de erro, que gera mais trabalho reativo. Reduzir toil, portanto, não libera só tempo — melhora a confiabilidade, porque tira o humano falível do caminho crítico das operações repetitivas.

As armadilhas — o ciclo vicioso e outras traições#

A armadilha mais cruel do tema é o ciclo vicioso do toil: ninguém tem tempo de automatizar porque todos estão afogados em toil, e ficarão afogados justamente porque ninguém automatiza. É um poço que se aprofunda sozinho. A única saída é uma decisão consciente e protegida — a regra dos 50% existe precisamente para reservar, à força, o tempo de engenharia que o dia a dia sempre tenta engolir. Se você deixar a demanda operacional decidir a alocação do time, ela consumirá 100% do tempo, sempre.

A segunda armadilha é automatizar o caminho errado. Automação prematura, ou de um processo que ainda não está estável e bem entendido, cria uma máquina que faz a coisa errada muito rápido. Automatize o que você já executa manualmente o suficiente para conhecer todas as arestas; caso contrário, você está codificando bugs.

A terceira, mais irônica, é a automação que vira novo toil. Um script frágil, sem tratamento de erro, sem observabilidade, que quebra a cada mudança e precisa de manutenção constante, não eliminou o toil — apenas o transformou em toil de manter a automação. Automação boa é robusta, testada e cuidada como software de produção, porque é isso que ela é. Automação mal feita é uma dívida que cobra juros.

Fechando#

Toil é o trabalho manual, repetitivo, automatizável, reativo e sem valor duradouro que escala com o serviço e, se não for combatido, consome o time inteiro. Reconhecê-lo com precisão — separando-o do overhead, do incidente agudo e do trabalho que exige julgamento — é o começo. Medi-lo com survey ou ticket accounting transforma a sensação de estar afogado num número acionável. A regra dos 50% protege o tempo de engenharia contra a fome insaciável da operação, quebrando o ciclo em que toil gera mais toil. E um método simples de priorização — frequência, esforço, risco e custo — diz o que atacar primeiro, enquanto a mentalidade de "automatize o processo, não a tarefa" garante que você suba de verdade a escada da autonomia, rumo ao self-healing. O objetivo final não é um time que apaga incêndios mais rápido; é um time que projeta sistemas que não pegam fogo, e que gasta suas melhores horas construindo, não repetindo. Toil eliminado não volta na semana seguinte — e essa é a diferença entre um time que progride e um que apenas sobrevive.