Eliminando o Toil
Tags: vaivoa, devops, iniciantes, valores
Published: 2021-11-22 18:55:41

## 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 {% user marcosrocha %}
Texto Original: 
[Eliminating Toil Written by Vivek Rau and Edited by Betsy Beyer](https://sre.google/sre-book/eliminating-toil/)

![linha horizontal](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/n8bndcx2jkn1jz1dy98v.png)
# 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](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/1wmziqv74ghhgyi9p0om.png)