BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Notícias Investigando os quase-acidentes para evitar desastres: Perguntas e Respostas no QCon Londres

Investigando os quase-acidentes para evitar desastres: Perguntas e Respostas no QCon Londres

Favoritos

Investigar os quase-acidentes reunindo dados empíricos e explorando qualquer coisa que possa parecer errada ou um pouco estranha pode ajudar a prevenir desastres, disse Ed Holland, gerente de desenvolvimento de software da Metaswitch Networks. No QCon Londres 2019, Ed deu uma palestra sobre como evitar ser um péssimo exemplo ao investigar os quase-acidentes.

"Todos estamos envolvidos em problemas e nos certificando de que nunca aconteçam novamente, da mesma maneira", disse Holland, "mas precisamos investigar também os quase-acidentes. A fim de investigar os que precisamos para garantir o produto, é necessário monitorar essas estatísticas e investigar tudo o que aparenta não estar correto" comentou Holland.

Holland mencionou que normalmente as anomalias eram simplesmente comportamentos que não eram esperados, porém, eram completamente legítimas e aumentavam a compreensão de como o produto estava sendo usado. Um grande número de casos foi o resultado de erros de configurações ou erros do produto.

Holland mostrou alguns exemplos de erros que foram investigados e mostraram ter pouca ou nenhuma visibilidade ou ainda impactos imediatos para o cliente, entretanto ao serem corrigidos foram evitados problemas gravíssimos posteriormente.

Péssimo balanceamento de carga: em alguns nós, a carga variava significativamente. O rastreamento foi simples, usando os gráficos estatísticos, onde foi mostrado um comportamento abaixo do ideal em equipamentos de terceiros, incluindo a redefinição do cache DNS a cada oito horas. Ao corrigir este erro, evitamos a sobrecarga prematura.

Picos de pausa para backup: nossas estatísticas mostraram picos estranhos em log de erros depois que lidamos com uma exceção e inserimos um comportamento de pausa para backup. Depois de analisar os diagnósticos do fluxo de chamadas, encontramos algumas chamadas (legitimamente) sendo repetidas para nó. Isso resultou em uma correção de código e, apesar da perda no serviço nesse caso fosse pequena, a correção teve um impacto mais amplo, atingindo o processamento de atualização, por exemplo.

Modelagem de desempenho: Usando a regressão linear em campos de dados, criamos um modelo de carregamento de dados de várias operações. Aplicando esse modelo aos diferentes sites, pudemos garantir que um equipamento OpenStack estava mal configurado em comparação aos outros.

Toda anomalia é interessante e conta uma história. Muitas vezes a história é simples: o cliente fez algo que foi casual, mas não esperávamos este tipo de comportamento pelo sistema, disse Holland. Mas normalmente nos é mostrado que há um bug na configuração do sistema ou no próprio software.

A chave de tudo é a proatividade ao reunir e analisar detalhadamente os dados anômalos que retornam do sistema. Isso costumava ser uma tarefa maçante, mas recentemente tornou-se muito mais fácil de ser implementado usando técnicas modernas de instrumentação, disse Holland. Investigar tudo, que é definido como investigar "eventos não dinâmicos", dá uma profunda compreensão da forma como o seu produto se comporta no ambiente produtivo. Essa compreensão significa que, em vez de esperar por um desastre e, em seguida, investigar e corrigir, se tem uma chance muito maior de prever e corrigir os problemas antes que ocorram. Além disso, como essa abordagem se baseia na realidade, é uma maneira mais econômica de obter um produto estável em comparação a testes laboratoriais adicionais, salientou Holland.

O InfoQ entrevistou Ed Holland sobre o que os levou a decidir investigar quase-acidentes, coletar dados confiáveis e como as organizações podem se preparar para investigar estes casos.

InfoQ: O que fez você decidir começar a investigar os quase-acidentes?

Ed Holland: Nosso cliente estava planejando migrar 10 milhões de assinantes de dispositivos móveis em um espaço de um mês mais ou menos.

Mesmo terminando as análises de risco, testes adicionais e correções, ainda não parecia que tínhamos feito o suficiente.

Este aumento de uso estavam muito além do que havíamos tratado antes e devido a isso, precisávamos de informações que pudéssemos usar para evitar problemas antes que ocorressem. Isso significava investigar qualquer coisa, sendo problema ou não.

InfoQ: O que pode ser feito para se coletar dados confiáveis o suficiente?

Holland: Coletar, armazenar e visualizar dados de forma confiável e em grande escala atualmente é bem simples, afinal, temos excelentes soluções de código aberto, como o influxdb, prometheus e grafana. O problema é reduzido à medida das alterações no código do produto. Em um mundo perfeito, eu teria estatísticas para literalmente tudo, analisando e contabilizando cada solicitação e resposta (por códigos de erro, por exemplo) e também detalhando o funcionamento interno dos algoritmos (como o algoritmo de sobrecarga).

InfoQ: Como as organizações podem se preparar para investigar os quase-acidentes?

Holland: Existem duas coisas que são necessárias para as organizações investigarem os quase-acidentes. Uma delas é, estarem preparadas para investir pesadamente na instrumentação do código do produto e nos componentes periféricos que permitem o armazenamento e a visualização dos dados. A outra é, uma mudança de mentalidade da investigação reativa de tickets levantados pelos clientes, para uma investigação proativa feita por alguém com conhecimento profundo sobre o produto e que consegue identificar as coisas que não estão corretas.

Essas mudanças precisam de um pouco de fé por parte dos gerentes de orçamento. Não há um ganho imediato óbvio, como ocorre com a resolução de tickets, na implementação de recursos ou no desenvolvimento de investimentos em infraestrutura. Em vez disso, o pedido é de financiamento para obter um melhor entendimento do produto e do seu uso em produção, a fim de reduzir os custos futuros.

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

BT