一時的な障害と決定論的な障害の違いとは？わかりやすく解説

CIにおける信頼性で最も重要な区別は、一時的 vs 決定論的です。一方は環境に起因しリトライ可能、もう一方はあなたのコードにあり修正が必要です。

CIの障害に関するほとんどすべての良い判断は、たった1つの問いから導かれます - これをもう一度実行したら成功するか？それに正しく答えることで、リトライすべきか、それともデバッグすべきかがわかります。間違えると、本物のバグに対して無駄なリトライを重ねるか、合格したはずの不具合に無駄な調査を費やすことになります。

2つのクラス

一時的な障害は環境によって引き起こされ - ネットワークの不具合、registryのタイムアウト、メモリ不足によるkill - そして自然に解消するため、リトライは成功します。決定論的な障害はコード、設定、または入力によって引き起こされ、実行のたびに同一に繰り返されるため、リトライは無駄です。あらゆるCIの障害は、このどちらかに当てはまります。

決め手となるテスト：再現性

再現性が両者を分ける境界線です。同じjobをもう一度実行してみましょう - 毎回同じように失敗するなら決定論的、時々合格するなら一時的です。このたった1つの問いは、エラーメッセージだけを読むよりも確実に、正しい対応へと導いてくれます。

正しく見極めることがなぜ重要か

決定論的な障害をリトライすると、時間を無駄にし、本当の修正を遅らせます。
一時的な障害をデバッグすると、バグでないものを追いかけて人の時間を無駄にします。
分類の誤りは信頼を損ないます - 本物の赤が棄却され、不具合が過剰に調査されます。

一時的であることを示唆するシグナル

ネットワークやregistryのエラー、レート制限、メモリ不足によるkill、プリエンプション、キャンセルは、特に再現しない場合、一時的である傾向があります。assertionの失敗、コンパイルや型のエラー、ファイルの欠落は、決定論的である傾向があります。エラーのクラスと再現性を組み合わせることで、自信を持った判断ができます。

Latchkeyの視点

まさにこの区別を自動化することが、自己修復の核心です。Latchkeyの自己修復マネージドrunnerは障害を分類し、一時的および機械的なものを検知して自動的にリトライし、一度きりの不具合であなたのbuildが失敗しないようにします。その一方で、決定論的な障害はあなたが修正できるよう、素早く失敗させます。

重要なポイント

一時的な障害は環境に起因しリトライ可能、決定論的なものはコードに起因し修正が必要です。
再現性が決め手となるテストです - 毎回失敗するか？
分類を誤ると、マシンの時間か人の時間のどちらかを無駄にします。
自己修復は、この分類をrunnerのレベルで自動化します。