Mitigando interrupções de software: mudando a observabilidade à esquerda

A crescente adoção do desenvolvimento de aplicativos em contêineres e nativos da nuvem melhorou significativamente a agilidade e as práticas de DevOps, bem como ofertas inovadoras e escaláveis. As organizações podem implantar rapidamente seu software em produção e reduzir dependências internas de software entre serviços.

Este é o resultado positivo e as organizações não estão a abrandar; eles procuram aprimorar essas práticas por meio da adoção de GenAI e práticas de engenharia de plataforma.

Os resultados menos positivos destas tecnologias complexas são muitas vezes a falta de controlo sobre os serviços essenciais e centrados nos negócios desde o momento em que são implantados na produção e utilizados pelos clientes.

Há uma desconexão evidente entre os desenvolvedores e seus aplicativos ativos em produção, devido aos processos e ferramentas atuais, como desempenho e monitoramento de aplicativos (APM) e outras soluções gerais de observabilidade. Eles atendem principalmente a personas de operações e são, por natureza, mais lentos para aproveitar as vantagens quando ocorre uma interrupção. Há uma necessidade imperiosa de capacitar os desenvolvedores para que assumam o controle de seus aplicativos em todos os ambientes, e isso só pode ser alcançado transferindo a observabilidade para os desenvolvedores.

Causas raiz mais comuns para interrupções de software

Os dados do Lightrun, juntamente com a pesquisa recente da Microsoft, destacam as principais causas de interrupções de software e problemas críticos P1-P2 encontrados por empresas e grupos de desenvolvimento de aplicativos modernos. A lista abaixo é priorizada da causa raiz mais alta e mais comum para a mais baixa:

• Erros de código
• Falha de dependência
• Problemas de infraestrutura
• Erro de implantação
• Bug de configuração
• Falha no banco de dados/rede
• Falha de autorização
• Outro

Cada uma das causas raiz de incidentes de produção acima mencionadas exige medidas de mitigação específicas, que vão desde a reversão de software até ajustes de infraestrutura e correções de configuração. É crucial compreender o impacto significativo que estes incidentes críticos têm nas operações comerciais e na reputação da marca.

Por exemplo, consideremos a recente interrupção sofrida pela Sainsbury’s, a segunda maior cadeia de supermercados do Reino Unido. Este incidente relatado não apenas perturbou a experiência do cliente, mas também causou um duro golpe nas receitas dos negócios. Da mesma forma, uma instância separada, num segmento de mercado diferente, viu o website e a aplicação da State Farm Insurance paralisados ​​durante vários dias, prejudicando gravemente a sua capacidade de servir os clientes.

É essencial reconhecer que a resolução de cada uma destas interrupções é um processo demorado e dispendioso, agravado pelas limitações das ferramentas APM atuais e pela abordagem desconectada entre as equipas de desenvolvimento e operações. De acordo com a pesquisa da Microsoft, as interrupções resultantes de bugs de código incorrem no maior tempo médio para resolução (MTTR), tempo para mitigar (TTM) e tempo para detecção (TTD).

Mudando a observabilidade do desenvolvedor para a esquerda

O conceito fundamental envolve a integração da observabilidade no início do ciclo de vida de desenvolvimento de software (SDLC), mas o que isso significa em termos práticos?

• Acessando dados ao vivo em tempo real: As metodologias de desenvolvimento existentes muitas vezes tratam a observabilidade como um procedimento estático e reativo. Idealmente, os desenvolvedores deveriam ter acesso em tempo real aos dados de observabilidade como parte de um processo de desenvolvimento moderno. Nas implementações modernas de engenharia de plataforma e na configuração de uma plataforma de desenvolvimento interno (IDP), uma plataforma de observabilidade será parte integrante da pilha de ferramentas dos desenvolvedores.
• Dados contextualizados: Embora as ferramentas tradicionais de observabilidade sejam excelentes na agregação e indexação de dados, elas são principalmente adaptadas aos requisitos das equipes de operações. A maioria das soluções de observabilidade apresenta painéis complexos inundados com informações que abrangem todo o sistema. No entanto, os desenvolvedores normalmente exigem dados específicos para o código em que estão trabalhando atualmente. Ao correlacionar e restringir logs, métricas e rastreamentos dentro do contexto do código dos desenvolvedores, informações essenciais podem ser reveladas com eficiência.
• Abordagem centrada no desenvolvedor: Da mesma forma, as ferramentas de observabilidade devem estar alinhadas com o fluxo de trabalho natural dos desenvolvedores. Em vez de exigir que os desenvolvedores mudem para outro painel, os dados devem ser apresentados em uma guia. Esta guia deve ser integrada diretamente ao seu IDE. Embora pareça algo insignificante, minimizar a alternância de contexto é crucial para manter a produtividade e simplificar as operações.
• Instrumentação dinâmica: Finalmente, os desenvolvedores devem possuir a capacidade de incorporar dinamicamente novos recursos de observabilidade em tempo real, sem a necessidade de modificações no código ou sem suportar o ciclo típico de construção e implantação. Isso não apenas economiza tempo em termos de implantação de código, mas também reduz custos, já que os desenvolvedores não são mais obrigados a adicionar instrumentação estática preventivamente.

As vantagens decorrentes da mudança para a esquerda na observabilidade do desenvolvedor podem ser classificadas em três pilares principais:

1. MTTR reduzido (tempo médio para resolução):

• Proteção reforçada de receitas e mitigação de riscos
• Maior eficiência no gerenciamento de incidentes
• Diminuição da ocorrência de incidentes críticos P1

2. Maior produtividade do desenvolvedor:

• Diminuição substancial no tempo de depuração dos desenvolvedores

3. Redução dos custos globais de observabilidade:

• Gastos reduzidos com logs estáticos
• Menor custo total de propriedade (TCO) para ferramentas APM

Observações finais

A adoção da mudança de observabilidade para a esquerda representa uma tendência emergente entre equipes de engenharia de software de alto desempenho. Reconhecendo as limitações da observabilidade estática e reativa, estas equipas compreenderam a natureza insustentável de simplesmente registar mais dados e adiar a resolução.

Ao integrar a observabilidade antecipadamente ao SDLC, essas equipes de alto desempenho estão produzindo não apenas códigos mais limpos e eficientes, mas também aliviando os desafios operacionais associados à depuração, à resposta a incidentes e ao gerenciamento de um volume esmagador de métricas de observabilidade. Resolver interrupções como as mencionadas acima em tempo hábil – em minutos e apenas horas, em vez de dias – ou mesmo prevenir tais problemas em primeiro lugar, são benefícios claros desta prática.

A postagem Mitigando interrupções de software: mudando a observabilidade para a esquerda apareceu pela primeira vez em The New Stack.