パイプラインの可観測性の基礎: CIが失敗する理由を可視化する

可観測性とは、再実行せずに「このbuildはなぜ失敗、あるいは遅くなったのか?」に答えられることです。それは、いくつかのシグナルをすべての実行にわたって一貫して収集することから生まれます。

多くのチームはCIをpass/failとして扱い、その間の履歴をすべて失っています。パイプラインの可観測性とは、シグナル - 所要時間、結果、exit code、flake率 - を捕捉し、失敗を一度きりの謎ではなく診断可能な傾向にすることです。

中核となるシグナル

jobごと・stepごとの所要時間の推移(徐々に遅くなる兆候を捉えるため)。
すべての失敗の結果とexit code/signal(137? 143? 127?)。
テストごとのpass/fail履歴(flakyさを特定するため)。
queue timeとrun time(runner不足と遅いjobを切り分けるため)。

ログから傾向へ

1本の失敗ログは、1回の実行について教えてくれます。同じデータを実行をまたいで集約すると、失敗が特定のjob、OS、時間帯、runnerに集中しているかどうかが分かります - それこそが実際に根本原因を指し示すものです。実行のメタデータを永続化しましょう。ログとともに流れ去らせてはいけません。

良い可観測性が答える問い

先週、どのstepがパイプラインの所要時間を悪化させたのか? どのテストが断続的に失敗し、それはどれくらいの頻度か? 失敗はmatrixの1つのセルに集中しているか? re-runは私たちにどれだけの時間とコストを費やさせているのか? これらのどれも単一のbuildビューからは答えられません - 蓄積されたシグナルからのみ答えられます。

それに基づいて行動する

可観測性は、行動を促して初めて役立ちます: flakeデータが名指しするテストをquarantineし、所要時間データが指摘するrunnerを適正サイズにし、exit codeデータが一時的だと明かすre-runを減らしましょう。Latchkeyのような自己修復型CIプラットフォームは、同じシグナルの上に構築され、一時的障害やリソース障害を自動的に回復します。

重要なポイント

可観測性は、再実行せずに「なぜ失敗/低速化したか」に答えます。
所要時間、exit code/signal、テストごとの履歴、queue timeとrun timeを追跡しましょう。
実行をまたいで集約しましょう - 単一のログは、根本原因を名指しするパターンを隠します。
目的はアクションです: quarantineし、適正サイズにし、一時的なre-runを減らすこと。