gerenciamento a nível de serviço é a prática de padronizar dados em uma linguagem universal. Dentro de uma organização, a comunicação entre as partes interessadas pode muitas vezes ser mais difícil do que o necessário. Os departamentos de TI geralmente não falam em termos que as partes de uma organização focadas nos negócios possam entender e, por sua vez, normalmente não se comunicam em termos que as equipes de TI considerem úteis. Para melhorar a confiabilidade, resolver essa barreira linguística ajuda a evitar problemas. O gerenciamento do nível de serviço, ou a prática de padronizar os dados em uma linguagem universal que todas as partes possam entender, ajuda a fazer exatamente isso.
O gerenciamento a nível de serviço se aplica melhor às práticas de tempo de operação, desempenho e confiabilidade, mas também se aplica às demais práticas de experiência do cliente, Inovação e crescimento e Eficiência operacional (saiba mais sobre essas práticas). Independentemente da área que você deseja melhorar, o uso do SLM tem duas áreas principais de impacto: resultados de negócios e resultados operacionais.
Os resultados de negócios exigidos em termos de confiabilidade concentram-se na redução do número de incidentes com impacto nos negócios, na sua duração e no número de pessoas envolvidas.
Reduza o número de incidentes que perturbam os negócios.
Reduza o tempo médio de resolução (MTTR).
Reduzir o número médio de pessoas envolvidas (FTEs) por incidente grave.
O resultado operacional necessário em termos de confiabilidade concentra-se na saúde do seu produto digital.
Meça o sucesso operacional pela porcentagem de aplicativos de produtos críticos que você cobre com seu nível de serviço padrão.
Examine a percentagem de adoção de políticas pelos seus principais intervenientes.
Foque no que é importante para os stakeholders, garanta a simplicidade e comprove a eficácia do gerenciamento a nível de serviço.
Por que usar o gerenciamento a nível de serviço?
Melhorar o nível de serviço e a confiabilidade requer a adoção da prática por todos os stakeholders do serviço. Isso inclui gerenciamento de engenharia, gerenciamento de produtos e gerenciamento executivo para mostrar rapidamente o poder e o valor do nível de serviço e iniciar discussões sobre o que é importante para cada grupo. As etapas deste guia proporcionarão discussões significativas muito rapidamente.
Um método comum primeiro estabelece o nível de serviço do desempenho de saída e do desempenho de entrada para um produto digital e suas capacidades críticas. Isso geralmente envolve um nível de serviço geral desaída e entrada para cada endpoint aplicativo (geralmente um ou dois) e, em seguida, aproximadamente 4 a 7 níveis de serviço de desempenho de saída para capacidades críticas assumidas medidas na endpoint transação .
Este método não pesquisa cada parte interessada sobre o que deve ou não ser medido, pois as pesquisas muitas vezes demoram muito e têm muitas partes em cenários como este. O importante é começar com a linha de base e o principal de transação como “capacidades”.
Implementações bem-sucedidas do nível de serviço demonstram a capacidade de medir e comunicar facilmente a saúde geral do sistema. Essa demonstração inicial mostrará o valor de investir mais tempo para refinar sua medida de nível de serviço. Quanto mais cedo você fornecer essa demonstração completa, mais cedo poderá obter ampla adoção e iniciar o processo de melhoria da confiabilidade em colaboração com todas as partes interessadas!
Vamos dar uma olhada em alguns dos termos comuns e definir nossos KPIs antes de prosseguir.
Terminologia
Um nível de serviço mede o desempenho de um sistema. Você mede o nível de serviço usando indicadores e comparando-os com um conjunto de objetivos de desempenho e resultados esperados.
Definimos gerenciamento a nível de serviço como a prática de relatar, manter e gerenciar a conformidade do nível de serviço.
Um indicador de nível de serviço (SLI) mede um nível de serviço. Um SLI identifica algo que você deseja medir e mede um ponto de dados ou um composto de pontos de dados. Um SLI geralmente representa uma porcentagem (%) de transação ou evento bem-sucedido. Ele mede o número total de eventos bons em relação ao número total de eventos válidos calculado em um período de tempo especificado, como 1 hora, 1 dia ou 1 semana.
Exemplos de SLIs:
Porcentagem de transações da API de login concluídas em 500 milissegundos.
Porcentagem de transações da API de login concluídas sem erro interno do servidor.
Porcentagem de transações da API de login concluídas em 500 milissegundos e sem erro interno do servidor.
Porcentagem de Pings de verificações sintéticas na API de Login que foram bem-sucedidas.
Porcentagem de logins do Browser que fazem a transição para a página de destino em 3 segundos.
Porcentagem de métricas ingeridas que ficam disponíveis para consulta em até 3 segundos.
Alguns ou todos os itens acima agregados em um único SLI.
Os objetivos de nível de serviço (SLO) descrevem o nível de serviço esperado de um sistema, trabalho ou capacidade. Geralmente indica a porcentagem necessária de sucesso de um ou mais SLIs dentro de um determinado período de tempo.
Exemplos de SLOs:
A API de login responderá em 500 milissegundos e estará livre de erros 99,99% das vezes por semana.
A capacidade de login móvel fará a transição para a página de destino em 3 segundos, 99,99% do tempo, a cada semana.
A ingestão de dados da métrica estará disponível para consulta em até 3 segundos após o consumo da API 99,99% do tempo todos os dias.
Um limite de serviço costuma ser o ponto em um sistema onde o consumidor faz uma solicitação por meio de um cliente, também conhecido como API externa ou endpoint. Os limites de serviço também podem ser internos entre dois sistemas distintos, onde uma coleção de aplicativos atende às solicitações de outra coleção de aplicativos. Por exemplo, um sistema de gerenciamento de identidade pode servir tanto para solicitações de login do cliente quanto para autorização de permissões para diferentes recursos.
Tipos de limites:
limite de serviço voltado para o cliente: a API GraphQL voltada para o cliente. Esse limite fornece a soma total do tempo de resposta e da métrica de sucesso necessários para medir a integridade do desempenho, sem a necessidade de medir cada dependência.
Limite de serviço interno: dependência do middleware por trás da API GraphQL voltada para o cliente. Cada API de dependência que responde ao nível do GraphQL conta como seu próprio limite de serviço interno. Os limites internos do serviço não representam a integridade geral do desempenho de saída em uma proporção de 1:1. Por exemplo, uma solicitação de cliente à API GraphQL pode atingir sete dependências internas. Uma dependência lenta não afeta o tempo de resposta total da solicitação original.
Um erro de orçamento mede e comunica seus objetivos de nível de conformidade de serviço. Temos informações mais detalhadas sobre esse método avançado em nossos documentos de gerenciamento a nível de serviço.
Um orçamento de erro rastreia o quanto seu serviço pode falhar antes de ficar “fora de conformidade”. Você pode usar alguns métodos diferentes para definir e medir orçamentos de erros. A palavra “erro” em “orçamento de erro” não significa erros de solicitação HTTP ou erros de aplicativo, mas sim se refere a “qualquer solicitação ou evento incorreto”, conforme definido em seus objetivos de nível de serviço.
Nota: Recomendamos que você primeiro aprenda como definir, calcular e comunicar a conformidade do seu nível de serviço antes de implementar orçamentos de erro. É muito importante que você possa estabelecer um destino para seus SLIs para medir o sucesso de quão bem o seu SLI atende ao seu destino. Por exemplo, você pode monitorar se está ou não dentro de 500 milissegundos e livre de erros em 99,99% cada um por um período de 24 horas de suas solicitações de login. Se o resultado de conformidade do SLI em 24 horas atingir 99,99%, você poderá considerar seu objetivo alcançado.
Referências
O Google define um orçamento de erro como:
“Resumindo, um orçamento de erros é a quantidade de erros que seu serviço pode acumular durante um determinado período de tempo antes que seu usuário comece a ficar insatisfeito. Depois de definir um objetivo para cada um (SLI) para seus objetivos de nível de serviço (SLO), o orçamento de erros é o restante, até 100." -- Google Cloud - Como as janelas de manutenção afetam seu orçamento de erros — dicas de SRE
A Atlassian define um orçamento de erro como:
“Um orçamento de erros é o tempo máximo que um sistema técnico pode falhar sem consequências contratuais. Por exemplo, se o seu acordo de nível de serviço (SLA) especifica que os sistemas funcionarão 99,99% do tempo antes que a empresa tenha que compensar os clientes pela interrupção, isso significa que o seu orçamento para erros (ou o tempo que seus sistemas podem parar sem consequências) é 52 minutos e 35 segundos por ano." -- Atlassian - O que é um orçamento de erro e por que isso é importante?
Pré-requisitos
Tenha dados para monitor e estabelecer SLIs, como por meio da instrumentação APM do seu aplicativo principal.
Você também pode utilizar o teste sintético da sua aplicação para gerar dados para monitor sem depender de clientes.
Embora não seja obrigatório, é altamente recomendável que você obtenha habilidades básicas com o painel do New Relic e o NRQL.