Este documento do framework de arquitetura do Google Cloud se baseia nas discussões anteriores sobre objetivos de nível de serviço (SLOs) explorando o que e como medir em relação a cargas de trabalho de serviço comuns. Este documento se baseia nos conceitos definidos em Componentes de objetivos de nível de serviço.
Decida o que avaliar
Seja qual for o domínio, muitos serviços compartilham recursos comuns e podem usar SLOs genéricos. Nesta seção, discutimos SLOs genéricos para diferentes tipos de serviço e fornecemos explicações detalhadas dos SLIs que se aplicam a cada SLO.
Cada uma das subseções a seguir identifica um tipo de serviço específico e fornece uma breve descrição desse serviço. Em seguida, em cada tipo de serviço, estão listados possíveis SLIs, uma definição do indicador e outras informações relacionadas ao SLI.
Serviços orientados por solicitação
Esse tipo de serviço recebe uma solicitação de um cliente (um usuário ou outro serviço), executa alguns cálculos, possivelmente envia solicitações de rede para um back-end e retorna uma resposta ao cliente.
Disponibilidade como um SLI
Disponibilidade é a proporção de solicitações válidas que são veiculadas. A lista a seguir abrange informações a serem consideradas ao usar a disponibilidade como um SLI:
- Como proprietário do serviço, você decide o que é uma solicitação válida. As definições comuns incluem não tamanho zero ou adere a um protocolo cliente-servidor. Um método para avaliar a validade é analisar os códigos de resposta HTTP (ou RPC). Por exemplo, códigos HTTP 5xx são erros relacionados ao servidor que contam em um SLO, enquanto os códigos 4xx são erros de cliente que não contam.
- Cada código de resposta retornado pelo serviço precisa ser examinado para garantir que o aplicativo use esses códigos de maneira adequada e consistente. O código é um indicador preciso da experiência dos usuários com o serviço? Por exemplo, como um site de e-commerce responde quando um usuário tenta pedir um item esgotado? A solicitação falha e retorna uma mensagem de erro? O site sugere produtos semelhantes? Os códigos de erro precisam estar vinculados às expectativas do usuário.
- Os desenvolvedores podem usar erros de forma acidental. Usando o cenário esgotado do marcador anterior, um desenvolvedor pode retornar um erro por engano. No entanto, o sistema está funcionando corretamente e não retornando erro. O código precisa retornar um sucesso, mesmo que o usuário não tenha conseguido comprar o item. Embora os proprietários de serviços devam receber uma notificação sobre o baixo inventário, a incapacidade de fazer uma venda não é um erro do ponto de vista do cliente e não é contabilizado em um SLO.
- Um exemplo de serviço mais complexo é aquele que gerencia solicitações assíncronas ou fornece um processo de longa duração para os clientes. Embora seja possível expor a disponibilidade de outra maneira, recomendamos representar a disponibilidade como a proporção de solicitações válidas que são bem-sucedidas. A disponibilidade também pode ser definida como o número de minutos em que a carga de trabalho do cliente está em execução (às vezes chamada de abordagem de bons minutos).
- Considere um serviço que oferece máquinas virtuais (VMs). É possível medir a disponibilidade em termos do número de minutos após uma solicitação inicial de que a VM está disponível para o usuário.
Latência como um SLI
A latência (ou velocidade) é a proporção de solicitações válidas que são exibidas mais rápido que um limite. Assim, a latência indica a rapidez do serviço e pode ser medida pelo cálculo da diferença entre os horários de início e término de um determinado tipo de solicitação. Essa é a percepção de latência do usuário, e os proprietários de serviços geralmente medem esse valor com muita precisão. Na realidade, os usuários não conseguem distinguir entre uma atualização de 100 milissegundos (ms) e uma atualização de 300 ms e podem até aceitar respostas entre 300 ms e 1.000 ms como normal. Para mais informações, consulte o Modelo de cauda.
Desenvolva métricas centradas na atividade com foco no usuário. Veja a seguir alguns exemplos dessas métricas:
- Interativo: um usuário aguarda 1.000 ms por um resultado depois de clicar em um elemento.
- Gravação: uma alteração em um sistema distribuído subjacente leva 1.500 ms. Embora esse período seja considerado lento, os usuários tendem a aceitá-lo. Recomendamos que você diferencie explicitamente entre gravações e leituras em suas métricas.
- Segundo plano: ações que não são visíveis ao usuário, como uma atualização periódica de dados ou outras solicitações assíncronas, não levam mais de 5.000 ms para serem concluídas.
A latência é geralmente medida como uma distribuição e conforme mencionado em Escolha seus SLIs. Dada uma distribuição, é possível medir vários percentis. Por exemplo, é possível medir o número de solicitações que são mais lentas do que o 99º percentil histórico. Os eventos mais rápidos que esse limite são considerados bons; as solicitações mais lentas são consideradas não tão boas. Você define esse limite com base nos requisitos do produto. É possível definir vários SLOs de latência, por exemplo, latência típica versus latência de cauda.
Não use apenas a latência média (ou mediana) como SLI. Se a latência média for muito lenta, metade dos usuários já está insatisfeito. Além disso, o serviço pode passar por uma latência ruim por dias antes da descoberta do problema. Portanto, defina seu SLO de latência de cauda (95o percentil) e de latência mediana (50o percentil).
No artigo Métricas importantes da ACM, Benjamin Treynor Sloss escreve o seguinte:
- "Uma boa regra prática... é que a latência de 99º percentil não deve ser mais que três a cinco vezes a latência mediana."
- "Descobrimos que as medidas de latência de 50º, 95º e 99º percentis de um serviço são valiosas individualmente, e o ideal é definir os SLOs para cada uma delas."
Determine seus limites de latência com base em percentis históricos e meça quantas solicitações se enquadram em cada bucket. Essa abordagem é um bom modelo a seguir.
Qualidade como um SLI
Qualidade é a proporção de solicitações válidas que são veiculadas sem degradação do serviço. Por exemplo, qualidade é um SLI útil para serviços complexos projetados para falhar normalmente. Para ilustrar, considere uma página da Web que carrega o conteúdo principal de um repositório de dados e recursos opcionais de 100 outros serviços e repositórios de dados. Se um dos elementos opcionais estiver fora de serviço ou for muito lento, a página ainda será renderizada sem os elementos opcionais. Nesse cenário, é possível usar SLIs para as seguintes ações:
- Ao medir o número de solicitações que recebem uma resposta degradada (uma resposta sem resposta de pelo menos um serviço de back-end), é possível informar a proporção de solicitações inválidas.
- É possível acompanhar o número de respostas sem resposta de um único back-end ou de vários back-ends.
Serviços de processamento de dados
Esses serviços consomem dados de uma entrada, processam esses dados e geram uma saída. O desempenho do serviço em etapas intermediárias não é tão importante quanto o resultado final. Os SLIs mais fortes são atualização, cobertura, precisão e capacidade. A latência e a disponibilidade são menos úteis.
Atualização como um SLI
A atualização é a proporção de dados válidos atualizados mais recentemente do que um limite. A lista a seguir fornece alguns exemplos de como usar a atualização como um SLI:
- Em um sistema em lote, a atualização é medida como o tempo decorrido durante uma execução de processamento concluída para uma determinada saída.
- No processamento em tempo real ou em sistemas mais complexos, a atualização rastreia a idade do registro mais recente processado em um pipeline.
- Em um jogo on-line que gera blocos de mapa em tempo real, os usuários podem não perceber a rapidez com que os blocos são criados, mas podem perceber quando os dados do mapa estão ausentes ou não estão atualizados. Nesse caso, a atualização rastreia dados ausentes ou desatualizados.
- Em um serviço que lê registros em um sistema de rastreamento para gerar a mensagem "X itens em estoque" para um site de e-commerce, um SLI de atualização pode ser definido como a porcentagem de solicitações que estão usando informações de estoque atualizadas recentemente (dentro de última hora).
- É possível também usar uma métrica para exibir dados não atualizados para atualizar o SLI quanto à qualidade.
Cobertura como um SLI
Cobertura é a proporção de dados válidos processados.
Para definir a cobertura, siga estas etapas:
- Determine se uma entrada será aceita como válida ou ignore-a. Por exemplo, se um registro de entrada estiver corrompido ou tiver tamanho zero e não puder ser processado, considere o registro inválido como uma métrica.
- Conte o número de registros válidos. Essa contagem pode ser realizada com um
método
*count()*simples e representa a contagem total de registros. - Por fim, conte o número de registros que foram processados e compare esse número com a contagem total de registros válidos. Esse valor é o SLI para cobertura.
Correção como um SLI
A correção é a proporção de dados válidos que produziram a saída correta. Considere os seguintes pontos ao usar a correção como um SLI:
- Em alguns casos, os métodos para determinar a exatidão de uma saída são usados para validar o processamento da saída. Por exemplo, um sistema que gira ou colore uma imagem nunca deve produzir uma imagem de zero byte ou uma imagem com comprimento ou largura igual a zero. É importante separar essa lógica de validação da própria lógica de processamento.
- Um método para medir um SLI de correção é usar dados de entrada de teste comprovado que produzem uma saída correta conhecida. Lembre-se de que os dados de entrada precisam ser representativos dos dados do usuário.
- Em outros casos, é possível usar uma verificação matemática ou lógica na saída, como no exemplo anterior de rotação de uma imagem.
- Por fim, considere um sistema de faturamento que determina a validade da transação verificando a diferença entre o saldo antes e depois de uma transação. Se esse valor corresponder ao valor da transação, ela é válida.
Capacidade como um SLI
A capacidade de processamento é a proporção de tempo em que a taxa de processamento de dados foi mais rápida que o limite. Veja alguns pontos a serem considerados ao usar a capacidade como um SLI:
- A capacidade de processamento em um sistema de processamento de dados geralmente é mais representativa da satisfação do usuário do que uma única medida de latência para uma determinada operação. Se o tamanho de cada entrada variar drasticamente, pode não fazer sentido comparar o tempo que cada elemento leva para ser concluído (se todos os jobs progridem a uma taxa aceitável).
- Bytes por segundo é uma maneira comum de medir o volume de trabalho necessário para processar dados, seja qual for o tamanho do conjunto de dados. Mas qualquer métrica que faça o dimensionamento aproximado e linear em relação ao custo de processamento pode funcionar.
- Pode valer a pena particionar os sistemas de processamento de dados com base nas taxas de capacidade de processamento esperadas. Ou implemente um sistema de qualidade de serviço que garanta que as entradas de alta prioridade sejam processadas e que as de baixa prioridade sejam enfileiradas. De qualquer forma, medir a capacidade conforme definido nesta seção ajuda a determinar se seu sistema está funcionando como dentro do SLO.
Serviços de execução programada
Para serviços que precisam executar uma ação em um intervalo regular, como cron jobs do Kubernetes, é possível medir o desvio e a duração da execução. Veja a seguir um exemplo de cron job programado do Kubernetes:
apiVersion: batch/v1beta1 kind: CronJob metadata: name: hello spec:
schedule: "0 * * * *"
Desvio como um SLI
Desvio é a proporção de execuções iniciadas dentro de uma janela aceitável do horário de início esperado. Ao usar o desvio, considere o seguinte:
- O desvio mede a diferença de tempo entre o horário de início de um job e o horário de início real. Considere o exemplo anterior do cron job do Kubernetes. Se estiver definido para começar no minuto zero de cada hora, mas começar três minutos após a hora, o desvio será de três minutos. Quando um job é executado antecipadamente, você tem um desvio negativo.
- É possível medir o desvio como uma distribuição ao longo do tempo, com intervalos aceitáveis correspondentes que definem um bom desvio. Para determinar o SLI, compare o número de execuções que estavam dentro de um bom intervalo.
Duração da execução como um SLI
Duração da execução é a proporção de execuções que são concluídas dentro da janela de duração aceitável. A seguir, abordamos conceitos importantes relacionados ao uso da duração da execução:
- Duração da execução é o tempo que um job leva para ser concluído. Para uma determinada execução, um modo de falha comum é quando a duração real excede a duração programada.
- Um caso interessante é aplicar esse SLI a um job sem fim. Como esses jobs não são concluídos, registre o tempo gasto em um determinado job em vez de esperar que um job seja concluído. Essa abordagem fornece uma distribuição precisa de quanto tempo leva para ser concluído, mesmo nos piores cenários.
- Assim como acontece com o desvio, é possível acompanhar a duração da execução como uma distribuição e definir limites superiores e inferiores aceitáveis para bons eventos.
Métricas para outros tipos de sistema
Muitas outras cargas de trabalho têm as próprias métricas para gerar SLIs e SLOs. Confira estes exemplos:
- Sistemas de armazenamento: durabilidade, capacidade de processamento, tempo para o primeiro byte, disponibilidade de blob;
- Mídia/vídeo: continuidade de reprodução do cliente, tempo para iniciar a reprodução, transcodificação da totalidade de execução do gráfico;
- Jogos: tempo para combinar jogadores ativos, tempo para gerar um mapa.
Decida como medir
A seção anterior abordou o que você está medindo. Depois de determinar o que medir, você pode decidir como medir. É possível coletar métricas de SLI de várias maneiras. As seções abaixo identificam vários métodos de medição, fornecem uma breve descrição de cada um, listam as vantagens e desvantagens e identificam as ferramentas de implementação adequadas para cada método.
Geração de registros do lado do servidor
O método de geração de registros do lado do servidor envolve o processamento de registros de solicitações ou dados processados do lado do servidor.
| Geração de registros do lado do servidor | Detalhes |
|---|---|
| Vantagens |
|
| Desvantagens |
|
| Método e ferramentas de implementação |
Métricas do servidor de aplicativos
O método de métricas do servidor de aplicativos envolve a exportação de métricas de SLI do código que atende às solicitações do usuário ou processa os dados dele.
| Métricas do servidor de aplicativos | Detalhes |
|---|---|
| Vantagens |
|
| Desvantagens |
|
| Método e ferramentas de implementação |
|
Métricas de infraestrutura de front-end
O método de métricas da infraestrutura de front-end usa métricas da infraestrutura de balanceamento de carga (como um balanceador de carga global de camada 7 no Google Cloud).
| Métricas de infraestrutura de front-end | Detalhes |
|---|---|
| Vantagens |
|
| Desvantagens |
|
| Método e ferramentas de implementação |
|
Clientes ou dados sintéticos
O método de clientes ou dados sintéticos envolve o uso de clientes que enviam solicitações fabricadas em intervalos regulares e valida as respostas.
| Clientes ou dados sintéticos | Detalhes |
|---|---|
| Vantagens |
|
| Desvantagens |
|
| Método e ferramentas de implementação |
|
Instrumentação do cliente
O método de instrumentação de cliente envolve a adição de recursos de observabilidade ao cliente com que o usuário interage e o registro de eventos na infraestrutura de serviço que acompanha SLIs.
| Instrumentação do cliente | Detalhes |
|---|---|
| Vantagens |
|
| Desvantagens |
|
| Método e ferramentas de implementação |
|
Escolher um método de medição
Depois de decidir o que e como medir seu SLO, a próxima etapa é escolher um método que se alinhe melhor à experiência do cliente com o serviço e exige o mínimo de esforço da sua parte. Para atingir esse ideal, talvez seja necessário usar uma combinação dos métodos nas tabelas anteriores. Confira a seguir as abordagens sugeridas que podem ser implementadas ao longo do tempo, listadas em ordem crescente de esforço:
- Use exportações de servidores de aplicativos e métricas de infraestrutura. Em geral, é possível acessar essas métricas de imediato, e elas agregam valor rapidamente. Algumas ferramentas de APM incluem as ferramentas de SLO integradas.
- Use a instrumentação do cliente. Como os sistemas legados geralmente não têm instrumentação do cliente para usuário final integrada, a configuração da instrumentação pode exigir um investimento significativo. No entanto, se você usar um pacote de APM ou um framework de front-end que fornece instrumentação do cliente, poderá acessar rapidamente insights sobre a satisfação do cliente.
- Use o processamento de registros. Se não for possível implementar exportações de servidor ou instrumentação do cliente (marcadores anteriores), mas os registros existirem, o processamento de registros pode ser a melhor abordagem. Outro método é combinar exportações e processamento de registros. Use exportações como uma fonte imediata para alguns SLIs (como disponibilidade imediata) e processamento de registros para sinais de longo prazo (como alertas de gravação lenta discutidos no guia sobre SLOs e alertas).
- Implemente testes sintéticos. Depois de ter uma compreensão básica de como seus clientes usam seu serviço, você testa o nível do serviço. Por exemplo, alimente contas de teste com dados válidos conhecidos e consulte-os. Essa abordagem pode ajudar a destacar modos de falha que não são prontamente observados, como para serviços de baixo tráfego.
A seguir
- Leia SLOs e alertas.
- Leia A arte dos SLOs (em inglês), um workshop desenvolvido pela equipe de Engenharia de confiabilidade para o cliente do Google.
- Faça o curso on-line sobre como criar SLOs: Engenharia de confiabilidade do site: medição e gerenciamento de confiabilidade (em inglês).
- Leia Engenharia de confiabilidade do site: como implementar SLOs (em inglês).
- Leia Conceitos de monitoramento de serviço (em inglês).
- Leia Como implementar objetivos de nível de serviço, de Alex Hidalgo.
- Leia sobre o desenvolvimento de SLOs com o Cloud Monitoring (em inglês).
- Avalie o SLO Generator (em inglês) flexível da Professional Services Organization (PSO) do Google.
- Leia nossos recursos sobre DevOps.
Saiba mais sobre os recursos de DevOps relacionados a esta série:
Faça a verificação rápida de DevOps para entender sua posição em relação ao restante do setor.
Explore outras categorias no Framework da arquitetura.
Para mais arquiteturas de referência, diagramas e práticas recomendadas, confira a Central de arquitetura do Cloud.