Escrito por Ollie Cook, Sara Smollett, Andrea Spadaccini,

Cara Donnelly, Jian Ma, e Garrett Plasky (Evernote)

com Stephen Thorne e Jessie Yang 

 

Estar de plantão significa estar disponível durante um determinado período de tempo, e estar pronto para responder a incidentes de produção durante esse período com a devida urgência. Os engenheiros de confiabilidade do site (SREs) geralmente são obrigados a participar de rotação de plantão.  Durante os turnos de plantão, os SREs diagnosticam, mitigam, corrigem ou escalam incidentes conforme necessário.  Além disso, os SREs são regularmente responsáveis ​​por tarefas de produção não urgentes.

 No Google, estar de plantão é uma das características que definem os SRE. As equipes de SRE mitigam incidentes, reparam problemas de produção e automatizam tarefas operacionais. Como a maioria de nossas equipes de SRE ainda não automatizou totalmente todas as suas tarefas operacionais, as escalações precisam de pontos de contato humanos – engenheiros de plantão. Dependendo de quão críticos são os sistemas suportados, ou do estado de desenvolvimento dos sistemas, nem todas as equipes SRE podem precisar estar de plantão. Segundo a nossa experiência, a maioria das equipes SRE fazem turnos de plantão.

 O plantão é um tópico grande e complexo, sobrecarregado com muitas restrições e uma margem limitada para tentativa e erro. O capítulo 11 do nosso primeiro livro (engenharia de confiabilidade do site), “Estar de Plantão,” já explorou este tópico. Este capítulo aborda comentários e perguntas específicas que recebemos sobre esse capítulo. Estas incluem o seguinte: 

• “Não somos o Google; somos muito mais pequenos. Não temos tantas pessoas no revezamento, e não temos sites em fusos horários diferentes. O que descreveu no seu primeiro livro é irrelevante para mim”.
• “Temos uma mistura de desenvolvedores e DevOps para a rotação de plantão.  Qual a melhor forma de organizá-los?  Dividir as responsabilidades”?
• “Nosso engenheiro de plantão é ‘paginado’ cerca de cem vezes em um turno típico de 24 horas. Muitas páginas são ignoradas, enquanto os verdadeiros problemas são enterrados debaixo da pilha. Por onde devemos começar”?
• “Temos uma alta taxa de rotatividade de plantões.  Como você aborda a lacuna de conhecimento dentro da equipe”?
• “Queremos reorganizar nossa equipe de DevOps no SRE. Qual é a diferença entre SRE de plantão, DevOps de plantão e desenvolvedores de plantão?  Por favor, seja específico, porque a equipe de DevOps está muito preocupada com isso”.

Oferecemos conselhos práticos para essas situações.  O Google é uma grande empresa com uma organização SRE madura, mas muito do que aprendemos ao longo dos anos pode ser aplicado a qualquer empresa ou organização, independentemente do tamanho ou maturidade. O Google tem centenas de rotações de plantão em serviços de todos os tamanhos e várias configurações de plantão, de simples a complicadas.  O plantão não é uma função exclusiva do SRE: muitas equipes de desenvolvedores estão diretamente de plantão para seu serviço. Cada configuração de plantão atende a necessidade de um determinado serviço.

Este capítulo descreve as configurações de plantão dentro e fora do Google.  Embora sua configuração e situação provavelmente sejam diferentes de nossos exemplos específicos, os conceitos essenciais que abordamos são amplamente aplicáveis.

Em seguida, nos aprofundamos na anatomia do carregamento do pager, explicando o que causa o carregamento do pager.  Sugerimos estratégias para otimizar a configuração de plantão e minimizar essa carga.

Por fim, compartilhamos dois exemplos de práticas dentro do Google: flexibilidade de plantão e dinâmica de equipe de plantão.  Essas práticas mostram que não importa quão matematicamente seja uma configuração de plantão, você não pode confiar apenas na logística da configuração de plantão.  Os incentivos e a natureza humana desempenham um papel importante e também devem ser levados em consideração. 

Recapitulação do capítulo “Estar de plantão” do primeiro livro SRE

A Engenharia de confiabilidade do site, em “Estar de plantão“, explica os princípios por trás das rotações de plantão no Google.  Esta seção discute os principais pontos desse capítulo.

No Google, o objetivo geral de estar de plantão é fornecer cobertura para serviços críticos, garantindo ao mesmo tempo que nunca alcançaremos a confiabilidade às custas da saúde de um engenheiro de plantão. Como resultado, as equipes de SRE esforçam-se por alcançar o equilíbrio. O trabalho de SRE deve ser uma combinação saudável de tarefas: trabalho de plantão e projeto. Especificar que os SREs gastem pelo menos 50% de seu tempo no trabalho do projeto significa que as equipes têm tempo para lidar com os projetos necessários para resolver estrategicamente quaisquer problemas encontrados na produção.  O pessoal da equipe deve ser adequado para garantir tempo para o trabalho do projeto.

 Visamos um máximo de dois incidentes por turno de plantão, para assegurar tempo adequado para o acompanhamento. Se a carga do pager ficar muito alta, é necessária uma ação corretiva.  (Exploramos o carregamento do pager mais adiante neste capítulo).

 A segurança psicológica é vital para rotações de plantão eficazes. Como estar de plantão pode ser assustador e altamente estressante, os engenheiros de plantão devem ser totalmente apoiados por uma série de procedimentos e caminhos de escalonamento para facilitar suas vidas.

 O plantão geralmente implica algum trabalho fora do horário de trabalho. Acreditamos que este trabalho deve ser compensado. Embora diferentes empresas possam optar por lidar com isso de maneiras diferentes, o Google oferece folgas ou compensação em dinheiro, limitada a uma proporção do salário total. O esquema de compensação fornece um incentivo para fazer parte do plantão e garante que os engenheiros não assumam muitos turnos de plantão por razões econômicas. 

Exemplo de configurações de plantão no Google e fora do Google

Esta seção descreve exemplos reais de configurações de plantão no Google e Evernote, uma empresa da Califórnia que desenvolve uma aplicação multiplataforma que ajuda indivíduos e equipes a criar, reunir e compartilhar informações.  Para cada empresa, exploramos o raciocínio por trás das configurações de plantão, filosofia geral de plantão e práticas de plantão. 

Google: Formação de uma nova equipe

Cenário inicial

Há alguns anos, Sara, uma SRE no Google Mountain View, iniciou uma nova equipe de SRE que precisava estar de plantão em três meses. Para colocar isso em perspectiva, a maioria das equipes de SRE do Google não espera que as novas contratações estejam prontas para plantão antes de três a nove meses. A nova equipe de SRE de Mountain View ofereceria suporte a três serviços do Google Apps que anteriormente eram apoiados por uma equipe de SRE em Kirkland, Washington (um voo de duas horas de Mountain View).  A equipe de Kirkland tinha uma equipe de SRE irmã em Londres, que continuaria a dar suporte a esses serviços juntamente com a nova equipe de SRE de Mountain View e equipes de desenvolvimento de produtos distribuídos.

A nova equipe SRE de Mountain View se reuniu rapidamente, reunindo sete pessoas:

• Sara, líder de tecnologia SRE
• Mike, um SRE experiente de outra equipe SRE
• Uma transferência de uma equipe de desenvolvimento de produto que era nova no SRE
• Quatro novas contratações (“Nooglers”)

Mesmo quando uma equipe está madura, ficar de plantão para novos serviços é sempre um desafio, e a nova equipe de Mountain View SRE era uma equipe relativamente júnior. No entanto, a nova equipe conseguiu integrar os serviços sem sacrificar a qualidade do serviço ou a velocidade do projeto. Eles fizeram melhorias imediatas nos serviços, incluindo a redução dos custos da máquina em 40% e a automatização completa de lançamentos de liberação com canarying e outras verificações de segurança. A nova equipe também continuou a fornecer serviços confiáveis, visando 99,98% de disponibilidade, ou aproximadamente 26 minutos de inatividade por trimestre.

Como a nova equipe SRE se esforçou para realizar tanto? Através de projetos iniciais, tutoria, e formação. 

Roteiro de formação

Embora a nova equipe de SRE não soubesse muito sobre seus serviços, Sara e Mike estavam familiarizados com o ambiente de produção e o SRE do Google. Como os quatro Nooglers completaram a orientação da empresa, Sara e Mike compilaram uma lista de verificação de duas dúzias de áreas de foco para as pessoas praticarem antes de entrar de plantão, como: 

• Administração de trabalhos de produção
• Noções básicas sobre informações de depuração
• “Drenagem” do tráfego longe de um cluster
• Reverter um push de software ruim
• Bloquear ou limitar o tráfego indesejado
• Aumento da capacidade de serviço adicional
• Utilização dos sistemas de monitoramento (para alertas e dashboards)
• Descrever a arquitetura, vários componentes, e dependências dos serviços

Os Nooglers encontraram algumas destas informações por conta própria, pesquisando a documentação e os codelabs existentes (tutoriais de codificação orientados e práticos) e ganharam compreensão sobre tópicos relevantes, trabalhando nos seus projetos iniciais. Quando um membro da equipe aprendeu sobre tópicos específicos relevantes para os projetos iniciais dos Nooglers, essa pessoa liderou uma sessão curta e improvisada para compartilhar essas informações com o resto da equipe. Sara e Mike cobriram os tópicos restantes. A equipe também realizou sessões de laboratório para realizar tarefas comuns de depuração e mitigação para ajudar todos a construir a memória muscular e ganhar confiança nas suas habilidades.

Além da lista de verificação, a nova equipe do SRE realizou uma série de “mergulhos profundos” para aprofundar seus serviços. A equipe navegou nos consoles de monitoramento, identificou trabalhos em execução e tentou depurar páginas recentes.  Sara e Mike explicaram que um engenheiro não precisa de anos de experiência em cada um dos serviços para se tornar razoavelmente proficiente. Eles treinaram a equipe para explorar um serviço desde os primeiros princípios e incentivaram os Nooglers a se familiarizarem com os serviços.  Eles foram abertos sobre os limites de seu conhecimento e ensinaram aos outros quando pedir ajuda.

Ao longo do ramp-up, a nova equipe SRE não estava sozinha. Sara e Mike viajaram para conhecer outras equipes de SRE e desenvolvedores de produtos e aprender com eles.  A nova equipe SRE se reuniu com as equipes de Kirkland e Londres realizando videoconferências, trocando e-mails, e conversando por IRC. Além disso, a equipe participou de reuniões semanais de produção, leu handoffs e post-mortems diários de plantão e consultou a documentação de serviço existente. Um SRE de Kirkland visitou para dar palestras e responder a perguntas. Um SRE de Londres elaborou um conjunto exaustivo de cenários de catástrofe e dirigiu-os durante a semana de formação de recuperação de desastres do Google (ver a seção “Preparação e Teste de Desastres” em Engenharia de Confiabilidade do site, Capítulo 33).

A equipe também praticou ficar de plantão por meio de exercícios de treinamento “Roda do Infortúnio” (ver a secção “Encenação de Desastres” em Engenharia de Confiabilidade do Site, Capítulo 28), onde eles representaram incidentes recentes para praticar a depuração de problemas de produção. Durante essas sessões, todos os SREs foram incentivados a oferecer sugestões sobre como resolver falhas de produção simuladas. Depois do término do processo de ramp-up com todos, a equipe ainda realizou essas sessões, alternando entre cada membro da equipe como líder da sessão.  A equipe gravou estes para referência futura.  

Antes de entrar de plantão, a equipe revisou diretrizes precisas sobre as responsabilidades dos engenheiros de plantão.  Por exemplo:

• No início de cada turno, o engenheiro de plantão lê o handoff do turno anterior.
• O engenheiro de plantão minimiza o impacto do usuário primeiro e, em seguida, garante que os problemas sejam totalmente resolvidos.
• No final do turno, o engenheiro de plantão envia um e-mail de handoff para o próximo engenheiro de plantão.

As diretrizes também especificavam quando escalar para outras pessoas, e como escrever post-mortems para grandes incidentes.

Por fim, a equipe leu e atualizou os playbooks de plantão. Os playbooks contêm instruções de alto nível sobre como responder a alertas automatizados.  Eles explicam a gravidade e o impacto do alerta e incluem sugestões de depuração e possíveis ações a serem tomadas para mitigar o impacto e resolver totalmente o alerta. No SRE, sempre que um alerta é criado, geralmente é criada uma entrada correspondente no playbook.  Esses guias reduzem o estresse, o tempo médio de reparo (MTTR) e o risco de erro humano.

Manutenção de playbook 

Os detalhes nos playbook ficam desatualizados na mesma proporção em que o ambiente de produção muda. Para lançamentos diários, os playbooks podem precisar de uma atualização em qualquer dia.  Escrever uma boa documentação, como qualquer forma de comunicação, é difícil. Então, como é que se mantêm os playbooks?

 Alguns SREs do Google defendem manter as entradas do playbook gerais para que elas mudem lentamente. Por exemplo, eles podem ter apenas uma entrada para todos os alertas de “Erros RPC Elevados”, para um engenheiro de plantão treinado ler em conjunto com um diagrama de arquitetura para o serviço de alerta atual. Outros SREs defendem playbooks passo-a-passo para reduzir a variabilidade humana e conduzir para baixo o MTTR. Se a sua equipe tiver opiniões conflitantes sobre o conteúdo dos playbooks, os playbooks podem ser puxados em várias direções.

 Este é um tópico controverso. Se não concordar com mais nada, pelo menos decida com a sua equipe que detalhes mínimos e estruturados os seus playbooks devem ter, e tente perceber quando os seus playbooks tiverem acumulado muita informação para além destes detalhes estruturados. Esboce um projeto para transformar novos conhecimentos de produção, duramente conquistados, em consolas de automatização ou monitoramento. Se os seus playbooks são uma lista determinista de comandos que o engenheiro de plantão executa sempre que um determinado alerta dispara, recomendamos que implementem a automação. 

Após dois meses, Sara, Mike, e a transferência do SRE acompanharam os turnos de plantão da equipe de Kirkland SRE de saída. Aos três meses, tornaram-se a principal equipe de plantão, com os SREs de Kirkland como apoio. Dessa forma, eles poderiam facilmente escalar para os SREs de Kirkland, se necessário.  Em seguida, os Nooglers seguiram os SREs locais mais experientes e se juntaram à rotação.

A boa documentação e as várias estratégias discutidas anteriormente ajudaram a equipe a formar uma base sólida e a subir rapidamente. Embora o plantão possa ser estressante, a confiança das equipes cresceu o suficiente para agir sem se questionar.  Havia segurança psicológica em saber que suas respostas eram baseadas no conhecimento coletivo da equipe e que, mesmo quando escaladas, os engenheiros de plantão ainda eram considerados engenheiros competentes.

Posfácio

Enquanto os SREs de Mountain View estavam em processo de ramp-up, eles souberam que sua experiente equipe irmã de SRE em Londres passaria para um novo projeto e uma nova equipe estava sendo formada em Zurique para dar suporte aos serviços anteriormente apoiados pela equipe de SRE de Londres. Para esta segunda transição, a mesma abordagem básica usada pelos SREs de Mountain View provou ser bem-sucedida.  O investimento anterior dos SREs de Mountain View no desenvolvimento de materiais de integração e treinamento ajudou a nova equipe de SRE de Zurique a crescer.

Embora a abordagem usada pelos SREs de Mountain View fizesse sentido quando um grupo de SREs estava se tornando uma equipe, eles precisavam de uma abordagem mais leve quando apenas uma pessoa se juntava à equipe em um determinado momento. Antecipando a rotatividade futura, os SREs criaram diagramas de arquitetura de serviço e formalizaram a lista de verificação básica do treinamento em uma série de exercícios que poderiam ser concluídos de forma semi-independente com o mínimo envolvimento de um mentor. Esses exercícios incluíam a descrição da camada de armazenamento, a realização de aumentos de capacidade e a revisão de como as solicitações HTTP são encaminhadas. 

Evernote: Encontrando nossos pés na nuvem

Movendo a nossa infra-estrutura on-prem para a nuvem

Não nos propusemos a reestruturar nosso processo de plantão, mas, como em muitas coisas na vida, a necessidade é a mãe da invenção.  Antes de dezembro de 2016, o Evernote era executado apenas em datacenters on-prem, criados para apoiar a nossa aplicação monolítica. Nossa rede e servidores foram projetados com uma arquitetura e fluxo de dados específicos em mente.  Isso, combinado com uma série de outras restrições, significava que não tínhamos a flexibilidade necessária para oferecer suporte a uma arquitetura horizontal. O Google Cloud Platform (GCP) forneceu uma solução concreta para nosso problema.  No entanto, ainda tínhamos um grande obstáculo a superar: migrar toda a nossa produção e infraestrutura de suporte para o GCP. 70 dias de avanço rápido. Por meio de um esforço hercúleo e muitos feitos notáveis (por exemplo, mover milhares de servidores e 3,5 PB de dados), fomos acomodados em nossa nova casa.  Nesse ponto, porém, nosso trabalho ainda não havia terminado: como iríamos monitorar, alertar e – o mais importante – responder a problemas em nosso novo ambiente?

Ajustando nossas políticas e processos de plantão

A mudança para a nuvem liberou o potencial de crescimento rápido de nossa infraestrutura, mas nossas políticas e processos de plantão ainda não foram configurados para lidar com esse crescimento.  Assim que a migração foi concluída, partimos para remediar o problema. Em nosso datacenter físico anterior, criamos redundância em quase todos os componentes.  Isso significava que, embora a falha do componente fosse comum devido ao nosso tamanho, geralmente nenhum componente individual era capaz de afetar negativamente os usuários. A infra-estrutura era muito estável porque a controlávamos — qualquer pequeno solavanco seria inevitavelmente devido a uma falha em algum lugar do sistema.  Nossas políticas de alerta foram estruturadas com isso em mente: alguns pacotes descartados, resultando em uma exceção de conexão JDBC (Java Database Connectivity), invariavelmente significavam que um host de VM (máquina virtual) estava prestes a falhar ou que o plano de controle em um de nossos interruptores estava com defeito. Mesmo antes do nosso primeiro dia na nuvem, percebemos que esse tipo de sistema de alerta/resposta não era sustentável no futuro.  Em um mundo de migrações ao vivo e latência de rede, precisávamos adotar uma abordagem muito mais holística ao monitoramento.

A reformulação dos eventos de paginação em termos de primeiros princípios, e escrever esses princípios como nossos SLOs (objetivos de nível de serviço) explícitos, ajudou a dar à equipe clareza sobre o que era importante alertar e nos permitiu eliminar a gordura de nossa infraestrutura de monitoramento. O nosso enfoque em indicadores de nível mais elevado, tais como a capacidade de resposta API, em vez de infra-estruturas de nível mais baixo, tais como as esperas de bloqueio de linha InnoDB no MySQL, permitiu-nos concentrar mais tempo na dor real que nossos usuários experimentam durante uma interrupção.  Para nossa equipe, isso significou menos tempo gasto na busca de problemas transitórios.  Isso se traduziu em mais sono, eficácia e, finalmente, satisfação no trabalho.

Reestruturando nosso monitoramento e métricas

Nosso principal revezamento de plantão é composto por uma equipe pequena, mas desconexa, de engenheiros que são responsáveis por nossa infraestrutura de produção e alguns outros sistemas de negócios (por exemplo, preparação e construção de infraestrutura de pipeline). Temos um horário semanal, 24 horas por dia, 7 dias por semana, com um procedimento de handoff bem calibrado, juntamente com uma revisão matinal de incidentes em uma reunião diária. O tamanho da nossa pequena equipe e o âmbito comparativamente grande da responsabilidade exige que façamos todos os esforços para manter a carga do processo leve, e que nos concentremos em fechar o mais rapidamente possível o ciclo de alerta/triagem/correção/análise. Uma das formas de o conseguirmos é manter a nossa relação sinal/ruído baixa, mantendo SLAs de alerta simples, mas eficazes (acordos de nível de serviço). Classificamos qualquer evento gerado pelas nossas métricas ou infraestrutura de monitoramento em três categorias:

P1: Lidar imediatamente com

• Deve ser imediatamente acionável
• Páginas de plantão
• Leva à triagem do evento
• Tem impacto no SLO

P2: Lidar com o próximo dia útil

• Geralmente não é voltado para o cliente, ou tem escopo muito limitado
• Envia um e-mail à equipe e notifica o canal de stream de eventos

P3: O evento é apenas informativo

• A informação é recolhida em dashboards, e-mails passivos e similares
• Inclui informação relativa ao planejamento de capacidade

Qualquer evento P1 ou P2 tem um ticket de incidente anexado a ele.  O ticket é usado para tarefas óbvias, como triagem de eventos e ações de correção de rastreamento, bem como para impacto do SLO, número de ocorrências e links de documentos postmortem, quando aplicável.

Quando um evento é paginado (categoria P1), o plantão tem a tarefa de avaliar o impacto para os usuários. Os incidentes são classificados em severidades de 1 a 3. Para incidentes de severidade 1 (Sev 1), mantemos um conjunto finito de critérios para tornar a decisão de escalada tão simples quanto possível para o respondente. Depois que o evento é escalado, montamos uma equipe de incidentes e iniciamos nosso processo de gerenciamento de incidentes.  O gerente de incidentes é chamado, um escrivão e um chefe de comunicação é eleito, e os nossos canais de comunicação são abertos. Após a resolução do incidente, realizamos um postmortem automático e compartilhamos os resultados em grande escala dentro da empresa. Para eventos com a classificação Sev 2 ou Sev 3, o atendente de plantão lida com o ciclo de vida do incidente, incluindo um post-mortem abreviado para revisão do incidente.

Um dos benefícios de manter nosso processo leve é ​​que podemos liberar explicitamente o plantão de qualquer expectativa do trabalho do projeto. Isso capacita e incentiva o plantão a tomar medidas imediatas de acompanhamento e também a identificar quaisquer lacunas importantes nas ferramentas ou no processo após a conclusão da revisão pós-incidente. Desta forma, alcançamos um ciclo constante de melhoria e flexibilidade durante cada turno de plantão, acompanhando a rápida taxa de mudança em nosso ambiente.  O objetivo é tornar cada turno de plantão melhor que o anterior.

Acompanhamento do nosso desempenho ao longo do tempo

Com a introdução dos SLOs, queríamos acompanhar o desempenho ao longo do tempo e compartilhar essas informações com as partes interessadas dentro da empresa. Implementamos uma reunião mensal de revisão do serviço, aberta a todos os interessados, para revisar e discutir o mês anterior do serviço. Também usamos este fórum para revisar nossa carga de plantão como um barômetro da saúde da equipe e discutir ações de remediação quando excedemos nosso orçamento de pager.  Este fórum tem o duplo propósito de difundir a importância dos SLOs dentro da empresa e manter a organização técnica responsável por manter a saúde e o bem-estar de nosso serviço e equipe. 

Engajamento com o CRE

Expressar nossos objetivos em termos de SLOs fornece uma base para engajar com a equipe de engenharia de confiabilidade do cliente (CRE) do Google. Depois de discutirmos nossos SLOs com o CRE para ver se eles eram realistas e mensuráveis, ambas as equipes decidiram que o CRE seria chamado junto com nossos próprios engenheiros para eventos de impacto do SLO. Pode ser difícil identificar as causas-raiz que estão escondidas atrás de camadas de abstração de nuvens, por isso ter um Googler ao nosso lado para tirar as suposições da triagem de eventos de caixa preta foi útil. Mais importante ainda, este exercício reduziu ainda mais o nosso MTTR, que é, em última análise, o que interessa aos nossos usuários.

Sustentando um ciclo auto-perpetuador

Em vez de gastar todo o nosso tempo no ciclo de triagem/análise de causa raiz/post-mortem, agora temos mais tempo como equipe para pensar em como levar o negócio adiante.  Especificamente, isso se traduz em projetos como melhorar nossa plataforma de microsserviços e estabelecer critérios de prontidão de produção para nossas equipes de desenvolvimento de produtos. Este último inclui muitos dos princípios que seguimos na reestruturação do nosso plantão, o que é particularmente útil para as equipes em seu primeiro rodeio “carregar o pager”.  Assim, perpetuamos o ciclo de melhoria do plantão para todos. 

Detalhes práticos de implementação

Até agora, discutimos detalhes sobre configurações de plantão, dentro e fora do Google.  Mas e as considerações específicas de estar de plantão?  As seções a seguir discutem esses detalhes de implementação com mais profundidade:

• Carregamento do pager — o que é, como funciona e como gerenciá-lo
• Como incluir flexibilidade no agendamento de plantão para criar um equilíbrio entre trabalho e vida pessoal mais saudável para os SREs
• Estratégias para melhorar a dinâmica da equipe, tanto dentro de uma determinada equipe SRE, quanto com equipes parceiras

Anatomia do Carregamento do pager

Seu pager é barulhento e está deixando sua equipe infeliz.  Você leu o Capítulo 31 em Engenharia de confiabilidade do site e realiza reuniões regulares de produção, tanto com sua equipe quanto com as equipes de desenvolvedores que você apoia.  Agora todos sabem que seus engenheiros de plantão estão insatisfeitos. O que se segue?

Carregamento do pager é o número de incidentes de página que um engenheiro de plantão recebe durante um período típico de turno (como por dia ou por semana). Um incidente pode envolver mais do que uma página. Aqui, vamos caminhar através do impacto de vários fatores no Carregamento do pager, e sugerir técnicas para minimizar o Carregamento do pager futuro.

Tempos de Resposta Apropriados

Os engenheiros não deveriam estar em um computador e trabalhando em um problema minutos depois de receber um pager, a menos que haja uma boa razão para fazê-lo.  Embora uma interrupção completa de um serviço gerador de receita voltado para o cliente normalmente exija uma resposta imediata, você pode lidar com problemas menos graves (por exemplo, backups com falha) em poucas horas.

Recomendamos verificar sua configuração de paginação atual para ver se você realmente deve ser paginado para tudo o que aciona uma página no momento. Você pode estar paginando para problemas que seriam melhor servidos por reparações automáticas (já que geralmente é melhor para um computador corrigir um problema do que exigir que um humano o conserte) ou um ticket (se não for realmente de alta prioridade). O Tabela 8-1 mostra alguns exemplos de eventos e respostas apropriadas. 

Tabela 8-1. Exemplos de tempos de resposta realistas

Descrição do incidente	Tempo de resposta	Impacto SRE
Interrupção de rede com impacto na receita	5 minutos	O SRE precisa estar sempre ao alcance de um laptop carregado e autenticado com acesso à rede;  não pode viajar;  deve coordenar fortemente com o secundário em todos os momentos
Sistema de processamento de pedidos de clientes em lote bloqueado	30 minutos	O SRE pode sair de casa para um recado rápido ou uma viagem curta;  secundário não precisa fornecer cobertura durante esse período
Os backups de um banco de dados para um serviço de pré-lançamento estão falhando	Ticket (resposta durante o horário de trabalho)	Nenhum

Cenário: Uma equipe em sobrecarga

A (hipotética) equipe SRE de conexão, responsável pelo balanceamento de carga de front-end e terminação de conexões de usuário final, encontrou-se em uma posição de alta carga de pager.  Eles tinham um orçamento de pager estabelecido de dois incidentes de pager por turno, mas no ano anterior vinham recebendo regularmente cinco incidentes de pager por turno.  A análise revelou que um terço dos turnos estava excedendo seu orçamento de pager. Os membros da equipe responderam heroicamente ao ataque diário de páginas, mas não conseguiram acompanhar;  simplesmente não havia tempo suficiente no dia para encontrar a causa raiz e corrigir adequadamente os problemas que chegavam. Alguns engenheiros deixaram a equipe para se juntar a equipes menos sobrecarregadas operacionalmente.  O acompanhamento de incidentes de alta qualidade era raro, pois os engenheiros de plantão só tinham tempo para mitigar os problemas imediatos.

O horizonte da equipe não era totalmente sombrio: eles tinham uma infraestrutura de monitoramento madura que seguia as melhores práticas de SRE.  Os limites de alerta foram definidos para se alinharem com o SLO e os alertas de paginação eram baseados em sintomas por natureza, o que significa que eram acionados apenas quando os clientes eram afetados. Quando a gerência sênior foi abordada com todas essas informações, eles concordaram que a equipe estava em sobrecarga operacional e revisaram o plano do projeto para trazer a equipe de volta a um estado saudável.

Em notícias menos positivas, com o tempo, a equipe do Connection assumiu a propriedade de componentes de software de mais de 10 equipes de desenvolvedores e dependia fortemente das redes de ponta e backbone voltadas para o cliente do Google. O grande número de relacionamentos intergrupais era complexo e silenciosamente se tornara difícil de administrar.

Apesar da equipe seguir as melhores práticas na estruturação de seu monitoramento, muitas das páginas que enfrentavam estavam fora de seu controle direto.  Por exemplo, uma sonda de caixa preta pode ter falhado devido ao congestionamento na rede, causando perda de pacotes.  A única ação que a equipe poderia tomar para mitigar o congestionamento no backbone era escalar a equipe diretamente responsável por essa rede.

Além de sua carga operacional, a equipe precisava entregar novas funcionalidades aos sistemas front-end, que seriam utilizadas por todos os serviços Google. Para piorar a situação, sua infraestrutura estava sendo migrada de uma estrutura obsoleta de 10 anos e um sistema de gerenciamento de cluster para uma substituição com melhor suporte. Os serviços da equipe estavam sujeitos a uma taxa de mudança sem precedentes, e as próprias mudanças causaram uma parcela significativa da carga de plantão.

A equipe claramente precisava combater essa carga excessiva de pager usando uma variedade de técnicas.  O gerente técnico do programa e o gerente de pessoas da equipe abordaram a alta administração com uma proposta de projeto, que a alta administração revisou e aprovou.  A equipe voltou toda a sua atenção para reduzir a carga do pager e aprendeu algumas lições valiosas ao longo do caminho. 

Inputs de Carregamento do pager

O primeiro passo para lidar com a alta carga de pager é determinar o que está causando isso. A carga de pager é influenciada por três fatores principais: bugs na produção, alertas, e processos humanos. Cada um destes fatores tem vários inputs, alguns dos quais discutiremos com mais detalhes nesta seção.

Para a produção: 

• O número de bugs existentes na produção
• A introdução de novos bugs na produção
• A velocidade com que os bugs recentemente introduzidos são identificados
• A velocidade com que os bugs são mitigados e removidos da produção

Para alertar:

• Os limiares de alerta que desencadeiam um alerta de paginação
• A introdução de novos alertas de paginação
• O alinhamento do SLO de um serviço com os SLOs dos serviços dos quais depende

Para processos humanos:

• O rigor das correções e acompanhamento de bugs
• A qualidade dos dados coletados sobre os alertas de paginação
• A atenção prestada às tendências de carga de pager
• Mudanças na produção provocadas pelo homem

Bugs preexistentes

Nenhum sistema é perfeito. Haverá sempre bugs na produção: no seu próprio código, no software e nas bibliotecas que constrói, ou nas interfaces entre eles. Os bugs podem não estar causando alertas de paginação agora, mas eles estão definitivamente presentes.  Você pode usar algumas técnicas para identificar ou prevenir bugs que ainda não causaram alertas de paginação: 

• Assegure-se de que os sistemas sejam tão complicados quanto precisam ser e nada mais (ver Simplicidade). 
• Atualize regularmente o software ou as bibliotecas em que seu sistema foi construído para aproveitar as correções de bugs (contudo, ver a seção seguinte sobre novos bugs).
• Realize regularmente testes destrutivos ou fuzzing (por exemplo, utilizando o Macaco do Caos Netflix).
• Realize testes de carga regulares, além de integração e testes de unidade.

Novos bugs

Idealmente, a equipe SRE e suas equipes de desenvolvedores parceiros devem detectar novos bugs antes mesmo de entrar em produção.  Na realidade, o teste automatizado perde muitos bugs, que são então lançados para produção.

O teste de software é um grande tópico bem abordado em outros lugares (por exemplo, Martin Fowler em Teste). No entanto, as técnicas de teste de software são particularmente úteis para reduzir o número de bugs que chegam à produção e o tempo que permanecem em produção: 

• Melhore os testes ao longo do tempo.  Em particular, para cada bug que você descobrir na produção, pergunte “Como poderíamos ter detectado esse bug na pré-produção?”  Certifique-se de que o acompanhamento de engenharia necessário ocorra (ver Rigor do acompanhamento).
• Não ignore o teste de carga, que geralmente é tratado como prioridade menor do que o teste funcional.  Muitos bugs se manifestam apenas sob condições de carga específicas ou com uma combinação específica de solicitações.
• Realize a encenação (testes com tráfego semelhante à produção, mas sintético) em um ambiente semelhante à produção. Discutimos brevemente a geração de tráfego sintético em Alertar sobre SLOs deste livro. 
• Execute canários (Lançamento de Canarying) em um ambiente de produção.
• Tenha uma baixa tolerância a novos bugs. Siga uma estratégia de “detectar, reverter, corrigir e avançar” em vez de uma estratégia “detectar, continuar avançando apesar de identificar o bug, corrigir e avançar novamente”. (Ver Atraso de mitigação para mais detalhes). 

Este tipo de estratégia de reversão exige lançamentos previsíveis e frequentes para que o custo de reversão de qualquer lançamento seja pequeno. Discutimos isto e tópicos relacionados em “Engenharia de Confiabilidade do Site”, em “Engenharia de Lançamento“.

Alguns bugs podem se manifestar apenas como resultado da alteração do comportamento do cliente.  Por exemplo:

• Bugs que se manifestam apenas sob níveis específicos de carga – por exemplo, tráfego de volta às aulas em setembro, Black Friday, Cyber ​​Monday ou aquela semana do ano em que o horário de verão significa que a Europa e a América do Norte estão uma hora mais próximas, o que significa que mais usuários estão acordados e online simultaneamente.
• Bugs que se manifestam apenas com uma combinação específica de solicitações – por exemplo, servidores mais próximos da Ásia experimentam uma combinação de tráfego mais cara devido a codificações de idioma para conjuntos de caracteres asiáticos.
• Bugs que se manifestam apenas quando os usuários usam o sistema de maneiras inesperadas, por exemplo, o Calendário sendo usado por um sistema de reservas de companhias aéreas!  Portanto, é importante expandir seu regime de testes para testar comportamentos que não ocorrem todos os dias.

Quando um sistema de produção é atormentado por vários bugs simultâneos, é muito mais difícil identificar se uma determinada página é para um bug existente ou para um novo bug. Minimizar o número de bugs na produção não apenas reduz a carga do pager, mas também facilita a identificação e classificação de novos bugs.  Portanto, é fundamental remover os bugs de produção de seus sistemas o mais rápido possível. Priorize a correção de bugs existentes acima da entrega de novas funcionalidades; se isto requer colaboração entre equipes, ver Modelo de Envolvimento SRE. 

Problemas de arquitetura ou de procedimentos, como verificação de integridade automatizada, autorrecuperação e redução de carga, podem precisar de um trabalho de engenharia significativo para serem resolvidos.  Lembre-se, para simplificar, consideraremos esses problemas como “bugs”, mesmo que seu tamanho, sua complexidade ou o esforço necessário para resolvê-los seja significativo.

O Capítulo 3 da Engenharia de Confiabilidade do Site descreve como os orçamentos de erros são uma maneira útil de gerenciar a taxa na qual novos bugs são liberados para produção.  Por exemplo, quando as violações de SLO de um serviço excedem uma certa fração de seu orçamento total de erros trimestrais – normalmente acordado com antecedência entre o desenvolvedor e as equipes de SRE – o desenvolvimento de novas funcionalidades e implementações relacionadas com as funcionalidades pode ser temporariamente interrompido para se concentrar na estabilização do sistema e na redução da frequência das páginas.

A equipe do Connection do nosso exemplo adotou uma política rígida exigindo que cada interrupção tivesse um bug de rastreamento.  Isso permitiu que o gerente de programa técnico da equipe examinasse a causa raiz de seus novos bugs de forma agregada. Estes dados revelaram que o erro humano era a segunda causa mais comum de novos bugs na produção.

Como os humanos são propensos a erros, é melhor que todas as alterações feitas nos sistemas de produção sejam feitas por automação informada pela configuração de intenção (desenvolvida por humanos). Antes de fazer uma alteração na produção, a automação pode realizar testes adicionais que os humanos não podem.  A equipe do Connection estava fazendo mudanças complexas na produção de forma semimanual.  Não surpreendentemente, as alterações manuais da equipe às vezes davam errado; a equipe introduziu novos bugs, o que causou páginas. Os sistemas automatizados que faziam as mesmas alterações teriam determinado que as alterações não eram seguras antes de entrarem em produção e se tornarem eventos de paginação. O gerente técnico do programa levou esses dados para a equipe e os convenceu a priorizar os projetos de automação. 

Atraso de identificação

É importante identificar prontamente a(s) causa(s) dos alertas, pois quanto mais tempo leva para identificar a causa raiz de uma página, mais oportunidades ela tem de se repetir e voltar a paginar.  Por exemplo, dada uma página que se manifesta apenas sob alta carga, digamos, no pico diário, se o código ou a configuração problemática não for identificado antes do próximo pico diário, é provável que o problema ocorra novamente.  Existem várias técnicas que você pode usar para reduzir os atrasos de identificação:

Use bons alertas e consoles

Certifique-se de que as páginas estejam vinculadas aos consoles de monitoramento relevantes e que os consoles destaquem onde o sistema está operando fora da especificação.  No console, correlacione os alertas de paginação de caixa preta e caixa branca e faça o mesmo com seus gráficos associados. Certifique-se de que os playbooks estão atualizados com conselhos sobre como responder a cada tipo de alerta. Engenheiros de plantão devem atualizar o playbook com informação atualizada quando a página correspondente disparar. 

Pratique a resposta a emergências

Execute exercícios de “Roda da Infelicidade” (descritos em Engenharia de confiabilidade do site) para compartilhar técnicas de depuração gerais e específicas de serviço com seus colegas.

Faça pequenos lançamentos

Se efetuar lançamentos frequentes e mais pequenos em vez de alterações monolíticas infrequentes, será mais fácil correlacionar os bugs com a alteração correspondente que os introduziu. Lançamentos de canários, descritos em Lançamentos de canários, dão um forte sinal sobre se um novo bug é devido a um novo lançamento.

Alterações de Log

A agregação da informação de mudança numa linha temporal pesquisável torna mais simples (e esperemos que mais rápido) correlacionar novos bugs com a mudança correspondente que os introduziu. Ferramentas como o “Slack plug-in para Jenkins” podem ser úteis.

Pedir ajuda

Em Engenharia de confiabilidade do site, “Gerenciando incidentes”, falamos sobre trabalhar juntos para gerenciar grandes interrupções.  O engenheiro de plantão nunca está sozinho;  incentive sua equipe a se sentir segura ao pedir ajuda. 

Atraso de mitigação

Quanto mais tempo demorar para mitigar um bug depois de identificado, mais oportunidades ele terá de repetir e paginar novamente.  Considere estas técnicas para reduzir os atrasos de mitigação:

Reverter as alterações 

• Se o bug foi introduzido em um código recente ou em um lançamento de configuração, remova imediatamente o bug da produção com um rollback, se for seguro e apropriado (um rollback sozinho pode ser necessário, mas não é suficiente se o bug causou corrupção de dados, por exemplo). Lembre-se de que mesmo uma “solução rápida” precisa de tempo para ser testada, construída e implementada.  O teste é vital para garantir que a correção rápida realmente corrije o bug, e que não introduz bugs adicionais ou outras consequências não intencionais. Geralmente, é melhor “reverter, corrigir e avançar” em vez de “avançar, corrigir e avançar novamente”.
• Se você almeja uma disponibilidade de 99,99%, terá aproximadamente 15 minutos de orçamento de erro por trimestre. O passo de construção do “avanço” pode demorar muito mais do que 15 minutos, portanto, a reversão afeta muito menos seus usuários.

(A disponibilidade de 99,999% permite um orçamento de erro de 80 segundos por trimestre. Nesse ponto, os sistemas podem precisar de propriedades de autorrecuperação, o que está fora do escopo deste capítulo).

• Se possível, evite alterações que não possam ser revertidas, tais como alterações incompatíveis com API e lançamentos de bloqueio.

Usar isolamento de funcionalidades 

• Projete seu sistema para que, se a funcionalidade X der errado, você possa desativá-la, por exemplo, por meio de um sinalizador de funcionalidade sem afetar a funcionalidade Y. Essa estratégia também melhora a velocidade de lançamento e torna a desativação da funcionalidade X uma decisão muito mais simples – não precisa verificar se os seus gestores de produto estão confortáveis ​​com a desativação da funcionalidade Y.

Drenar solicitações

• Drene solicitações (ou seja, redirecione solicitações de clientes) para longe dos elementos do seu sistema que exibem o bug. Por exemplo, se o bug for o resultado de uma implementação de código ou configuração, e se for lançado para a produção gradualmente, poderá ter a oportunidade de drenar os elementos de sua infraestrutura que receberam a atualização.  Isso permite mitigar o impacto no cliente em segundos, em vez de reverter, o que pode levar minutos ou mais.

Alerta

O máximo de dois incidentes distintos do Google SRE por turno de 12 horas nos incentiva a ser atenciosos e cautelosos sobre a forma como configuramos os alertas de paginação e como introduzimos novos alertas. Em Engenharia de confiabilidade do site, “Monitoramento de sistemas distribuídos“, se descreve a abordagem do Google para definir os limites para alertas de paginação. Observar rigorosamente essas diretrizes é fundamental para manter um revezamento de plantão saudável.

Vale a pena destacar alguns elementos chave discutidos nesse capítulo:

• Todos os alertas devem ser imediatamente acionáveis.  Deve haver uma ação que esperamos que um humano execute imediatamente após receber a página que o sistema não pode executar.  A relação sinal-ruído deve ser alta para garantir poucos falsos positivos;  uma relação sinal-ruído baixa aumenta o risco de os engenheiros de plantão desenvolverem fadiga de alerta.
• Se uma equipe subscreve integralmente o alerta baseado no SLO, ou paginação apenas quando o orçamento de erro é queimado (consulte a seção “Caixa preta versus caixa branca” em Engenharia de confiabilidade do site), é fundamental que todas as equipes envolvidas no desenvolvimento e manutenção do serviço concordem sobre a importância de cumprir o SLO e priorizem o seu trabalho em conformidade.
• Se uma equipe subscreve plenamente um alerta baseado em SLO e em sintomas, relaxar os limites de alerta raramente é uma resposta apropriada para ser paginado.
• Tal como o novo código, os novos alertas devem ser revisados ​​de forma completa e cuidadosa. Cada alerta deve ter uma entrada no playbook correspondente.

A recepção de uma página cria um impacto psicológico negativo. Para minimizar esse impacto, só introduza novos alertas de paginação quando realmente precisar deles. Qualquer pessoa da equipe pode escrever um novo alerta, mas toda a equipe analisa as adições de alerta propostas e pode sugerir alternativas.  Teste minuciosamente os novos alertas em produção para verificar falsos positivos antes de serem atualizados para alertas de paginação.  Por exemplo, você pode enviar um e-mail para o autor do alerta quando o alerta for acionado, em vez de chamar o engenheiro de plantão.

Novos alertas podem encontrar problemas na produção dos quais você não estava ciente. Depois que você resolver esses bugs de produção, o alerta só irá paginar sobre novos bugs, funcionando eficazmente como testes de regressão.

Certifique-se de executar os novos alertas no modo de teste por tempo suficiente para experimentar condições de produção periódicas típicas, como lançamentos regulares de software, eventos de manutenção por seu provedor de nuvem, picos de carga semanais e assim por diante. Uma semana de testes é provavelmente mais ou menos o tempo certo. No entanto, esta janela apropriada depende do alerta e do sistema.

Finalmente, use a taxa de disparo do alerta durante o período de teste para prever o consumo esperado do orçamento do seu pager como resultado do novo alerta. Aprove ou desautorize explicitamente o novo alerta como uma equipe. Se a introdução de um novo alerta de pager fizer com que o seu serviço exceda o seu orçamento de pager, a estabilidade do sistema necessita de atenção adicional. 

Rigor do acompanhamento

Procure identificar a causa raiz de cada página.  As “causas raiz” se estendem para fora da máquina e para os processos da equipe.  Uma interrupção foi causada por um bug que teria sido detectado por um teste de unidade?  A causa raiz pode não ser um bug no código, mas sim um bug nos processos da equipe em torno da revisão de código.

Se você conhece a causa raiz, pode corrigi-la e evitar que ela incomode você ou seus colegas novamente.  Se sua equipe não conseguir descobrir a causa raiz, adicione monitoramento e/ou log que o ajudarão a encontrar a causa raiz da página na próxima vez que ela ocorrer. Se você não tiver informações suficientes para identificar o bug, sempre poderá fazer algo para ajudar a depurar a página da próxima vez.  Você raramente deve concluir que uma página é acionada por “causa desconhecida”.  Lembre-se de que, como engenheiro de plantão, você nunca está sozinho, então peça a um colega para revisar suas descobertas e ver se há alguma coisa que lhe tenha escapado. Normalmente, é mais fácil encontrar a causa raiz de um alerta logo após o alerta ser acionado e novas evidências estiverem disponíveis.

Explicar uma página como “transitória” ou não tomar nenhuma ação porque o sistema “se corrigiu” ou o bug inexplicavelmente “desapareceu”, convida o bug a acontecer novamente e causar outra página, o que causa problemas para o próximo engenheiro de plantão.

A simples correção imediata do bug (ou a correção de um “ponto”) perde uma oportunidade de ouro para evitar alertas semelhantes no futuro. Use o alerta de paginação como uma chance de trazer à tona o trabalho de engenharia que melhora o sistema e evita uma classe inteira de possíveis bugs futuros. Faça isso registrando um bug do projeto no componente de produção de sua equipe e defenda a priorização de sua implementação coletando dados sobre quantos bugs e páginas individuais esse projeto removeria. Se sua proposta levar 3 semanas úteis ou 120 horas úteis para ser implementada e uma página custa em média 4 horas úteis para ser tratada adequadamente, há um ponto de equilíbrio claro após 30 páginas.

Por exemplo, imagine uma situação em que há muitos servidores no mesmo domínio de falha, como um switch em um datacenter, causando várias falhas simultâneas regulares: 

Correção de pontos

Reequilibre a sua área de cobertura atual em mais domínios de falha e pare por aí.

Correção sistêmica

Use a automação para garantir que esse tipo de servidor e todos os outros servidores semelhantes estejam sempre espalhados por domínios de falha suficientes e que sejam reequilibrados automaticamente quando necessário.

Correção de monitoramento (ou prevenção)

Alerte preventivamente quando a diversidade do domínio de falha estiver abaixo do nível esperado, mas ainda não impactando o serviço.  Idealmente, o alerta seria um alerta de ticket, não uma página, pois não requer uma resposta imediata.  O sistema ainda está servindo com satisfação, embora em um nível mais baixo de redundância. 

Para ter a certeza de que o acompanhamento dos alertas de paginação é minucioso, considere as seguintes questões:

• Como posso evitar que esse bug específico aconteça novamente?
• Como posso evitar que bugs como este voltem a acontecer, tanto para este sistema como para outros sistemas pelos quais sou responsável?
• Quais testes poderiam ter impedido que esse bug fosse liberado para produção?
• Quais alertas de ticket poderiam ter acionado uma ação para evitar que o bug se tornasse crítico antes de ser paginado?
• Que alertas informativos poderiam ter surgido em um console antes de o bug se tornar crítico?
• Maximizei o impacto das correções que estou fazendo?

É claro que não basta que um engenheiro de plantão registre apenas bugs relacionados com as páginas que ocorrem no seu turno. É extremamente importante que os bugs identificados pela equipe SRE sejam tratados rapidamente, para reduzir a possibilidade de recorrência.  Certifique-se de que o planejamento de recursos para as equipes de SRE e desenvolvedor considere o esforço necessário para responder a bugs.

Recomendamos reservar uma fração do tempo do SRE e da equipe de desenvolvedores para responder aos bugs de produção à medida que eles surgem. Por exemplo, um plantonista do Google não trabalha normalmente em projetos durante o seu turno de plantão. Em vez disso, eles trabalham em bugs que melhoram a saúde do sistema. Certifique-se de que sua equipe priorize rotineiramente os bugs de produção acima de outros trabalhos do projeto.  Os gerentes de SRE e líderes de tecnologia devem certificar-se de que os bugs de produção sejam prontamente tratados e encaminhar para os tomadores de decisão da equipe de desenvolvedores quando necessário.

Quando um evento de página é suficientemente sério para justificar um post-mortem, é ainda mais importante seguir esta metodologia para catalogar e rastrear itens de ação de acompanhamento. (Ver Cultura post-mortem: Aprendendo com o fracasso para mais detalhes). 

Qualidade dos dados

Uma vez identificados os bugs no seu sistema que causaram páginas, surgem naturalmente uma série de questões:

• Como se sabe qual o bug a corrigir primeiro?
• Como é que sabe que componente do seu sistema causou a maioria das suas páginas?
• Como você determina qual ação manual e repetitiva os engenheiros de plantão estão realizando para resolver as páginas?
• Como você sabe quantos alertas com causas raiz não identificadas permanecem?
• Como você sabe quais bugs são realmente, não apenas anedoticamente, os piores?

A resposta é simples: colete dados!

Ao construir seus processos de coleta de dados, você pode rastrear e monitorar os padrões na carga de plantão, mas este esforço não se dimensiona. É muito mais sustentável registrar um bug de placeholder para cada alerta de paginação no seu sistema de rastreamento de bugs (por exemplo, Jira, IssueTracker), e para o engenheiro de plantão criar um link entre os alertas de paginação do seu sistema de monitoramento e o bug relevante, à medida que eles percebem que cada alerta é sintomático de um problema preexistente. Você terminará com uma lista de bugs ainda não compreendidos em uma coluna e uma lista de todas as páginas que acredita-se que cada bug tenha causado na próxima.

Uma vez estruturados os dados sobre as causas das páginas, é possível começar a analisar esses dados e produzir relatórios. Esses relatórios podem responder a perguntas como, por exemplo:

• Quais bugs causam mais páginas?  Idealmente, reverteríamos e corrigiríamos os erros imediatamente, mas às vezes, encontrar a causa raiz e implantar a correção leva muito tempo e, às vezes, silenciar os principais alertas não é uma opção razoável.  Por exemplo, a equipe SRE de conexão mencionada acima pode enfrentar um congestionamento de rede contínuo que não pode ser resolvido imediatamente, mas ainda precisa ser rastreado.  A coleta de dados sobre quais problemas de produção estão causando mais páginas e estresse para a equipe oferece suporte a conversas orientadas por dados sobre como priorizar seu esforço de engenharia sistematicamente.
• Que componente do sistema é a causa da maioria das páginas (gateway de pagamentos, microserviço de autenticação, etc.)?
• Quando correlacionados com seus outros dados de monitoramento, páginas específicas correspondem a outros sinais (picos na taxa de solicitação, número de sessões simultâneas de clientes, número de inscrições, número de retiradas, etc.)?

Vincular dados estruturados a bugs e as causas-raiz de suas páginas tem outros benefícios:

• Você pode preencher automaticamente uma lista de bugs existentes (ou seja, problemas conhecidos), o que pode ser útil para sua equipe de suporte.
• Você pode priorizar automaticamente a correção de bugs com base no número de páginas que cada bug causa.

A qualidade dos dados coletados determinará a qualidade das decisões que humanos ou autômatos podem tomar.  Para garantir dados de alta qualidade, considere as seguintes técnicas:

• Definir e documentar a política e as expectativas da sua equipe em matéria de coleta de dados para páginas.
• Configure alertas de não paginação do sistema de monitoramento para destacar onde as páginas não foram tratadas de acordo com essas expectativas.  Gerentes e líderes de tecnologia devem garantir que as expectativas sejam atendidas.
• Os colegas de equipe devem acompanhar uns aos outros quando as transferências não atendem às expectativas.  Comentários positivos como: “Talvez isso possa estar relacionado ao bug 123”, “Eu registrei um bug com suas descobertas para que possamos acompanhar com mais detalhes” ou “Isso se parece muito com o que aconteceu no meu turno na quarta-feira passada  : <link para a página, bug>” reforçam poderosamente os comportamentos esperados e garantem que você maximize as oportunidades de melhoria.  Ninguém quer ser paginado pelo mesmo problema que paginou seu colega de equipe no turno anterior. 

Vigilância

 Com demasiada frequência, as equipes caem em sobrecarga operacional por mil cortes. Para evitar ferver a rã, é importante prestar atenção à saúde dos engenheiros de plantão ao longo do tempo, e assegurar que a saúde da produção seja priorizada de forma consistente e contínua pelo SRE e pelas equipes de desenvolvedores.

 As técnicas a seguir podem ajudar uma equipe a ficar de olho no carregamento do pager:

• Nas reuniões de produção (consulte a seção “Comunicações: Reuniões de produção” em Engenharia de confiabilidade do site, Capítulo 31), converse regularmente sobre tendências no carregamento de pager com base nos dados estruturados coletados.  Descobrimos que uma média final de 21 dias é útil.
• Configure alertas de tickets, possivelmente direcionados a líderes ou gerentes de tecnologia, para quando a carga do pager ultrapassar um limite de “aviso” com o qual sua equipe concorda de antemão.
• Realize reuniões regulares entre a equipe do SRE e a equipe do desenvolvedor para discutir o estado atual da produção e os bugs de produção pendentes que estão paginando o SRE.

Flexibilidade de plantão

Duração do Turno

Uma rotação de plantão que tenha que lidar com uma ou mais páginas por dia deve ser estruturada de maneira sustentável: recomendamos limitar a duração dos turnos a 12 horas.  Turnos mais curtos são melhores para a saúde mental de seus engenheiros.  Os membros da equipe correm o risco de exaustão quando os turnos são longos e, quando as pessoas estão cansadas, cometem erros. A maioria dos humanos simplesmente não consegue produzir um trabalho de alta qualidade se estiver continuamente de plantão.  Muitos países têm leis sobre horas máximas de trabalho, pausas e condições de trabalho.

Embora a distribuição de turnos de plantão através das horas de dia de uma equipe seja ideal, um sistema de turnos de 12 horas não necessita de uma equipe  distribuída globalmente. É preferível estar de plantão durante a noite durante 12 horas do que estar de plantão durante 24 horas ou mais. É possível fazer turnos de 12 horas funcionar mesmo num único local. Por exemplo, em vez de pedir a um único engenheiro que esteja de plantão 24 horas por dia durante um turno de uma semana inteira, seria melhor que dois engenheiros dividissem uma semana de plantão, com uma pessoa de plantão durante o dia e uma de plantão durante a noite.

Em nossa experiência, 24 horas de plantão sem prorrogação não é uma configuração sustentável.  Embora não seja o ideal, turnos noturnos ocasionais de 12 horas pelo menos garantem pausas para seus engenheiros.  Outra opção é encurtar os turnos para durar menos de uma semana – algo como 3 dias, 4 dias de folga. 

Cenário: Uma mudança nas circunstâncias pessoais

Imagine que você é membro de uma equipe de plantão para um grande serviço que tem um modelo de follow-the-sun 24/7 dividido em dois locais. O arranjo funciona bem para você.  Embora você não esteja entusiasmado com a possibilidade de uma página às 6h, você está feliz com o trabalho que você e a equipe estão fazendo para manter a carga operacional gerenciável e melhorar a confiabilidade do serviço.

Tudo está bem… até que um dia você percebe que a agenda de plantão e as demandas de sua vida pessoal estão começando a entrar em conflito.  Existem muitas razões potenciais para isso – por exemplo, tornar-se pai, precisar viajar em cima da hora e tirar uma licença do trabalho ou doença.

Você precisa que seus deveres de plantão coexistam com sua nova agenda pessoal.

Muitas equipes e organizações enfrentam esse desafio à medida que amadurecem.  As necessidades das pessoas mudam ao longo do tempo e manter um equilíbrio saudável de diversas origens de colegas de equipe leva a uma rotação de plantão caracterizada por diversas necessidades.  A chave para manter um equilíbrio saudável, justo e equitativo entre trabalho de plantão e vida pessoal é a flexibilidade.

Há várias maneiras de aplicar flexibilidade às rotações de plantão para atender às necessidades dos membros da equipe e, ao mesmo tempo, garantir a cobertura de seus serviços ou produtos.  É impossível escrever um conjunto abrangente de diretrizes de tamanho único.  Incentivamos a adoção da flexibilidade como princípio, em vez de simplesmente adotar os exemplos listados aqui. 

Automatize a programação de plantão

À medida que as equipes crescem, a contabilização de restrições de programação – planos de férias, distribuição de dias úteis de plantão versus fins de semana, preferências individuais, requisitos religiosos e assim por diante – torna-se cada vez mais difícil.  Você não pode gerenciar esta tarefa manualmente;  é difícil encontrar qualquer solução, muito menos uma solução justa.

“Justiça” não significa uma distribuição completamente uniforme de cada tipo de turno entre os membros da equipe.  Pessoas diferentes têm necessidades e preferências diferentes.  Portanto, é importante que a equipe compartilhe essas preferências e tente atendê-las de forma inteligente.  A composição e as preferências da equipe determinam se sua equipe prefere uma distribuição uniforme ou uma maneira mais personalizada de atender às preferências de programação.

Usar uma ferramenta automatizada para agendar turnos de plantão torna essa tarefa muito mais fácil.  Esta ferramenta deve ter algumas características básicas: 

• Deve reorganizar os turnos de plantão para acomodar as necessidades de mudança dos membros da equipe.
• Deve reequilibrar automaticamente a carga de plantão em resposta a quaisquer alterações.
• Deveria fazer o seu melhor para garantir a imparcialidade, levando em consideração preferências pessoais, como “sem primárias durante os finais de semana em abril”, bem como informações históricas, como carga de plantão recente por engenheiro.
• Para que os engenheiros de plantão possam planejar seus turnos de plantão, isso nunca deve alterar uma programação já gerada.

A geração de programação pode ser totalmente automatizada ou agendada por um humano.  Da mesma forma, algumas equipes preferem que os membros assinem explicitamente o cronograma, enquanto outras se sentem confortáveis ​​com um processo totalmente automatizado.  Você pode optar por desenvolver sua própria ferramenta internamente se suas necessidades forem complexas, mas há vários pacotes de software comercial e de código aberto que podem ajudar a automatizar a programação de plantão.

Plano para swaps de curto prazo

Solicitações de mudanças de curto prazo na agenda de plantão acontecem com frequência.  Ninguém pode prometer na segunda-feira que não terá gripe na quinta-feira.  Ou você pode precisar executar uma tarefa urgente imprevista no meio de seu turno de plantão.

Você também pode facilitar as trocas de plantão por motivos não urgentes – por exemplo, para permitir que os plantonistas participem de sessões de treinamento esportivo.  Nessa situação, os membros da equipe podem trocar um subconjunto do dia de plantão (por exemplo, metade do domingo).  As trocas não urgentes geralmente são o melhor esforço.

Equipes com uma resposta estrita de pager SLO precisam levar em consideração a cobertura de deslocamento diário.  Se o SLO de resposta do seu pager for de 5 minutos e seu trajeto for de 30 minutos, você precisa garantir que outra pessoa possa responder a emergências enquanto você chega ao trabalho.

Para atingir esses objetivos com flexibilidade, recomendamos dar aos membros da equipe a capacidade de atualizar a rotação de plantão.  Além disso, tenha uma política documentada que descreva como as trocas devem funcionar.  As opções de descentralização variam de uma política totalmente centralizada, onde apenas o gerente pode alterar o cronograma, até uma totalmente descentralizada, onde qualquer membro da equipe pode alterar a política de forma independente.  Em nossa experiência, instituir a revisão por pares das mudanças oferece uma boa relação entre segurança e flexibilidade.

Planeje para pausas de longo prazo

Às vezes, os membros da equipe precisam parar de atender no revezamento de plantão devido a mudanças nas circunstâncias pessoais ou esgotamento.  É importante que as equipes sejam estruturadas para permitir que os plantonistas saiam temporariamente do revezamento.

Idealmente, o tamanho da equipe deve permitir uma redução (temporária) da equipe sem fazer com que o restante da equipe sofra muita carga operacional.  Em nossa experiência, você precisa de um mínimo de cinco pessoas por site para manter o plantão em uma configuração multisite, 24 horas por dia, 7 dias por semana, e oito pessoas em uma configuração de site único, 24 horas por dia, 7 dias por semana.  Portanto, é seguro assumir que cada local precisará de um engenheiro extra como proteção contra a redução de pessoal, elevando a equipe mínima para seis engenheiros por site (multisite) ou nove por site (site único). 

Planeje horários de trabalho de meio período

Estar de plantão com horários de trabalho de meio período pode parecer incompatível, mas descobrimos que acordos de plantão e de meio período são compatíveis se você tomar certas precauções.  A discussão a seguir pressupõe que, se um membro do seu revezamento de plantão trabalhar meio período, ele não estará disponível para turnos de plantão fora da semana de trabalho de meio período.

Existem dois modelos principais de trabalho de meio período: 

• Trabalhar uma quantidade reduzida de dias inteiros por semana – por exemplo, quatro dias de 8 horas por semana, em vez de cinco
• Trabalhar uma quantidade reduzida de tempo todos os dias – por exemplo, 6 horas por dia, em vez de 8 horas por dia

Ambos os modelos são compatíveis com o trabalho de plantão, mas exigem ajustes diferentes no cronograma de plantão.

O primeiro modelo coexiste facilmente com o trabalho de plantão, especialmente se o(s) dia(s) de folga são constantes ao longo do tempo.  Em resposta, você pode adotar uma duração de turno de plantão de menos de sete dias por semana (por exemplo, de segunda a quinta ou sexta a domingo) e configurar o agendador automatizado para não agendar o(s) engenheiro(s) de meio período para estarem de plantão nos dias em que não trabalham.

O segundo modelo é possível de duas maneiras: 

• Divida as horas de plantão com outro engenheiro, para que ninguém fique de plantão quando não deveria.  Por exemplo, se um engenheiro de plantão precisa trabalhar das 9h às 16h, você pode atribuir a primeira metade do turno (9h às 15h) para ele.  Alterne a segunda metade (das 15h às 21h) dentro da equipe da mesma forma que alterna outros turnos de plantão.
• O engenheiro de meio período pode trabalhar em horário integral em seus dias de plantão, o que pode ser viável se o turno de plantão não for muito frequente.

Conforme mencionado no Capítulo 11 da Engenharia de confiabilidade do site, o Google SRE compensa o suporte fora do horário normal com uma taxa horária reduzida de pagamento ou folga, de acordo com as leis e regulamentações trabalhistas locais.  Leve em consideração a agenda reduzida de um engenheiro de meio período ao determinar a compensação de plantão.

A fim de manter um equilíbrio adequado entre o tempo do projeto e o tempo de plantão, os engenheiros que trabalham em horário reduzido devem receber uma quantidade proporcionalmente menor de trabalho de plantão.  Equipes maiores absorvem essa carga adicional de plantão com mais facilidade do que equipes menores. 

Dinâmica de equipe de plantão

Nosso primeiro livro abordou como fatores de estresse, como alta carga de pager e pressão de tempo, podem forçar os engenheiros de plantão a adotar estratégias de decisão baseadas em intuição e heurística, em vez de razão e dados (consulte a seção “Sentindo-se seguro” no Capítulo 11 desse livro). Trabalhando a partir dessa discussão sobre psicologia de equipe, como você constrói uma equipe com dinâmicas positivas?  Considere uma equipe de plantão com o seguinte conjunto de problemas hipotéticos.

Cenário: Uma cultura de “sobreviver à semana”

Uma empresa começa com alguns fundadores e um punhado de funcionários, todos desenvolvedores de recursos.  Todo mundo conhece todo mundo, e todo mundo pega pagers.

A empresa cresce mais.  O plantão é limitado a um conjunto menor de desenvolvedores de recursos mais experientes que conhecem melhor o sistema.

A empresa cresce ainda mais.  Eles adicionam uma função de operações para lidar com a confiabilidade.  Essa equipe é responsável pela saúde da produção e a função do trabalho é focada nas operações, não na codificação.  O plantão se torna uma rotação conjunta entre desenvolvedores de recursos e operações.  Os desenvolvedores de recursos têm a palavra final na manutenção do serviço, e a entrada de operações é limitada a tarefas operacionais.  A essa altura, há 30 engenheiros na rotação de plantão: 25 desenvolvedores de recursos e 5 de operações, todos localizados no mesmo site. 

A equipe é atormentada pelo alto volume de pager.  Apesar de seguir as recomendações descritas anteriormente neste capítulo para minimizar a carga do pager, a equipe está com o moral baixo.  Como os desenvolvedores de recursos priorizam o desenvolvimento de novos recursos, o acompanhamento de plantão leva muito tempo para ser implementado.

Para piorar a situação, os desenvolvedores de recursos estão preocupados com a saúde de seu próprio subsistema.  Um desenvolvedor de recursos insiste em paginar por taxa de erro em vez de taxa de erro para seu módulo de missão crítica, apesar das reclamações de outros membros da equipe.  Esses alertas são barulhentos e retornam muitos falsos positivos ou páginas não acionáveis.

Outros membros da rotação de plantão não se incomodam especialmente com o alto volume de pagers.  Claro, há muitas páginas, mas a maioria delas não leva muito tempo para resolver.  Como diz um engenheiro de plantão: “Eu dou uma olhada rápida no assunto da página e sei que são duplicados.  Então eu simplesmente os ignoro.”

Soa familiar?

Algumas equipes do Google tiveram problemas semelhantes durante seus primeiros dias de maturidade.  Se não forem tratados com cuidado, esses problemas têm o potencial de separar o desenvolvedor de recursos e as equipes de operações e dificultar a operação de plantão.  Não há bala de prata para resolver esses problemas, mas encontramos algumas abordagens particularmente úteis.  Embora sua metodologia possa ser diferente, seu objetivo geral deve ser o mesmo: criar dinâmicas de equipe positivas e evitar cuidadosamente o colapso. 

Proposta um: capacite seus engenheiros de operações

Você pode remodelar a organização de operações de acordo com as diretrizes descritas neste livro e Engenharia de confiabilidade do site, talvez até incluindo uma mudança de nome (SRE ou similar) para indicar a mudança de função.  Simplesmente renomear sua organização de operações não é uma panacéia, mas pode ser útil para comunicar uma mudança real nas responsabilidades longe do antigo modelo centrado em operações.  Deixe claro para a equipe e toda a empresa que os SREs são os donos da operação do site.  Isso inclui definir um roteiro compartilhado para confiabilidade, conduzir a resolução completa de problemas, manter regras de monitoramento e assim por diante.  Os desenvolvedores de recursos são colaboradores necessários, mas não são proprietários desses empreendimentos.

 Para retornar à nossa equipe hipotética, este anúncio deu início às seguintes mudanças operacionais:

• Os itens de ação são atribuídos apenas aos cinco engenheiros de DevOps, que agora são SREs.  Os SREs trabalham com especialistas no assunto – muitos deles apresentam desenvolvedores – para realizar essas tarefas.  Os SREs assumem o debate “taxa de erro versus proporção de erro” mencionado anteriormente, negociando uma mudança no alerta com os desenvolvedores de recursos.
• Os SREs são incentivados a mergulhar no código para fazer as alterações por conta própria, se possível.  Eles enviam revisões de código para os especialistas no assunto.  Isso tem o benefício de construir um senso de propriedade entre os SREs, bem como atualizar suas habilidades e autoridade para ocasiões futuras.

Com esse arranjo, os desenvolvedores de recursos são colaboradores explícitos nos recursos de confiabilidade, e os SREs têm a responsabilidade de possuir e melhorar o site.

 Proposta dois: Melhorar as relações de equipe

 Outra solução possível é construir laços de equipe mais fortes entre os membros da equipe.  O Google designa um “orçamento divertido” especificamente para organizar atividades externas para fortalecer os laços da equipe.

 Descobrimos que relacionamentos de equipe mais robustos criam um espírito de maior compreensão e colaboração entre os colegas de equipe.  Como resultado, é mais provável que os engenheiros corrijam bugs, concluam itens de ação e ajudem seus colegas.  Por exemplo, digamos que você desativou um trabalho de pipeline noturno, mas esqueceu de desativar o monitoramento que verificava se o pipeline foi executado com êxito.  Como resultado, você acidentalmente chama um colega às 3 da manhã. Se você passou algum tempo com esse colega, você se sentiria muito pior com o que aconteceu e se esforçaria para ser atencioso sendo mais cuidadoso no futuro.  A mentalidade de “eu protejo meus colegas” se traduz em um ambiente de trabalho mais produtivo.

 Também descobrimos que fazer com que todos os membros da rotação de plantão se sentem juntos, independentemente do cargo e da área de função, ajuda a melhorar tremendamente as relações da equipe.  Incentive as equipes a almoçarem juntas.  Não subestime o poder de mudanças relativamente simples como essas.  Ele joga diretamente na dinâmica da equipe. 

Conclusão

O plantão SRE é diferente das funções de operações tradicionais.  Em vez de se concentrar apenas nas operações do dia-a-dia, o SRE possui total propriedade do ambiente de produção e busca melhorá-lo por meio da definição de limites de confiabilidade apropriados, desenvolvimento de automação e realização de projetos estratégicos de engenharia.  O plantão é fundamental para as operações do site, e tratá-lo corretamente é crucial para os resultados da empresa.

O plantão é uma fonte de muita tensão, tanto individual quanto coletivamente.  Mas se você olhou nos olhos do monstro por tempo suficiente, há sabedoria a ser encontrada.  Este capítulo ilustra algumas das lições sobre plantão que aprendemos da maneira mais difícil;  esperamos que nossa experiência possa ajudar outras pessoas a evitar ou resolver problemas semelhantes.

Se sua equipe de plantão está se afogando em alertas intermináveis, recomendamos dar um passo atrás para observar a situação de um nível superior.  Compare notas com outras equipes de SRE e parceiros.  Depois de reunir as informações necessárias, resolva os problemas de maneira sistemática.  A estruturação cuidadosa do plantão é um tempo bem gasto para engenheiros de plantão, equipes de plantão e toda a empresa. 

Fonte: Google SRE Work Book