Estar de Plantão

Escrito por Andrea Spadaccini
Editado por Kavita Guliani

Estar de plantão é uma tarefa crítica que muitas equipes de operações e engenharia devem assumir para manter seus serviços confiáveis e disponíveis. No entanto, existem várias armadilhas na organização de rotações e responsabilidades de plantão que podem levar a sérias consequências para os serviços e para as equipes se não forem evitadas. Este capítulo descreve os princípios básicos na abordagem do plantão que os engenheiros de confiabilidade do site no Google (SREs) desenvolveram ao longo dos anos e explica como essa abordagem levou a serviços confiáveis e carga de trabalho sustentável ao longo do tempo.

Introdução

Diversas profissões exigem que os funcionários realizem algum tipo de plantão, o que implica estar disponível para chamadas durante o horário laboral e não laboral. No contexto da TI, as atividades de plantão têm sido historicamente realizadas por equipes de operações dedicadas com a responsabilidade primária de manter o(s) serviço(s) pelos quais são responsáveis em bom estado de saúde.

Muitos serviços importantes do Google, por exemplo, Pesquisa, Anúncios e Gmail, têm equipes dedicadas de SREs responsáveis pelo desempenho e confiabilidade desses serviços. Assim, os SREs ficam de plantão para os serviços que apoiam. As equipes SRE são bastante diferentes das equipes puramente operacionais, pois colocam grande ênfase no uso da engenharia para abordar os problemas. Esses problemas, que normalmente caem no domínio operacional, existem em uma escala que seria intratável sem soluções de engenharia de software.

Para impor esse tipo de solução de problemas, o Google contrata pessoas com formação diversificada em sistemas e engenharia de software para as equipes de SRE. Limitamos a quantidade de tempo que os SREs gastam em trabalho puramente operacional em 50%; no mínimo, 50% do tempo de um SRE deve ser alocado para projetos de engenharia que dimensionem ainda mais o impacto da equipe por meio da automação, além de melhorar o serviço.

A vida de um Engenheiro de Plantão

Esta seção descreve as atividades típicas de um engenheiro de plantão e fornece algumas informações básicas para o restante do capítulo.

Como guardiões dos sistemas de produção, os engenheiros de plantão cuidam de suas operações atribuídas, gerenciando as interrupções que afetam a equipe e realizando e/ou examinando as alterações na produção.

Quando em plantão, um engenheiro está disponível para realizar operações nos sistemas de produção em minutos, de acordo com os tempos de resposta de paging acordados pela equipe e pelos proprietários do sistema de negócios. Os valores típicos são 5 minutos para serviços voltados para o usuário ou de outra forma altamente urgentes e 30 minutos para sistemas menos urgentes. A empresa fornece o dispositivo de recebimento de alertas, que normalmente é um telefone. O Google tem sistemas flexíveis de entrega de alertas que podem ser enviados por meio de vários mecanismos (e-mail, SMS, chamada de robô, aplicativo) em vários dispositivos.

Os tempos de resposta estão relacionados à disponibilidade de serviço desejada, conforme demonstrado pelo seguinte exemplo simplista: se um sistema voltado para o usuário deve obter 4 noves de disponibilidade em um determinado trimestre (99,99%), o tempo de inatividade trimestral permitido é de cerca de 13 minutos (ver Tabela de Disponibilidade). Esta restrição implica que o tempo de reação dos engenheiros de plantão deve ser da ordem de minutos (estritamente falando, 13 minutos). Para sistemas com SLOs mais relaxados, o tempo de reação pode ser da ordem de dezenas de minutos.

Assim que um alerta é recebida e reconhecida, o engenheiro de plantão deve fazer a triagem do problema e trabalhar para sua resolução, possivelmente envolvendo outros membros da equipe e escalando conforme necessário.

Eventos de produção não notificáveis, como alertas de prioridade mais baixa ou lançamentos de software, também podem ser controlados e/ou examinados pelo engenheiro de plantão durante o horário comercial. Essas atividades são menos urgentes do que os eventos de alerta, que têm prioridade sobre quase todas as outras tarefas, incluindo o trabalho do projeto. Para obter mais informações sobre interrupções e outros eventos de não paginação que contribuem para a carga operacional, leia o Capítulo 29.

Muitas equipes têm uma rotação de plantão primária e secundária. A distribuição de funções entre a primária e a secundária varia de equipe para equipe. Uma equipe pode empregar a secundária como um substituto para os alertas que o principal de plantão perde. Outra equipe pode especificar que o plantão primário trata apenas dos alertas, enquanto o secundário trata de todas as outras atividades de produção não urgentes.

Em equipes para as quais uma rotação secundária não é estritamente necessária para a distribuição de tarefas, é comum que duas equipes relacionadas sirvam como auxiliares de plantão uma para a outra, com tarefas de manuseio indireto. Essa configuração elimina a necessidade de uma rotação secundária exclusiva de plantão.

Existem muitas maneiras de organizar rotações de plantão; para uma análise detalhada, consulte o capítulo “Oncall” do livro The Practice of Cloud System Administration: DevOps and SRE Practices for Web Services, Volume 2.

Plantão equilibrado

As equipes de SRE têm restrições específicas quanto à quantidade e qualidade dos turnos de plantão. A quantidade de plantão pode ser calculada pela porcentagem de tempo gasto pelos engenheiros em tarefas de plantão. A qualidade do plantão pode ser calculada pelo número de incidentes que ocorrem durante um turno de plantão.

Os gerentes de SRE têm a responsabilidade de manter a carga de trabalho de plantão equilibrada e sustentável entre esses dois eixos.

Equilíbrio em quantidade

Acreditamos fortemente que o “E” em “SRE” é uma característica definidora de nossa organização, por isso nos esforçamos para investir pelo menos 50% do tempo de SRE em engenharia. Do restante, não mais do que 25% pode ser gasto em plantão, deixando até 25% do restante em outros tipos de trabalho operacional não relacionado a projetos.

Usando a regra de 25% de plantão, podemos derivar o número mínimo de SREs necessários para manter um rodízio de plantão 24 horas por dia, 7 dias por semana. Supondo que haja sempre duas pessoas de plantão (primária e secundária, com funções diferentes), o número mínimo de engenheiros necessários para plantão de uma equipe de local único é oito: assumindo turnos de uma semana, cada engenheiro está trabalhando de plantão (primário ou secundário) por uma semana a cada mês. Para equipes de dois locais, um tamanho mínimo razoável de cada equipe é seis, tanto para honrar a regra de 25% quanto para garantir uma massa significativa e crítica de engenheiros para a equipe.

Se um serviço envolve trabalho suficiente para justificar o crescimento de uma equipe de um único local, preferimos criar uma equipe de vários locais. Uma equipe com vários locais é vantajosa por dois motivos:

Os turnos noturnos têm efeitos prejudiciais à saúde das pessoas, e uma rotação “siga o sol” em vários locais permite que as equipes evitem turnos noturnos por completo.
Limitar o número de engenheiros na rotação do plantão garante que os engenheiros não percam o contato com os sistemas de produção (veja abaixo em: Um inimigo traiçoeiro: subcarga operacional).

No entanto, equipes com vários locais incorrem em sobrecarga de comunicação e coordenação. Portanto, a decisão de ir para vários locais ou para um único local deve ser baseada nas compensações que cada opção acarreta, na importância do sistema e na carga de trabalho que cada sistema gera.

Equilíbrio na qualidade

Para cada turno de plantão, um engenheiro deve ter tempo suficiente para lidar com quaisquer incidentes e atividades de acompanhamento, como escrever postmortems. Definimos um incidente como uma sequência de eventos e alertas que estão relacionados à mesma causa raiz e seriam discutidos como parte do mesmo postmortem. Descobrimos que, em média, lidar com as tarefas envolvidas em um incidente de plantão – análise de causa raiz, remediação e atividades de acompanhamento, como escrever um postmortem e corrigir bugs – leva 6 horas. Conclui-se que o número máximo de incidentes por dia é de 2 por turno de plantão de 12 horas. Para ficar dentro desse limite, a distribuição de eventos de paging deve ser muito plana ao longo do tempo, com um valor médio provável de 0: se um determinado componente ou problema causa alertas todos os dias (incidentes medianos/dia > 1), é provável que algo mais vá quebrar em algum ponto, causando mais incidentes do que deveria ser permitido.

Se este limite for excedido temporariamente, por exemplo, por um trimestre, medidas corretivas devem ser colocadas em prática para garantir que a carga operacional retorne a um estado sustentável (consulte Capítulo 30, Sobrecarga operacional e Incorporação de um SRE para recuperar da sobrecarga operacional).

Compensação

A compensação adequada deve ser considerada para suporte fora do expediente. Diferentes organizações lidam com a compensação por plantão de maneiras diferentes; o Google oferece compensação em dinheiro ou folga, limitada a alguma proporção do salário total. O teto de remuneração representa, na prática, o limite da quantidade de trabalho em regime de plantão que será assumido por qualquer pessoa. Essa estrutura de compensação garante o incentivo ao envolvimento em tarefas de plantão conforme exigido pela equipe, mas também promove uma distribuição equilibrada do trabalho de plantão e limita as desvantagens potenciais do trabalho de plantão excessivo, como esgotamento ou tempo inadequado para trabalhar no projeto.

Sentindo seguro

Conforme mencionado anteriormente, as equipes SRE oferecem suporte aos sistemas mais críticos do Google. Ser um SRE de plantão normalmente significa assumir a responsabilidade pelos sistemas voltados para o usuário e críticos para a receita ou pela infraestrutura necessária para manter esses sistemas em funcionamento. A metodologia SRE para pensar e enfrentar os problemas é vital para o funcionamento adequado dos serviços.

A pesquisa moderna identifica duas formas distintas de pensar que um indivíduo pode, consciente ou inconscientemente, escolher quando confrontado com desafios:

Ação intuitiva, automática e rápida
Funções cognitivas racionais, focadas e deliberadas

Quando se está lidando com interrupções relacionadas a sistemas complexos, a segunda dessas opções tem maior probabilidade de produzir melhores resultados e conduzir a um tratamento de incidentes bem planejado.

Para se certificar de que os engenheiros estão no estado de espírito adequado para aproveitar essa mentalidade, é importante reduzir o estresse relacionado a estar de plantão. A importância e o impacto dos serviços e as consequências de potenciais interrupções podem criar uma pressão significativa sobre os engenheiros de plantão, prejudicando o bem-estar de membros individuais da equipe e possivelmente levando os SREs a fazerem escolhas incorretas que podem colocar em risco a disponibilidade do serviço. Os hormônios do estresse, como o cortisol e o hormônio liberador de corticotropina (CRH), são conhecidos por causar consequências comportamentais – incluindo o medo – que podem prejudicar as funções cognitivas e causar tomadas de decisão subótimas.

Sob a influência desses hormônios do estresse, a abordagem cognitiva mais deliberada é tipicamente subsumida por ação irrefletida e não considerada (porém imediata), levando a um potencial abuso de heurísticas. As heurísticas são comportamentos muito tentadores quando se está de plantão. Por exemplo, quando as mesmas páginas de alerta pela quarta vez na semana e as três páginas anteriores foram iniciadas por um sistema de infraestrutura externa, é extremamente tentador exercer viés de confirmação associando automaticamente esta quarta ocorrência do problema à causa anterior.

Embora a intuição e as reações rápidas possam parecer características desejáveis no meio do gerenciamento de incidentes, elas têm suas desvantagens. A intuição pode estar errada e muitas vezes é menos suportável por dados óbvios. Assim, seguir a intuição pode levar um engenheiro a perder tempo perseguindo uma linha de raciocínio incorreta desde o início. As reações rápidas estão profundamente enraizadas no hábito e as respostas habituais não são consideradas, o que significa que podem ser desastrosas. A metodologia ideal no gerenciamento de incidentes atinge o equilíbrio perfeito entre a execução de etapas no ritmo desejado quando dados suficientes estão disponíveis para tomar uma decisão razoável e, ao mesmo tempo, examinar criticamente suas suposições.

É importante que os SREs de plantão entendam que podem contar com vários recursos que tornam a experiência menos assustadora do que possa parecer. Os recursos de plantão mais importantes são:

Caminhos de escalonamento claros
Procedimentos de gerenciamento de incidentes bem definidos
Uma cultura postmortem sem culpa

As equipes de desenvolvedores de sistemas com suporte SRE geralmente participam de um rodízio de plantão 24 horas por dia, 7 dias por semana, e sempre é possível escalar para essas equipes parceiras quando necessário. O escalonamento apropriado de interrupções é geralmente baseado em princípios de reagir a interrupções graves com dimensões desconhecidas significativas.

Quando se está lidando com incidentes, se o problema é complexo o suficiente para envolver várias equipes ou se, após alguma investigação, ainda não for possível estimar um limite superior para o período de tempo do incidente, pode ser útil adotar um protocolo formal de gerenciamento de incidentes. O Google SRE usa o protocolo descrito no Capítulo 14, Gerenciando Incidentes, que oferece um conjunto de etapas bem definido e fácil de seguir que ajuda um engenheiro de plantão a buscar racionalmente uma resolução de incidente satisfatória com toda a ajuda necessária.

Este protocolo é suportado internamente por uma ferramenta baseada na web que automatiza a maioria das ações de gerenciamento de incidentes, como transferência de funções e registro e comunicação de atualizações de status. Essa ferramenta permite que os gerentes de incidentes se concentrem em lidar com o incidente, em vez de gastar tempo e esforço cognitivo em ações mundanas, como formatar e-mails ou atualizar vários canais de comunicação de uma vez.

Por fim, quando ocorre um incidente, é importante avaliar o que deu errado, reconhecer o que deu certo e tomar medidas para evitar que os mesmos erros se repitam no futuro. As equipes SRE devem escrever postmortems após incidentes significativos e detalhar um cronograma completo dos eventos que ocorreram. Ao focar nos eventos e não nas pessoas, esses postmortems fornecem um valor significativo. Em vez de culpar os indivíduos, eles derivam valor da análise sistemática dos incidentes de produção. Erros acontecem, e o software deve garantir que cometamos o mínimo de erros possível. Reconhecer oportunidades de automação é uma das melhores maneiras de prevenir erros humanos.

Evitando carga operacional inapropriada

Conforme mencionado em “Plantão Equilibrado” (acima), os SREs gastam no máximo 50% de seu tempo em trabalho operacional. O que acontece se as atividades operacionais excederem esse limite?

Sobrecarga operacional

A equipe SRE e a liderança são responsáveis por incluir objetivos concretos no planejamento de trabalho trimestral, a fim de garantir que a carga de trabalho retorne a níveis sustentáveis. O empréstimo temporário de um SRE experiente para uma equipe sobrecarregada, que será discutido no Capítulo 30, pode fornecer um respiro para que a equipe possa avançar no tratamento dos problemas.

Idealmente, os sintomas de sobrecarga operacional devem ser mensuráveis, de modo que as metas possam ser quantificadas (por exemplo, número de tickets diários <5, e eventos de paging por turno <2).

O monitoramento mal configurado é uma causa comum de sobrecarga operacional. Os alertas de paging devem estar alinhados aos sintomas que ameaçam os SLOs. Todos os alertas de paging também devem ser acionáveis. Alertas de baixa prioridade que incomodam o engenheiro de plantão a cada hora (ou com mais frequência) interrompem a produtividade, e a fadiga que tais alertas induzem também pode fazer com que alertas sérios sejam tratados com menos atenção que o necessário. Consulte o Capítulo 29 para uma discussão mais detalhada.

Também é importante controlar o número de alertas que os engenheiros de plantão recebem para um único incidente. Às vezes, uma única condição anormal pode gerar vários alertas, por isso é importante regular o fan-out de alerta, garantindo que os alertas relacionados sejam agrupados pelo sistema de monitoramento ou alerta. Se, por qualquer motivo, alertas duplicados ou não informativos forem gerados durante um incidente, silenciar esses alertas pode fornecer o silêncio necessário para que o engenheiro de plantão se concentre no próprio incidente. Alertas ruidosos que geram sistematicamente mais de um alerta por incidente devem ser ajustados para se aproximarem de uma proporção de alerta/incidente de 1:1. Isso permite que o engenheiro de plantão se concentre no incidente em vez de fazer a triagem de alertas duplicados.

Às vezes, as mudanças que causam sobrecarga operacional não estão sob o controle das equipes de SRE. Por exemplo, os desenvolvedores de aplicativos podem introduzir alterações que tornam o sistema mais barulhento, menos confiável ou ambos. Nesse caso, é apropriado trabalhar em conjunto com os desenvolvedores de aplicativos para definir objetivos comuns para melhorar o sistema.

Em casos extremos, as equipes SRE podem ter a opção de “devolver o pager” – o SRE pode solicitar que a equipe de desenvolvimento fique de plantão exclusivamente para o sistema até que ele atenda aos padrões da equipe SRE em questão. A devolução do pager não acontece com muita frequência, porque quase sempre é possível trabalhar com a equipe de desenvolvedores para reduzir a carga operacional e tornar um determinado sistema mais confiável. Em alguns casos, porém, mudanças complexas ou arquitetônicas que abrangem vários trimestres podem ser necessárias para tornar um sistema sustentável do ponto de vista operacional. Nesses casos, a equipe SRE não deve estar sujeita a uma carga operacional excessiva. Em vez disso, é apropriado negociar a reorganização das responsabilidades de plantão com a equipe de desenvolvimento, possivelmente encaminhando alguns ou todos os alertas de paging para o desenvolvedor de plantão. Essa solução é normalmente uma medida temporária, durante a qual as equipes SRE e de desenvolvimento trabalham juntas para colocar o serviço em forma para ser integrado pela equipe de SRE novamente.

A possibilidade de renegociar responsabilidades de plantão entre SRE e equipes de desenvolvimento de produto atesta o equilíbrio de poderes entre as equipes. (Para obter mais discussões sobre a tensão natural entre SREs e as equipes de desenvolvimento de Produto, consulte o Capítulo 1). Essa relação de trabalho também exemplifica como a tensão saudável entre essas duas equipes e os valores que elas representam – confiabilidade versus velocidade de recurso – normalmente é resolvido pelo grande benefício do serviço e, por extensão, da empresa como um todo.

Um inimigo traiçoeiro: sobrecarga operacional

Estar de plantão para um sistema silencioso é uma felicidade, mas o que acontece se o sistema estiver muito silencioso ou quando os SREs não estiverem de plantão com a frequência necessária? Uma subcarga operacional é indesejável para uma equipe SRE. Ficar fora de contato com a produção por longos períodos de tempo pode levar a problemas de confiança, tanto em termos de excesso de confiança quanto de falta de confiança, enquanto lacunas de conhecimento são descobertas apenas quando ocorre um incidente.

Para neutralizar essa eventualidade, as equipes SRE devem ser dimensionadas para permitir que cada engenheiro esteja de plantão pelo menos uma ou duas vezes por trimestre, garantindo assim que cada membro da equipe esteja suficientemente exposto à produção. Os exercícios da “Roda do infortúnio” (discutidos no Capítulo 28, em Acelerando SREs para On-Call e além) também são atividades de equipe úteis que podem ajudar a afinar e aprimorar habilidades de resolução de problemas e conhecimento do serviço. O Google também tem um evento anual de recuperação de desastres para toda a empresa, denominado DiRT (Disaster Recovery Training), que combina exercícios teóricos e práticos para realizar testes de vários dias de sistemas de infraestrutura e serviços individuais; veja em Weathering the unexpected.

Conclusões

A abordagem aos plantões descrita neste capítulo serve como uma diretriz para todas as equipes SRE no Google e é a chave para promover um ambiente de trabalho sustentável e gerenciável. A abordagem do Google para o plantão nos permitiu usar o trabalho de engenharia como o meio principal para dimensionar as responsabilidades de produção e manter alta confiabilidade e disponibilidade, apesar da crescente complexidade e número de sistemas e serviços pelos quais os SREs são responsáveis.

Embora essa abordagem possa não ser imediatamente aplicável a todos os contextos em que os engenheiros precisam estar de plantão para serviços de TI, acreditamos que ela representa um modelo sólido que as organizações podem adotar em escala para atender a um volume crescente de trabalho de plantão.

Fonte: Google SRE Book