Trabalhar com palavras em inglês na área de tecnologia não deve ser problema, afinal de contas, estamos rodeados delas em nosso cotidiano. Entretanto, esta nova palavra: Toil, saiu dos escritórios hipsters do Vale do Silício e já faz parte das nossas organizações em território tupiniquim. Como uma imagem vale mais que mil palavras, observe a seguinte:
Quantas vezes você vê isso nos seus projetos atuais, em resumo, muitas pessoas, mas também times inteiros e até organizações por completo esquecem de sua tarefa ou problema original a se resolver, e na ilusão de ter uma solução, acaba gerando um novo problema, que muitas vezes vira um loop quase que infinito que só chega ao fim tentando mais uma nova solução, que mais uma vez entrará no looping, e ao invés de ter um único problema, agora nesse cenário aqui descrito existem três.
O autor Vivek Rau, em seu livro, articula uma definição excelente:
“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 escala linearmente à medida que um serviço cresce.”
Imagine um Serviço de negócio para um Open Banking, como: Movimentação de Contas. Imagine fazer uma mudança de negócio que te custa 30 minutos, mas o deploy é tão complexo, são tantos yamls, tantos Istios, tantos kubectl apply .... Que faz com que o novo release leve 2 dias, e ainda com risco de erros.
Sim, isto está acontecendo, e está muito mais perto do que você possa imaginar, isto acontece usualmente na reinstalação inúmeras vezes de um cluster kubernetes que você achava que apresentava problemas por causa do provedor de nuvem, e depois de usar AWS, Digital Ocean, Oracle, Azure, você percebeu que o Ingress que estava tentando usar não tem suporte a certificados do tipo LetsEncrypt. Nós passamos por um problema desses em uma combinação de ambiente, onde acabamos cometendo este erro, achando que o problema estava num lugar e ao invés de focarmos em averiguar a chave do problema, partimos para soluções no modelo go-horse, que no final, se tivéssemos sentado numa dailly e compartilhado esse problema de forma mais aberta e comunicativa, levaria 1 hora para ser resolvido, e não semanas. Perceba então o impacto negativo que Toil traz para as organizações.
Impacto nos Negócios
Certamente o maior impactado do Toil é o negócio, que vai acabar tendo uma implementação que deixará a desejar, apenas para atender aos prazos das Sprints, ao invés de poder se focar essencialmente em algo que possa ser inovador, gerando diferencial competitivo para a área de negócio e empresa que você trabalha.
Calma, pode ser pior: Toil + Turn over
Sim caro leitor, imagine alguém preso num toil que por incrível que pareça, recebe uma proposta e sai da empresa, sim, isso também aconteceu com a gente... Conclusão: Tivemos ainda mais trabalho para entender o que a pessoa estava tentando fazer, ou onde queria chegar, até termos um "q" de alguma sabedoria de nossa líder que disse: "E por que não recomeçamos do zero...". Voila, resolvemos alguns destes toils de maneira muito mais efetiva.
Quando a frase "Tenha espirito de dono" destrói os ambientes
Essa frase é linda, desperta empoderamento, sentimento de pertencimento, sentimentos apenas não tão fortes quanto a raiva e angústia gerada quando uma pessoa "cria um Toil para chamar de seu", e simplesmente, além de não deixar ninguém tocar no problema, o protege mais que Gollum protegia a preciosa jóia da premiada estória de JR Tolkien: O Senhor dos Anéis. Estes membros de equipe geram problemas inclusive para os gestores, que pouco podem fazer para tentar que as coisas fluam no caminho certo.
Para finalizar
Ao final deixaremos algumas ótimas referências que abordarão este assunto com uma maior extensão, porém, em nossos brainstormings, chegamos a conclusão que algumas ações e boas-práticas podem nos ajudar a reduzir ou pelo menos desviar de Toils complicados, abaixo alguns deles:
Se for usar Kubernetes, tentar usar alguma ferramenta que faça uma boa abstração dos ambientes que rodam em nuvens públicas, muitas vezes usar direto o AKS, e EKS e algumas ligeiras diferenças entre essas soluções, muitas vezes trazem uma certa dor de cabeça. Um bom orquestrador como o Rancher pode ser uma boa alternativa, para você começar a evitar e se possível eliminar os fã-boy de alguma nuvem específica, que muitas vezes puxam a sardinha para um lado específico, e esquecem que no final do dia, nós temos que fazer o que é bom para os negócios das empresas, e isto muitas vezes vai além de nossas preferências meramente pessoais. PS- Estamos testando recentemente o Platform9, em breve poderemos comentar um pouco sobre esta solução.
Na parte de CI/CD é interessante termos os pipelines escritos, ou representados de uma forma uniforme e comum, onde qualquer pessoa possa entender, nestes quesitos, ferramentas como o Harness tem apresentado um modelo de fluxo visual, que nos faz entender e seguir os passos que as tarefas estão passando, além de ser muito mais fácil de explicar para qualquer pessoa o que está acontecendo por de trás dos panos, ao invés de milhares de shell scripts, como chamadas de CURL, SSH, etc.
Seu backlog deverá ter o tempo de desenvolvimento da tarefa, e depois as fases de QA e Prod, se estas tarefas começarem a durar pelo menos a mesma coisa, ou pior, mais ainda que o tempo que você levou na construção, reveja se você não está começando a se prender em seu primeiro toil.