Objetivos de nível de serviços do monitoramento de nuvem

Este artigo faz parte de uma série do guia de monitoramento de nuvem.

Nas seções abaixo, você aprenderá sobre os princípios fundamentais dos objetivos de nível de serviço e como implementá-los e aplicá-los.

Visão geral

Os SLOs (Service Level Objectives, objetivos de nível de serviço) são metas mensuráveis para os principais indicadores de nível de serviço (SLIs) centrados no cliente. Eles medem a experiência do cliente em relação a uma carga de trabalho de negócios ou infraestrutura e determinam se o provedor de serviços da empresa atende às promessas feitas em um contrato de nível de serviço (SLA) formalmente negociado ou em um acordo informal entre todas as partes.

Como agente de serviços, você confia no compromisso da Microsoft com a confiabilidade dos serviços, conforme definido nos contratos de nível de serviço da Microsoft para serviços do Azure. Isso permite que você se concentre em suas responsabilidades na cadeia de serviços, como monitoramento sintético, conectividade de rede e segurança e conformidade.

Terminologia

Abaixo estão as definições para cada um desses termos e uma breve descrição. Essas definições foram retiradas do Manual SRE do Google.

Termo	Descrição
Acordo de nível de serviço (SLA)	Geralmente um compromisso vinculativo entre um prestador de serviços e um cliente. Um acordo normalmente inclui consequências de não cumprir as metas de SLO . Aspectos particulares do serviço são qualidade, disponibilidade e responsabilidades, conforme acordado entre o provedor de serviços e o consumidor do serviço.
Monitoring	A prática de coletar dados quantitativos em tempo real sobre serviços e sistemas.
Métricas	Mede o comportamento relevante do serviço e pode ser agregado em indicadores de nível de serviço (SLIs), que são processados e agregados para medir o estado operacional atual de um serviço e quantificar seu comportamento. Os SLIs são os principais indicadores em tempo real da integridade atual de um serviço.
Logs	Começa com o código e relata informações sobre uma execução individual de um caminho de código ou evento discreto. Use essas informações para ajudar a solucionar problemas e trabalhar para identificar problemas de causa raiz que afetam a experiência do cliente e a confiabilidade do serviço medida por SLIs/SLOs.
Objetivo de nível de serviço (SLO)	Um valor de destino para o nível de serviço, medido por indicadores de nível de serviço (SLIs), que define expectativas sobre o desempenho de um serviço. Os SLOs rastreiam especificamente a experiência do cliente de ponta a ponta. Para estabelecer bons SLOs, você normalmente começa definindo a experiência desejada e, em seguida, instrumenta o código de serviço para medir essa experiência (coletar SLIs relevantes) e definir o alvo de como você atende às expectativas do cliente ou não.
Indicador de nível de serviço (SLI)	Uma métrica que quantifica a qualidade ou confiabilidade do serviço. No mínimo, quatro SLIs comuns são avaliados: disponibilidade, latência, taxa de transferência e taxa de erro.
Disponibilidade	Geralmente refere-se à porcentagem mensurável ou observável de tempo que um sistema está operacional e funcional. Você mede a disponibilidade como um destino voltado para o cliente para a continuidade da experiência, que é afetada por um ou mais problemas de confiabilidade (e outros modos de falha relacionados a alterações de configuração, atualizações aplicadas e muito mais).
Orçamento de erro	A porcentagem do buffer restante em relação ao SLO. Os orçamentos de erros são a ferramenta que o DevOps usa para equilibrar a confiabilidade do serviço com o ritmo da inovação.

O objetivo dos SLOs

Os SLOs servem a muitos propósitos essenciais no desenvolvimento e nas operações de cargas de trabalho em nuvem, incluindo:

• Quase em tempo real (NRT): Para dar uma visão NRT da saúde de um serviço como experimentado por um cliente.
• Redução do tempo de notificação (TTN): impulsione a notificação automatizada de problemas de serviço aos clientes, reduzindo significativamente o tempo de notificação (TTN).
• Sinal primário para os clientes: Atue como um sinal primário para operações de implantação, impulsionando a reversão automatizada se ocorrerem problemas, expondo assim menos clientes a possíveis problemas.
• Verificação de alterações: forneça validação de que as alterações alcançaram a melhoria esperada da experiência do cliente.
• Determinar prioridades: ajude as equipes a entender se devem criar recursos ou trabalhar na confiabilidade.
• Insights sobre a integridade do serviço: habilite discussões objetivas e focadas no cliente sobre a integridade do serviço.
• Reduza o tempo de análise: acelere a mitigação e a análise de causa raiz (RCA) dos problemas do cliente, direcionando o foco para o serviço responsável.
• Dependências arquitetônicas: Atuam como uma entrada essencial nas decisões de arquitetura quando os serviços assumem dependências.
• Cria confiança: Fornece uma compreensão compartilhada das medidas de saúde, o que cria confiança entre as equipes.
• Traga transparência: Exponha os mesmos SLIs que usamos para administrar nossos negócios aos nossos clientes para que eles possam executar os seus.
• Painel único de vidro: habilite um único painel de vidro horizontal para os serviços e suas dependências e silos de decomposição.

Ao usar os SLOs para impulsionar o processo de engenharia, o DevOps e a TI podem obter uma compreensão inicial da integridade do aplicativo ou do serviço de infraestrutura compilado ou migrado para o Azure. Essa compreensão pode ser usada para conduzir as decisões humanas e automatizadas que precisam ser tomadas sobre a confiabilidade desses serviços. Essa transformação na prática de engenharia impactará significativamente a confiabilidade desses serviços no curto prazo.

Como definir SLOs?

O objetivo de um SLO é obter sinais claros que medem com precisão a qualidade da perspectiva do cliente. Cada equipe de serviço cria um pequeno conjunto de SLOs (Objetivos de Nível de Serviço), que definem o intervalo permitido para as métricas mensuráveis mais importantes do serviço, conforme experimentado pelo consumidor do serviço. Um SLO é uma meta numérica definida para uma métrica emitida por um serviço. As métricas associadas a essa meta podem ser monitoradas para determinar se o serviço está íntegro.

Por exemplo, aqui está um exemplo simplificado de um SLO para um aplicativo interno baseado na Web de controle de tempo - As solicitações nos últimos 5 minutos são atendidas em menos de 1000 milissegundos no percentil 99.

As métricas são agregações de dados de séries temporais chamadas Indicadores de Nível de Serviço (SLIs). O local em que os SLIs são coletados é muito importante. No exemplo acima, se o cliente interagir com o serviço usando uma API, medir a latência do sistema e o tempo para processar solicitações serão SLIs precisos. No entanto, se o cliente interagir com o serviço usando um portal da Web, o tempo total de atendimento da solicitação também deve incluir o desempenho do JavaScript da página da Web.

O foco para os proprietários de serviços é determinar o seguinte:

• Quais cenários são indicadores críticos da integridade do serviço da perspectiva do cliente,
• Onde reunir os SLIs para que estejam o mais próximo possível da experiência do cliente e
• Quais devem ser os SLOs para esses SLIs?

Os SLOs podem ser definidos com uma abordagem gradual para impulsionar a realização ou são prescritos diretamente pela empresa. Você usa os SLOs definidos por um serviço para tomar decisões arquitetônicas sobre como criá-los. Por isso, é essencial escolher com cuidado quais cenários medir e qual prazo medir. Para resumir, um SLO é composto pelos seguintes valores:

• Um SLI. Por exemplo, a proporção de solicitações suficientemente rápidas, medida a partir do balanceador de carga, é inferior a 400 ms.
• Uma duração. O período em que uma métrica é medida.
• Um destino. Por exemplo, uma porcentagem de destino das solicitações rápidas para o total de solicitações (como 90%) que você espera atender para determinada duração.

Tipos de SLOs

Se você examinar todo o setor, haverá dois tipos de SLOs:

• SLOs centrados em serviço - Esses SLOs são metas táticas que as equipes definem para melhorar a qualidade de seu serviço ao longo do tempo gradualmente. Eles são projetados para serem metas pragmáticas alcançáveis em um marco da engenharia. Por exemplo, se um serviço estiver atingindo 99,7% de disponibilidade no momento, a equipe poderá definir uma meta para atingir 99,9% de disponibilidade no próximo trimestre.

• SLOs centrados no cliente - Esses SLOs definem o estado ou a meta futura ideal. Neste ponto, mais investimentos em qualidade seriam considerados desnecessários, porque você está atendendo plenamente às expectativas dos clientes.

Por exemplo, se o cliente espera que um serviço comercial ou de infraestrutura que você opera forneça 99,99% de disponibilidade e, no momento, o serviço atinge apenas 99,8% de disponibilidade, o SLO centrado no cliente ainda é de 99,99%.

A definição de SLOs adequados demora. O primeiro passo é conversar com seus clientes e entender o que seus usuários querem do serviço para derivar uma pequena seleção de indicadores e documentá-lo. Aprenda os cenários e tolerâncias de como eles usam seu serviço e o que seu serviço precisa fornecer para executar seus negócios com sucesso. Normalmente, essa é uma experiência iterativa e a expectativa varia de 100% de disponibilidade em todas as condições, sem impacto em nosso fluxo de receita ao gerenciamento de expectativas extremamente variáveis entre os segmentos do cliente.

As abordagens de monitoramento que analisam apenas a integridade do serviço (ou da instância de serviço) são vulneráveis a problemas de experiência do cliente ausentes em ambas as extremidades do espectro; A integridade do serviço nem sempre se correlaciona com a qualidade da experiência do cliente. Isso ocorre porque há diferentes características de comportamento entre um serviço PaaS e SaaS do Azure, a configuração desses serviços do Azure, como e onde (ou seja, qual região) seus recursos são implantados e a adição de seu código/lógica personalizado, o que adiciona mais complexidade.

Ao definir um SLO, é importante lembrar que o(s) seu(s) provedor(es) de nuvem são uma dependência do seu SLA. Considere os contratos de nível de serviço especificados para cada um de seus serviços. Para o Azure, consulte Contratos de Nível de Serviço (SLA) para Serviços Online

Como definir os SLIs?

Uma especificação SLI é uma declaração formal das expectativas dos usuários sobre uma dimensão de confiabilidade específica para seu serviço, como latência ou disponibilidade.

Comece simples selecionando as métricas certas para medir e coletar, e não complique demais coletando muitas métricas que não são significativas. Verifique se os SLIs definidos têm uma relação direta com a experiência do cliente. É por isso que é essencial entender a perspectiva dos usuários para começar com apenas alguns indicadores.

Se o seu serviço é limitado por recursos de alguma forma, como memória ou CPU, sua saturação também pode ser um excelente SLI. No entanto, a saturação não deve ser usada como um SLO, uma vez que não corresponde diretamente a uma experiência de usuário ruim (um serviço pode ter alta utilização de memória, mas os usuários não são afetados).

Recomendamos que você crie até três indicadores. Mais de três indicadores raramente agregam valor substancial. Muitas vezes, um número excessivo de indicadores pode significar que você inclui sintomas de indicadores primários. O tráfego e a saturação devem ser adicionais a esses três indicadores principais, pois descrevem a carga de serviço e o apoio na interpretação de outros indicadores de serviço.

Como implementar os SLOs?

Os SLIs que mais importam são os que mais claramente representam um impacto no seu serviço do ponto de vista do seu cliente. Para muitos serviços, isso inclui latência, taxa de transferência, taxa de erro e disponibilidade. Se o seu serviço tiver considerações especiais que afetem a experiência do cliente, os SLIs para essas áreas também devem ser medidos. Por exemplo, a latência de processamento de ponta a ponta para um serviço de mensagens é um indicador direto da experiência do cliente e deve ser coberta por uma SLI.

Exemplos de SLO

Os Recursos Humanos estão interessados em modernizar seu aplicativo interno baseado na Web de controle de tempo e hospedá-lo na nuvem do Azure com a ajuda da TI corporativa. Eles querem que o serviço continue acessando todos os usuários da organização. Portanto, estão interessados no seguinte:

• Relatórios de uso e quantos usuários estão usando o serviço ao longo do tempo.
• Monitoramento regular de integridade, como disponibilidade, desempenho, segurança e conformidade (garantia de serviço).
• Custo, como o custo mensal de um serviço.
• Segurança cibernética, em termos de controle de acesso a recursos e dados, seguindo uma estratégia de segurança de Confiança Zero.

Como vemos nesses exemplos acima, as categorias e exemplos de SLO/SLI são necessários para definir no início do design do serviço. Não é diferente dos serviços locais que você está compilando.

Tabelas de SLO/Categorias de SLI

Os exemplos a seguir não são de forma alguma uma lista completa. Embora os SLOs de confiabilidade e facilidade de manutenção sejam características dos sistemas há décadas, você pode definir SLOs que incluam medidas de segurança cibernética, experiência do usuário e da qualidade e custo.

Serviços

Medidas típicas de alto nível de um serviço ou sistema são geralmente codificadas em contratos de serviço. A maioria dos contratos modernos mede a disponibilidade como o SLO principal e usa medidas simples de tempo de inatividade com base nos principais itens de carga de trabalho ou unidades de produção, como tokens de autenticação, caixas de correio ou contas de armazenamento.

Categoria	Descrição	Exemplo
Disponibilidade	Tempo de inatividade simples ou Tempo Médio entre a Manutenção ou disponibilidade operacional (MTBM/(MTBM+MDT))	99,99% em um período mensal
Capacidade	Garanta desempenho adequado, máximo ou ideal de negócios e serviços, taxa de transferência, armazenamento, pessoas, largura de banda, demanda, recursos e funções de serviço. Inclui limites de profissionais e de tempo para atuar como gatilhos.	% de utilização (CPU, armazenamento, memória, latência, taxa de transferência, escala)
Segurança	Ameaças ativas e vulnerabilidades (internas e externas) que podem ou estão causando danos aos negócios, ativos e dados.	Detecção de Ameaça HAFNIUM
Conformidade	Atualizações, níveis de manutenção, conformidade de proteção, descompasso de configuração desejado	99,5% de atualizações atendidas em todos os ativos
Continuidade	Capacidade de sobreviver e se recuperar de grandes desastres e eventos externos.	Hora (reconstituição)
Quality of Service (QoS)	Características da experiência real dos usuários ao longo do tempo.	Qualidade de chamada do Teams – perda de pacotes recebidos < 2%

Confiabilidade

A confiabilidade, o SLO clássico, implica o grau de confiabilidade, durabilidade e qualidade ao longo do tempo de sistemas, serviços, recursos ou componentes para falhas e failovers, com esforço de gerenciamento aplicado para lidar com falhas (como criar mais redundância ou adicionar uma rede de entrega de conteúdo) para aumentar o tempo operacional ou a disponibilidade. Também pode significar a precisão, fidelidade, integridade e confiabilidade dos dados usados para medir SLOs. Pode significar a probabilidade clássica de que um sistema irá desempenhar sua função pretendida sob condições especificadas, como tensão de temperatura. A resiliência também inclui fatores de projeto internos ou recursos que fornecem adaptabilidade, como dimensionamento, resfriamento, balanceamento de carga, recuperação, demanda imprevisível, desempenho degradado sob estresse severo e projeto para continuidade em desastres maiores (geralmente um SLO separado).

Categoria	Descrição	Exemplo
Taxa de Falha	Número de falhas ao longo do total de horas de operação	5 falhas em 973 horas, nosso 0,00514
MTBF (Tempo Médio entre Falhas)	O MTBF é o inverso da taxa de falha	194,6 horas

Facilidade de manutenção

Combine os SLOs de suporte para processos de gerenciamento de serviços de TI, como gerenciamento de incidentes e problemas, juntamente com os SLOs de confiabilidade, para que a medição de disponibilidade possa ser obtida.

Categoria	Descrição	Exemplo
Desempenho de Incidentes de Serviço	Por categoria, produto ou prioridade.	Medidas de tempo e de custo para cada fase do ciclo de vida do incidente.
Desempenho de Incidentes de Segurança	Por categoria, produto ou prioridade.	Medidas de tempo e de custo para cada fase do ciclo de vida do incidente.
MTTR (Tempo de Reparo) do Componente	Desde a detecção de eventos até a restauração ou correção.
MTBM (Tempo Médio entre a Manutenção)	Tempo médio ou médio entre todas as ações de manutenção, incluindo ações preventivas onde ocorre o trabalho normal de produção.	Confira Tempo de Atraso de Manutenção
MDT (Tempo de Atraso de Manutenção)	Tempo total desde a detecção até a recuperação, incluindo logística e atraso administrativo.	Hora de substituir o hardware para incluir pedidos, remessas e instalações.

Experiência do cliente

Categoria	Descrição	Exemplo
Produtividade	A quantidade, a taxa ou a velocidade da carga de trabalho ou da carga produtiva colocada em um sistema ao longo do tempo.	Transações por unidade de tempo.
Taxa de erros	O número total de erros em porcentagem.	% de eventos de segurança
Latency	Uma medida de tempo ou atraso da entrada para a saída, movimentação do trabalho por meio de um processo ou do aplicativo para o usuário.	Média em segundos.

Others

Categoria	Descrição	Exemplo
Custo	Meça despesas, faturamento e faturas por serviço, componente ou tempo.	Despesas de Capital ou despesas operacionais
Cobertura	Porcentagem de componentes, sistemas e serviços sob gerenciamento (conformidade)	Conformidade
Confiabilidade do feed	Falhas de batimentos cardíacos, conectores, alterações e muito mais.	Controle de alterações nos dados críticos da empresa.
Produtividade	Eficácia para realizar tarefas de maneira produtiva	Profissionais, tempo por funcionário, produtividade do analista.

Considerações

• Garanta o acesso. Verifique se os gerentes e outras personas na organização têm acesso às visualizações disponíveis no Azure Monitor ou de outros serviços do Azure, especialmente SaaS e PaaS do Azure, para evitar a duplicação.

• Monitore a cobertura ou a visibilidade total do ativo. Garanta agentes, logs emitidos, tabelas e consultas para todos os ativos que precisam ser gerenciados e protegidos, e identifique "pontos cegos" ou lacunas na cobertura para garantir realismo nos SLOs.

• Obtenha os dados corretos na frente dos consumidores certos. Garantir que os consumidores de SLOs e SLIs possam interpretar os dados subjacentes para criar confiança e orientar decisões usando as informações obtidas dos dados.

• Faça promessas razoáveis. Ao definir SLOs como metas , especialmente quando o gerenciamento de custos é essencial, certifique-se de que o desempenho real do sistema não esteja com desempenho excessivo nem entrega insuficiente, ou ajuste a meta para gerenciar as expectativas do cliente.

• Explique os eventos externos imprevistos. Desenvolva planos de continuidade e avaliações de risco para explicar eventos que não estão sob controle, como clima, interrupções de energia ou desastres.

• Explique a Alteração. Garantir que os SLOs sejam responsáveis por alterações no serviço ou alterações na confiabilidade técnica, taxa de transferência, qualidade e capacidade de manutenção - como reduções na equipe de suporte.

• Forneça um conjunto equilibrado de SLOs. Garanta uma variedade de SLOs que forneçam uma perspectiva equilibrada ou de 360 graus sobre o serviço ou sistema e um foco na confiabilidade.

Próximas etapas

Coletar os dados certos