DEV Community

Cover image for Eliminando o Toil
Marcos Rocha for VaiVoa

Posted on • Originally published at marcosfellps.wordpress.com

4 1

Eliminando o Toil

Eliminando o Toil

Se um operador humano precisar tocar seu sistema durante as operações normais, você tem um bug. A definição de normal muda à medida que seus sistemas crescem.
Carla Geisser, Google SRE

Na SRE, queremos dedicar mais tempo ao trabalho de projeto de engenharia de longo prazo, ao invés do trabalho operacional. Como o termo trabalho operacional pode ser mal interpretado, usamos uma palavra específica: toil.

Definição de toil

toil não é apenas “trabalho que não gosto de fazer”. Também não é equivalente a tarefas administrativas ou trabalho sujo. As preferências quanto aos tipos de trabalho que são satisfatórios e agradáveis variam de pessoa para pessoa e algumas pessoas até gostam de trabalhos manuais e repetitivos. Há também tarefas administrativas que precisam ser feitas, mas não devem ser categorizadas como toil: isso é sobrecarga. A sobrecarga costuma ser um trabalho não diretamente vinculado à execução de um serviço de produção e inclui tarefas como reuniões de equipe, definição e classificação de metas, formulários e papelada de RH. O trabalho sujo às vezes pode ter um valor de longo prazo e, nesse caso, também não é toil . Limpar toda a configuração de alerta do seu serviço e remover a confusão pode ser sujo, mas não é toil.

Então, o que é toil? O toil é o tipo de trabalho vinculado à execução de um serviço de produção que tende a ser manual, repetitivo, automatizado, tático, desprovido de valor duradouro e que escala linearmente à medida que o serviço cresce. Nem toda tarefa considerada toil tem todos esses atributos, mas quanto mais de perto o trabalho corresponder a uma ou mais das seguintes descrições, mais provável será que seja árduo:

Manual

Isso inclui trabalhos como a execução manual de um script que automatiza algumas tarefas. Executar um script pode ser mais rápido do que executar manualmente cada etapa do script, mas o tempo prático que um ser humano gasta executando esse script (não o tempo decorrido) ainda é tempo de trabalho.

Repetitivo

Se você está realizando uma tarefa pela primeira vez, ou mesmo pela segunda vez, este trabalho não é árduo. O toil é o trabalho que você faz continuamente. Se você está resolvendo um novo problema ou inventando uma nova solução, este trabalho não é árduo.

Automatizável

Se uma máquina pode realizar a tarefa tão bem quanto um ser humano, ou a necessidade da tarefa pode ser projetada para longe, essa tarefa é toil. Se o julgamento humano é essencial para a tarefa, há uma boa chance de não ser toil.

Tático

O trabalho é orientado por interrupções e reativo, em vez de orientado por estratégia e proativo. Lidar com alertas constantes é árduo. Talvez nunca possamos eliminar totalmente esse tipo de trabalho, mas temos que trabalhar continuamente para minimizá-los.

Sem valor duradouro

Se o seu serviço permanecer no mesmo estado depois de terminar uma tarefa, provavelmente a tarefa foi árdua. Se a tarefa produziu uma melhoria permanente em seu serviço, provavelmente não foi árdua, mesmo se alguma quantidade de trabalho pesado – como mergulhar em códigos e configurações legados e corrigi-los – estivesse envolvida.

O(n) com o crescimento do serviço

Se o trabalho envolvido em uma tarefa aumenta linearmente com o tamanho do serviço, volume de tráfego ou contagem de usuários, essa tarefa provavelmente é árdua. Um serviço gerenciado e projetado idealmente pode crescer em pelo menos uma ordem de magnitude com zero trabalho adicional, exceto alguns esforços únicos para adicionar recursos.

Por que menos toil é melhor

Nossa organização SRE tem uma meta anunciada de manter o trabalho operacional (ou seja, toil) abaixo de 50% do tempo de cada SRE. Pelo menos 50% do tempo de cada SRE deve ser gasto no trabalho do projeto de engenharia que irá reduzir o trabalho futuro ou adicionar recursos ao serviço. O desenvolvimento de recursos normalmente se concentra em melhorar a confiabilidade, o desempenho ou a utilização, o que geralmente reduz o toil como um efeito de segunda ordem.

Compartilhamos essa meta de 50% porque o toil tende a se expandir se não for verificado e pode preencher rapidamente 100% do tempo de todos. O trabalho de redução de toil e ampliação de serviços é a “Engenharia” em Site Reliability Engineering. O trabalho de engenharia é o que permite que a organização SRE se expanda sublinearmente com o tamanho do serviço e gerencie os serviços de forma mais eficiente do que uma equipe de Dev ou de operações pura.

Além disso, quando contratamos novos SREs, prometemos a eles que a SRE não é uma organização de operações típica, citando a regra de 50% mencionada acima. Precisamos cumprir essa promessa, não permitindo que a organização SRE ou qualquer subequipe dentro dela se transforme em uma equipe operacional.

Calculando o toil

Se buscamos limitar o tempo que um SRE gasta com toil para 50%, como esse tempo é gasto?

Há um limite mínimo para a quantidade de trabalho que qualquer SRE precisa lidar se estiver de plantão. Um SRE típico tem uma semana de plantão primário e uma semana de plantão secundário em cada ciclo. Segue-se que, em uma rotação de 6 pessoas, pelo menos 2 de cada 6 semanas são dedicadas a turnos de plantão e tratamento de interrupção, o que significa que o limite inferior do trabalho potencial é 2/6 = 33% do tempo de um SRE. Em uma rotação de 8 pessoas, o limite inferior é 2/8 = 25%.

Consistente com esses dados, os SREs relatam que sua principal fonte de trabalho são as interrupções (ou seja, mensagens não urgentes relacionadas ao serviço e e-mails). A próxima fonte principal é a resposta de plantão (urgente), seguida por comunicados e envios. Mesmo que nossos processos de release e push sejam geralmente tratados com uma boa quantidade de automação, ainda há muito espaço para melhorias nesta área.

Pesquisas trimestrais dos SREs do Google mostram que o tempo médio gasto trabalhando é de cerca de 33%, então nos saímos muito melhor do que nossa meta geral de 50%. No entanto, a média não captura outliers: alguns SREs alegam 0% de toil (projetos de desenvolvimento puro sem trabalho de plantão) e outros alegam 80% de toil. Quando SREs individuais relatam trabalho excessivo, geralmente indica a necessidade de que os gerentes distribuam a carga de trabalho de maneira mais uniforme pela equipe e incentive-os a encontrar projetos de engenharia satisfatórios.

O que se define como Engenharia?

O trabalho de engenharia é novo e requer intrinsecamente julgamento humano. Produz uma melhoria permanente no seu serviço e é orientada por uma estratégia. Frequentemente, é criativo e inovador, adotando uma abordagem orientada ao design para resolver um problema – quanto mais generalizado, melhor. O trabalho de engenharia ajuda sua equipe ou a organização SRE a lidar com um serviço maior, ou mais serviços, com o mesmo nível de pessoal.

As atividades SRE típicas se enquadram nas seguintes categorias aproximadas:

Engenharia de software

Envolve escrever ou modificar o código, além de qualquer projeto associado e trabalho de documentação. Os exemplos incluem escrever scripts de automação, criar ferramentas ou estruturas, adicionar recursos de serviço para escalabilidade e confiabilidade ou modificar o código de infraestrutura para torná-lo mais robusto.

Engenharia de sistemas

Envolve configurar sistemas de produção, modificar configurações ou documentar sistemas de uma forma que produza melhorias duradouras a partir de um esforço único. Os exemplos incluem configuração e atualizações de monitoramento, configuração de balanceamento de carga, configuração do servidor, ajuste de parâmetros do sistema operacional e configuração do load balancer. A engenharia de sistemas também inclui consultoria em arquitetura, design e produção para equipes de desenvolvedores.

toil

Trabalho diretamente vinculado à execução de um serviço que é repetitivo, manual, etc.

Sobrecarga

Trabalho administrativo não vinculado diretamente à execução de um serviço. Os exemplos incluem contratação, papelada de RH, reuniões de equipe/empresa, higienização de filas de bugs, formulários, revisões de pares, auto avaliações e cursos de treinamento.

Cada SRE precisa despender pelo menos 50% de seu tempo em trabalho de engenharia, em média em alguns trimestres ou um ano. O toil tende a ser pontiagudo, portanto, 50% do tempo gasto em engenharia pode não ser realista para algumas equipes de SRE, e eles podem cair abaixo dessa meta em alguns trimestres. Mas se a fração de tempo gasto em projetos fica em média significativamente abaixo de 50% no longo prazo, a equipe afetada precisa dar um passo atrás e descobrir o que está errado.

O toil é sempre ruim?

O toil não torna todos infelizes o tempo todo, especialmente em pequenas quantidades. Tarefas previsíveis e repetitivas podem ser relaxantes. Elas produzem um sentimento de realização e vitórias rápidas. Elas podem ser atividades de baixo risco e baixo estresse. Algumas pessoas gravitam em torno de tarefas que envolvem toil e podem até gostar desse tipo de trabalho.

O toil nem sempre é invariavelmente ruim, e todos precisam estar cientes de que alguma quantidade de toil é inevitável na função de SRE e, na verdade, em quase qualquer função de engenharia. É bom em pequenas doses, e se você está feliz com essas pequenas doses, o toil não é um problema. O trabalho torna-se tóxico quando experimentado em grandes quantidades. Se você está sobrecarregado com muito trabalho, deve se preocupar e reclamar em voz alta. Entre as muitas razões pelas quais trabalhar demais é ruim, considere o seguinte:

Estagnação de carreira

O progresso de sua carreira diminuirá ou será interrompido se você investir pouco tempo em projetos. O Google recompensa o trabalho sujo quando é inevitável e tem um grande impacto positivo, mas você não pode fazer carreira fora da sujeira.

Baixa moral

As pessoas têm limites diferentes para a quantidade de toil que podem tolerar, mas todos têm um limite. Muito toil leva ao esgotamento, ao tédio e ao descontentamento.

Além disso, gastar muito tempo trabalhando em detrimento do tempo gasto com engenharia prejudica uma organização SRE das seguintes maneiras:

Cria confusão

Trabalhamos muito para garantir que todos os que trabalham na ou com a organização SRE entendam que somos uma organização de engenharia. Indivíduos ou equipes dentro de SRE que se envolvem em muito toil prejudicam a clareza dessa comunicação e confundem as pessoas sobre o nosso papel.

Retarda o progresso

O trabalho excessivo torna a equipe menos produtiva. A velocidade do recurso de um produto diminuirá se a equipe SRE estiver muito ocupada com trabalho manual e combate a incêndios para lançar novos recursos imediatamente.

Define precedente

Se você estiver muito disposto a trabalhar, seus colegas Dev terão incentivos para sobrecarregá-lo com ainda mais trabalho, às vezes mudando as tarefas operacionais que deveriam ser desempenhadas pelos Devs para SRE. Outras equipes também podem começar a esperar que os SREs realizem esse trabalho, o que é ruim por razões óbvias.

Promove atrito

Mesmo que você não esteja pessoalmente infeliz com o toil, seus atuais ou futuros companheiros de equipe podem gostar muito menos. Se você construir muito trabalho nos procedimentos de sua equipe, você motiva os melhores engenheiros da equipe a começar a procurar em outro lugar por um trabalho mais gratificante.

Causa violação de fé

As novas contratações ou transferências que ingressam na SRE com a promessa de um projeto de trabalho se sentirão enganadas, o que é ruim para o moral.

Conclusão

Se todos nós nos comprometermos a eliminar um pouco de trabalho a cada semana com alguma boa engenharia, iremos continuamente limpar nossos serviços e podemos mudar nossos esforços coletivos para a engenharia em escala, arquitetando a próxima geração de serviços e construindo SRE cruzado conjuntos de ferramentas. Vamos inventar mais e trabalhar menos.

Fonte

Escrito por Vivek Rau
Editado por Betsy Beyer
Traduzido por


Texto Original:
Eliminating Toil Written by Vivek Rau and Edited by Betsy Beyer

linha horizontal

Disclaimer

A VaiVoa incentiva seus Desenvolvedores em seu processo de crescimento e aceleração técnica. Os artigos publicados não traduzem a opinião da VaiVoa. A publicação obedece ao propósito de estimular o debate.

logo vaivoa

Heroku

Build apps, not infrastructure.

Dealing with servers, hardware, and infrastructure can take up your valuable time. Discover the benefits of Heroku, the PaaS of choice for developers since 2007.

Visit Site

Top comments (0)

A Workflow Copilot. Tailored to You.

Pieces.app image

Our desktop app, with its intelligent copilot, streamlines coding by generating snippets, extracting code from screenshots, and accelerating problem-solving.

Read the docs