SRE (Site Reliability Engineering) é uma abordagem para garantir a disponibilidade de projetos web. É considerado um framework para DevOps e fala sobre como obter sucesso na aplicação de práticas DevOps. Tradução neste artigo livros do Google. Eu mesmo preparei esta tradução e confiei na minha própria experiência na compreensão dos processos de monitoramento. No canal de telegrama и Também publiquei uma tradução do Capítulo 6 do mesmo livro sobre metas de nível de serviço.
Tradução por gato. Gostar de ler!
É impossível gerir um serviço se não houver compreensão de quais indicadores realmente importam e como medi-los e avaliá-los. Para tal, definimos e fornecemos um determinado nível de serviço aos nossos utilizadores, independentemente de utilizarem uma das nossas APIs internas ou um produto público.
Usamos nossa intuição, experiência e compreensão do desejo dos usuários para compreender os Indicadores de Nível de Serviço (SLIs), os Objetivos de Nível de Serviço (SLOs) e os Acordos de Nível de Serviço (SLAs). Estas dimensões descrevem as principais métricas que queremos monitorizar e às quais reagiremos caso não consigamos fornecer a qualidade de serviço esperada. Em última análise, escolher as métricas corretas ajuda a orientar as ações corretas caso algo dê errado e também dá à equipe de SRE confiança na integridade do serviço.
Este capítulo descreve a abordagem que usamos para combater os problemas de modelagem de métricas, seleção de métricas e análise de métricas. A maior parte da explicação será sem exemplos, por isso usaremos o serviço de Shakespeare descrito no seu exemplo de implementação (pesquisa pelas obras de Shakespeare) para ilustrar os pontos principais.
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 uma definição cuidadosa porque em geral o termo SLA é sobrecarregado e tem vários significados dependendo do contexto. Para maior clareza, queremos separar esses valores.
Indicadores.
O SLI é um indicador de nível de serviço – uma medida quantitativa cuidadosamente definida de um aspecto do nível de serviço prestado.
Para a maioria dos serviços, o SLI principal é considerado a latência da solicitação – quanto tempo leva para retornar uma resposta a uma solicitação. Outros SLIs comuns incluem a taxa de erros, 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 medições são frequentemente agregadas: os dados brutos são primeiro coletados e depois convertidos em uma taxa de mudança, média ou percentil.
Idealmente, o SLI mede diretamente o nível de serviço de interesse, mas às vezes apenas uma métrica relacionada está disponível para medição porque a original é difícil de obter ou interpretar. Por exemplo, a latência do lado do cliente costuma ser uma métrica mais apropriada, mas há momentos em que a latência só pode ser medida no servidor.
Outro tipo de SLI importante para SREs é a disponibilidade, ou a porção de tempo durante a qual um serviço pode ser usado. Frequentemente definida como a taxa de solicitações bem-sucedidas, às vezes chamada de rendimento. (O tempo de vida – a probabilidade de os dados serem retidos por um longo período de tempo – também é importante para sistemas de armazenamento de dados.) Embora 100% de disponibilidade não seja possível, uma disponibilidade próxima de 100% é frequentemente alcançável; os valores de disponibilidade são expressos como o número de “noves” » percentagem de disponibilidade. Por exemplo, a disponibilidade de 99% e 99,999% pode ser rotulada como “2 noves” e “5 noves”. A meta atual de disponibilidade declarada do Google Compute Engine é “três noves e meio” ou 99,95%.
Objetivos
Um SLO é um objetivo de nível de serviço: um valor alvo ou intervalo de valores para um nível de serviço medido pelo SLI. Um valor normal para SLO é “SLI ≤ Target” ou “Lower Limit ≤ SLI ≤ Upper Limit”. Por exemplo, podemos decidir que retornaremos resultados de pesquisa de Shakespeare “rápidos”, definindo o SLO para uma latência média de consulta de pesquisa inferior a 100 milissegundos.
Escolher o SLO certo é um processo complexo. Primeiro, nem sempre é possível escolher um valor específico. Para solicitações HTTP externas de entrada para seu serviço, a métrica Consulta por segundo (QPS) é determinada principalmente pelo desejo dos usuários de visitar seu serviço, e você não pode definir um SLO para isso.
Por outro lado, você pode dizer que deseja que a latência média de cada solicitação seja inferior a 100 milissegundos. Definir tal meta pode forçá-lo a escrever seu frontend com baixa latência ou comprar equipamento que forneça tal latência. (100 milissegundos é obviamente um número arbitrário, mas é melhor ter números de latência ainda mais baixos. Há evidências que sugerem que velocidades rápidas são melhores que velocidades lentas, e que a latência no processamento de solicitações de usuários acima de determinados valores na verdade força as pessoas a ficar longe do seu serviço.)
Novamente, isso é mais ambíguo do que pode parecer à primeira vista: você não deve excluir completamente o QPS do cálculo. O fato é que o QPS e a latência estão fortemente relacionados entre si: QPS mais altos geralmente levam a latências mais altas, e os serviços geralmente apresentam uma queda acentuada no desempenho quando atingem um determinado limite de carga.
A seleção e publicação de um SLO define as expectativas do usuário sobre como o serviço funcionará. Essa estratégia pode reduzir reclamações infundadas contra o proprietário do serviço, como lentidão no desempenho. Sem um SLO explícito, os usuários muitas vezes criam suas próprias expectativas sobre o desempenho desejado, o que pode não ter nada a ver com as opiniões das pessoas que projetam e gerenciam o serviço. Esta situação pode levar a expectativas inflacionadas do serviço, quando os usuários acreditam erroneamente que o serviço será mais acessível do que realmente é, e causar desconfiança quando os usuários acreditam que o sistema é menos confiável do que realmente é.
Acordo
Um acordo de nível de serviço é um contrato explícito ou implícito com seus usuários que inclui as consequências do cumprimento (ou não cumprimento) dos SLOs que eles contêm. As consequências são mais facilmente reconhecidas quando são financeiras – um desconto ou uma multa – 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 cumpridos?” Se não houver consequências claras, é quase certo que você esteja olhando para um SLO.
O SRE normalmente não está envolvido na criação de SLAs porque os SLAs estão intimamente ligados às decisões de negócios e produtos. O SRE, no entanto, está envolvido em ajudar a mitigar as consequências de OLAs falhados. Eles também podem ajudar a determinar o SLI: Obviamente, deve haver uma forma objetiva de medir o SLO no acordo ou haverá desacordo.
A Pesquisa Google é um exemplo de serviço importante que não possui um SLA público: queremos que todos usem a Pesquisa da maneira mais eficiente possível, mas ainda não assinamos um contrato com o mundo. No entanto, ainda existem consequências se a pesquisa não estiver disponível - a indisponibilidade resulta numa queda na nossa reputação, bem como na redução das receitas de publicidade. Muitos outros serviços do Google, como o Google for Work, têm acordos de nível de serviço explícitos com os usuários. Independentemente de um determinado serviço ter um SLA, é importante definir o SLI e o SLO e utilizá-los para gerenciar o serviço.
Tanta teoria - agora é experimentar.
Indicadores na prática
Dado que concluímos que é importante selecionar métricas apropriadas para medir o nível de serviço, como saber quais métricas são importantes para um serviço ou sistema?
Com o que você e seus usuários se preocupam?
Você não precisa usar todas as métricas como um SLI que pode acompanhar em um sistema de monitoramento; Entender o que os usuários desejam de um sistema ajudará você a selecionar diversas métricas. A escolha de muitos indicadores torna difícil focar em indicadores importantes, enquanto a escolha de um número pequeno pode deixar grandes partes do seu sistema sem supervisão. Normalmente usamos vários indicadores-chave para avaliar e compreender a integridade de um sistema.
Os serviços geralmente podem ser divididos em várias partes em termos de SLI que são relevantes para eles:
- Sistemas front-end personalizados, como as interfaces de pesquisa do serviço Shakespeare do nosso exemplo. Eles devem estar disponíveis, não apresentar atrasos e ter largura de banda suficiente. Nesse sentido, podem ser feitas perguntas: podemos responder à solicitação? Quanto tempo demorou para responder ao pedido? Quantas solicitações podem ser processadas?
- Sistemas de armazenamento. Eles valorizam baixa latência de resposta, disponibilidade e durabilidade. Perguntas relacionadas: Quanto tempo leva para ler ou gravar dados? Podemos acessar os dados mediante solicitação? Os dados estão disponíveis quando precisamos deles? Consulte o Capítulo 26 Integridade de dados: o que você lê é o que você escreve para uma discussão detalhada dessas questões.
- Os sistemas de big data, como pipelines de processamento de dados, dependem da taxa de transferência e da latência do processamento de consultas. Perguntas relacionadas: Quantos dados são processados? Quanto tempo leva para os dados viajarem desde o recebimento de uma solicitação até a emissão de uma resposta? (Algumas partes do sistema também podem apresentar atrasos em determinados estágios.)
Coleção de indicadores
Muitos indicadores de nível de serviço são coletados naturalmente no lado do servidor, usando um sistema de monitoramento como o Borgmon (veja abaixo). ) ou Prometheus, ou simplesmente analisar periodicamente os logs, identificando respostas HTTP com status 500. Porém, alguns sistemas devem ser equipados com coleta de métricas do lado do cliente, pois a falta de monitoramento do lado do cliente pode levar à falta de uma série de problemas que afetam usuários, mas não afetam as métricas do lado do servidor. Por exemplo, focar na latência de resposta de back-end de nosso aplicativo de teste de pesquisa Shakespeare pode resultar em latência do lado do usuário devido a problemas de JavaScript: nesse caso, medir quanto tempo leva para o navegador processar a página é uma métrica melhor.
Agregação
Para simplicidade e facilidade de uso, frequentemente agregamos medições brutas. Isto deve ser feito com cuidado.
Algumas métricas parecem simples, como solicitações por segundo, mas mesmo essa medição aparentemente simples agrega dados implicitamente ao longo do tempo. A medição é recebida especificamente uma vez por segundo ou a média da medição é calculada com base no número de solicitações por minuto? A última opção pode ocultar um número instantâneo muito maior de solicitações que duram apenas alguns segundos. Considere um sistema que atende 200 solicitações por segundo com números pares e 0 no restante do tempo. Uma constante na forma de um valor médio de 100 solicitações por segundo e o dobro da carga instantânea não são a mesma coisa. Da mesma forma, calcular a média das latências das consultas pode parecer atraente, mas esconde um detalhe importante: é possível que a maioria das consultas seja rápida, mas haverá muitas consultas lentas.
A maioria dos indicadores é melhor vista como distribuições do que como médias. Por exemplo, para latência SLI, algumas solicitações serão processadas rapidamente, enquanto outras sempre levarão mais tempo, às vezes muito mais. Uma média simples pode esconder estes longos atrasos. A figura mostra um exemplo: embora uma solicitação típica demore aproximadamente 50 ms para ser atendida, 5% das solicitações são 20 vezes mais lentas! O monitoramento e alerta baseado apenas na latência média não apresenta alterações de comportamento ao longo do dia, quando na verdade há alterações perceptíveis no tempo de processamento de algumas solicitações (linha superior).
Latência do sistema com percentis 50, 85, 95 e 99. O eixo Y está em formato logarítmico.
O uso de percentis para indicadores permite ver a forma da distribuição e suas características: um nível de percentil alto, como 99 ou 99,9, mostra o pior valor, enquanto o percentil 50 (também conhecido como mediana) mostra o estado mais frequente de a métrica. Quanto maior a dispersão do tempo de resposta, maior será o impacto das solicitações de longa duração na experiência do usuário. O efeito é potencializado sob alta carga e na presença de filas. A pesquisa de experiência do usuário mostrou que as pessoas geralmente preferem um sistema mais lento com alta variação no tempo de resposta, portanto, algumas equipes de SRE se concentram apenas em pontuações de percentil alto, com base no fato de que se o comportamento de uma métrica no percentil 99,9 for bom, a maioria dos usuários não terá problemas .
Nota sobre erros estatísticos
Geralmente preferimos trabalhar com percentis em vez da média (média aritmética) de um conjunto de valores. Isto permite-nos considerar valores mais dispersos, que muitas vezes apresentam características significativamente diferentes (e mais interessantes) da média. Devido à natureza artificial dos sistemas de computação, os valores das métricas são frequentemente 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 maiores. do que o tempo limite. Como resultado, não podemos aceitar que a média e a mediana possam ser iguais ou próximas uma da outra!
Sem testes prévios, e a menos que certas suposições e aproximações padrão sejam válidas, temos o cuidado de não concluir que os nossos dados são normalmente distribuídos. Se a distribuição não for conforme o esperado, o processo de automação que corrige o problema (por exemplo, quando vê valores discrepantes, ele reinicia o servidor com altas latências de processamento de solicitações) pode estar fazendo isso com muita frequência ou com pouca frequência (ambos os quais não são muito bom).
Padronizar indicadores
Recomendamos padronizar as características gerais do SLI para que você não precise especular sobre elas todas as vezes. Qualquer recurso que satisfaça os padrões padrão pode ser excluído 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 as medições são feitas: “A cada 10 segundos”
- Quais solicitações estão incluídas: "HTTP GET de trabalhos de monitoramento de caixa preta"
- Como os dados são obtidos: “Graças ao nosso monitoramento medido no servidor”
- Latência de acesso a dados: “Tempo até o último byte”
Para economizar esforço, crie um conjunto de modelos SLI reutilizáveis para cada métrica comum; eles também tornam mais fácil para todos entenderem o que significa um determinado SLI.
Metas na prática
Comece pensando (ou descobrindo!) o que interessa aos seus usuários, não o que você pode medir. Muitas vezes, o que interessa aos 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, acabará com SLOs menos úteis. Como resultado, descobrimos por vezes que identificar inicialmente os objectivos desejados e depois trabalhar com indicadores específicos funciona melhor do que escolher indicadores e depois atingir os objectivos.
Definir metas
Para maior clareza, deve ser definido como os ONS são medidos e as condições sob as quais são válidos. Por exemplo, poderíamos dizer o seguinte (a segunda linha é igual à primeira, mas usa os padrões SLI):
- 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 100 ms.
Se o formato das curvas de desempenho for importante, você poderá especificar vários SLOs:
- 90% das chamadas Get RPC são concluídas em menos de 1 ms.
- 99% das chamadas Get RPC são concluídas em menos de 10 ms.
- 99.9% das chamadas Get RPC são concluídas em menos de 100 ms.
Se seus usuários gerarem cargas de trabalho heterogêneas: processamento em massa (para o qual a taxa de transferência é importante) e processamento interativo (para o qual a latência é importante), pode valer a pena definir metas separadas para cada classe de carga:
- 95% das solicitações dos clientes exigem produtividade. Defina a contagem de chamadas RPC executadas <1 s.
- 99% dos clientes se preocupam com a latência. Defina a contagem de chamadas RPC com tráfego <1 KB e execução <10 ms.
É irrealista e indesejável insistir que os SLOs serão cumpridos 100% do tempo: isto pode reduzir o ritmo de introdução de novas funcionalidades e implementação e exigir soluções dispendiosas. Em vez disso, é melhor permitir um orçamento de erros – a porcentagem permitida de tempo de inatividade do sistema – e monitorar esse valor diariamente ou semanalmente. A alta administração pode querer avaliações mensais ou trimestrais. (O orçamento de erros é simplesmente um SLO para comparação com outro SLO.)
A porcentagem de violações do SLO pode ser comparada ao orçamento de erros (consulte o Capítulo 3 e a seção ), com o valor da diferença usado como entrada para o processo que decide quando implantar novas versões.
Selecionando valores alvo
A seleção de valores de planejamento (SLOs) não é uma atividade puramente técnica devido aos interesses do produto e do negócio que devem ser refletidos nos SLIs, SLOs (e possivelmente SLAs) selecionados. Da mesma forma, pode ser necessário trocar informações sobre questões relacionadas com pessoal, tempo de colocação no mercado, disponibilidade de equipamento e financiamento. A SRE deve fazer parte desta conversa e ajudar a compreender os riscos e a viabilidade das diferentes opções. Apresentamos algumas perguntas que podem ajudar a garantir 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 de um sistema, adaptar as métricas sem raciocínio pode impedir a manutenção do sistema: serão necessários esforços heróicos para atingir metas que não podem ser alcançadas sem uma reformulação significativa.
Mantenha simples
Cálculos complexos do SLI podem ocultar alterações no desempenho do sistema e dificultar a localização da causa do problema.
Evite absolutos
Embora seja tentador ter um sistema que possa lidar com uma carga crescente indefinidamente sem aumentar a latência, esse requisito não é realista. Um sistema que se aproxime de tais ideais provavelmente exigirá muito tempo para ser projetado e construído, será caro para operar e será bom demais para as expectativas dos usuários que aceitariam menos.
Use o mínimo de SLOs possível
Selecione um número suficiente de SLOs para garantir uma boa cobertura dos atributos do sistema. Proteja os SLOs que você escolher: se você nunca conseguir vencer uma discussão sobre prioridades especificando um SLO específico, provavelmente não valerá a pena considerar esse SLO. No entanto, nem todos os atributos do sistema são passíveis de SLOs: é difícil calcular o nível de satisfação do usuário usando SLOs.
Não persiga a perfeição
Você sempre pode refinar as definições e metas dos SLOs ao longo do tempo, à medida que aprende mais sobre o comportamento do sistema sob carga. É melhor começar com uma meta flutuante que você irá refinar com o tempo do que escolher uma meta excessivamente rígida que precisa ser relaxada quando você achar que é inatingível.
Os SLOs podem e devem ser um fator-chave na priorização do trabalho dos SREs e dos desenvolvedores de produtos, porque refletem uma preocupação para os usuários. Um bom SLO é uma ferramenta de aplicação útil para uma equipe de desenvolvimento. Mas um SLO mal projetado pode levar a um desperdício de trabalho se a equipe fizer esforços heróicos para alcançar um SLO excessivamente agressivo, ou a um produto ruim se o SLO for muito baixo. SLO é uma alavanca poderosa, use-a com sabedoria.
Controle suas medidas
SLI e SLO são elementos-chave usados para gerenciar sistemas:
- Monitore e meça sistemas SLI.
- Compare SLI com SLO e decida se é necessária alguma ação.
- Se for necessária ação, descubra o que precisa acontecer para atingir a meta.
- Conclua esta ação.
Por exemplo, se a etapa 2 mostrar que a solicitação está expirando e interromperá o SLO em algumas horas se nada for feito, a etapa 3 poderá envolver o teste da hipótese de que os servidores estão vinculados à CPU e a adição de mais servidores distribuirá a carga. Sem um SLO, você não saberia se (ou quando) agir.
Defina o SLO - então as expectativas do usuário serão definidas
A publicação de um SLO define as expectativas do usuário quanto ao comportamento do sistema. Os usuários (e usuários potenciais) geralmente desejam saber o que esperar de um serviço para saber se ele é adequado para uso. Por exemplo, as pessoas que desejam utilizar um site de compartilhamento de fotos podem querer evitar o uso de um serviço que promete longevidade e baixo custo em troca de uma disponibilidade um pouco menor, mesmo que o mesmo serviço possa ser ideal para um sistema de gerenciamento de registros de arquivo.
Para definir expectativas realistas para seus usuários, use uma ou ambas as seguintes táticas:
- Mantenha uma margem de segurança. Use um SLO interno mais rígido do que o anunciado aos usuários. Isto lhe dará a oportunidade de reagir aos problemas antes que eles se tornem visíveis externamente. O buffer SLO também permite que você tenha uma margem de segurança ao instalar versões que afetam o desempenho do sistema e garantem que o sistema seja fácil de manter sem frustrar os usuários com tempo de inatividade.
- Não exceda as expectativas do usuário. Os usuários se baseiam no que você oferece, não no que você diz. Se o desempenho real do seu serviço for muito melhor que o SLO declarado, os usuários confiarão no desempenho atual. Você pode evitar a dependência excessiva desligando intencionalmente o sistema ou limitando o desempenho sob cargas leves.
Compreender até que ponto um sistema satisfaz as expectativas ajuda a decidir se deve investir na aceleração do sistema e torná-lo mais acessível e resiliente. Alternativamente, se um serviço tiver um desempenho demasiado bom, algum tempo do pessoal deverá ser gasto noutras prioridades, como saldar dívidas técnicas, adicionar novas funcionalidades ou introduzir novos produtos.
Acordos na prática
A criação de um SLA exige que as equipes comerciais e jurídicas definam as consequências e penalidades pela violação dele. A função do SRE é ajudá-los a compreender os prováveis desafios no cumprimento dos SLOs contidos no SLA. A maioria das recomendações para a criação de SLOs também se aplica aos SLAs. É aconselhável ser conservador no que você promete aos usuários, porque quanto mais você tiver, mais difícil será alterar ou remover SLAs que pareçam irracionais ou difíceis de cumprir.
Obrigado por ler a tradução até o fim. Inscreva-se no meu canal de telegram sobre monitoramento и .
Fonte: habr.com