Nota do Editor: O seguinte é um artigo escrito para e publicado no Relatório de Tendências de 2024 da DZone,Observabilidade e Desempenho: O Precipício da Construção de Sistemas de Software Altamente Performantes.
“Qualidade não é um ato, é um hábito”, disse Aristóteles, um princípio que é verdadeiro no mundo do software também. Especificamente para os desenvolvedores, isso significa que proporcionar satisfação ao usuário não é um esforço único, mas um compromisso contínuo. Para alcançar esse compromisso, as equipes de engenharia precisam ter metas de confiabilidade que definam claramente o desempenho básico que os usuários podem esperar. É exatamente aqui que entram em cena os objetivos de nível de serviço (SLOs).
Em termos simples, os SLOs são metas de confiabilidade para os produtos alcançarem a fim de manter os usuários satisfeitos. Eles servem como a ponte quantificável entre metas de qualidade abstratas e as decisões operacionais diárias que as equipes de DevOps devem tomar. Devido a essa importância, é crítico defini-los de forma eficaz para o seu serviço. Neste artigo, passaremos por uma abordagem passo a passo para definir SLOs com um exemplo, seguido por alguns desafios com os SLOs.
Passos para Definir Objetivos de Nível de Serviço
Como qualquer outro processo, definir SLOs pode parecer esmagador no início, mas ao seguir alguns passos simples, você pode criar objetivos eficazes. É importante lembrar que os SLOs não são métricas definidas e esquecidas. Em vez disso, fazem parte de um processo iterativo que evolui à medida que você ganha mais insights sobre o seu sistema. Portanto, mesmo que seus SLOs iniciais não sejam perfeitos, tudo bem – eles podem e devem ser refinados ao longo do tempo.
Figura 1. Passos para definir SLOs
Passo 1: Escolha Jornadas Críticas do Usuário
Uma jornada crítica do usuário refere-se à sequência de interações que um usuário realiza para alcançar um objetivo específico dentro de um sistema ou serviço. Garantir a confiabilidade dessas jornadas é importante porque isso impacta diretamente a experiência do cliente. Algumas maneiras de identificar jornadas críticas do usuário podem ser através da avaliação do impacto financeiro/nos negócios quando um determinado fluxo de trabalho falha e da identificação de fluxos frequentes através da análise do usuário.
Por exemplo, considere um serviço que cria máquinas virtuais (VMs). Algumas das ações que os usuários podem realizar neste serviço são navegar pelos formatos de VM disponíveis, escolher uma região para criar a VM e lançar a VM. Se a equipe de desenvolvimento fosse ordená-las por impacto nos negócios, a classificação seria:
- Lançar a VMporque isso tem um impacto direto na receita. Se os usuários não puderem lançar uma VM, então a funcionalidade principal do serviço falhou, afetando diretamente a satisfação do cliente e a receita.
- Escolher uma região para criar a VM. Embora os usuários ainda possam criar uma VM em uma região diferente, isso pode resultar em uma experiência degradada se tiverem uma preferência regional. Essa escolha pode afetar o desempenho e conformidade.
- Navegar pelo catálogo de VMs. Embora seja importante para a tomada de decisões, tem um impacto direto menor no negócio porque os usuários podem alterar o formato da VM posteriormente.
Passo 2: Determinar Indicadores de Nível de Serviço que Podem Rastrear Jornadas do Usuário
Agora que as jornadas do usuário estão definidas, o próximo passo é medi-las de forma eficaz. Indicadores de Nível de Serviço (SLIs) são as métricas que os desenvolvedores usam para quantificar o desempenho e a confiabilidade do sistema. Para equipes de engenharia, os SLIs servem a um propósito duplo: Eles fornecem dados acionáveis para detectar degradação, orientar decisões arquiteturais e validar mudanças de infraestrutura. Eles também formam a base para SLOs significativos, fornecendo as medidas quantitativas necessárias para definir e rastrear metas de confiabilidade.
Por exemplo, ao lançar uma VM, alguns dos SLIs podem ser disponibilidade e latência.
Disponibilidade: De um total de X solicitações para lançar uma VM, quantas tiveram sucesso? Uma fórmula simples para calcular isso é:
Se houve 1.000 solicitações e 998 delas tiveram sucesso, então a disponibilidade é = 99,8%.
Latência: Das solicitações totais para lançar uma VM, quanto tempo a 50ª, 95ª ou 99ª percentil das solicitações levaram para lançar a VM? Os percentis aqui são apenas exemplos e podem variar dependendo do caso de uso específico ou expectativas de nível de serviço.
- Num cenário com 1.000 solicitações, onde 900 solicitações foram concluídas em 5 segundos e as 100 restantes levaram 10 segundos, a latência do percentil 95 seria = 10 segundos.
- Embora as médias também possam ser usadas para calcular latências, os percentis são geralmente recomendados porque consideram as latências de cauda, oferecendo uma representação mais precisa da experiência do usuário.
Passo 3: Identificar Números-Alvo para SLOs
Em termos simples, os SLOs são os números-alvo que queremos que nossos SLIs alcancem em uma janela de tempo específica. Para o cenário de VM, os SLOs podem ser:
- A disponibilidade do serviço deve ser superior a 99% em uma janela de 30 dias em rotação.
- A latência do percentil 95 para iniciar as VMs não deve exceder oito segundos.
Ao definir esses objetivos, algumas coisas a ter em mente são:
-
Usando dados históricos. Se você precisa definir SLOs com base em um período de 30 dias em rotação, colete dados de várias janelas de 30 dias para definir os objetivos.
- Se você não possui esses dados históricos, comece com uma meta mais gerenciável, como mirar em uma disponibilidade de 99% a cada dia, e ajuste-a ao longo do tempo à medida que você reunir mais informações.
- Lembre-se, os SLOs não são definitivos; eles devem evoluir continuamente para refletir as necessidades em mudança do seu serviço e dos clientes.
-
Considerando SLOs de dependência. Os serviços geralmente dependem de outros serviços e componentes de infraestrutura, como bancos de dados e balanceadores de carga.
-
Por exemplo, se o seu serviço depende de um banco de dados SQL com um SLO de disponibilidade de 99,9%, então o SLO do seu serviço não pode exceder 99,9%. Isso ocorre porque a máxima disponibilidade é limitada pelo desempenho de suas dependências subjacentes, que não podem garantir uma maior confiabilidade.
-
Desafios dos SLOs
Pode ser intrigante definir o SLO como 100%, mas isso é impossível. Uma disponibilidade de 100%, por exemplo, significa que não há espaço para atividades importantes como envio de recursos, correção de falhas ou testes, o que não é realista. Definir SLOs requer colaboração entre várias equipes, incluindo engenharia, produto, operações, QA e liderança. Garantir que todas as partes interessadas estejam alinhadas e concordem com as metas é essencial para que o SLO seja bem-sucedido e acionável.
Passo 4: Considerar o Orçamento de Erros
Um orçamento de erros é a medida de tempo de inatividade que um sistema pode suportar sem desagradar os clientes ou violar obrigações contratuais. Abaixo está uma maneira de olhar para isso:
- Se o orçamento de erros estiver quase esgotado, a equipe de engenharia deve se concentrar em melhorar a confiabilidade e reduzir incidentes, em vez de lançar novos recursos.
- Se houver muito orçamento de erros restante, a equipe de engenharia pode se dar ao luxo de priorizar o envio de novos recursos, já que o sistema está se saindo bem dentro de suas metas de confiabilidade.
Existem duas abordagens comuns para medir o orçamento de erros: baseada em tempo e baseada em eventos. Vamos explorar como a afirmação “A disponibilidade do serviço deve ser superior a 99% em uma janela de 30 dias” se aplica a cada uma.
Medida Baseada em Tempo
Em um orçamento de erros baseado em tempo, a afirmação acima se traduz em o serviço sendo permitido ficar fora do ar por 43 minutos e 50 segundos em um mês, ou 7 horas e 14 minutos em um ano. Aqui está como calculá-lo:
-
Determine o número de pontos de dados. Comece determinando o número de unidades de tempo (pontos de dados) dentro da janela de tempo do SLO. Por exemplo, se a unidade de tempo base é 1 minuto e a janela do SLO é de 30 dias:
-
Calcule o orçamento de erro. Em seguida, calcule quantos pontos de dados podem “falhar” (ou seja, tempo de inatividade). O orçamento de erro é a porcentagem de falhas permitidas.
Converta isso em tempo:
Isso significa que o sistema pode experimentar 7 horas e 14 minutos de tempo de inatividade em uma janela de 30 dias.
Por último, mas não menos importante, o restante do orçamento de erro é a diferença entre o total possível de inatividade e a inatividade já utilizada.
Medida Baseada em Eventos
Para a medida baseada em eventos, o orçamento de erro é medido em termos de porcentagens. A afirmação mencionada traduz-se em um orçamento de erro de 1% em uma janela de 30 dias contínuos.
Vamos supor que há 43.200 pontos de dados nessa janela de 30 dias, e 100 deles são ruins. Você pode calcular quanto do orçamento de erro foi consumido usando esta fórmula:
Agora, para descobrir quanto do orçamento de erro permanece, subtraia isso do orçamento de erro total permitido (1%):
Assim, o serviço ainda pode tolerar mais 0,77% de pontos de dados ruins.
Vantagens do Orçamento de Erros
Os orçamentos de erros podem ser utilizados para configurar monitores automatizados e alertas que notificam as equipes de desenvolvimento quando o orçamento corre o risco de esgotamento. Esses alertas permitem que reconheçam quando é necessário ter mais cautela ao implementar mudanças na produção. As equipes frequentemente enfrentam ambiguidade ao priorizar recursos versus operações. O orçamento de erros pode ser uma forma de lidar com este desafio. Ao fornecer métricas claras e baseadas em dados, as equipes de engenharia podem priorizar tarefas de confiabilidade em detrimento de novos recursos quando necessário. O orçamento de erros é uma das estratégias bem estabelecidas para melhorar a responsabilidade e maturidade dentro das equipes de engenharia.
Cuidados a Ter Com os Orçamentos de Erros
Quando há orçamento extra disponível, os desenvolvedores devem procurar utilizá-lo ativamente. Esta é uma excelente oportunidade para aprofundar o entendimento do serviço experimentando técnicas como a engenharia do caos. As equipes de engenharia podem observar como o serviço responde e descobrir dependências ocultas que podem não ser aparentes durante operações normais. Por último, mas não menos importante, os desenvolvedores devem monitorar de perto o esgotamento do orçamento de erros, pois incidentes inesperados podem rapidamente esgotá-lo.
Conclusão
Os objetivos de nível de serviço representam uma jornada em vez de um destino na engenharia de confiabilidade. Embora forneçam métricas importantes para medir a confiabilidade do serviço, seu verdadeiro valor reside na criação de uma cultura de confiabilidade dentro das organizações. Em vez de buscar a perfeição, as equipes devem abraçar os SLOs como ferramentas que evoluem junto com seus serviços. Olhando para o futuro, a integração de IA e aprendizado de máquina promete transformar os SLOs de medições reativas em instrumentos preditivos, permitindo que as organizações antecipem e previnam falhas antes que impactem os usuários.
Recursos adicionais:
-
Implementando Objetivos de Nível de Serviço, Alex Hidalgo, 2020
-
“Objetos de Nível de Serviço,” Chris Jones et al., 2017
-
“Implementando SLOs,” Steven Thurgood et al., 2018
Este é um trecho do Relatório de Tendências 2024 da DZone, Observabilidade e Desempenho: O Abismo de Construir Sistemas de Software Altamente Performáticos.
Source:
https://dzone.com/articles/framework-for-service-level-objectives