CIインシデントとは何か？解説

CIインシデントとは、チームのmergeおよび出荷の能力をブロックまたは低下させるほどに重大な、継続的インテグレーションシステムへの混乱です。

すべての赤いbuildがインシデントというわけではありません。インシデントとは、pipeline自体が信頼できなくなる、あるいは利用できなくなり、デリバリーを停止させるほどになった状態です。プロバイダーの障害、ダウンしているregistry、停止したself-hostedのフリートなどです。これらを検知と対応を伴うインシデントとして扱うことが、チームを静かに消耗させるのを防ぎます。

何が失敗をインシデントに引き上げるか

単一のjobがfailするのは日常茶飯事です。それがインシデントになるのは、影響が広範または持続的であるときです。多数のbuildが同時にfailする、pipelineがまったく実行できない、あるいはチーム全体でデリバリーがブロックされる、といった場合です。範囲と継続時間こそが、インシデントを一度きりのものと分けるものです。

よくあるCIインシデント

jobの実行を妨げるCIプロバイダーの障害。
registryまたは依存関係のミラーがダウンし、多数のインストールがfailすること。
停止したself-hosted runnerのフリート。孤立したjob、あるいは埋まったディスク。
すべてのpipelineを壊す、不適切な共有設定の変更。

インシデント vs transientな不具合

transientな不具合は短時間で自然に解消しますが、インシデントは持続的で、通常は介入を必要とします。リトライは不具合には対処できますが、進行中のインシデントには対処できません。多数のjobにわたってリトライがfailし続けるなら、おそらく孤立したtransientなノイズではなく、インシデントの最中にいます。

適切に対応する

早期に検知し（個々のjobだけでなく失敗率にアラートを設定する）、チームが時間を無駄にしないようコミュニケーションし、緩和し（failover、一時停止、または問題の変更をロールバックする）、その後は改善できるよう復旧時間を測定します。MTTRを追跡することで、インシデントを学習のループへと変えられます。

Latchkeyの視点

自己修復は、人間に到達する孤立した失敗の数を減らすため、本物のインシデントが際立ちます。Latchkeyの自己修復managed runnerは、transientおよびメカニカルな失敗を自動的にリトライするため、一度きりの不具合があなたのbuildをfailさせることはなく、インシデントと取り違えられることもありません。

重要なポイント

CIインシデントは、チーム全体にわたってデリバリーをブロックまたは低下させます。
範囲と継続時間が、インシデントを一度きりの失敗と区別します。
プロバイダーの障害、registryのダウンタイム、停止したフリートがよくあります。
早期に検知し、コミュニケーションし、緩和し、復旧を測定しましょう。