CIオブザーバビリティとは？わかりやすく解説

CIオブザーバビリティとは、パイプラインが出力するデータ、つまりログ、メトリクス、トレース、障害の分類から、パイプラインが何をしているのか、そしてなぜ失敗したのかを理解できる能力のことです。

中が見えないパイプラインは、改善できないパイプラインです。オブザーバビリティは、赤い壁を実行可能なインサイトに変えるものです - どのjobが失敗するのか、どのくらいの頻度で、なぜ失敗するのか、そしてその原因が自分のコードなのか環境なのか。それがなければ、あらゆる障害を毎回ゼロから調査することになります。

3つの古典的なシグナル

ログ：何が起きたかをステップごとに記録した詳細な記録。
メトリクス：失敗率、所要時間、キュー時間などの集計された数値。
トレース：実行がjobやステージをどのように流れ、どこで時間が費やされたか。

CIオブザーバビリティが加えるもの

一般的なシグナルを超えて、CIオブザーバビリティとは障害を分類することを意味します - 本物 vs 一時的、flaky vs 決定論的、機械的 vs 論理的。赤いbuildはデータですが、「一時的なregistryのタイムアウト、リトライ済み、復旧」とタグ付けされた赤いbuildはインサイトです。この分類こそが、データを実行可能なものにします。

なぜ重要なのか

オブザーバビリティは復旧を短縮します。障害がそれ自身の診断を伴っていれば、遅い部分、つまり何が壊れたのかを突き止める作業を飛ばして、修正するか棄却するかへ直行できます。また傾向も明らかにします - じわじわ上昇する失敗率や、単一の赤いbuildでは決して露見しない、繰り返し発生するflakyなテストなどです。

何を計測すべきか

失敗率とその内訳（本物、一時的、flaky）、jobの所要時間とキュー時間、リトライ回数とそれが何を復旧させたか、そしてテストごとのflakinessを追跡しましょう。目標は、生のログを掘り返すことなく、「パイプラインは健全か、そうでなければなぜか？」に一目で答えられることです。

Latchkeyの視点

自己修復とオブザーバビリティは互いを補強し合います - 適切な障害をリトライするには、それらを分類しなければならず、その分類そのものがオブザーバビリティだからです。Latchkeyの自己修復マネージドrunnerは、一時的および機械的な障害を検知して自動的にリトライし、一度きりの不具合であなたのbuildが失敗しないようにします。その一方で、修復された内容を隠すのではなく可視化しておきます。

重要なポイント

CIオブザーバビリティとは、パイプラインの挙動をその出力から理解することです。
ログ、メトリクス、トレースが古典的なシグナルです。
障害を分類すること（本物 vs 一時的）が、データを実行可能なものにします。
優れたオブザーバビリティは復旧を短縮し、傾向を浮き彫りにします。