SRE (Site Reliability Engineering) - uma abordagem para garantir a disponibilidade de projetos da web. Ele é considerado uma estrutura para o DevOps e mostra como ter sucesso na aplicação de práticas do DevOps. Este artigo é uma tradução do Capítulo 4 dos Objetivos do nível de serviço da Engenharia de confiabilidade do site do Google. Eu mesmo preparei esta tradução e confiei em minha própria experiência na compreensão dos processos de monitoramento. No canal de telegrama monitorim_it e no último post sobre Habré , também publiquei uma tradução do capítulo 6 do mesmo livro sobre monitoramento de sistemas distribuídos.

Tradução por cat. Boa leitura!

É impossível gerenciar um serviço se não houver entendimento de quais indicadores realmente importam e como medi-los e avaliá-los. Para esse fim, definimos e fornecemos um certo nível de serviço aos nossos usuários, independentemente de eles usarem uma de nossas APIs internas ou um produto público.

Utilizamos nossa intuição, experiência e reconhecemos o desejo dos usuários de ter uma idéia de indicadores de nível de serviço (SLI), objetivos de nível de serviço (SLO) e contrato de nível de serviço (SLA). Essas medidas descrevem as principais métricas que queremos controlar e às quais responderemos se não pudermos fornecer a qualidade de serviço esperada. Por fim, a escolha dos indicadores certos ajuda a gerenciar as ações certas, se algo der errado, e também confere confiança à equipe do SRE na saúde do serviço.

Este capítulo descreve a abordagem que usamos para lidar com os problemas de modelagem, seleção e análise de métricas. A maioria das explicações será sem exemplos; portanto, usaremos o serviço de Shakespeare descrito no exemplo de sua implementação (procure as obras de Shakespeare) para ilustrar os principais pontos.

Terminologia de nível de serviço

Muitos leitores provavelmente estão familiarizados com o conceito de SLA, mas os termos SLI e SLO merecem definição cuidadosa, pois, em geral, o termo SLA está sobrecarregado e possui vários significados, dependendo do contexto. Para maior clareza, queremos separar esses valores.

Indicadores

O SLI é um indicador do nível de serviço - uma medida cuidadosamente quantificada de um aspecto do nível de serviço fornecido.

Para a maioria dos serviços, o atraso na solicitação é considerado como o SLI principal - quanto tempo é necessário para retornar uma resposta à solicitação. Outras SLIs comuns incluem a taxa de erro, geralmente expressa como uma fração de todas as solicitações recebidas, e a taxa de transferência do sistema, geralmente medida em solicitações por segundo. As medidas geralmente são agregadas: os dados brutos são coletados primeiro e depois convertidos em taxa de variação, média ou percentil.

Idealmente, o SLI mede diretamente o nível de serviço de interesse, mas às vezes apenas a métrica associada está disponível para medição, porque é difícil obter ou interpretar o original. Por exemplo, a latência do lado do cliente geralmente é uma métrica mais apropriada, mas acontece que medir a latência só é possível no servidor.

Outro tipo de SLI que é importante para o SRE é a disponibilidade ou parte do tempo durante o qual o serviço pode ser usado. É geralmente definido como a porcentagem de solicitações bem-sucedidas, às vezes chamadas de geração. (Expectativa de vida - a probabilidade de os dados serem armazenados por um longo período de tempo também é importante para os sistemas de armazenamento de dados.) Embora a acessibilidade seja 100% impossível, acessibilidade próxima a 100% geralmente é possível, valores de acessibilidade são expressos como o número “nove” »Porcentagem de disponibilidade. Por exemplo, a disponibilidade de 99% e 99,999% pode ser referida como "2 noves" e "5 noves". A atual meta declarada de acessibilidade para o Google Compute Engine é "três e meio e nove" ou 99,95%.

Objetivos

SLO é a meta de um nível de serviço: um valor-alvo ou intervalo de valores para o nível de serviço medido pelo SLI. O valor normal para SLO é "SLI ≤ valor alvo" ou "limite inferior ≤ SLI ≤ limite superior". Por exemplo, podemos decidir que retornaremos os resultados da pesquisa para as obras de Shakespeare "rapidamente", assumindo na forma de SLO o valor do atraso médio da consulta de pesquisa é inferior a 100 milissegundos.

Escolher o SLO certo é um processo complexo. Primeiro, você nem sempre pode selecionar um valor específico. Para solicitações HTTP de entrada externas ao seu serviço, a métrica do número de solicitações por segundo (QPS) é determinada principalmente pelo desejo dos usuários de visitar seu serviço e você não pode instalar o SLO para isso.

Por outro lado, você pode dizer que deseja que o atraso médio para cada solicitação seja inferior a 100 milissegundos. Definir essa meta pode fazer com que você escreva seu front-end com um atraso baixo ou compre equipamentos que ofereçam esse atraso. (100 milissegundos é obviamente um valor arbitrário, mas é melhor ter taxas de latência ainda mais baixas. Há razões para acreditar que alta velocidade é melhor que lenta e que atrasar o processamento de solicitações de usuários acima de certos valores realmente força as pessoas a ficarem longe do seu serviço.)

Novamente, isso é mais ambíguo do que parece à primeira vista: não vale a pena jogar o QPS fora do cálculo. O fato é que o pacote QPS e o atraso estão fortemente relacionados um ao outro: um QPS mais alto geralmente leva a atrasos mais longos e, geralmente, os serviços sofrem uma queda acentuada no desempenho quando um determinado limite de carga é atingido.

A escolha e publicação do SLO define as expectativas do usuário sobre como o serviço funcionará. Essa estratégia pode reduzir reclamações irracionais sobre o proprietário do serviço, por exemplo, sobre seu trabalho lento. Sem um SLO explícito, os usuários geralmente criam suas próprias expectativas sobre o desempenho desejado, o que pode não estar relacionado às opiniões das pessoas que projetam e gerenciam o serviço. Esse alinhamento pode levar a altas expectativas do serviço, quando os usuários acreditam erroneamente que o serviço será mais acessível do que realmente é e causam desconfiança quando os usuários consideram o sistema menos confiável do que realmente é.

Acordo

Um contrato de nível de serviço é um contrato explícito ou implícito com seus usuários que inclui as consequências do início (ou ausência) dos SLOs que eles contêm. As consequências são mais facilmente reconhecidas quando são financeiras - um desconto ou uma penalidade - mas podem assumir outras formas. Uma maneira fácil de falar sobre a diferença entre SLOs e SLAs é perguntar: "O que acontece se os SLOs não forem atendidos?" Se não houver conseqüências óbvias, você certamente verá o SLO.

Os SREs geralmente não estão envolvidos na criação de SLAs porque eles estão intimamente relacionados a soluções de negócios e produtos. A SRE, no entanto, está envolvida em ajudar a evitar as consequências de falhas nos SLOs. Eles também podem ajudar a determinar os SLIs: obviamente, deve haver uma maneira objetiva de medir os SLOs em um contrato ou haverá divergências.

A Pesquisa do Google é um exemplo de um serviço importante que não possui um SLA para o público: queremos que todos usem a Pesquisa com a maior eficiência possível, mas não assinamos um contrato com o mundo inteiro. No entanto, ainda existem consequências se a pesquisa não estiver disponível - a inacessibilidade leva a uma queda em nossa reputação, bem como a uma diminuição na receita de publicidade. Muitos outros serviços do Google, como o Google for Work, têm acordos explícitos de nível de serviço com os usuários. Independentemente de um serviço específico ter um SLA, é importante determinar o SLI e o SLO e usá-los para gerenciar o serviço.

Tanta teoria - agora para experimentar.

Indicadores na prática

Como concluímos que é importante selecionar os indicadores apropriados para medir o nível de serviço, como você sabe agora quais indicadores são relevantes para o serviço ou sistema?

O que você e seus usuários se preocupam

Você não precisa usar cada indicador como um SLI, que pode ser rastreado no sistema de monitoramento; Compreender o que os usuários desejam do sistema ajudará você a escolher algumas métricas. A escolha de muitos indicadores dificulta a atenção a indicadores importantes, enquanto a escolha de poucos pode deixar partes significativas do sistema sem supervisão. Normalmente, usamos vários indicadores-chave para avaliar e entender o estado do sistema.

Os serviços, em regra, podem ser divididos em várias partes em termos de SLI, que são relevantes para eles:

• Sistemas de front-end personalizados, como as interfaces de pesquisa de serviço de Shakespeare do nosso exemplo. Eles devem estar acessíveis, sem atrasos e ter largura de banda suficiente. Nesse sentido, você pode fazer perguntas: podemos responder à solicitação? Quanto tempo levou para responder à solicitação? Quantas solicitações podem ser processadas?
• Sistemas de armazenamento. Baixa latência, disponibilidade e durabilidade são importantes para eles. Perguntas relacionadas: Quanto tempo leva para ler ou gravar dados? Podemos acessar dados sob demanda? Os dados estão disponíveis quando precisamos? Veja o capítulo 26 Integridade de Dados: o que você lê é o que você anotou para uma discussão detalhada dessas questões.
• Os sistemas de big data, como os pipelines de processamento de dados, dependem da taxa de transferência e da latência do processamento de solicitações. Perguntas relevantes: quantos dados são processados? Quanto tempo leva para os dados passarem de receber uma solicitação para emitir uma resposta? (Algumas partes do sistema também podem ter atrasos em determinados estágios.)

Coleta de Indicadores

É mais natural coletar muitos indicadores de nível de serviço no lado do servidor usando um sistema de monitoramento como o Borgmon (consulte o Capítulo 10 - Práticas de alerta de séries temporais ) ou o Prometheus, ou simplesmente analisando periodicamente os logs para identificar respostas HTTP com um status de 500. No entanto, alguns sistemas devem estar equipados com uma coleção de métricas do lado do cliente, pois a falta de monitoramento no lado do cliente pode levar à falta de vários problemas que afetam os usuários, mas não afetam as métricas do lado do servidor. Por exemplo, focar na resposta atrasada do back-end de nosso aplicativo de teste, procurando as obras de Shakespeare, pode levar a um atraso no processamento de solicitações no lado do usuário devido a problemas de JavaScript: nesse caso, medir quanto tempo a página levará para processar no navegador é o melhor indicador.

Agregação

Para simplificar e facilitar o uso, geralmente agregamos dimensões brutas. Isso deve ser feito com cuidado.

Alguns indicadores parecem simples, por exemplo, o número de consultas por segundo, mas mesmo essa medição direta e óbvia agrega implicitamente dados ao longo do tempo. A medida é obtida especificamente uma vez por segundo ou a média é calculada sobre o número de consultas por minuto? A última opção pode ocultar um número instantâneo muito maior de solicitações armazenadas por apenas alguns segundos. Considere um sistema que atende 200 solicitações por segundo com números pares e 0 pelo resto do tempo. Uma constante na forma de um valor médio de 100 solicitações por segundo e duas vezes mais carga instantânea não é a mesma coisa. Da mesma forma, a média da latência de solicitações pode parecer atraente, mas oculta um detalhe importante: é possível que a maioria das solicitações seja rápida, mas haverá muitas solicitações que serão lentas.

A maioria dos indicadores é melhor visualizada como distribuições do que como médias. Por exemplo, para atrasos no SLI, algumas solicitações serão processadas rapidamente, enquanto outras sempre levarão mais, às vezes muito mais. Uma média simples pode ocultar esses longos atrasos. A figura mostra um exemplo: embora uma solicitação típica seja atendida por aproximadamente 50 ms, 5% das solicitações são 20 vezes mais lentas! O monitoramento e alertas baseados apenas na latência média não mostram mudanças no comportamento durante o dia, quando, de fato, há mudanças visíveis no tempo de processamento de algumas solicitações (a linha superior).


50, 85, 95 e 99 percentil de atraso do sistema. O eixo Y está no formato logarítmico.

O uso de percentis para indicadores permite ver a forma da distribuição e suas características: um alto nível de um percentil, como 99 ou 99,9, mostra o pior valor e, no percentil 50 (também conhecido como mediana), é possível ver o estado mais frequente da métrica. Quanto maior a variação no tempo de resposta, mais fortes as consultas de longo prazo afetam a experiência do usuário. O efeito é aprimorado com carga alta na presença de filas. Os estudos de experiência do usuário mostraram que as pessoas geralmente preferem um sistema mais lento com uma alta dispersão do tempo de resposta; portanto, alguns comandos do SRE se concentram apenas em valores percentuais altos, com base no pressuposto de que, se o comportamento da métrica no percentil 99,9 for bom, a maioria dos usuários não experimentará problemas

Nota sobre erros estatísticos

Geralmente, preferimos trabalhar com percentis do que com um conjunto de valores médio (média aritmética). Isso nos permite considerar valores mais dispersos, que geralmente têm características significativamente diferentes (e mais interessantes) do que a média. Devido à natureza artificial dos sistemas de computação, os valores das métricas geralmente são distorcidos, por exemplo, nenhuma solicitação pode receber uma resposta em menos de 0 ms e um tempo limite de 1000 ms significa que não pode haver respostas bem-sucedidas com valores que excedem o tempo limite. Como resultado, não podemos aceitar que a média e as medianas possam ser iguais ou próximas umas das outras!

Sem verificação preliminar, e se algumas suposições e aproximações padrão não forem cumpridas, tentamos não tirar conclusões de que nossos dados são normalmente distribuídos. Se a distribuição não for como o esperado, o processo de automação que corrige o problema (por exemplo, quando vê valores fora dos limites, reinicia o servidor com altas latências para processar a solicitação) pode fazer isso com muita frequência ou com pouca frequência (ambas as opções não são muito boas).

Padronizar indicadores

Recomendamos a padronização das características gerais das SLIs, para que você não precise falar sobre elas todas as vezes. Qualquer função que atenda aos modelos padrão pode ser excluída da especificação de um SLI individual, por exemplo:

• Intervalos de agregação: "média de 1 minuto"
• Áreas de agregação: “Todas as tarefas no cluster”
• Com que frequência são feitas as medições: "A cada 10 segundos"
• Quais pedidos estão incluídos: "HTTP GET de trabalhos de monitoramento de caixa preta"
• Como os dados foram recebidos: "Graças ao nosso monitoramento medido no servidor",
• Atraso no acesso a dados: "Tempo até o último byte"

Para economizar esforço, crie um conjunto de modelos de SLI reutilizáveis ​​para cada métrica comum; eles também facilitam a compreensão de todos sobre o que significa um SLI específico.

Objetivos da prática

Comece pensando (ou descubra!) Com o que seus usuários se preocupam, não com o que você pode medir. Freqüentemente, o que incomoda seus usuários é difícil ou impossível de medir, então você acaba se aproximando das necessidades deles. No entanto, se você começar com o que é fácil de medir, obterá SLOs menos úteis. Como resultado, às vezes descobrimos que a definição inicial das metas desejadas e o trabalho adicional com indicadores específicos funcionam melhor do que escolher indicadores e, em seguida, atingir metas.

Definir metas

Para maior clareza, deve-se determinar como os SLOs são medidos e as condições sob as quais eles são válidos. Por exemplo, podemos dizer o seguinte (a segunda linha é igual à primeira, mas usa valores SLI por padrão):

• 99% (média de 1 minuto) das chamadas Get RPC serão concluídas em menos de 100 ms (medido em todos os servidores back-end).
• 99% das chamadas Get RPC serão concluídas em menos de 100ms.

Se a forma das curvas de desempenho for importante, você poderá especificar vários objetivos de SLO:

• 90% das chamadas Get RPC concluídas em menos de 1 ms.
• 99% das chamadas Get RPC concluídas em menos de 10 ms.
• 99,9% das chamadas Get RPC concluídas em menos de 100 ms.

Se seus usuários gerarem cargas heterogêneas: processamento em massa (para o qual a largura de banda é importante) e processamento interativo (para o qual a quantidade de atraso é importante), pode ser aconselhável definir metas separadas para cada classe de carregamento:

• 95% das solicitações de clientes são largura de banda importante. Defina a contagem de chamadas RPC em andamento <1 s.
• 99% dos clientes valorizam a quantidade de atraso. Configure a contagem de chamadas RPC com tráfego <1 kB e em andamento <10 ms.

É irreal e indesejável insistir que os SLOs serão executados em 100% dos casos: isso pode diminuir o ritmo da introdução de novas funcionalidades e implantação e exigir soluções caras. Em vez disso, é melhor permitir um orçamento de erros - uma fração do tempo de inatividade do sistema e monitorar esse valor diariamente ou semanalmente.A alta gerência pode querer uma avaliação mensal ou trimestral. (O orçamento do erro é apenas um SLO para comparação com outro SLO).

A porcentagem de violação do SLO pode ser comparada com o orçamento de erro (consulte o Capítulo 3 e a seção “Motivação para orçamentos de erro” ), e o valor da diferença é usado como uma entrada para o processo que decide quando implantar novas versões.

Selecionar valores planejados

A seleção de valores planejados (SLO) não é uma atividade puramente técnica devido aos interesses do produto e do negócio, que devem refletir-se no SLI, SLO (e, possivelmente, SLA) selecionados. Da mesma forma, pode ser necessário trocar informações sobre questões relacionadas a pessoal, tempo de colocação no mercado, disponibilidade de equipamentos e financiamento. O SRE deve fazer parte dessa conversa e ajudar a lidar com os riscos e a viabilidade das várias opções. Descobrimos algumas perguntas que podem ajudar a fornecer uma discussão mais produtiva:

não escolha uma meta com base no desempenho atual.
Embora seja importante compreender os pontos fortes e os limites do sistema, a adaptação de indicadores sem raciocínio pode impedi-lo de dar suporte ao sistema: serão necessários esforços heróicos para alcançar metas que não podem ser alcançadas sem uma grande reorganização.

Mantenha-o simples
Os cálculos complexos de SLI podem ocultar alterações no desempenho do sistema e dificultar a localização da causa do problema.

Evite o absoluto
Embora seja tentador ter um sistema que possa suportar uma carga crescente ilimitada sem aumentar o valor do atraso, esse requisito não é realista. Um sistema que atenda a esses ideais provavelmente forçará muito tempo para projetar e construir, custará caro para operar será muito bom para as expectativas dos usuários que teriam menos.

Use o menor número possível de SLOs.
Escolha SLOs suficientes para fornecer uma boa cobertura dos atributos do sistema. Proteja os SLOs que você escolher: se você nunca conseguir vencer uma disputa sobre prioridades especificando um SLO específico, provavelmente não deve considerá-lo. No entanto, nem todos os atributos do sistema se prestam ao SLO: é difícil calcular o nível de entusiasmo do usuário com o SLO.

Não busque a perfeição
Você sempre pode esclarecer as definições e os objetivos do SLO ao longo do tempo, quando aprender mais sobre o comportamento do sistema sob carga. É melhor começar com uma meta flutuante, que você esclarecerá com o tempo, do que escolher uma meta muito estrita, que deve ser enfraquecida quando você achar que é inatingível.

Os SLOs podem e devem ser o principal fator na priorização do trabalho para SRE e desenvolvedores de produtos, pois refletem o atendimento ao usuário. Um bom SLO é uma ferramenta útil para convencer uma equipe de desenvolvimento. Mas um SLO mal projetado pode levar a um trabalho desnecessário se a equipe fizer esforços heróicos para obter um SLO excessivamente agressivo ou um produto ruim se o SLO for muito baixo. SLO é uma alavanca poderosa, use-a com sabedoria.

Medições de controle

SLI e SLO são os principais elementos usados ​​para gerenciar sistemas:

• Monitorar e medir sistemas SLI.
• Compare o SLI com o SLO e decida se são necessárias ações.
• Se uma ação for necessária, descubra o que precisa acontecer para atingir a meta.
• Execute esta ação.

Por exemplo, se a etapa 2 mostrar que o tempo limite da solicitação está aumentando e interromper o SLO após algumas horas, se nada for feito, a etapa 3 poderá incluir o teste da hipótese de que a carga do servidor está vinculada aos processadores e a adição de novos servidores distribuirá a carga . Sem o SLO, você não saberia se (ou quando) tomar uma ação.

Definir SLO - as expectativas do usuário são definidas
A publicação de um SLO define as expectativas do usuário em relação ao comportamento do sistema. Os usuários (e usuários em potencial) geralmente querem saber o que esperar de um serviço para ver se ele é adequado para uso. Por exemplo, as pessoas que desejam usar um site de compartilhamento de fotos podem querer evitar o uso de um serviço que promete durabilidade e baixo custo em troca de disponibilidade um pouco menor, embora o mesmo serviço possa ser ideal para um sistema de gerenciamento de gravação de arquivo.

Para definir expectativas realistas para seus usuários, use uma ou ambas das seguintes táticas:

• . SLO, . , . SLO , .
• . , , . , SLO, . , .

Compreender o quão bem o sistema atende às expectativas ajuda a decidir se o sistema deve ser acelerado e mais acessível e mais estável. Como alternativa, se o serviço funcionar muito bem, dedique algum tempo à equipe em outras prioridades, como pagar dívidas técnicas, adicionar novos recursos ou colocar novos produtos em operação.

Acordos de prática

A criação de um SLA exige que as equipes comerciais e jurídicas determinem as conseqüências e as penalidades por violá-lo. O papel do SRE é ajudá-los a entender as prováveis ​​dificuldades com a execução dos SLOs contidos nos SLAs. A maioria das diretrizes de SLO também é aplicável a SLAs. É aconselhável ser conservador quanto ao que você promete aos usuários, porque quanto mais eles são, mais difícil é alterar ou remover SLAs que parecem irracionais ou difíceis de implementar.

Obrigado por ler a tradução até o fim. Inscreva-se no meu canal de telegrama sobre o monitoramento monitorim_it e o blog no Medium .