A realidade de um engenheiro de rede (com macarrão e... sal?)
Recentemente, ao discutir vários incidentes com engenheiros, notei um padrão interessante.
Nessas discussões, invariavelmente surge a questão da “causa raiz”. Leitores fiéis provavelmente sabem que tenho em . Em muitas organizações, a análise de incidentes baseia-se inteiramente neste conceito. Eles usam diferentes técnicas para identificar relações de causa e efeito, como . Esses métodos assumem a chamada “linearidade dos acontecimentos” como um dogma indiscutível.
Quando você desafia essa ideia e aponta que a linearidade é tranquilizadoramente enganosa em sistemas complexos, nasce uma discussão fascinante. Os disputantes insistem veementemente que só o conhecimento da “causa raiz” nos permite compreender o que está a acontecer.
Percebi um padrão interessante: desenvolvedores e devops reagem de maneira diferente a essa ideia. Na minha experiência, é mais provável que os desenvolvedores argumentem que a causa raiz é importante e que as relações de causa e efeito sempre podem ser estabelecidas nos eventos. Por outro lado, o DevOps concorda com mais frequência que um mundo complexo nem sempre obedece à linearidade.
Sempre me perguntei por que isso acontece? O que faz programadores criticarem a ideia “a causa raiz é um mito” assim? Como um sistema imunológico que reconhece um agente estranho. Por que eles reagem dessa maneira, enquanto os devops bastante inclinado considerar esta ideia?
Não tenho certeza, mas tenho algumas idéias sobre isso. Relaciona-se aos diferentes contextos em que esses profissionais realizam seu trabalho diário.
Os desenvolvedores geralmente trabalham com ferramentas determinísticas. É claro que compiladores, linkers e sistemas operacionais são todos sistemas complexos, mas estamos acostumados com o fato de que eles fornecem resultados determinísticos e os imaginamos como determinísticos: se fornecermos os mesmos dados de entrada, geralmente esperamos a mesma saída desses sistemas. E se houver um problema com a saída (“bug”), os desenvolvedores o resolvem analisando os dados de entrada (do usuário ou de um conjunto de ferramentas durante o processo de desenvolvimento). Eles procuram um “erro” e depois alteram os dados de entrada. Isso corrige o "bug".
Suposição básica do desenvolvimento de software: os mesmos dados de entrada produzem de forma confiável e determinística a mesma saída.
Na verdade, um resultado não determinístico é considerado um bug: se a saída inesperada ou errada não for reproduzida, então os desenvolvedores tendem a estender a investigação para outras partes da pilha (sistema operacional, rede, etc.) que também se comportam de maneira mais ou menos deterministicamente, produzindo o mesmo resultado com os mesmos dados de entrada... e se não for esse o caso, então isso ainda é considerado um bug. Agora é um bug do sistema operacional ou da rede.
Em qualquer caso, o determinismo é uma suposição básica, quase dada como certa, para grande parte do trabalho que os programadores realizam.
Mas para qualquer cara de devops que passou o dia acumulando hardware ou descobrindo uma API de nuvem, a ideia de um mundo completamente determinístico (desde que seja possível mapear todas as entradas!) é, na melhor das hipóteses, um conceito passageiro. Mesmo se você deixar isso de lado , engenheiros experientes viram as coisas mais estranhas deste mundo. Eles sabem disso , sem mencionar os milhões de outros fatores ambientais.
Portanto, é mais fácil para engenheiros experientes duvidarem que todos os incidentes tenham uma única causa raiz, e técnicas como os “Cinco Porquês” levarão corretamente (e repetidamente!) a essa causa raiz. Na verdade, isto contradiz a sua própria experiência, onde as peças do puzzle não se encaixam tão bem na prática. Portanto, aceitam essa ideia com mais facilidade.
É claro que não estou dizendo que os desenvolvedores sejam ingênuos, estúpidos ou incapazes de entender como a linearidade pode ser enganosa.
Mas parece-me que uma reacção comum dos promotores nestes debates tem muitas vezes a ver com o facto de o conceito de determinismo serve-os bem no geral no trabalho diário. Eles não encontram o não-determinismo com tanta frequência quanto os engenheiros precisam pegar os gatos de Schrödinger em sua infraestrutura.
Isto pode não explicar completamente as reações observadas no revelador, mas é um poderoso lembrete de que as nossas reações são uma mistura complexa de muitos fatores.
É importante lembrar essa complexidade, quer estejamos lidando com um único incidente, colaborando em um pipeline de entrega de software ou tentando compreender o mundo mais amplo.
Fonte: habr.com