A área de TI é cheia de desafios e o maior deles é conseguir entregar valor aos clientes de maneira cada vez mais rápida e flexível.
Para resolver esse baita desafio, ferramentas que automatizam processos são bem-vindas, pois permitem focar em entregar novas funcionalidades no lugar de realizar trabalhos manuais e repetitivos.
As tarefas manuais e repetitivas ganharam uma terminologia pelos times de SRE (Site Reliability Engineering): TOIL.
De acordo com o que escreveu Vivek Rau no livro sobre SRE da Google:
Toil é o tipo de trabalho vinculado à execução de um serviço de produção que tende a ser manual, repetitivo, automatizável, tático, desprovido de valor duradouro e que se dimensiona linearmente à medida que o serviço cresce.
Ou seja, Toils são tarefas que não devemos e/ou queremos mais realizar.
Como reconhecer toils?
Nem todas as tarefas consideradas como Toil têm todos os atributos comentados na definição do Vivek. Mas quanto mais uma tarefa se encaixa nessas características, maior é a probabilidade dessa tarefa ser um Toil.
Vamos entrar em mais detalhes sobre o que significam essas características.
Tarefas Manuais
Tarefas manuais incluem trabalhos como a execução manual de um script que automatiza alguma tarefa. A execução de um script pode ser mais rápida do que a execução manual de cada etapa do script, mas o tempo prático que um ser humano gasta executando esse script (não o tempo decorrido) ainda é o tempo necessário.
Tarefas Repetitivas
Se você estiver executando uma tarefa pela primeira vez, ou mesmo pela segunda, este trabalho não é trabalhoso. O que é trabalhoso é o que você faz repetidamente. Se você está resolvendo um novo problema ou inventando uma nova solução, esta tarefa não é trabalhosa.
Tarefas que podem ser automatizadas
Se uma máquina puder realizar a tarefa tão bem quanto um ser humano, essa tarefa será um toil. Se o julgamento humano é essencial para a tarefa, há uma boa chance de que não seja um toil.
Tarefas Reativas
Toils são tarefas que geram interrupções, que geram ações reativas. Tarefas que não são toils são estratégicas e geram ações pró-ativas. Tarefas como enviar e tratar alertas por exemplo, são toils. Talvez nunca consigamos eliminar completamente esse tipo de trabalho, mas precisamos trabalhar continuamente para minimizá-lo.
Tarefas que possuem nenhum valor duradouro
Se seu serviço permanecer no mesmo estado após a conclusão de uma tarefa, provavelmente a tarefa foi cansativa. Se a tarefa produziu uma melhoria permanente em seu serviço, provavelmente não foi trabalhoso, mesmo que alguma quantidade de trabalho pesado – como cavar códigos e configurações legadas e corrigi-las – estivesse envolvida.
Tarefas que crescem com o tamanho do serviço
Se o trabalho envolvido em uma tarefa aumenta linearmente com o tamanho do serviço, o volume de tráfego ou a contagem de usuários, essa tarefa provavelmente será um toil. Um serviço idealmente gerenciado e projetado pode crescer em pelo menos uma ordem de magnitude com zero trabalho adicional, além de alguns esforços únicos para adicionar recursos.
Como evitar o crescimento de toils?
Na Google, o pessoal do time de SRE tem por meta manter a quantidade de toils abaixo de 50% do trabalho global da equipe (isso já demonstra a importância de conseguir medir essa quantidade).
O ideal sendo que pelo menos 50% do tempo de cada pessoa seja gasto em atividades que reduzirão toils, ou que gerarão valor ao projeto/negócio. Essas tarefas gerando valor geralmente se concentram em melhorar a confiabilidade, desempenho ou utilização do projeto/negócio, o que geralmente reduz indiretamente toils também.
Essa meta é de 50% porque a quantidade de toils tende a crescer rapidamente até eventualmente alcançar 100% do tempo de atuação da equipe caso não sejam acompanhados e resolvidos a tempo. Outra necessidade de manter a quantidade de toils abaixo de 50% é para manter a área de atuação da equipe atraente para novos integrantes. Ninguém quer gastar seu tempo em resolver toils.
Toil é Dívida Técnica?
Toil e dívida técnica (e não Débito Técnico) são duas coisas diferentes.
Como explicado no Wikipedia:
“Dívida técnica é um conceito no desenvolvimento de software que reflete o custo implícito de retrabalho adicional causado pela escolha de uma solução fácil agora, em vez de usar uma abordagem melhor que levaria mais tempo.”
Comentamos no início do artigo que as empresas procuram cada vez mais implantar recursos rapidamente. Mas mesmo assim, elas esperam que as equipes de TI lidem com aspectos não funcionais, como confiabilidade, desempenho e segurança.
Como os requisitos não funcionais não são visíveis nas histórias de usuários (em métodos ágeis por exemplo), as equipes de TI podem não prestar atenção em todos os detalhes, o que pouco a pouco pode gerar dívidas técnicas.
O Dag Liodden comenta no seu blog que existem 3 tipos de Dívidas Técnicas: algumas são deliberadas, outras acidentais, e algumas aparecem ao longo do tempo devido a uma complexidade desnecessária do código, que se acumula ao longo das implementações.
As dívidas deliberadas são fáceis de encontrar e identificar. Os outros 2 tipos de dívidas podem demorar mais a ser encontrados.
É importante identificar rapidamente as dívidas técnicas, porque elas geram toils. E quanto mais perto da release (da dívida técnica relacionada) identificamos o toil, mas rápido conseguiremos resolver ele através de uma automação.
Como automatizar toils com Ritchie?
Resolver um toil significa automatizá-lo. Mas será que existe uma maneira fácil de fazer isso?
Uma maneira de solucionar isso é usando o Ritchie, um CLI (Command Line Interface) open source que permite criar, armazenar e compartilhar automações através de comandos simples executados no terminal.
Essas automações (chamadas de fórmulas no contexto da ferramenta) podem ser escritas em qualquer linguagens de programação e o próprio Ritchie permite a sua execução no Windows, MacOS e Linux.
Vamos pensar no seguinte cenário: um desenvolvedor precisa ter acesso aos logs de uma função específica de uma aplicação.
Geralmente, ele precisaria do auxílio de um SRE para acessar esses dados pois precisa das credenciais de acesso ao Serverless.
Para o SRE, essa tarefa é manual, repetitiva, não agrega muito valor ao negócio, e aumenta à medida que a quantidade de usuário da aplicação cresce. Ou seja, é um toil.
Com o Ritchie o desenvolvedor tem acesso a essa informação de maneira autônoma, sem pedir auxílio para o SRE, que poderia ter liberado o acesso com credenciais de leitura ao dev diretamente pelo Ritchie.
Segue abaixo a execução da fórmula que automatizou esse toil usando o Ritchie:
À medida que o usuário sinaliza qual a fórmula quer utilizar, o sistema automaticamente passa, linha a linha, a perguntar os parâmetros específicos (Function e Stage) necessários para executar a ação desejada.
Também é possível executar comandos usando STDIN para automatizar o uso de fórmulas do Ritchie em rotinas resolvendo toils automaticamente.
Os processos de onboarding nas empresas de TI podem ser considerados tarefas reativas, repetitivas, muitas vezes manuais, e que podem ser automatizadas… Será que podemos considerar esses processos como TOIL? Leia também como acelerar o processo de onboarding com Ritchie.
Um CLI para todas as automações
Entenda como o Ritchie pode te ajudar a ter mais autonomia programando.
Ainda ficou com alguma dúvida no assunto ou quer compartilhar sua experiência? Escreva pra gente nos comentários!
