Capítulo 6 - Monitorando Sistemas Distribuídos

Capítulo 6 – Monitorando Sistemas Distribuídos

Escrito por Rob Ewaschuk

Editado por Betsy Beyer

As equipes SRE do Google têm alguns princípios básicos e práticas recomendadas para criar sistemas de monitoramento e alerta bem-sucedidos. Este capítulo oferece diretrizes sobre quais problemas devem interromper uma pessoa, via alerta, e como lidar com problemas que não são sérios o suficiente para acionar um incidente.

Definições

Não há um vocabulário uniformemente compartilhado para discutir todos os tópicos relacionados ao monitoramento. Mesmo dentro do Google, o uso dos termos a seguir varia, mas as interpretações mais comuns estão listadas aqui.

Monitoramento

Coletar, processar, agregar e exibir dados quantitativos em tempo real sobre um sistema, como tipos e contagens de consultas, tipos e contagens de erros, tempos de processamento e tempos de vida do servidor.

Monitoramento de caixa branca

Monitoramento baseado em métricas expostas pelas partes internas do sistema, incluindo logs, interfaces como a Java Virtual Machine Profiling Interface ou um manipulador HTTP que emite estatísticas internas.

Monitoramento caixa preta

Testar comportamento visível externamente como um usuário o veria.

Dashboard

Um aplicativo (geralmente baseado na web) que fornece uma visão resumida das principais métricas de um serviço. Um dashboard pode ter filtros, seletores e assim por diante, mas é pré-construído para expor as métricas mais importantes para seus usuários. O dashboard também pode exibir informações da equipe, como tamanho da fila de tíquetes, uma lista de bugs de alta prioridade, o atual engenheiro de plantão para uma determinada área de responsabilidade ou pushes recentes.

Alerta

Uma notificação destinada a ser lida por uma pessoa e enviada a um sistema como um bug ou fila de tickets, um alias de e-mail ou um pager. Respectivamente, esses alertas são classificados como tickets, alertas de e-mail (por vezes conhecido como “alerta de spam”, porque raramente são lidos ou acionados) e pages.

Causa raiz

Um defeito em um software ou sistema humano que, se reparado, inspira confiança de que esse evento não acontecerá novamente da mesma forma. Um determinado incidente pode ter várias causas raiz, por exemplo: talvez tenha sido causado por uma combinação de automação de processo insuficiente, software que travou em uma entrada falsa e teste insuficiente do script usado para gerar a configuração. Cada um desses fatores pode ser a causa raiz única e, como tal, cada um deve ser reparado.

Nó e máquina

Usado de forma intercambiável para indicar uma única instância de um kernel em execução em um servidor físico, máquina virtual ou container. Pode haver vários serviços que valem a pena monitorar em uma única máquina. Os serviços podem ser:

Relacionados um ao outro: por exemplo, um servidor de cache e um servidor web
Serviços não relacionados compartilhando hardware: por exemplo, um repositório de código e uma master para um sistema de configuração como Puppet ou Chef

Push

Qualquer alteração no software em execução de um serviço ou em sua configuração.

Por que monitorar?

Existem muitos motivos para monitorar um sistema, incluindo:

Analisando tendências de longo prazo

Qual é o tamanho do meu banco de dados e com que velocidade ele está crescendo? Com que rapidez minha contagem de usuários ativos diários está crescendo?

Comparando ao longo do tempo ou grupos experimentais

As consultas são mais rápidas com Acme Bucket de 2.72 bytes em comparação com Ajax DB 3.14? Quão melhor é minha taxa de acertos do memcache com um nó extra? Meu site está mais lento do que na semana passada?

Alerta

Algo está quebrado e alguém precisa consertar agora! Ou algo pode quebrar em breve, então alguém deve verificar logo.

Criação de dashboard

Os dashboards devem responder a perguntas básicas sobre seu serviço e normalmente incluem alguma forma dos four golden signals (discutidos mais adiante nesse artigo, em “Os Four Golden Signals”).

Conduzindo uma análise retrospectiva ad hoc (ou seja, depuração)

Nossa latência disparou; o que mais aconteceu na mesma época?

O monitoramento do sistema também é útil para fornecer dados básicos para a análise de negócios e para facilitar a análise de violações de segurança. Como este livro se concentra nos domínios da engenharia nos quais o SRE tem especialização específica, não discutiremos essas aplicações de monitoramento aqui.

Monitorar e alertar permite que um sistema nos reporte quando está quebrado, ou talvez quando estiver prestes a quebrar. Quando o sistema não consegue se consertar automaticamente, queremos que um humano investigue o alerta, determine se há um problema real em mãos, mitigue o problema e determine a causa raiz do problema. A menos que você esteja realizando auditoria de segurança em componentes de um sistema com escopo muito restrito, você nunca deve acionar um alerta simplesmente porque “algo parece um pouco estranho”.

Acionar um humano é um uso bastante caro do tempo de um funcionário. Se um funcionário estiver trabalhando, uma chamada interrompe seu fluxo de trabalho. Se o funcionário está em casa, uma chamada interrompe uma rotina pessoal e talvez até mesmo seu sono. Quando as chamadas ocorrem com muita frequência, os funcionários duvidam, pulam ou até ignoram os alertas recebidos, às vezes até mesmo ignorando uma chamada “real” que está mascarada pelo ruído. As interrupções podem ser prolongadas porque outros ruídos interferem em um diagnóstico e correção rápidos. Os sistemas de alerta eficazes têm bom sinal e ruído muito baixo.

Definindo expectativas razoáveis para o monitoramento

O monitoramento de um aplicativo complexo é um esforço de engenharia significativo por si só. Mesmo com uma infraestrutura substancial para instrumentação, coleta, exibição e alerta, uma equipe SRE do Google de 10 a 12 membros normalmente tem um, ou às vezes dois membros, cuja principal atribuição é construir e manter sistemas de monitoramento para seus serviços. Esse número diminuiu ao longo do tempo à medida que generalizamos e centralizamos a infraestrutura de monitoramento comum, mas cada equipe SRE normalmente tem pelo menos uma “pessoa de monitoramento”. (Dito isso, embora possa ser divertido ter acesso a painéis de gráficos de tráfego e similares, as equipes SRE evitam cuidadosamente qualquer situação que exija que alguém tenha que “olhar para uma tela para observar os problemas”).

Em geral, o Google tem tendência para sistemas de monitoramento mais simples e rápidos, com melhores ferramentas para análise post hoc. Evitamos sistemas “mágicos” que tentam aprender limites ou detectam automaticamente a causalidade. As regras que detectam mudanças inesperadas nas taxas de solicitação do usuário final são um contraexemplo; embora essas regras sejam mantidas o mais simples possível, elas fornecem uma detecção muito rápida de uma anomalia muito simples, específica e grave. Outros usos de dados de monitoramento, como planejamento de capacidade e previsão de tráfego, podem tolerar mais fragilidade e, portanto, mais complexidade. Experimentos observacionais conduzidos ao longo de um horizonte de tempo muito longo (meses ou anos) com uma taxa de amostragem baixa (horas ou dias) também podem tolerar mais fragilidade porque amostras perdidas ocasionais não esconderão uma tendência de longa duração.

O Google SRE obteve sucesso apenas limitado com hierarquias de dependência complexas. Raramente usamos regras como: “Se eu sei que o banco de dados está lento, alerta para um banco de dados lento; do contrário, alerta para o site geralmente lento”. As regras de dependência geralmente pertencem a partes muito estáveis do nosso sistema, como nosso sistema para drenar o tráfego de usuário de um datacenter. Por exemplo, “se um datacenter estiver drenado, não me alerte sobre sua latência” é uma regra comum de alerta de datacenter. Poucas equipes no Google mantêm hierarquias de dependência complexas porque nossa infraestrutura tem uma taxa constante de refatoração contínua.

Algumas das ideias descritas neste capítulo ainda são aspiracionais: sempre há espaço para passar mais rapidamente do sintoma para a(s) causa(s) raiz(es), especialmente em sistemas em constante mudança. Portanto, embora este capítulo estabeleça alguns objetivos para sistemas de monitoramento e algumas maneiras de atingir esses objetivos, é importante que os sistemas de monitoramento – especialmente o caminho crítico desde o início de um problema de produção, passando por uma chamada até um humano, via triagem básica e profundidade de debug – sejam simples e compreensíveis para todos na equipe.

Da mesma forma, para manter o ruído baixo e o sinal alto, os elementos do seu sistema de monitoramento que direcionam para uma chamada precisam ser muito simples e robustos. As regras que geram alertas para humanos devem ser simples de entender e representar uma falha evidente.

Sintomas versus causas

Seu sistema de monitoramento deve abordar duas questões: o que está quebrado? e por quê?

O “o que está quebrado” indica o sintoma; o “porquê” indica uma causa (possivelmente intermediária). Alguns sintomas hipotéticos e as causas correspondentes são listados abaixo:

Sintoma: HTTP 500s ou 404s

Causa: Os servidores de banco de dados estão recusando conexões

Sintoma: Minhas respostas estão lentas

Causa: CPUs estão sobrecarregadas por um bogosort ou um cabo Ethernet está preso sob um rack, visível como perda parcial de pacotes

Sintoma: Usuários na Antártica não estão recebendo GIFs animados de gatos

Causa: Sua rede de distribuição de conteúdo (CDN) odeia cientistas e felinos e, portanto, colocou na lista negra alguns IPs de cliente

Sintoma: O conteúdo privado pode ser lido por todo mundo

Causa: Um novo push de software fez com que as ACLs fossem esquecidas e permitiu todas as solicitações

“O quê” versus “por quê” é uma das distinções mais importantes em um bom monitoramento, com sinal máximo e ruído mínimo.

Caixa-preta versus caixa-branca

Combinamos o uso intenso de monitoramento de caixa-branca com usos modestos, porém críticos, de monitoramento de caixa-preta. A maneira mais simples de pensar em monitoramento de caixa-preta versus monitoramento de caixa-branca é que o monitoramento de caixa-preta é orientado por sintomas e representa problemas ativos (não previstos). Por exemplo: “O sistema não está funcionando corretamente agora”. O monitoramento de caixa-branca depende da capacidade de inspecionar as entranhas do sistema, como logs ou endpoints HTTP, com instrumentação. Este tipo de monitoramento permite, portanto, a detecção de problemas iminentes, falhas mascaradas por novas tentativas e assim por diante.

Observe que, em um sistema de várias camadas, o sintoma de uma pessoa é a causa de outra. Por exemplo, suponha que o desempenho de um banco de dados esteja lento. As leituras lentas do banco de dados são um sintoma para o SRE do banco de dados que as detecta. No entanto, para o SRE de front-end que observa um site lento, as mesmas leituras lentas do banco de dados são uma causa. Portanto, monitoramento de caixa-branca às vezes é orientado por sintomas e às vezes por causa, a depender do quão informativo for sua caixa branca.

Ao coletar telemetria para debug, o monitoramento de caixa-branca é essencial. Se os servidores da web parecem lentos em solicitações pesadas de banco de dados, você precisa saber a velocidade com que o servidor da web percebe o banco de dados, e o quão rápido o banco de dados acredita ser. Caso contrário, você não pode distinguir um servidor de banco de dados realmente lento de um problema de rede entre seu servidor da web e seu banco de dados.

Para paging, o monitoramento de caixa-preta tem o principal benefício de forçar a disciplina para apenas incomodar um humano quando um problema já está em andamento e contribuindo para sintomas reais. Por outro lado, para problemas que ainda não ocorreram, mas são iminentes, o monitoramento de caixa-preta é inútil.

Os Four Golden Signals

Os four golden signals, também conhecidos por quatro sinais de ouro, do monitoramento são: latência, tráfego, falhas e saturação. Se você só pode medir quatro métricas de seu sistema, concentre-se nessas quatro.

Latência

O tempo que leva para atender a uma solicitação. É importante distinguir entre a latência de solicitações bem-sucedidas e a latência de solicitações com falhas. Por exemplo, um erro HTTP 500 disparado devido à perda de conexão com um banco de dados ou outro backend crítico pode ser atendido muito rapidamente; no entanto, como um erro HTTP 500 indica uma falha na solicitação, fatorar 500s em sua latência geral pode resultar em cálculos enganosos. Por outro lado, um erro lento é ainda pior do que um erro rápido! Portanto, é importante rastrear a latência do erro, em vez de apenas filtrar os erros.

Tráfego

Tráfego é a medida de quanta demanda está sendo colocada em seu sistema, a partir de uma métrica específica de alto nível do sistema. Para um serviço da web, essa medição geralmente é de solicitações HTTP por segundo, talvez divididas pela natureza das solicitações (por exemplo, conteúdo estático versus conteúdo dinâmico). Para um sistema de streaming de áudio, esta medição pode se concentrar na taxa de I/O da rede ou de sessões simultâneas. Para um sistema de armazenamento chave-valor, essa medida pode ser de transações e recuperações por segundo.

Falhas

A taxa de solicitações que falham, seja explicitamente (por exemplo, HTTP 500s), ou implicitamente (por exemplo, uma resposta de sucesso HTTP 200, mas associada ao conteúdo errado) ou ainda por política (por exemplo, “Se você se comprometeu com um segundo de tempo de resposta, qualquer solicitação acima de um segundo é um erro“). Quando os códigos de resposta do protocolo são insuficientes para expressar todas as condições de falha, protocolos secundários (internos) podem ser necessários para rastrear os modos de falha parcial. Monitorar esses casos pode ser drasticamente diferente: capturar o HTTP 500s no balanceador de carga pode fazer um bom trabalho na captura de todas as solicitações com falha completa, ao passo que apenas testes de sistema de ponta a ponta podem detectar que você está servindo o conteúdo errado.

Saturação

O quão “completo” o seu serviço é. Uma medida de sua fração de sistema, enfatizando os recursos que são mais restritos (por exemplo, em um sistema com restrição de memória, mostrar memória; em um sistema com restrição de I/O, mostrar I/O). Observe que muitos sistemas degradam o desempenho antes de atingirem 100% de utilização, portanto, ter uma meta de utilização é essencial.

Em sistemas complexos, a saturação pode ser complementada com medição de carga de nível mais alto: seu serviço pode lidar adequadamente com o dobro do tráfego, lidar com apenas 10% mais tráfego ou lidar com ainda menos tráfego do que recebe atualmente? Para serviços muito simples que não têm parâmetros que alteram a complexidade da solicitação (por exemplo, “Dê-me um nonce” ou “Eu preciso de um número inteiro monotônico global exclusivo“) que raramente mudam de configuração, um valor estático de um teste de carga pode ser adequado. Conforme discutido no parágrafo anterior, no entanto, a maioria dos serviços precisa usar sinais indiretos, como utilização da CPU ou largura de banda da rede, que têm um limite superior conhecido. Os aumentos de latência geralmente são um indicador importante de saturação. Medir o seu tempo de resposta do 99º percentil em uma pequena janela (por exemplo, um minuto) pode dar um sinal muito precoce de saturação.

Por fim, a saturação também se preocupa com as previsões de saturação iminente, como por exemplo: “Parece que seu banco de dados encherá o disco rígido em 4 horas“.

Se você medir todos os four golden signals e acionar um humano quando um sinal for problemático (ou, no caso de saturação, quase problemático), seu serviço será pelo menos decentemente coberto pelo monitoramento.

Preocupação com a cauda (ou, instrumentação e desempenho)

Ao construir um sistema de monitoramento do zero, é tentador projetá-lo com base na média de alguma quantidade: a latência média, o uso médio da CPU de seus nós ou a capacidade média dos bancos de dados. O perigo apresentado pelos dois últimos casos é óbvio: CPUs e bancos de dados podem ser facilmente utilizados de uma forma muito desequilibrada. O mesmo se aplica à latência. Se executarmos um serviço web com uma latência média de 100 ms a 1.000 solicitações por segundo, 1% das solicitações pode facilmente levar 5 segundos. (Se 1% das solicitações são 50x a média, significa que o restante das solicitações é cerca de 2x mais rápida que a média. Mas quando a distribuição não é medida, a ideia de que a maioria dos pedidos está perto da média é apenas um pensamento otimista). Se os usuários dependerem de vários serviços web para renderizar as páginas, o 99º percentil de um backend pode facilmente se tornar a resposta média de um frontend.

A maneira mais simples de diferenciar entre uma média lenta e uma “cauda” muito lenta de solicitações é coletar contagens de solicitações divididas por latências (adequadas para renderizar um histograma), em vez de latências reais: quantas solicitações atendi que levaram entre 0 ms e 10 ms, entre 10 ms e 30 ms, entre 30 ms e 100 ms, entre 100 ms e 300 ms, e assim por diante? Distribuir os limites do histograma de forma aproximadamente exponencial (neste caso, por fatores de aproximadamente 3), geralmente é uma maneira fácil de visualizar a distribuição de suas solicitações.

Escolha uma resolução apropriada para as medições

Diferentes aspectos de um sistema devem ser medidos sob diferentes níveis de granularidade. Por exemplo:

Observar a carga da CPU no intervalo de tempo de um minuto não revelará nem mesmo picos de longa duração que geram latências de cauda altas.
Por outro lado, para um serviço web que não requer mais do que 9 horas de downtime agregado por ano (99,9% de uptime anual), sondar o status 200 (sucesso) mais de uma ou duas vezes por minuto é provavelmente algo desnecessariamente frequente.
Da mesma forma, verificar se o disco rígido está cheio para um serviço que requer 99,9% de disponibilidade mais de uma vez a cada 1–2 minutos é provavelmente desnecessário.

Tome cuidado ao estruturar a granularidade de suas medições. Coletar medições por segundo da carga da CPU pode render dados interessantes, mas essas medições frequentes podem ser muito caras para coletar, armazenar e analisar. Se sua meta de monitoramento exige alta resolução, mas não exige latência extremamente baixa, você pode reduzir esses custos realizando amostragem interna no servidor e, em seguida, configurando um sistema externo para coletar e agregar essa distribuição ao longo do tempo ou entre servidores. Você pode:

1. Registrar a utilização atual da CPU a cada segundo.

Usar intervalos de granularidade de 5% e incrementar o intervalo de utilização de CPU apropriado a cada segundo.
Agregar esses valores a cada minuto.

Essa estratégia permite observar breves pontos de acesso da CPU sem incorrer em custos muito altos devido à coleta e retenção.

Tão simples quanto possível, não mais simples

Empilhar todos esses requisitos uns sobre os outros pode resultar em um sistema de monitoramento muito complexo – seu sistema pode acabar tendo os seguintes níveis de complexidade:

Alertas em diferentes limites de latência, em diferentes percentis, em todos os tipos de métricas diferentes
Código extra para detectar e expor as possíveis causas
Dashboards associados para cada uma dessas possíveis causas

As fontes de complexidade potencial são intermináveis. Como todos os sistemas de software, o monitoramento pode acabar tão complexo que se tornará frágil, complicado de mudar e de fazer uma manutenção.

Portanto, projete seu sistema de monitoramento tendo em vista a simplicidade. Ao escolher o que monitorar, tenha em mente as seguintes diretrizes:

As regras que detectam incidentes reais devem ser, na medida do possível, as mais simples, previsíveis e confiáveis.
A coleta de dados, agregação e configuração de alerta que raramente é exercida (por exemplo, menos de uma vez por trimestre para algumas equipes SRE) devem ser removidos.
Os sinais que são coletados, mas não são expostos em nenhum painel pré-elaborado nem usados por qualquer alerta, são igualmente candidatos à remoção.

Na experiência do Google, a coleta e agregação básica de métricas, combinadas com alertas e painéis, funcionou bem como um sistema relativamente autônomo. (Na verdade, o sistema de monitoramento do Google é dividido em vários binários, mas normalmente as pessoas aprendem sobre todos os aspectos desses binários). Pode ser tentador combinar o monitoramento com outros aspectos da inspeção de sistemas complexos, como o profiling detalhado de sistema, debug de processo único, rastreamento de detalhes sobre exceções ou travamentos, teste de carga, coleta e análise de log ou ainda inspeção de tráfego. Embora a maioria desses assuntos compartilhem semelhanças com o monitoramento básico, combinar muitos deles pode resultar em sistemas excessivamente complexos e frágeis. Como em muitos outros aspectos da engenharia de software, manter sistemas distintos com pontos de integração claros, simples e fracamente acoplados é uma estratégia melhor (por exemplo, usar APIs web para extrair dados em um formato que pode permanecer constante por um longo período de tempo).

Unindo os conceitos

Os princípios discutidos neste capítulo podem ser unidos em uma “filosofia” sobre monitoramento e alerta que é amplamente endossada e seguida pelas equipes SRE do Google. Embora essa filosofia de monitoramento seja um tanto aspiracional, é um bom ponto de partida escrever ou revisar um novo alerta e poder ajudar sua organização a fazer as perguntas certas, independentemente do tamanho da sua empresa ou da complexidade de seu serviço ou sistema.

Ao criar regras para monitoramento e alerta, fazer as seguintes perguntas pode ajudá-lo a evitar falsos positivos e esgotamento do plantão:

Esta regra detecta uma condição (de outra forma não detectável) que é urgente, acionável e ativa ou iminentemente visível para o usuário? (Situações de redundância zero (N + 0) contam como iminentes, assim como partes “quase completas” do seu serviço! Para obter mais detalhes sobre o conceito de redundância, acesse: N+1 Redundancy)
Serei capaz de ignorar esse alerta, sabendo que é benigno? Quando e por que poderei ignorar esse alerta e como posso evitar esse cenário?
Este alerta indica definitivamente que os usuários estão sendo afetados negativamente? Existem casos detectáveis em que os usuários não estão sendo afetados negativamente, como tráfego drenado ou deploys de teste, e que devem ser filtrados?
Posso agir em resposta a este alerta? Essa ação é urgente ou pode esperar até de manhã? A ação pode ser automatizada com segurança? Essa ação será uma solução de longo prazo ou apenas uma solução alternativa de curto prazo?
Outras pessoas estão sendo avisadas por este problema, tornando pelo menos uma das páginas desnecessária?

Essas perguntas refletem uma filosofia fundamental sobre plantões e alertas:

Cada vez que o pager tocar, devo ser capaz de reagir com um senso de urgência. Só consigo reagir com urgência algumas vezes por dia antes de ficar esgotado
Cada alerta deve ser acionável
Cada resposta de alerta deve exigir inteligência. Se um alerta merece apenas uma resposta robótica, então não deveria ser acionável
Os alertas devem ser sobre um problema novo ou um evento que não tenha sido visto antes

Essa perspectiva dissipa certas distinções: se um alerta satisfaz as quatro observações anteriores, é irrelevante se o pager é acionado por monitoramento de caixa branca ou caixa preta. Essa perspectiva também amplifica certas distinções: é melhor empregar mais esforço ao detectar os sintomas do que as causas; quando se tratar de causas, preocupe-se apenas com as que forem muito definidas e iminentes.

Monitoramento de longo prazo

Em sistemas de produção modernos, os sistemas de monitoramento rastreiam um sistema em constante evolução com alterações na arquitetura de software, características de carga e metas de desempenho. Um alerta, que é excepcionalmente raro atualmente e difícil de automatizar, pode se tornar frequente, talvez até merecendo um script hackeado para resolvê-lo. Neste ponto, alguém deve encontrar e eliminar as causas básicas do problema; se tal resolução não for possível, a resposta ao alerta merece ser totalmente automatizada.

É importante que as decisões sobre monitoramento sejam feitas com objetivos de longo prazo em mente. Cada alerta que aparece hoje distrai o ser humano de melhorar o sistema para amanhã, então muitas vezes é o caso de dar um golpe de curto prazo na disponibilidade ou no desempenho a fim de melhorar a perspectiva de longo prazo para o sistema. Vamos dar uma olhada em dois estudos de caso que ilustram essa compensação.

Bigtable SRE: um caso de alertas em excesso

A infraestrutura interna do Google é normalmente oferecida e medida em relação a um Objetivo de Nível de Serviço (consulte Capítulo 4 para informações detalhadas sobre SLO). Muitos anos atrás, o SLO do Bigtable era baseado no desempenho médio de um cliente sintético bem comportado. Por conta de problemas no Bigtable e nas camadas inferiores da pilha de armazenamento, o desempenho médio foi impulsionado por uma cauda “grande”: 5% das piores solicitações costumavam ser significativamente mais lentas do que o resto.

Alertas de e-mail eram acionados conforme o SLO se aproximava, e alertas de paging eram acionados quando o SLO era excedido. Ambos os tipos de alertas eram disparados de forma volumosa, consumindo uma quantidade inaceitável de tempo de engenharia: a equipe consumiu uma quantidade significativa de tempo fazendo a triagem dos alertas para encontrar os poucos que eram realmente acionáveis e muitas vezes perdendo os problemas que afetavam os usuários, porque poucos realmente afetaram. Muitas das páginas não eram urgentes, devido a problemas bem conhecidos na infraestrutura, e tiveram respostas automáticas ou mesmo não receberam resposta.

Para remediar a situação, a equipe usou uma abordagem em três frentes: ao fazer grandes esforços para melhorar o desempenho do Bigtable, também reduzimos temporariamente nossa meta de SLO, usando a latência de solicitação do 75º percentil. Também desabilitamos os alertas de e-mail, pois eram tantos que perder tempo diagnosticando-os era inviável.

Essa estratégia nos deu espaço para respirar e realmente corrigir os problemas de longo prazo no Bigtable e nas camadas inferiores da pilha de armazenamento, em vez de consertar constantemente os problemas táticos. Os engenheiros de plantão podiam realmente realizar o trabalho, uma que não eram acompanhados por ‘páginas’ o tempo todo. Por fim, o recuo temporário dos alertas nos permitiu progredir mais rapidamente em direção a um serviço melhor.

Gmail: respostas previsíveis e programáveis de humanos

Nos primeiros dias do Gmail, o serviço foi construído em um sistema de gerenciamento de processo distribuído adaptado chamado Workqueue, originalmente criado para processamento em lote de partes do índice de pesquisa. O Workqueue foi “adaptado” a processos de longa duração e posteriormente aplicado ao Gmail, mas alguns bugs na base de código relativamente opaca do agendador se mostraram difíceis de superar.

Naquela época, o monitoramento do Gmail era estruturado de forma que alertas fossem disparados quando tarefas individuais fossem “canceladas” pelo Workqueue. Essa configuração não era ideal porque, mesmo naquela época, o Gmail tinha muitos, muitos milhares de tarefas, cada tarefa representando uma fração de um por cento de nossos usuários. Nós nos preocupávamos profundamente em fornecer uma boa UX aos usuários do Gmail, mas essa configuração de alerta era impossível de manter.

Para resolver esse problema, o Gmail SRE construiu uma ferramenta que ajudou a “cutucar” o agendador da maneira certa para minimizar o impacto para os usuários. A equipe teve várias discussões sobre se deveria ou não simplesmente automatizar todo o loop, desde a detecção do problema até o ajuste do reescalonador, até que uma solução melhor de longo prazo fosse alcançada, mas alguns temiam que esse tipo de solução alternativa atrasaria uma correção real.

Esse tipo de tensão é comum dentro de uma equipe e muitas vezes reflete uma desconfiança subjacente quanto à autodisciplina de cada um: enquanto alguns membros da equipe querem implementar um “hack” para dar tempo para uma correção adequada, outros temem que um hack seja esquecido ou que a correção adequada será despriorizada indefinidamente. Essa preocupação é verossímil, pois é fácil construir camadas de dívidas técnicas insustentáveis corrigindo os problemas em vez de fazer correções reais. Os gerentes e líderes técnicos desempenham um papel fundamental na implementação de correções verdadeiras de longo prazo, apoiando e priorizando correções de longo prazo potencialmente demoradas, mesmo quando a “dor” inicial do paging diminui.

Alertas com respostas automáticas e algorítmicas devem funcionar como uma bandeira vermelha. A relutância por parte da equipe em automatizar essas páginas indica que ela não tem confiança de que pode limpar seu débito técnico. Este é um grande problema que vale a pena escalar.

A longa caminhada

Um tema comum conecta os exemplos anteriores sobre o Bigtable e o Gmail: a tensão entre a disponibilidade de curto e longo prazo. Frequentemente, a força total do esforço pode ajudar um sistema raquítico a atingir alta disponibilidade, mas esse caminho geralmente é de curta duração e repleto de esgotamento e dependência de um pequeno número de membros heroicos da equipe. Assumir uma redução controlada e de curto prazo na disponibilidade costuma ser uma troca dolorosa, mas estratégica para a estabilidade de longo prazo do sistema. É importante não pensar em cada alerta como um evento isolado, mas considerar se o nível geral de paginação leva a um sistema saudável e apropriadamente disponível com uma equipe saudável e viável e perspectiva de longo prazo. Revisamos as estatísticas sobre a frequência do acionamento (geralmente expressa como incidentes por turno, em que um incidente pode ser composto de alguns alertas relacionadas) em relatórios trimestrais com a gerência, garantindo que os tomadores de decisão sejam mantidos atualizados sobre o carregamento do pager e a integridade geral de suas equipes.

Conclusão

Um pipeline de monitoramento e alerta saudável é simples e fácil de pensar. Ele se concentra principalmente nos sintomas de plantão, reservando heurísticas orientadas à causa para servir como auxiliares na depuração de problemas. Monitorar os sintomas é tão mais fácil quanto mais “ups” houver na pilha que você monitora, embora o monitoramento da saturação e do desempenho de subsistemas, como bancos de dados, muitas vezes deva ser executado diretamente no próprio subsistema. Os alertas de email têm um valor muito limitado e tendem a ser facilmente sobrecarregados com ruído; em vez disso, você deve alimentar um painel que monitore todos os problemas subcríticos em andamento para o tipo de informação que normalmente termina em alertas de email. Um painel também pode ser emparelhado com um log, a fim de analisar correlações históricas.

A longo prazo, alcançar uma rotação de plantão e de produto bem-sucedida inclui a escolha de alertar sobre sintomas ou problemas reais iminentes, adaptando suas metas às metas que são realmente alcançáveis e certificando-se de que seu monitoramento oferece suporte a um diagnóstico rápido.

Fonte: Google SRE Book