Eliminando o Toil

Marcos Rocha — Mon, 22 Nov 2021 18:55:41 +0000

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

Marcos RochaFollow

Meu nome é Marcos Rocha. Os artigos aqui escritos tem como objetivo de ajudar, documentar e sedimentar novos conhecimentos. Seja bem vindo!

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

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.

DEV Community: Marcos Rocha

Eliminando o Toil