Objetivos de nível de serviço (SLOs) são um conceito familiar para profissionais de DevOps e engenheiros de confiabilidade de site (SREs), pois são cruciais para monitorar a saúde do sistema e soar o alarme quando algo está errado. Embora os SLOs tenham sido tradicionalmente o domínio da engenharia de backend, seu valor é óbvio ao ajudar equipes móveis a garantir aplicativos de alto desempenho e tomar decisões de priorização entre o trabalho de recursos e confiabilidade.
Para muitas organizações, no entanto, os SLOs móveis são um empreendimento novo e, às vezes, intimidador. Mas eles não precisam ser. Qualquer equipe pode adotar SLOs efetivamente como parte de sua estratégia de observabilidade móvel seguindo algumas práticas recomendadas. Aqui estão cinco dicas para projetar SLOs móveis altamente eficazes.
1. Pense em termos de experiências de usuário de ponta a ponta
Para aqueles que vêm de um background em DevOps, pode ser tentador traduzir conceitos familiares sobre disponibilidade de endpoint, latência, etc., diretamente para dispositivos móveis. Mas você terá que mudar seu pensamento ao criar SLOs para dispositivos móveis para analisar as experiências do usuário final em sua totalidade.
Você vai querer criar seus SLOs em torno de um fluxo ou atividade de ponta a ponta que você está tentando otimizar, como um processo de login ou pesquisa, em vez de nos componentes técnicos individuais que fazem o fluxo acontecer — como renderizações de tela, chamadas de API, etc. As ações técnicas são eventos dentro do seu SLO que, com as ferramentas certas, podem ser isolados quando for hora de solucionar um problema, mas não devem ser o foco final.
2. Meça os números de impacto do usuário, não apenas os incidentes
Eventos que acontecem em dispositivos móveis podem ter um nível inesperado de impacto em sua base de usuários, tanto acima quanto abaixo do que você pode antecipar. Isso ocorre porque os dados móveis são amplamente moldados pelo conceito de usuários únicos e sessões únicas, enquanto os dados de backend não são. Se, por exemplo, você notar 1.000 instâncias de um certo tipo de falha, como saberia como essas instâncias são distribuídas entre seus usuários? 1.000 usuários únicos experimentaram a falha uma vez, ou um usuário infeliz experimentou a falha 1.000 vezes?
Se você estiver medindo apenas contagens de incidentes, é impossível saber isso. Como resultado, você pode estar disparando o alarme para violações de SLO de forma muito estrita ou muito frouxa. Para entender verdadeiramente como você deve priorizar sua resposta a violações de SLO, pense em termos de números de usuários e números de eventos.
3. Identifique os fluxos de usuários que têm o maior impacto
Em última análise, o propósito dos SLOs é priorizar e direcionar o trabalho técnico para que ele sirva ao seu negócio. É por isso que, quando você considera quais SLOs construir para dispositivos móveis, é crucial identificar os fluxos de usuários que têm o maior impacto no seu negócio para que haja um entendimento claro sobre o motivo pelo qual uma violação do SLO forçará sua equipe a priorizar esse problema em detrimento de outros trabalhos.
Comece com os indicadores mais diretos e óbvios do impacto comercial. Por exemplo, seus clientes não conseguirem finalizar a compra no aplicativo afetará diretamente suas vendas. Um problema com notificações push, por outro lado, pode contribuir para um declínio gradual na receita, mas está mais para trás no funil de vendas que uma interrupção com essa funcionalidade não deve exigir que seus engenheiros larguem tudo para consertá-lo.
4. Evite amostragem
Um dos grandes desafios com dados móveis é que há muitos deles. Você pode estar acostumado a amostrar dados que alimentam SLOs de backend para reduzir custos de processamento e armazenamento de dados. Isso faz sentido: afinal, você está lidando com um ambiente previsível composto por um número limitado de tipos de dispositivos e outras variáveis razoavelmente estáveis.
Mas quando se trata de dispositivos móveis, essas suposições não se sustentam. Há permutações quase infinitas de tipos de dispositivos, sistemas operacionais, versões de aplicativos, condições de rede, infraestrutura local, etc. Isso significa que a amostragem dos dados que você alimenta em SLOs quase garantirá que você esteja perdendo visibilidade essencial.
5. Defina a população com a qual você realmente se importa
Como você analisa uma montanha de dados de alta cardinalidade se não estiver fazendo amostragem? E o que isso significa, falando de forma prática, para seus SLOs móveis? Esse atoleiro pode ser amplamente resolvido com hiperfoco nas populações com as quais você realmente se importa, e fazer isso toca na sugestão que fizemos na Dica 2 sobre objetivos de negócios.
Considere, dentre todas as pessoas que usam seu aplicativo, quais grupos são responsáveis pela maior parte da receita. Dependendo do seu modelo de negócio, isso pode significar clientes pagantes versus usuários de teste gratuito. Ou pode significar pessoas que estão na versão mais recente do seu aplicativo em vez de retardatários. Ou pode até ser aqueles que vivem em certos mercados geográficos que estão gerando 80% das compras no seu aplicativo.
O ponto é que é impossível se esforçar para ter uma experiência perfeita para todos os usuários o tempo todo: você gastaria todo o seu tempo em confiabilidade e nada em inovação. No entanto, se você puder isolar certos públicos que são críticos para os negócios, poderá refinar seus SLOs móveis e seus protocolos de erro resultantes para limitar a interrupção de outros trabalhos de engenharia importantes quando a confiabilidade se tornar um problema.
Iterar e aprender continuamente
Há muito mais em jogo ao trabalhar com sua estratégia de SLO, pois cada aplicativo é único quando se trata de sua base de usuários, metas de produto e estrutura de receita. As dicas acima são aplicáveis em quase todos os casos, mas você deve sempre considerar suas necessidades exclusivas de clientes e negócios e mapear as medições adequadamente.
Uma das grandes coisas sobre SLOs é a capacidade de iterar, especialmente para dispositivos móveis, onde ainda não há "padrões universais" ou expectativas rigorosas. Não tenha medo de começar a medir e iterar repetidamente, à medida que você entende melhor quais são os benchmarks de desempenho do seu aplicativo e quais níveis de falha seus usuários estão realisticamente dispostos a tolerar.
Manter um bom desempenho do aplicativo é um esforço de longo prazo, então trate os SLOs como uma ferramenta para orientá-lo.
