Como definir SLOs

Este documento é a primeira de duas partes que mostram como as equipes que operam serviços on-line podem começar a criar e adotar uma cultura de engenharia de confiabilidade do site (SRE) usando objetivos de nível de serviço (SLO). Um SLO é um nível pretendido de confiabilidade para um serviço.

No software como serviço (SaaS), existe uma tensão natural entre a velocidade do desenvolvimento do produto e a estabilidade operacional. Quanto mais você alterar seu sistema, maior será a probabilidade de ele falhar. Ferramentas de monitoramento e observabilidade podem ajudar a manter a confiança na estabilidade operacional, aumentando a velocidade de desenvolvimento. No entanto, embora essas ferramentas, também conhecidas como de gerenciamento de desempenho de aplicativos (APM), sejam importantes, uma das suas principais aplicações é configurar SLOs.

Se definido corretamente, um SLO pode ajudar as equipes a tomar decisões operacionais baseadas em dados que aumentam a velocidade de desenvolvimento sem prejudicar a estabilidade. O SLO também pode alinhar as equipes de desenvolvimento e operações em torno de um objetivo único acordado, o que pode aliviar a tensão natural que existe entre os objetivos: criar e iterar produtos (desenvolvimento) e manter integridade do sistema (operações).

Os SLOs são descritos em detalhes no Livro SRE e na Pasta de trabalho SRE, junto a outras práticas de SRE. Esta série tenta simplificar o processo de compreensão e desenvolvimento de SLOs para facilitar a adoção deles. Depois de ler e entender esses artigos, você pode encontrar mais nos livros.

O objetivo desta série é mostrar um caminho claro para a implementação de SLOs na sua organização:

  • Este documento analisa o que são SLOs e como defini-los para seus serviços.
  • A adoção de SLOs abrange diferentes tipos de SLOs baseados em modelos de carga de trabalho, como avaliar esses SLOs e como desenvolver alertas com base neles.

Esta série é destinada a SREs, equipes de operações, DevOps, administradores de sistemas e outros responsáveis pela estabilidade e confiabilidade de um serviço on-line. Ele pressupõe que você entende como os serviços de Internet se comunicam com navegadores da Web e dispositivos móveis e que tem um entendimento básico de como os serviços da Web são monitorados, implantados e solucionados.

Os relatórios State of DevOps identificaram recursos que impulsionam o desempenho da entrega de software. Esta série ajudará você com os seguintes recursos:

Terminologia

Os documentos desta série usam os seguintes termos e definições:

  • nível de serviço: uma medida do desempenho de um determinado serviço para o usuário. Você pode descrever essa medida em termos de satisfação do usuário e medi-la por vários métodos, dependendo do que o serviço faz e do que o usuário espera que ele faça ou o que foi dito que ele pode fazer.

    Exemplo: "Um usuário espera que nosso serviço esteja disponível e seja rápido."

  • jornada crítica do usuário (CUJ, na sigla em inglês): conjunto de interações que um usuário tem com um serviço para atingir uma única meta, por exemplo, um único clique ou um pipeline de várias etapas.

    Exemplo: "Um usuário clica no botão para finalizar a compra e aguarda a resposta de que o carrinho foi processado e um recibo enviado".

  • indicador de nível de serviço (SLI): um medidor de satisfação do usuário que pode ser medido de forma quantitativa para um nível de serviço. Em outras palavras, para medir um nível de serviço, você precisa medir um indicador que represente a satisfação do usuário com esse nível de serviço, por exemplo, a disponibilidade dele. Uma SLI pode ser considerada como uma linha em um gráfico que muda com o tempo, à medida que o serviço melhora ou piora.

    Exemplo: "Avalie o número de solicitações bem-sucedidas nos últimos 10 minutos dividido pelo número de todas as solicitações válidas nos últimos 10 minutos."

  • Objetivo de nível de serviço (SLO): o nível que você espera que um serviço alcance na maioria das vezes e em relação ao qual um SLI é medido.

    Exemplo: "As respostas de serviço precisam ser mais rápidas que 400 milissegundos (ms) para 95% de todas as solicitações válidas avaliadas ao longo de 14 dias."

    Gráfico que mostra a relação entre SLOs e SLIs.

  • contrato de nível de serviço (SLA): uma descrição do que precisa acontecer se um SLO não for alcançado. Geralmente, um SLA é um contrato legal entre provedores e clientes e pode até mesmo incluir termos de remuneração. Em discussões técnicas sobre SRE, esse termo geralmente é evitado.

    Exemplo: "Se o serviço não fornecer disponibilidade de 99,95% em um mês, o provedor de serviços compensará o cliente por cada minuto fora da conformidade."

  • orçamento do erro: quanto tempo ou quantos eventos negativos você pode tolerar antes de violar seu SLO. Essa medição informa quantos erros sua empresa pode esperar ou tolerar. O erro de orçamento é essencial na ajuda para tomar decisões potencialmente arriscadas.

    Exemplo: "Se nosso SLO estiver com 99,9% disponível, permitiremos que 0,1% das solicitações exibiam erros, sejam incidentes, acidentes ou experimentações".

Por que usar SLOs?

Ao criar uma cultura de SRE, por que começar com SLOs? Em resumo, se você não definir um nível de serviço, será difícil medir se os clientes estão satisfeitos com o serviço. Mesmo que você saiba que pode melhorar o serviço, a falta de um nível de serviço definido torna difícil determinar onde e quanto investir em melhorias.

Pode ser tentador desenvolver SLOs separados para cada serviço, se voltado para o usuário ou não. Por exemplo, um erro comum é medir dois ou mais serviços separadamente (por exemplo, um serviço de front-end e um armazenamento de dados de back-end), quando o usuário depende de ambos e não está ciente da distinção. Uma abordagem melhor é desenvolver SLOs baseados no produto (coleção de serviços) e se concentrar nas interações mais importantes que os usuários têm com ele.

Portanto, para desenvolver um SLO eficaz, o ideal é que você entenda as interações dos usuários com o serviço, conhecidas como jornadas críticas do usuário (CUJs, na sigla em inglês). Uma CUJ considera as metas dos usuários e como eles usam os serviços da sua empresa para atingir essas metas. O CUJ é definido a partir da perspectiva do cliente sem considerar os limites do serviço. Se a CUJ for atendida, o cliente estará satisfeito, e clientes satisfeitos são uma medida importante para o sucesso de um serviço.

Um dos principais aspectos da satisfação do cliente com um serviço é a confiabilidade dele. Não importa o que um serviço faz, se não é confiável. Assim, a confiabilidade é o recurso mais importante de qualquer serviço. Uma métrica comum de confiabilidade é o tempo de atividade, que, normalmente, significa a quantidade de tempo que um sistema ficou ativo. No entanto, preferimos uma métrica mais útil e precisa: disponibilidade. A disponibilidade ainda responde à pergunta se um sistema está ativo, mas de maneira mais precisa do que medindo o tempo desde que um sistema estava inativo. Nos sistemas distribuídos hoje, os serviços podem estar parcialmente fora do ar, um fator que o tempo de atividade não captura bem.

A disponibilidade costuma ser descrita em termos de noves, como 99,9% disponível (três noves) ou 99,99% disponíveis (quatro noves). Medir um SLO de disponibilidade é uma das melhores maneiras de avaliar a confiabilidade do sistema.

Além de ajudar a definir o sucesso operacional, um SLO pode ajudar você a escolher onde investir recursos. Os livros de SRE geralmente observam que cada nove que você cria pode resultar em um custo incremental com utilitário secundário. Sabe-se, por exemplo, que atingir o próximo nove em disponibilidade custa dez vezes mais do que o anterior.

Como escolher um SLI

Para determinar se um SLO é atendido (ou seja, bem-sucedido), você precisa de uma medida. Essa medida é chamada de indicador de nível de serviço (SLI). Um SLI mede o nível de um determinado serviço que você está entregando ao cliente. O ideal é que o SLI esteja vinculado a uma CUJ aceita.

Como selecionar as melhores métricas

A primeira etapa no desenvolvimento de um SLI é escolher uma métrica, como solicitações por segundo, erros por segundo, comprimento da fila, distribuição de códigos de resposta durante um determinado período ou o número de bytes transmitidos.

Essas métricas tendem a ser dos seguintes tipos:

  • Contador. Por exemplo, o número de erros que ocorreram até um determinado ponto de medição. Esse tipo de métrica pode aumentar, mas não diminuir.
  • Distribuição. Por exemplo, o número de eventos que preenchem um segmento de medição específico para um determinado período. Você pode medir quantas solicitações levam de 0 a 10 ms para serem concluídas, quantas demoram de 11 a 30 ms e quantas levam de 31 a 100 ms. O resultado é uma contagem para cada bucket, por exemplo, [0-10: 50], [11-30: 220], [31-100: 1.103].
  • Indicador. Por exemplo, o valor real de uma parte mensurável do sistema, como o comprimento da fila. Esse tipo de métrica pode aumentar ou diminuir.

Para mais informações sobre esses tipos, consulte a documentação do projeto Prometheus e os tipos de métricas do Cloud Monitoring ValueType e MetricKind.

Uma distinção importante sobre SLIs é que nem todas as métricas são SLIs. Na verdade, o SRE Workbook declara o seguinte (grifo adicionado):

"...geralmente, recomendamos tratar o SLI como a proporção de dois números: o número de bons eventos dividido pelo número total de eventos..."

"O SLI varia de 0% a 100%, em que 0% significa que nada funciona e 100% significa que nada está corrompido. Descobrimos essa escala intuitiva e esse estilo estão bem próximos do conceito de erro de orçamento."

Muitas empresas de software rastreiam centenas ou milhares de métricas. Apenas algumas são qualificadas como SLIs. Então, além de ser uma proporção de bons eventos em um total de eventos, o que qualifica uma métrica como um bom SLI? Uma boa métrica de SLI tem as seguintes características:

  • A métrica está diretamente relacionada à satisfação do usuário. Geralmente, os usuários ficam insatisfeitos se um serviço não se comportar como esperado, falhar ou ficar lento. Todos os SLOs baseados nessas métricas podem ser validados comparando seu SLI com outros sinais de satisfação do usuário (por exemplo, o número de tíquetes de reclamações de clientes, volume de chamadas de suporte, sentimento de mídia social ou encaminhamentos). Se sua métrica não corresponder a esses outros indícios de satisfação do usuário, talvez não seja uma boa métrica para ser usada como SLI.
  • A degradação da métrica está relacionada às interrupções. Uma métrica que apresenta bons resultados durante uma interrupção é a métrica errada para um SLI. Uma métrica que exibe maus resultados durante a operação normal também é errada para um SLI.
  • A métrica fornece uma boa proporção sinal/ruído. Qualquer métrica que resulta em um grande número de falsos negativos ou falsos positivos não é uma boa SLI.
  • A métrica é escalonada monotonicamente e, de maneira linear, com satisfação no cliente. À medida que a métrica melhora, a satisfação do cliente melhora.

Considere os gráficos no diagrama a seguir. Duas métricas que podem ser usadas como SLIs para um serviço são convertidas em gráficos ao longo do tempo. O período em que um serviço degrada é destacado em vermelho, e o período em que um serviço é bom é destacado em azul.

image

No caso do SLI inválido, a insatisfação do usuário não corresponde diretamente a um evento negativo (como degradação do serviço, lentidão ou interrupção). Além disso, o SLI flutua independentemente da satisfação do usuário. Com uma boa SLI, a SLI e a satisfação do usuário se correlacionam, os diferentes níveis de satisfação são claros e há muito menos flutuações irrelevantes.

Como selecionar o número certo de métricas

Normalmente, um único serviço tem vários SLIs, especialmente quando ele realiza diferentes tipos de trabalho ou atende a diferentes tipos de usuários. Por exemplo, separar as solicitações de leitura de solicitações de gravação é uma boa ideia, já que elas tendem a atuar de maneiras diferentes. Nesse caso, é melhor selecionar métricas apropriadas para cada serviço.

Por outro lado, muitos serviços executam tipos semelhantes de trabalho, o que pode ser diretamente comparável. Por exemplo, se você tiver um marketplace on-line, os usuários poderão visualizar uma página inicial, uma subcategoria ou uma lista de top-10, uma página de detalhes ou pesquisar itens. Em vez de desenvolver e medir uma SLI separada para cada uma dessas ações, combine-as em uma única categoria de SLI, por exemplo, procurar serviços.

Na realidade, as expectativas de um usuário não mudam muito entre as ações de uma categoria semelhante. A satisfação deles não depende da estrutura dos dados que eles buscam, se os dados são derivados de uma lista estática de itens promovidos ou se é o resultado gerado dinamicamente por uma pesquisa sustentada por machine learning em um grande conjunto de dados. Sua felicidade é quantificável por uma resposta a uma pergunta: "Eu vi uma página inteira de itens rapidamente?"

O ideal é usar o menor número possível de SLIs para representar com precisão as tolerâncias de um determinado serviço. Normalmente, um serviço precisa ter entre dois e seis SLIs. Se você tiver poucos SLIs, poderá perder indicadores valiosos. Se tiver muitos SLIs, sua equipe de plantão terá muito o que acompanhar e apenas um utilitário marginal adicionado. Lembre-se de que os SLIs devem simplificar sua compreensão da integridade da produção e fornecer uma sensação de abrangência.

Como escolher um SLO

Um SLO é composto pelos seguintes valores:

  • Um SLI. Por exemplo, a proporção de respostas com o código HTTP 200 para um número total de respostas.
  • Uma duração. O período em que uma métrica é medida. Esse período pode se basear no calendário (por exemplo, do primeiro dia de um mês até o primeiro dia do próximo) ou em uma janela contínua (por exemplo, os últimos 30 dias).
  • Um destino. Por exemplo, uma porcentagem desejada de bons eventos em um total de eventos (como 99,9%) que você espera atingir por um determinado período.

À medida que você desenvolve um SLO, definir a duração e a meta pode ser difícil. Uma maneira de iniciar o processo é identificar SLIs e formatá-los ao longo do tempo. Se você não conseguir decidir qual duração e meta usar, lembre-se de que seu SLO não precisa ser perfeito imediatamente. Provavelmente, você irá iterar no SLO para garantir que ele se alinhe à satisfação do cliente e atenda às necessidades da sua empresa. Tente começar com dois noves (99,0%) por um mês.

À medida que acompanha a conformidade com o SLO durante eventos como implantações, interrupções e padrões de tráfego diários, é possível conseguir insights sobre o destino bom, ruim ou até mesmo tolerante. Por exemplo, em um processo em segundo plano, você pode definir 75% de sucesso como adequado. Mas, nas solicitações essenciais para o usuário, é possível tentar algo mais agressivo, como 99,95%.

É claro que não existe um SLO único que pode ser aplicado a todos os casos de uso. Os SLOs dependem de vários fatores:

  • expectativas do cliente;
  • tipo de carga de trabalho;
  • infraestrutura para disponibilização, execução e monitoramento;
  • o domínio do problema.

A parte 2 desta série, Como adotar SLOs, se concentra em SLOs que não dependem de domínio. SLOs que independem de domínio (como disponibilidade de serviço) não substituem indicadores de nível alto (como widgets vendidos por minuto). No entanto, eles podem ajudar a avaliar se um serviço está funcionando, qualquer que seja o caso de uso comercial.

Os indicadores independentes de domínio geralmente podem ser reduzidos a uma pergunta. Por exemplo, "O serviço está disponível?" ou "O serviço é rápido o suficiente?" Geralmente, a resposta é encontrada em um SLO que considera dois fatores: disponibilidade e latência. Você pode descrever um SLO nos seguintes termos, sendo X = 99,9% e Y = 800 ms:

X% das solicitações válidas são bem-sucedidas e realizadas em menos de Y ms.

A seguir