Capítulo 30 – Integrar um SRE para se Recuperar da Sobrecarga Operacional

Escrito por Randall Bosetti

Editado por Diane Bates

É política padrão das equipes SRE do Google dividir uniformemente o seu tempo entre os projetos e o trabalho de operações reativas. Na prática, este equilíbrio pode ser perturbado durante meses a fio por um aumento do volume diário de tickets. Uma quantidade pesada de trabalho de operações é especialmente perigosa porque a equipe SRE pode esgotar-se ou ser incapaz de progredir no trabalho do projeto. Quando uma equipe tem que alocar uma quantidade desproporcionada de tempo para resolução de tickets ao custo de gastar tempo melhorando o serviço, a escalabilidade e a confiabilidade sofrem.

Uma forma de aliviar este fardo é transferir temporariamente um SRE para a equipe sobrecarregada. Uma vez integrado numa equipe, o SRE concentra-se em melhorar as práticas da equipe, em vez de simplesmente ajudar a equipe a esvaziar a fila de tickets. O SRE observa a rotina diária da equipe e faz recomendações para melhorar as suas práticas. Esta consulta dá à equipe uma nova perspectiva sobre as suas rotinas que os membros da equipe não podem assegurar por si próprios.

Quando se utiliza esta abordagem, não é necessário transferir mais do que um engenheiro. Dois SREs não produzem necessariamente melhores resultados e podem na realidade causar problemas se a equipe reagir de forma defensiva.

Se você está iniciando sua primeira equipe de SRE, a abordagem descrita neste capítulo o ajudará a evitar se transformar em uma equipe de operação focada exclusivamente numa rotação de tickets. Se você decidir integrar a si mesmo ou a um dos seus relatórios numa equipe, reserve algum tempo para rever as práticas e filosofia do SRE na introdução do Capítulo 1 e o material sobre monitorização no Capítulo 6.

As seções seguintes fornecem orientações para o SRE que será integrado numa equipe.

Fase 1: Aprender o Serviço e Obter Contexto

O seu trabalho enquanto integrado com a equipe é articular a razão pela qual os processos e hábitos contribuem ou prejudicam a escalabilidade do serviço. Lembre à equipe que mais tickets não devem exigir mais SREs: o objetivo do modelo SRE é apenas introduzir mais seres humanos à medida que mais complexidade é acrescentada ao sistema. Em vez disso, tente chamar a atenção para a forma como hábitos de trabalho saudáveis reduzem o tempo gasto nos tickets. Fazer isso é tão importante quanto apontar oportunidades perdidas de automação ou simplificação do serviço.

Modo Operacional versus Escala Não Linear

O termo modo operacional refere-se a um certo método de manter um serviço em funcionamento. Vários itens de trabalho aumentam com o tamanho do serviço. Por exemplo, um serviço precisa de uma forma de aumentar o número de máquinas virtuais configuradas (VMs) à medida que cresce. Uma equipe em modo operacional responde tendo um maior número de administradores gerindo esses VMs. O SRE concentra-se antes em escrever software ou eliminar preocupações de escalabilidade, para que o número de pessoas necessárias para executar um serviço não aumente em função da carga no serviço.

As equipes que entram no modo operacional podem estar convencidas de que a escala não é importante para elas (“o meu serviço é minúsculo”). Acompanhe uma sessão de plantão para determinar se a avaliação é verdadeira, porque o elemento de escala afeta sua estratégia.

Se o serviço primário é importante para o negócio, mas na realidade é minúsculo (implicando poucos recursos ou baixa complexidade), ponha mais atenção às formas como a abordagem atual da equipe os impede de melhorar a confiabilidade do serviço. Lembre-se de que o seu trabalho é fazer o serviço funcionar, e não proteger a equipe de desenvolvimento de alertas.

Por outro lado, se o serviço está apenas começando, concentre-se em formas de preparar a equipe para um crescimento explosivo. Um serviço de 100 pedidos/segundo pode se transformar num serviço de 10k pedidos/segundo em um ano. 

Identificar as Maiores Fontes de Estresse

As equipes SRE caem por vezes no modo operacional porque se concentram em como abordar rapidamente as emergências em vez de como reduzir o número de emergências. Uma falha no modo operacional acontece normalmente em resposta a uma pressão esmagadora, real ou imaginária. Depois de ter aprendido o suficiente sobre o serviço para fazer perguntas difíceis sobre o seu projeto e implantação, passe algum tempo priorizando várias falhas de serviço de acordo com o seu impacto nos níveis de estresse da equipe. Tenha em mente que, devido à perspectiva e história da equipe, alguns problemas muito pequenos ou interrupções podem produzir uma quantidade desordenada de estresse.

Identifique o Kindling

Uma vez identificados os maiores problemas existentes de uma equipe, passemos às situações de emergência à espera de acontecer. Por vezes, as emergências iminentes surgem sob a forma de um novo subsistema que não foi projetado para ser autogerenciado. Outras fontes incluem:

Lacunas de conhecimento

Em grandes equipes, as pessoas podem especializar-se demasiado sem consequências imediatas. Quando uma pessoa se especializa, corre o risco de ou não ter o amplo conhecimento de que necessita para realizar o apoio de plantão ou permitir aos membros da equipe ignorar as peças críticas do sistema que possuem.

Serviços desenvolvidos pelo SRE que estão aumentando silenciosamente em importância

Estes serviços muitas vezes não recebem a mesma atenção cuidadosa que os lançamentos de novas funcionalidades porque são mais pequenos em escala e implicitamente endossados por pelo menos um SRE.

Forte dependência da “próxima grande coisa”

As pessoas podem ignorar os problemas durante meses a fio, porque acreditam que a nova solução que está no horizonte evita correções temporárias.

Alertas comuns que não são diagnosticados nem pela equipe de desenvolvimento nem pelos SREs

Tais alertas são frequentemente classificados como transitórios, mas ainda assim distraem os seus colegas de equipe da resolução de problemas reais. Investigue tais alertas por completo, ou conserte as regras de alerta.

Qualquer serviço que seja simultaneamente objeto de queixas dos seus clientes e que careça de um SLI/SLO/SLA formal

Ver Capítulo 4 para uma discussão de SLIs, SLOs, e SLAs. 

Qualquer serviço com um plano de capacidade que seja efetivamente “Adicionar mais servidores: os nossos servidores estavam ficando sem memória ontem à noite”.

Os planos de capacidade devem ser suficientemente voltados para o futuro. Se o seu modelo de sistema prevê que os servidores precisam de 2 GB, um teste de carga que passe a curto prazo (revelando 1,99 GB na sua última execução) não significa necessariamente que a capacidade do seu sistema esteja em condições adequadas.

Os postmortems que só têm itens de ação para fazer recuar as alterações específicas que causaram uma interrupção

Por exemplo, “Mudar o tempo limite de transmissão de volta para 60 segundos”, em vez de “Descobrir porque é que às vezes leva 60 segundos para buscar o primeiro megabyte de nossos vídeos promocionais”.

Qualquer componente crítico de serviço para o qual as SREs existentes respondem às perguntas dizendo: “Não sabemos nada sobre isso; os desenvolvedores são os donos”.

Para dar um apoio de plantão aceitável para um componente, deve pelo menos saber as consequências quando este quebra e a urgência necessária para resolver os problemas. 

Fase 2: Contexto de Partilha

Depois de analisar a dinâmica e os pontos problemáticos da equipe, lance as bases para a melhoria através de melhores práticas como os postmortems e a identificação de fontes de trabalho e a melhor forma de os abordar.

Escreva um bom postmortem para a equipe 

Os postmortems oferecem muito insight sobre o raciocínio coletivo de uma equipe. Os postmortems conduzidos por equipes pouco saudáveis são frequentemente ineficazes. Alguns membros da equipe podem considerar os postmortems punitivos, ou mesmo inúteis. Embora possam ser tentados a rever os arquivos postmortems e deixar comentários para melhorias, isso não ajuda a equipe. Em vez disso, o exercício pode colocar a equipe na defensiva.

Em vez de tentar corrigir erros anteriores, aproprie-se do próximo postmortem. Haverá uma interrupção enquanto estiver integrado. Se não for a pessoa de plantão, junte-se ao SRE de plantão para escrever um grande postmortem, sem culpa. Este documento é uma oportunidade para demonstrar como uma mudança para o modelo SRE beneficia a equipe, tornando as correções de bugs mais permanentes. Correções de bugs mais permanentes reduzem o impacto das interrupções no tempo dos membros da equipe.

Tal como mencionado, poderá encontrar respostas como “Por que eu?” Esta resposta é especialmente provável quando uma equipe acredita que o processo postmortem é retaliatório. Esta atitude vem da adesão à Teoria da Maçã Má: o sistema está funcionando bem, e se nos livrarmos de todas as maçãs más e dos seus erros, o sistema continuará funcionando bem. A Teoria da Maçã Má é comprovadamente falsa, como demonstram as provas de várias disciplinas, incluindo a segurança aérea. Deve-se apontar esta falsidade. A frase mais eficaz para uma postmortem é dizer: “Os erros são inevitáveis em qualquer sistema com múltiplas interações sutis”. Você estava de plantão e eu confio em você para tomar as decisões certas com as informações certas. Gostaria que escrevesse o que estava pensando em cada momento, para que possamos descobrir onde o sistema o enganou, e onde as exigências cognitivas eram demasiado elevadas”. 

Classifique os incêndios de acordo com o tipo

Há dois tipos de incêndios neste modelo simplificado por conveniência:

  • Alguns incêndios não deveriam existir. Provocam o que é comummente chamado trabalho operacional ou labuta (ver Capítulo 5).

     

  • Outros incêndios que causam estresse e/ou digitação furiosa fazem realmente parte do trabalho.

Em qualquer dos casos, a equipe precisa construir ferramentas para controlar a queima.

Classifique os incêndios da equipe em labuta e não labuta. Quando terminar, apresente a lista à equipe e explique claramente porque é que cada incêndio é ou um trabalho que deve ser automatizado ou uma sobrecarga aceitável para o funcionamento do serviço.

Fase 3: Mudança de direção

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?”

Conclusão

Seguindo os princípios delineados neste capítulo, uma equipe SRE tem o seguinte:

  • Uma perspectiva técnica, possivelmente quantitativa, sobre a razão pela qual devem mudar.

     

  • Um forte exemplo de como é a mudança.

     

  • Uma explicação lógica para grande parte da “sabedoria popular” utilizada pelo SRE.

     

  • Os princípios fundamentais necessários para enfrentar situações inovadoras de uma forma escalável.

A sua tarefa final é escrever um relatório pós-ação. Este relatório deve reiterar a sua perspectiva, exemplos e explicações. Deve também fornecer alguns itens de ação para a equipe, a fim de assegurar que exercem o que lhes ensinou. Pode organizar o relatório como um postvitam, explicando as decisões críticas em cada passo que levou ao sucesso.

A maior parte do compromisso está agora completa. Depois que sua atribuição integrada for concluída, deverá permanecer disponível para revisões de design e código. Fique de olho na equipe durante os próximos meses para confirmar que estão melhorando lentamente o planejamento da sua capacidade, a resposta de emergência e os processos de implementação. 

 

Fonte: Google SRE Book

Escrito por Randall Bosetti

Editado por Diane Bates

É política padrão das equipes SRE do Google dividir uniformemente o seu tempo entre os projetos e o trabalho de operações reativas. Na prática, este equilíbrio pode ser perturbado durante meses a fio por um aumento do volume diário de tickets. Uma quantidade pesada de trabalho de operações é especialmente perigosa porque a equipe SRE pode esgotar-se ou ser incapaz de progredir no trabalho do projeto. Quando uma equipe tem que alocar uma quantidade desproporcionada de tempo para resolução de tickets ao custo de gastar tempo melhorando o serviço, a escalabilidade e a confiabilidade sofrem.

Uma forma de aliviar este fardo é transferir temporariamente um SRE para a equipe sobrecarregada. Uma vez integrado numa equipe, o SRE concentra-se em melhorar as práticas da equipe, em vez de simplesmente ajudar a equipe a esvaziar a fila de tickets. O SRE observa a rotina diária da equipe e faz recomendações para melhorar as suas práticas. Esta consulta dá à equipe uma nova perspectiva sobre as suas rotinas que os membros da equipe não podem assegurar por si próprios.

Quando se utiliza esta abordagem, não é necessário transferir mais do que um engenheiro. Dois SREs não produzem necessariamente melhores resultados e podem na realidade causar problemas se a equipe reagir de forma defensiva.

Se você está iniciando sua primeira equipe de SRE, a abordagem descrita neste capítulo o ajudará a evitar se transformar em uma equipe de operação focada exclusivamente numa rotação de tickets. Se você decidir integrar a si mesmo ou a um dos seus relatórios numa equipe, reserve algum tempo para rever as práticas e filosofia do SRE na introdução do Capítulo 1 e o material sobre monitorização no Capítulo 6.

As seções seguintes fornecem orientações para o SRE que será integrado numa equipe.

Fase 1: Aprender o Serviço e Obter Contexto

O seu trabalho enquanto integrado com a equipe é articular a razão pela qual os processos e hábitos contribuem ou prejudicam a escalabilidade do serviço. Lembre à equipe que mais tickets não devem exigir mais SREs: o objetivo do modelo SRE é apenas introduzir mais seres humanos à medida que mais complexidade é acrescentada ao sistema. Em vez disso, tente chamar a atenção para a forma como hábitos de trabalho saudáveis reduzem o tempo gasto nos tickets. Fazer isso é tão importante quanto apontar oportunidades perdidas de automação ou simplificação do serviço.

Modo Operacional versus Escala Não Linear

O termo modo operacional refere-se a um certo método de manter um serviço em funcionamento. Vários itens de trabalho aumentam com o tamanho do serviço. Por exemplo, um serviço precisa de uma forma de aumentar o número de máquinas virtuais configuradas (VMs) à medida que cresce. Uma equipe em modo operacional responde tendo um maior número de administradores gerindo esses VMs. O SRE concentra-se antes em escrever software ou eliminar preocupações de escalabilidade, para que o número de pessoas necessárias para executar um serviço não aumente em função da carga no serviço.

As equipes que entram no modo operacional podem estar convencidas de que a escala não é importante para elas (“o meu serviço é minúsculo”). Acompanhe uma sessão de plantão para determinar se a avaliação é verdadeira, porque o elemento de escala afeta sua estratégia.

Se o serviço primário é importante para o negócio, mas na realidade é minúsculo (implicando poucos recursos ou baixa complexidade), ponha mais atenção às formas como a abordagem atual da equipe os impede de melhorar a confiabilidade do serviço. Lembre-se de que o seu trabalho é fazer o serviço funcionar, e não proteger a equipe de desenvolvimento de alertas.

Por outro lado, se o serviço está apenas começando, concentre-se em formas de preparar a equipe para um crescimento explosivo. Um serviço de 100 pedidos/segundo pode se transformar num serviço de 10k pedidos/segundo em um ano. 

Identificar as Maiores Fontes de Estresse

As equipes SRE caem por vezes no modo operacional porque se concentram em como abordar rapidamente as emergências em vez de como reduzir o número de emergências. Uma falha no modo operacional acontece normalmente em resposta a uma pressão esmagadora, real ou imaginária. Depois de ter aprendido o suficiente sobre o serviço para fazer perguntas difíceis sobre o seu projeto e implantação, passe algum tempo priorizando várias falhas de serviço de acordo com o seu impacto nos níveis de estresse da equipe. Tenha em mente que, devido à perspectiva e história da equipe, alguns problemas muito pequenos ou interrupções podem produzir uma quantidade desordenada de estresse.

Identifique o Kindling

Uma vez identificados os maiores problemas existentes de uma equipe, passemos às situações de emergência à espera de acontecer. Por vezes, as emergências iminentes surgem sob a forma de um novo subsistema que não foi projetado para ser autogerenciado. Outras fontes incluem:

Lacunas de conhecimento

Em grandes equipes, as pessoas podem especializar-se demasiado sem consequências imediatas. Quando uma pessoa se especializa, corre o risco de ou não ter o amplo conhecimento de que necessita para realizar o apoio de plantão ou permitir aos membros da equipe ignorar as peças críticas do sistema que possuem.

Serviços desenvolvidos pelo SRE que estão aumentando silenciosamente em importância

Estes serviços muitas vezes não recebem a mesma atenção cuidadosa que os lançamentos de novas funcionalidades porque são mais pequenos em escala e implicitamente endossados por pelo menos um SRE.

Forte dependência da “próxima grande coisa”

As pessoas podem ignorar os problemas durante meses a fio, porque acreditam que a nova solução que está no horizonte evita correções temporárias.

Alertas comuns que não são diagnosticados nem pela equipe de desenvolvimento nem pelos SREs

Tais alertas são frequentemente classificados como transitórios, mas ainda assim distraem os seus colegas de equipe da resolução de problemas reais. Investigue tais alertas por completo, ou conserte as regras de alerta.

Qualquer serviço que seja simultaneamente objeto de queixas dos seus clientes e que careça de um SLI/SLO/SLA formal

Ver Capítulo 4 para uma discussão de SLIs, SLOs, e SLAs. 

Qualquer serviço com um plano de capacidade que seja efetivamente “Adicionar mais servidores: os nossos servidores estavam ficando sem memória ontem à noite”.

Os planos de capacidade devem ser suficientemente voltados para o futuro. Se o seu modelo de sistema prevê que os servidores precisam de 2 GB, um teste de carga que passe a curto prazo (revelando 1,99 GB na sua última execução) não significa necessariamente que a capacidade do seu sistema esteja em condições adequadas.

Os postmortems que só têm itens de ação para fazer recuar as alterações específicas que causaram uma interrupção

Por exemplo, “Mudar o tempo limite de transmissão de volta para 60 segundos”, em vez de “Descobrir porque é que às vezes leva 60 segundos para buscar o primeiro megabyte de nossos vídeos promocionais”.

Qualquer componente crítico de serviço para o qual as SREs existentes respondem às perguntas dizendo: “Não sabemos nada sobre isso; os desenvolvedores são os donos”.

Para dar um apoio de plantão aceitável para um componente, deve pelo menos saber as consequências quando este quebra e a urgência necessária para resolver os problemas. 

Fase 2: Contexto de Partilha

Depois de analisar a dinâmica e os pontos problemáticos da equipe, lance as bases para a melhoria através de melhores práticas como os postmortems e a identificação de fontes de trabalho e a melhor forma de os abordar.

Escreva um bom postmortem para a equipe 

Os postmortems oferecem muito insight sobre o raciocínio coletivo de uma equipe. Os postmortems conduzidos por equipes pouco saudáveis são frequentemente ineficazes. Alguns membros da equipe podem considerar os postmortems punitivos, ou mesmo inúteis. Embora possam ser tentados a rever os arquivos postmortems e deixar comentários para melhorias, isso não ajuda a equipe. Em vez disso, o exercício pode colocar a equipe na defensiva.

Em vez de tentar corrigir erros anteriores, aproprie-se do próximo postmortem. Haverá uma interrupção enquanto estiver integrado. Se não for a pessoa de plantão, junte-se ao SRE de plantão para escrever um grande postmortem, sem culpa. Este documento é uma oportunidade para demonstrar como uma mudança para o modelo SRE beneficia a equipe, tornando as correções de bugs mais permanentes. Correções de bugs mais permanentes reduzem o impacto das interrupções no tempo dos membros da equipe.

Tal como mencionado, poderá encontrar respostas como “Por que eu?” Esta resposta é especialmente provável quando uma equipe acredita que o processo postmortem é retaliatório. Esta atitude vem da adesão à Teoria da Maçã Má: o sistema está funcionando bem, e se nos livrarmos de todas as maçãs más e dos seus erros, o sistema continuará funcionando bem. A Teoria da Maçã Má é comprovadamente falsa, como demonstram as provas de várias disciplinas, incluindo a segurança aérea. Deve-se apontar esta falsidade. A frase mais eficaz para uma postmortem é dizer: “Os erros são inevitáveis em qualquer sistema com múltiplas interações sutis”. Você estava de plantão e eu confio em você para tomar as decisões certas com as informações certas. Gostaria que escrevesse o que estava pensando em cada momento, para que possamos descobrir onde o sistema o enganou, e onde as exigências cognitivas eram demasiado elevadas”. 

Classifique os incêndios de acordo com o tipo

Há dois tipos de incêndios neste modelo simplificado por conveniência:

  • Alguns incêndios não deveriam existir. Provocam o que é comummente chamado trabalho operacional ou labuta (ver Capítulo 5).

     

  • Outros incêndios que causam estresse e/ou digitação furiosa fazem realmente parte do trabalho.

Em qualquer dos casos, a equipe precisa construir ferramentas para controlar a queima.

Classifique os incêndios da equipe em labuta e não labuta. Quando terminar, apresente a lista à equipe e explique claramente porque é que cada incêndio é ou um trabalho que deve ser automatizado ou uma sobrecarga aceitável para o funcionamento do serviço.

Fase 3: Mudança de direção

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?”

Conclusão

Seguindo os princípios delineados neste capítulo, uma equipe SRE tem o seguinte:

  • Uma perspectiva técnica, possivelmente quantitativa, sobre a razão pela qual devem mudar.

     

  • Um forte exemplo de como é a mudança.

     

  • Uma explicação lógica para grande parte da “sabedoria popular” utilizada pelo SRE.

     

  • Os princípios fundamentais necessários para enfrentar situações inovadoras de uma forma escalável.

A sua tarefa final é escrever um relatório pós-ação. Este relatório deve reiterar a sua perspectiva, exemplos e explicações. Deve também fornecer alguns itens de ação para a equipe, a fim de assegurar que exercem o que lhes ensinou. Pode organizar o relatório como um postvitam, explicando as decisões críticas em cada passo que levou ao sucesso.

A maior parte do compromisso está agora completa. Depois que sua atribuição integrada for concluída, deverá permanecer disponível para revisões de design e código. Fique de olho na equipe durante os próximos meses para confirmar que estão melhorando lentamente o planejamento da sua capacidade, a resposta de emergência e os processos de implementação. 

 

Fonte: Google SRE Book

Experimente agora, grátis!