Programadores da Schrodinger, devops e gatos

A realidade de um engenheiro de rede (com macarrão e ... sal?)

Recentemente, discutindo vários incidentes com engenheiros, notei um padrão interessante.

Nestas discussões, a questão da "causa raiz" invariavelmente surge. Os leitores fiéis provavelmente saberão que tenho alguns pensamentos sobre isso . Em muitas organizações, a análise de incidentes se baseia inteiramente nesse conceito. Eles usam técnicas diferentes para identificar relacionamentos de causa e efeito, como o Five Why . Esses métodos sugerem a chamada "linearidade dos eventos" como um dogma inegável.

Quando você questiona essa idéia e ressalta que, em sistemas complexos, a linearidade é tranquilizadora e tranquilizadora, nasce uma discussão fascinante. Os debatedores insistem apaixonadamente que apenas o conhecimento da "causa raiz" nos permite entender o que está acontecendo.

Percebi um padrão interessante: desenvolvedores e desenvolvedores reagem de maneira diferente a essa idéia. Na minha experiência, os desenvolvedores costumam argumentar que a causa raiz é importante e que os relacionamentos de causa e efeito sempre podem ser estabelecidos em eventos. Por outro lado, os devotos concordam com mais frequência que um mundo complexo nem sempre está sujeito à linearidade.

Eu sempre me perguntei por que isso? O que faz os programadores criticarem a idéia de "causa raiz - mito"? Como um sistema imunológico que reconhece um agente estranho. Por que eles reagem dessa maneira, enquanto os devops têm mais probabilidade de considerar essa idéia?

Não tenho muita certeza, mas há uma consideração a esse respeito. Está associado a vários contextos em que esses profissionais realizam o trabalho diário.

Os desenvolvedores geralmente trabalham com ferramentas determinísticas. Obviamente, compiladores, linkers, sistemas operacionais são todos sistemas complexos, mas estamos acostumados a fornecer um resultado determinístico e os apresentamos como determinísticos: se fornecermos os mesmos dados de entrada, normalmente esperamos a mesma saída desses sistemas . E se houver um problema ("bug"), os desenvolvedores o resolverão analisando os dados de entrada (do usuário ou de um conjunto de ferramentas no processo de desenvolvimento). Eles procuram um "erro" e depois modificam a entrada. Isso corrige o erro.


A principal premissa do desenvolvimento de software: os mesmos dados de entrada de forma confiável e determinística fornecem a mesma saída

De fato, um resultado não determinístico é considerado um erro: se uma conclusão inesperada ou incorreta não é reproduzida, os desenvolvedores procuram expandir o estudo para outras partes da pilha (sistema operacional, rede etc.) que também se comportam de forma mais ou menos determinística, dando o mesmo resultado com a mesma entrada ... e se não for , ainda será considerado um bug. Agora, isso agora é um bug do sistema operacional ou da rede.

De qualquer forma, o determinismo é um pressuposto básico, quase dado como certo para a maioria do trabalho que os programadores realizam.

Mas para qualquer devopa que passou o dia coletando ferro em racks ou separando a API da nuvem, a idéia de um mundo completamente determinístico (desde que haja uma oportunidade de exibir todos os dados de entrada!) É, na melhor das hipóteses, um conceito fugaz. Mesmo descartando as piadas do BOHF sobre manchas de sol , engenheiros experientes viram as coisas mais estranhas do mundo. Eles sabem que mesmo um grito humano pode desacelerar um servidor , sem mencionar 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 "Five Why" corretamente (e repetíveis!) Levam a essa causa raiz. De fato, isso contradiz a própria experiência, quando as peças do quebra-cabeça na prática não se somam tão claramente. Portanto, eles percebem mais facilmente essa ideia.

Obviamente, não estou dizendo que os desenvolvedores são ingênuos, estúpidos ou incapazes de entender como a linearidade pode enganar. Programadores experientes provavelmente também viram muito não determinismo em sua vida.

Mas parece-me que a reação usual dos desenvolvedores nessas disputas está frequentemente relacionada ao fato de que o conceito de determinismo como um todo os serve bem no trabalho cotidiano. Eles não encontram o não-determinismo com tanta freqüência quanto os engenheiros precisam capturar os gatos Schrodinger em sua infraestrutura.

Talvez isso não explique completamente as reações observadas pelos desenvolvedores, mas este é um lembrete poderoso de que nossas reações são uma mistura complexa de muitos fatores.

É importante ter em mente essa complexidade, independentemente de estarmos investigando um único incidente ou trabalhando juntos em um pipeline de entrega de software ou tentando entender um mundo mais amplo.