ネットワークエンジニアの現実（麺と…塩？）
最近、エンジニアとさまざまな出来事について話し合っているときに、興味深いパターンに気づきました。
こうした議論では、必ず「根本原因」という問題が浮上します。 忠実な読者はおそらく私が持っていることを知っているでしょう 上の 。 多くの組織では、インシデント分析は完全にこの概念に基づいています。 彼らは因果関係を特定するために次のようなさまざまな手法を使用します。 。 これらの方法は、議論の余地のない定説として、いわゆる「イベントの線形性」を前提としています。
この考えに異議を唱え、複雑なシステムでは線形性が確実に欺瞞的であることを指摘すると、興味深い議論が生まれます。 論争者たちは、「根本原因」を知ることによってのみ、何が起こっているのかを理解できると熱心に主張しています。
私は興味深いパターンに気づきました。開発者と Devops はこのアイデアに対して異なる反応を示します。 私の経験では、開発者は根本原因が重要であり、イベントには因果関係が常に確立できると主張する可能性が高くなります。 一方で、DevOps は、複雑な世界が常に線形性に従っているわけではないことに同意することが多いです。
いつも不思議に思っていたのですが、これはなぜでしょうか？ 何 作る プログラマーは「根本原因は神話である」という考えをそのように批判するのでしょうか？ 異物を認識する免疫システムのようなものです。 DevOps がなぜこのように反応するのか むしろ傾いている このアイデアを検討してみてはいかがでしょうか？
完全にはわかりませんが、これについてはいくつか考えがあります。 それは、これらの専門家が日常業務を遂行するさまざまな状況に関連しています。
開発者は多くの場合、決定論的なツールを使用して作業します。 もちろん、コンパイラ、リンカー、オペレーティング システム - これらはすべて複雑なシステムですが、私たちはそれらが決定的な結果を与えるという事実に慣れており、それらが決定的なものであると想像します。同じ入力データを提供すると、通常は次の結果が得られると期待します。これらのシステムからの出力は同じです。 そして、出力に問題 (「バグ」) がある場合、開発者は入力データ (ユーザーまたは開発プロセス中の一連のツールからのデータ) を分析することで問題を解決します。 彼らは「エラー」を探して、入力データを変更します。 これにより「バグ」が修正されます。
ソフトウェア開発の基本的な前提: 同じ入力データが確実かつ決定的に同じ出力を生成します。
実際、非決定的な結果自体はバグとみなされます。予期せぬ出力や誤った出力が再現されない場合、開発者はスタックの他の部分 (オペレーティング システム、ネットワークなど) にも調査を拡張する傾向があり、これらの部分も同様に動作します。多かれ少なかれ決定論的に、同じ入力データで同じ結果を生成します...そして そうでない場合、その場合、これはまだバグとみなされます。 現時点では、オペレーティング システムまたはネットワークのバグです。
いずれにせよ、決定論は基本的なものであり、プログラマーの仕事のほとんどにおいてほぼ当然の前提となっています。
しかし、ハードウェアを買い集めたり、クラウド API を考え出すことに一日を費やした Devops 担当者にとって、完全に決定的な世界 (すべての入力をマッピングすることさえ可能であれば!) というアイデアは、よく言ってもつかの間の概念です。 それを脇に置いても 、経験豊富なエンジニアは、この世で最も奇妙なものを見てきました。 彼らはそれを知っています 環境における他の何百万もの要因は言うまでもありません。
そのため、経験豊富なエンジニアは、すべてのインシデントには単一の根本原因があるのではないかと疑いやすくなり、「XNUMX つのなぜ」のようなテクニックを使えば、その根本原因を正確に (そして繰り返し!) 導き出すことができます。 実際、これは彼ら自身の経験と矛盾しており、実際にはパズルのピースがそれほどきれいにはまりません。 したがって、彼らはこの考えをより簡単に受け入れます。
もちろん、開発者が世間知らずだ、愚かだ、または線形性がいかに欺瞞的であるかを理解できないと言っているわけではありません。
しかし、これらの議論における開発者からの共通の反応は、多くの場合、決定論の概念が 全体的にはうまく機能します 日々の仕事の中で。 エンジニアがインフラストラクチャ上でシュレーディンガーの猫を捕まえなければならないほど、非決定論に遭遇することはありません。
これは観察された開発者の反応を完全には説明できないかもしれませんが、私たちの反応が多くの要因の複雑な混合物であることを強く思い出させてくれます。
単一のインシデントに対処している場合でも、ソフトウェア配信パイプラインで共同作業している場合でも、より広い世界を理解しようとしている場合でも、この複雑さを覚えておくことが重要です。
出所： habr.com