Esta secção revê o conceito de indicadores do nível de serviço (INSs), define o que torna um INS bom ou útil e fornece exemplos de implementações de INSs para serviços selecionados. Esta página destina-se a pessoas que querem exemplos que implementem SLIs específicos do serviço.
Introdução aos INSs
A fiabilidade de um serviço é uma noção abstrata; o que a fiabilidade significa depende do serviço e das necessidades dos respetivos utilizadores. Um indicador ao nível do serviço (INS) é uma medida dessa fiabilidade a usar para comunicar acerca da fiabilidade do serviço e para gerir o serviço.
Os IESs são medidos ao longo de um período. Normalmente, o tamanho da janela depende da decisão que as informações estão a ser usadas para tomar. Por exemplo, pode medir um único SLI das seguintes formas:
- Na hora mais recente, para criar políticas de alerta.
- Ao longo de semanas, para tomar decisões táticas.
- Ao longo de meses, para tomar decisões estratégicas.
Recomendamos 28 dias como ponto de partida para medir o seu SLI. Este valor oferece um bom equilíbrio entre os exemplos de utilização estratégicos e táticos.
Para mais informações, consulte as seguintes secções do Site Reliability Engineering Workbook:
Propriedades de um bom INS
Consideramos que os SLIs "bons" são as medidas que cumprem os seguintes critérios:
Os SLIs são boas medidas de proxy para a satisfação dos utilizadores.
Um bom INS está fortemente correlacionado com a satisfação do utilizador. Usa o INS como base para um objetivo ao nível do serviço (SLO), um limite definido no INS. Define o SLO de modo que, quando o SLI estiver dentro de um intervalo definido, a maioria dos seus utilizadores fique satisfeita. Para que esta relação se mantenha, o SLI tem de ser uma boa medida proxy para a satisfação dos utilizadores.
Se o SLI for um bom indicador da satisfação do utilizador, quando existe um evento que afeta a satisfação do utilizador, o SLI muda numa determinada direção. Da mesma forma, quando não existem eventos que afetem a satisfação do utilizador, o SLI não se altera.
Os SLIs são dimensionados monotonicamente e linearmente com a satisfação do utilizador.
Um bom SLI é dimensionado monotonicamente e linearmente com a satisfação do utilizador. Se o SLI melhorar, a satisfação do utilizador também melhora. Da mesma forma, se o INS diminuir, a satisfação do utilizador diminui. A quantidade de melhoria no valor de um bom INS corresponde à quantidade de melhoria na satisfação dos utilizadores.
Os INSs produzem medições que variam entre 0% e 100%.
Um bom INS produz uma medição do desempenho que varia entre 0% e 100%: este intervalo é intuitivo e fácil de usar. Por exemplo, um desempenho do SLI de 100% significa que tudo está a funcionar e um desempenho do SLI de 0% significa que nada está a funcionar.
Ter um SLI que varia entre 0% e 100% torna a definição de um SLO no SLI fácil e clara: atribua uma percentagem alvo, como 99,9%, e o desempenho do SLI tem de ser igual ou superior a esse alvo para que o serviço cumpra o respetivo SLO.
Promessas
Uma forma de implementar um INS que tenha estas propriedades é pensar no INS em termos de promessas feitas aos seus utilizadores. Ao contabilizar as promessas que fez e cumpriu durante um período, pode obter um número que varia entre 0% e 100%. Estes INSs também se traduzem bem em margens de erro: para um determinado SLO, a sua margem de erro é o número de promessas que pode não cumprir durante um período enquanto continua a cumprir o SLO.
Alguns exemplos de promessas:
- Para devolver uma resposta com um código de estado HTTP
200ao pedido de um cliente. - Para responder a um pedido gRPC em menos de 100 ms.
- Para concluir o fluxo de trabalho "Criar máquina virtual" com êxito.
- Para publicar dados que foram atualizados nos últimos 10 minutos.
- Para começar a executar o trabalho em lote agendado no prazo de um minuto após a respetiva hora de início.
Especificações e implementações de SLI
Uma especificação de INS é o que quer medir. A especificação não inclui os detalhes técnicos exatos de como vai medi-lo. Por exemplo, segue-se uma especificação de um SLI para o tempo de carregamento da página:
- A percentagem de pedidos da página inicial que são carregados em menos de 100 ms.
Existem várias formas de medir um SLI, cada uma com compromissos e vantagens. As formas de medir o SLI são as implementações do SLI. Por exemplo, pode implementar a especificação de carregamento de páginas como uma das seguintes:
- O campo de latência do registo de pedidos do servidor de aplicações.
- Métricas exportadas pelo servidor de aplicações.
- Métricas exportadas por um balanceador de carga à frente dos servidores de aplicações.
- Um serviço de monitorização de caixa negra que envia pedidos artificiais ao sistema e mede o tempo necessário para receber respostas válidas.
- Código específico da aplicação executado no navegador do cliente que regista informações de tempo e as envia de volta para um serviço de recolha.
Cada uma destas escolhas envolve compromissos entre as seguintes caraterísticas:
- Fidelidade: a precisão com que capta a experiência do utilizador.
- Cobertura: que proporção das interações dos utilizadores é medida.
- Custo: a quantidade de dinheiro e tempo de engenharia necessários para criar e manter a solução.
A fidelidade à experiência do utilizador melhora normalmente quando o SLI é medido mais perto do utilizador. Por exemplo, a implementação que usa código no navegador do utilizador resulta numa medição mais precisa da latência do que a latência percebida pelo utilizador ou por outras opções de medição.
A desvantagem é que a medição baseada no navegador também inclui qualquer latência introduzida pela ligação do utilizador ao seu serviço. Por exemplo, quando um serviço é usado através da Internet pública, esta latência pode variar significativamente com a localização geográfica ou as condições da rede.
O resultado é que o sinal baseado no navegador é um bom proxy para a satisfação dos utilizadores. No entanto, este sinal pode não fornecer informações acionáveis que possa usar para melhorar a fiabilidade do seu serviço.
Para ver informações sobre como combinar várias medições para equilibrar esta compensação, consulte esta publicação do The Telegraph.
Segmentação
Pode precisar de vários SLIs para um serviço quando o seu serviço realiza diferentes tipos de trabalho para diferentes utilizadores ou quando realiza uma tarefa específica com diferentes resultados possíveis.
Tarefas diferentes
Os serviços que realizam vários tipos de trabalho para diferentes categorias de utilizadores e em que cada tipo de trabalho influencia a satisfação do utilizador de forma diferente beneficiam de vários SLIs.
Por exemplo, se o seu serviço processar pedidos de leitura e escrita, os utilizadores que realizam essas tarefas podem ter requisitos diferentes:
- Os pedidos de leitura têm de ser rápidos.
- Os pedidos de escrita têm de ser bem-sucedidos.
Para captar estes diferentes requisitos, o SLI tem de conseguir distinguir entre estes dois casos. Normalmente, a métrica de SLI tem uma etiqueta que pode usar para classificar os valores num de vários segmentos.
Uma tarefa com resultados diferentes
Os serviços que realizam um único tipo de trabalho, mas em que as expetativas dos utilizadores diferem com base na resposta, beneficiam de vários SLIs.
Por exemplo, se o seu serviço oferecer apenas acesso de leitura aos dados, os utilizadores podem ter uma tolerância diferente para a latência consoante o resultado do pedido:
- Os utilizadores podem tolerar erros devolvidos rapidamente, porque podem tentar novamente o pedido imediatamente.
- Os utilizadores podem ser menos tolerantes com pedidos bem-sucedidos que demoram muito tempo.
- Os utilizadores são menos tolerantes com o pior cenário possível: pedidos que demoram muito tempo a devolver um erro.
Neste caso, o SLI de latência tem de conseguir distinguir entre pedidos bem-sucedidos e pedidos sem êxito.
O que se segue?
Para informações sobre a implementação de SLIs para Google Cloud serviços que usamGoogle Cloud métricas, consulte o seguinte:
Para obter informações sobre a implementação de SLIs específicas da aplicação, consulte o seguinte:
Para ver um exemplo que ilustra como criar um SLI para serviços que comunicam métricas personalizadas, consulte o artigo Definir SLOs: observabilidade através de métricas personalizadas.