Como a observabilidade ajuda na confiabilidade

Tornar nossos sistemas observáveis não os torna automaticamente mais confiáveis, mas nos dá os insights necessários para melhorar sua confiabilidade. Eles informam nossas decisões sobre como lidar com as falhas e ajudam a medir o impacto que nossos esforços têm na disponibilidade, tempo de atividade e desempenho. Isso inclui:

• Medir o custo do tempo de inatividade e mostrar como uma redução nos incidentes corresponde ao aumento da receita.
• Acompanhamento de melhorias na disponibilidade, desempenho e estabilidade do sistema em uma iniciativa de confiabilidade.
• Acompanhar a quantidade de tempo que as equipes de engenharia gastam solucionando problemas, depurando e corrigindo sistemas e os custos associados. Isso inclui os custos de oportunidade perdidos de desviar recursos de análise de atividades geradoras de receita, como criar novos produtos e recursos.

Em seguida, vamos ver como podemos usar dados de observabilidade para começar a melhorar a confiabilidade.

Defina suas prioridades e objetivos

Ao iniciar uma prática de observabilidade, a tentação é coletar o máximo de dados possível. Isso pode levar rapidamente à sobrecarga de informações e inundar seus analistas com painéis e alertas irrelevantes. Muitas equipes usam os quatro sinais de ouro (latência, tráfego, erros e saturação) popularizados pelo Google, mas o problema é que cada equipe tem requisitos e expectativas diferentes sobre como seus sistemas devem operar.

A maneira de usar a observabilidade de forma eficaz é se concentrar no que é importante para sua organização. Suas métricas mais importantes são aquelas que capturam a experiência do cliente. Por exemplo, se você é um varejista online, as qualidades mais importantes de seus sistemas podem ser:

• Alta disponibilidade de serviços essenciais em seu aplicativo, como front-end do site, serviço de checkout ou o processamento de pagamentos. Se algum desses serviços falhar, todo o aplicativo estará em risco.
• Alta escalabilidade, especialmente durante períodos de pico de tráfego, como Black Friday e Cyber Monday. A última coisa que os clientes querem ver durante um evento de compras é uma página de erro ou uma tela de carregamento.
• Baixo tempo de resposta para serviços voltados para o usuário, como seu front-end. Quanto menor o tempo de resposta, melhor o desempenho do serviço e os clientes mais satisfeitos.

Defina os níveis de serviço

Depois de identificar as métricas mais importantes, precisamos definir limites aceitáveis. Por exemplo, como nosso site é um serviço voltado para o cliente que fornece funcionalidades críticas, queremos ter um nível muito alto de disponibilidade. Nossos clientes também esperam um alto nível de disponibilidade: se nosso site estiver indisponível ou lento, eles provavelmente irão para um concorrente. Para criar confiança com nossos clientes, precisamos definir expectativas para o nível de serviço que eles podem esperar ao usar nossos serviços.

Isso geralmente é feito usando acordos de nível de serviço (SLAs), que são contratos entre um provedor de serviços e um usuário final prometendo uma qualidade mínima de serviço, geralmente na forma de disponibilidade ou tempo de atividade. Se um serviço não cumprir seu SLA, seus usuários podem ter direito a descontos ou reembolsos, criando um incentivo financeiro para melhorar a confiabilidade.

Para criar um SLA, as organizações primeiro determinam a experiência que desejam fornecer aos clientes e, em seguida, identificam as métricas que refletem com precisão essa experiência. Isso geralmente é um esforço conjunto entre as equipes de Produto e Infraestrutura: o Produto define o nível de serviço esperado e a Infraestrutura identifica as métricas a serem medidas e seus intervalos aceitáveis. Essas métricas são indicadores de nível de serviço (SLIs), e os intervalos aceitáveis são objetivos de nível de serviço (SLO).

Em sistemas distribuídos, os SLAs são medidas de disponibilidade ao longo de um período de tempo. Por exemplo, 99% significa que um sistema não pode ficar indisponível por mais de 3,65 dias por ano. 99,9% deixam apenas 8,77 horas de inatividade por ano. Empresas voltadas para o futuro buscam alta disponibilidade (HA), o que significa 99,99% ou 52,6 minutos de inatividade por ano. Isso pode parecer um nível alto, mas considere que, para um varejista on-line, um segundo de inatividade pode significar milhares de reais em vendas perdidas.

Valide a aderência aos seus níveis de serviço

Com um nível de serviço alvo estabelecido, devemos validar continuamente se nossos sistemas estão aderindo às nossas metas. Começamos instrumentando nossos sistemas para os logs, métricas e rastreamentos que determinamos serem necessários para nossos objetivos de negócios. Ferramentas como Amazon CloudWatch, Grafana, Prometheus, Datadog e New Relic ajudam a coletar e consolidar esses dados em um sistema que nossos analistas podem usar facilmente para monitorar o comportamento do sistema. Podemos criar painéis que não apenas mostram o desempenho dos sistemas, mas também o quão bem eles estão em relação aos objetivos de níveis de serviço (SLOs). Se eles correm o risco de ficarem indisponíveis, monitorando e enviando alertas automatizados notificarão os analistas de infraestrutura e equipes de resposta a incidentes. Automatizar o máximo possível garante que nossas equipes sejam rapidamente notificadas em caso de problemas.

Agora que temos informações sobre nossos sistemas e podemos detectar quando algo dá errado, podemos começar a nos concentrar em onde podemos melhorar. Começamos procurando áreas em que não estamos atendendo (ou apenas cumprindo) nossos SLOs e consideramos como podemos projetar nossos sistemas para lidar com esse risco. Depois de implantar uma correção, continuar a instrumentar e monitorar nossos sistemas garante que a correção foi resolvida. O uso desse ciclo de feedback nos permite continuar melhorando nossos sistemas até atingirmos nossas metas, e a automação nos ajuda a manter esse nível de aderência.

Valide suas práticas de observabilidade e confiabilidade usando a Engenharia do Caos

Apenas ter uma prática de observabilidade em vigor não significa que estamos livres. Precisamos validar que estamos rastreando as métricas certas, que nossos painéis estão relatando informações relevantes e que nossos alertas são garantidos para notificar as pessoas certas no momento certo.

Embora pudéssemos esperar pela ocorrência de um incidente de produção, essa é uma abordagem reativa e nos expõe a riscos. Em vez disso, e se pudéssemos testar proativamente nossa prática de observabilidade simulando condições de produção? Por exemplo, se a capacidade de resposta do aplicativo for um de nossos objetivos de níveis de serviço, devemos garantir que nossa ferramenta de monitoramento possa detectar alterações na latência e no tempo de resposta. Mas como fazer isso sem colocar nossos sistemas em risco? É aqui que a Engenharia do Caos ajuda.

A Engenharia do Caos é a prática de injetar deliberadamente falhas em um sistema, observando como o sistema responde e usando nossas observações para melhorar sua confiabilidade. A palavra-chave aqui é observar: sem visibilidade, não podemos determinar com precisão como as falhas afetam nossos sistemas, nossos SLOs e a experiência do cliente. A observabilidade nos ajuda a medir o impacto das falhas – e o impacto de nossas correções – de maneira significativa e objetiva.

Combinar a Engenharia do Caos com a observabilidade traz muitos benefícios, incluindo:

• Ajudar a estabelecer um processo de gerenciamento de incidentes. Isso inclui definir os níveis de gravidade do incidente, rastrear o tempo médio de detecção (TMD) e o tempo médio de resolução (TMR), abordar e mitigar as falhas e preparar as equipes para responder a incidentes.
• Ajudar as equipes a alcançar seus mais alto níveis de confiabilidade, encontrando lacunas no monitoramento, simulando possíveis falhas e ajudando a testar completamente as alterações nos sistemas antes da implantação na produção.
• Usando dados de observabilidade para guiar diretamente o design de experimentos de caos, para que possamos testar nossos sistemas de forma mais completa.

Para resumir…

• A observabilidade é uma medida dos comportamentos internos de um sistema com base em suas saídas.
  
  • Os dados de observabilidade geralmente são categorizados em três tipos (chamados de pilares): logs, métricas e rastreamentos.
• O monitoramento é o processo de coleta e análise contínua de dados sobre um sistema para mostrar o desempenho dele ao longo do tempo. O monitoramento complementa a observabilidade.
  
  • Alertas são notificações automáticas geradas por um sistema de monitoramento quando uma determinada condição é atendida, como um valor medido que excede um determinado limite.
• As equipes usam dados de observabilidade para definir objetivos de desempenho e disponibilidade do sistema, rastrear a aderência a esses objetivos e monitorar eventos como incidentes.
• A observabilidade nos ajuda a quantificar e rastrear mudanças nos sistemas ao longo do tempo, incluindo melhorias de confiabilidade.
• A Engenharia do Caos ajuda a validar sua prática de observabilidade simulando condições degradadas do sistema. Isso ajuda a configurar painéis, definir alertas e garantir que suas equipes acompanhem as métricas mais relevantes.