Neste documento do Framework de arquitetura do Google Cloud, descrevemos como a experiência do usuário define confiabilidade e como escolher os objetivos de nível de serviço adequados para atender a esse nível de confiabilidade. Este documento se baseia nos conceitos definidos em Componentes dos SLOs.
A cultura de engenharia de confiabilidade do site (SRE) valoriza serviços confiáveis e a satisfação do cliente (ou a satisfação do cliente). Sem um nível de serviço definido e um método para coletar métricas, é difícil (se não impossível) determinar onde e quanto investir em melhorias.
A métrica de substituição usada para medir o nível de serviço é o objetivo de nível de serviço (SLO, na sigla em inglês). Um SLO é composto pelos seguintes valores:
- Um indicador de nível de serviço (SLI): uma métrica de um aspecto específico do seu serviço, conforme descrito em Escolher seus SLIs.
- Duração: a janela em que o SLI é medido. Pode ser baseado em agenda ou janela contínua.
- Uma meta: o valor (ou intervalo de valores) que o SLI precisa atingir na duração determinada em um serviço íntegro. Por exemplo, a porcentagem de eventos bons em relação ao total de eventos que você espera que seu serviço atenda, como 99,9%.
Escolher os SLOs certos para seu serviço é um processo. Você começa definindo as jornadas do usuário que definem confiabilidade e, por fim, seus SLOs. Os SLOs escolhidos precisam medir todo o sistema e, ao mesmo tempo, equilibrar as necessidades de desenvolvimento de recursos com a estabilidade operacional. Depois de escolher os SLOs, é necessário melhorá-los de maneira iterativa e gerenciá-los usando erros de orçamento.
Defina as jornadas dos usuários
O ideal é que seus SLIs e SLOs se baseiem em jornadas ideais do usuário (CUJs). As CUJs consideram as metas do usuário e como seu serviço os ajuda a atingir essas metas. Você define uma CUJ sem considerar os limites do serviço. Quando uma CUJ é atendida, o cliente fica satisfeito, e isso é uma indicação de que o serviço foi bem-sucedido.
A satisfação do cliente, ou insatisfação nessa questão, determina a confiabilidade e é o recurso mais importante de qualquer serviço.
Portanto, defina um SLO alto o suficiente para que a maioria dos usuários fique satisfeita com o serviço. Assim como 100% de disponibilidade não é o objetivo certo, adicionar mais "noves" aos SLOs rapidamente se torna caro e pode nem mesmo importar para o cliente.
Para tempo de atividade e outras métricas vitais, procure uma meta inferior a 100%, mas perto dela. Avalie o nível mínimo de desempenho e disponibilidade do serviço necessário. Não defina metas com base em níveis contratuais externos.
Usar CUJs para desenvolver SLOs
Escolha as CUJs mais importantes da sua empresa e siga estas etapas para desenvolver SLOs:
- Escolha uma especificação de SLI (como disponibilidade ou atualização).
- Defina como implementar a especificação de SLI.
- Confira se o plano abrange todas as CUJs.
- Defina os SLOs com base no desempenho anterior ou nas necessidades da empresa.
As CUJs não devem ser limitadas a um único serviço, nem a uma única equipe ou organização de desenvolvimento. Seu serviço pode depender de dezenas ou mais serviços. Você também pode esperar que esses serviços operem a 99,5%. No entanto, se o desempenho de ponta a ponta (todo o sistema) não for rastreado, executar um serviço confiável será desafiador.
Definir meta e duração
Definir meta e duração (consulte a definição anterior de um SLO) pode ser difícil. Uma maneira de iniciar o processo é identificar SLIs e formatá-los ao longo do tempo. Lembre-se, um SLO não precisa ser perfeito desde o início. Itere no seu SLO para garantir que ele esteja alinhado com a satisfação do cliente e atenda às necessidades dos seus negócios.
Ao rastrear a conformidade com o SLO durante eventos como implantações, interrupções e padrões de tráfego diários, você receberá insights sobre o destino. Esses insights deixarão mais evidente o que é bom, ruim ou tolerável para seus objetivos e duração.
Desenvolvimento de recursos, melhorias de código, upgrades de hardware e outras tarefas de manutenção podem ajudar a tornar seu serviço mais confiável. A capacidade de fazer essas mudanças pequenas e frequentes ajuda a oferecer recursos mais rapidamente e com maior qualidade. No entanto, a taxa com que seu serviço muda também afeta a confiabilidade. As metas de confiabilidade alcançáveis definem um ritmo e um escopo de mudança (chamada de velocidade do recurso) que os clientes podem tolerar e aproveitar.
Se você não puder medir a experiência do cliente e definir metas com base nela, recorra a fontes externas e à análise de comparativos de mercado. Se não houver concorrência comparável, avalie a experiência do cliente, mesmo que ainda não seja possível definir metas. Com o tempo, você pode atingir um limite razoável de satisfação do cliente. Esse limite é seu SLO.
Entender todo o sistema
Seu serviço pode existir em uma longa linha de serviços com processamento upstream e downstream. A avaliação do desempenho de um sistema distribuído (serviço a serviço) não reflete com precisão a experiência do seu cliente e pode causar uma interpretação excessivamente sensível.
Em vez disso, meça o desempenho em relação ao SLO no front-end do processo para entender a experiência dos usuários. O usuário não está preocupado com uma falha de componente que faça com que uma consulta falhe se ela for repetida de maneira automática e com sucesso.
Se houver serviços internos compartilhados, cada serviço poderá medir o desempenho separadamente em relação ao SLO associado, com serviços voltados ao usuário agindo como clientes. Processe esses SLOs separadamente.
É possível criar um serviço altamente disponível (por exemplo, 99,99%) sobre um serviço menos disponível (por exemplo, 99,9%) usando fatores de resiliência, como novas tentativas inteligentes, armazenamento em cache e enfileiramento. Qualquer pessoa com um conhecimento prático de estatística deve ser capaz de ler e entender seu SLO sem entender o serviço subjacente ou o layout organizacional, conforme descrito na lei de Conway.
Escolher os SLOs corretos
Há uma tensão natural entre a velocidade de desenvolvimento do produto e a estabilidade operacional. Quanto mais você alterar seu sistema, maior será a probabilidade de ele falhar. As ferramentas de monitoramento e observabilidade são essenciais para a estabilidade operacional à medida que você aumenta a velocidade do recurso. Elas são conhecidas como ferramentas de Gerenciamento do desempenho de aplicativos (APM) e também podem ser usadas para definir SLOs.
Quando definido corretamente, um SLO ajuda as equipes a tomar decisões operacionais baseadas em dados que aumentam a velocidade de desenvolvimento sem sacrificar a estabilidade. O SLO também pode alinhar equipes de desenvolvimento e operações em torno de um único objetivo acordado. Compartilhar um único objetivo diminui a tensão natural mencionada anteriormente: a meta da equipe de desenvolvimento de criar e iterar produtos e a meta da equipe de operações de manter a integridade do sistema.
Use este e outros documentos de confiabilidade no framework da arquitetura para entender e desenvolver SLOs. Depois de ler e entender esses artigos, vá para informações mais detalhadas sobre SLOs (e outras práticas de SRE) no The SRE Book e Apostila de SRE.
Use SLOs internos rigorosos
Recomenda-se ter SLOs internos mais rigorosos do que SLAs externos. Como as violações do SLA tendem a exigir a emissão de um crédito financeiro ou reembolso de clientes, é recomendável resolver os problemas antes que eles tenham impacto financeiro.
Recomendamos o uso desses SLOs internos mais rigorosos, com um processo retrospectivo sem apontar culpados e uma análise de incidentes. Para mais informações, consulte Criar um processo colaborativo de gerenciamento de incidentes na categoria de confiabilidade do Architecture Center.
Melhore os SLOs de modo iterativo
Os SLOs não devem ser definidos de maneira definitiva. Revise os SLOs periodicamente (trimestral ou pelo menos uma vez por ano) e confirme se eles refletem com precisão a satisfação do usuário e se correlacionam com interrupções do serviço. Garanta que elas cubram as necessidades comerciais atuais e todas as novas jornadas ideais do usuário. Revise e aumente seus SLOs conforme necessário após essas revisões periódicas.
Use erros de orçamento para gerenciar a velocidade de desenvolvimento
As margens de erro mostram se o serviço é mais ou menos confiável do que o necessário para uma janela de tempo específica. Os erros de orçamento são calculados como 100%: SLO durante um período, como 30 dias.
Quando houver capacidade restante no erro de orçamento, será possível continuar a lançar melhorias ou novos recursos rapidamente. Quando a margem de erro estiver próxima de zero, diminua ou congele as alterações de serviço e invista recursos de engenharia para melhorar os recursos de confiabilidade.
O Google Cloud Observability inclui o monitoramento de SLO para minimizar o esforço de configurar SLOs e margens de erro. O pacote de operações inclui uma interface gráfica do usuário para ajudá-lo a configurar SLOs manualmente, uma API para configuração programática de SLOs e painéis integrados para rastrear a taxa de gravação de erros de orçamento. Para mais informações, consulte Como criar um SLO.
Resumo das recomendações de SLO
- Defina e avalie SLIs voltados ao cliente, como disponibilidade ou latência do serviço.
- Defina um orçamento de erro centrado no cliente que seja mais rigoroso do que o SLA externo. Incluir consequências para violações como o congelamento da produção.
- Configure SLIs de latência para capturar valores atípicos, como 90o ou 99o percentil, para detectar as respostas mais lentas.
- Analise os SLOs pelo menos uma vez por ano e confirme se eles estão bem relacionados à satisfação do usuário e às interrupções de serviço.
A seguir
- Leia Escolher seus SLIs.
- Acesse Coursera - SRE: Measure and Managing Reliability.
- Saiba mais sobre SLOs nos SLOs do capítulo do livro SRE e na Pasta de trabalho do SRE para implementar SLOs.
- Explore outras categorias no Framework da arquitetura.
- Para mais arquiteturas de referência, diagramas e práticas recomendadas, confira a Central de arquitetura do Cloud.