A saúde da equipe é um processo. Como tal, não é algo que se possa resolver com esforço heroico. Para garantir que a equipe possa se autorregular, você pode ajudá-los a construir um bom modelo mental para um engajamento SRE ideal.

Nota

Os seres humanos são bastante bons na homeostase, por isso concentre-se em criar (ou restaurar) as condições iniciais corretas e ensinar o pequeno conjunto de princípios necessários para fazer escolhas saudáveis.

Comece com o Básico

As equipes que lutam com a distinção entre o SRE e o modelo de operações tradicional geralmente são incapazes de articular por que certos aspectos do código, dos processos ou da cultura da equipe as incomodam. Em vez de tentar abordar cada uma destas questões ponto por ponto, trabalhe a partir dos princípios delineados nos Capítulo 1 e Capítulo 6. 

O seu primeiro objetivo para a equipe deve ser escrever um objetivo de nível de serviço (SLO), se ainda não existir um. O SLO é importante porque fornece uma medida quantitativa do impacto das interrupções, além de quão importante pode ser uma mudança de processo. Um SLO é provavelmente a alavanca mais importante para mover uma equipe do trabalho de operações reativas para um foco SRE saudável e de longo prazo. Se este acordo estiver faltando, nenhum outro conselho neste capítulo será útil. Se você estiver em uma equipe sem SLOs, leia primeiro o Capítulo 4, depois obtenha as indicações técnicas e a gestão numa sala e comece a arbitrar. 

Obtenha Ajuda para Limpar o Kindling

Você pode ter um forte desejo de simplesmente corrigir os problemas que identificar. Por favor, resista ao impulso de corrigir estas questões por si próprio, porque isso reforça a ideia de que “fazer mudanças é para outras pessoas”. Em vez disso, tome as seguintes medidas: 

1. Encontre um trabalho útil que possa ser realizado por um membro da equipe.

    

    

2. Explique claramente como este trabalho aborda uma questão a partir do postmortem de uma forma permanente. Mesmo equipes saudáveis podem produzir artigos de ação com visão curta.

    

    

3. Sirva como revisor para as alterações do código e revisões de documentos.

    

    

4. Repita para dois ou três problemas.

Quando identificar um problema adicional, coloque-o num relatório de bug ou num documento para a equipe consultar. Fazer isso serve ao duplo propósito de distribuir informações e incentivar os membros da equipe a escrever documentos (que geralmente são a primeira vítima da pressão do prazo). Sempre explique seu raciocínio e enfatize que uma boa documentação garante que a equipe não repita erros antigos em um contexto ligeiramente novo.

Explique o seu raciocínio

À medida que a equipe recupera o seu ímpeto e agarra o essencial das mudanças sugeridas, avance para enfrentar as decisões cotidianas que originalmente levaram à sobrecarga das operações. Prepare-se para que este empreendimento seja desafiado. Se tiver sorte, o desafio será do tipo: “Explique por quê”. Agora mesmo. No meio da reunião semanal de produção”.

Se você não tiver sorte, ninguém exige uma explicação. Esclareça este problema por completo, explicando simplesmente todas as suas decisões, quer alguém peça ou não uma explicação. Consulte as noções básicas que ressaltam as suas sugestões. Fazer isso ajuda a construir o modelo mental da equipe. Depois que você sair, a equipe deve ser capaz de prever qual seria seu comentário sobre um design ou lista de alterações. Se não explicar o seu raciocínio, ou o fizer mal, há o risco de a equipe simplesmente imitar esse comportamento indiferente, por isso seja explícito.

Exemplos de uma explicação completa da sua decisão:

• “Não estou odiando o último lançamento porque os testes são ruins. Estou recuando porque o error budget que definimos para os lançamentos está esgotado”.
  

   

   

• “Os lançamentos têm que ser seguros porque o nosso SLO é rígido. Atender a esse SLO exige que o tempo médio de recuperação seja pequeno, portanto, um diagnóstico aprofundado antes de uma reversão não é realista”.

Exemplos de uma explicação insuficiente da sua decisão:

• “Não acho que ter cada servidor gerando sua configuração de roteamento seja seguro, porque não podemos vê-lo”.

Esta decisão é provavelmente correta, mas o raciocínio é pobre (ou mal explicado). A equipe não consegue ler a sua mente, então eles provavelmente podem imitar o raciocínio ruim observado. Em vez disso, tente “[…] não é seguro porque um bug nesse código pode causar uma falha correlacionada em todo o serviço e o código adicional é uma fonte de bugs que pode atrasar um reversão”.

• “A automatização deve desistir se encontrar uma implantação conflitante”.

Tal como o exemplo anterior, esta explicação é provavelmente correta, mas insuficiente. Em vez disso, tente “[…] porque estamos fazendo a suposição simplificadora de que todas as mudanças passam pela automatização, e algo violou claramente essa regra. Se isto acontecer com frequência, devemos identificar e remover fontes de mudança não organizada”.

Faça perguntas importantes

As perguntas principais não são perguntas carregadas. Ao falar com a equipe SRE, tente fazer perguntas de uma forma que encoraje as pessoas a pensar sobre os princípios básicos. É particularmente valioso para você modelar esse comportamento porque, por definição, uma equipe no modo de operações rejeita esse tipo de raciocínio de seus próprios constituintes. Uma vez que tenha passado algum tempo explicando o seu raciocínio para várias questões políticas, esta prática reforça a compreensão da equipe sobre a filosofia SRE.

Exemplos de perguntas principais:

• “Vejo que o alerta do TaskFailures dispara frequentemente, mas os engenheiros de plantão normalmente não fazem nada para responder ao alerta. Como é que isto afeta o SLO”?

   

   

• “Este procedimento de entrega parece bastante complicado. Sabe porque há tantos arquivos de configuração para atualizar quando se cria uma nova instância do serviço”?

Contra exemplos de perguntas principais:

• “O que há com todos esses lançamentos antigos e parados”?

   

   

• “Porque é que o Frobnitzer faz tantas coisas?”