2026年10月8日 17:54 UTC postmortem
##**概要**
10月1日～10月8日の間、CirCIのお客様は、ジョブが正常に起動しなくなったり、起動できなかったりする5つの別々のインシデントを経験しました。 クラウドプロバイダーから限られたインスタンスの可用性によって、インシデントの3つが運転されました。 一つは、当社のスケジューリングインフラの構成の問題によって引き起こされ、インシデント中に発生した内部サービスのメモリ制限によって行われます。
※10月1日(土)〜10月7日(日)〜10月24日(日) 構成の問題は、Gen 2 のスケジューリングサーバが高性能なローカルディスクを使用するのを防ぎました。 トラフィックのバースト中に、フォールバックディスクは飽和してジョブプレースメントが遅くなります。
* 10月 7, 13:27 に 14:06 UTC:** マシンジョブは、クラウドプロバイダから十分な仮想マシンを取得できないため、通常よりも長く待機しました。
* 10月 7, 14:24 に 15:21 UTC:** インフラのエラーに失敗したジョブやワークフローが遅延しました。 各ジョブをメモリから実行し、再起動した起動時に設定するサービスです。
* 10月 7, 18:49 に 20:05 UTC:** Docker Gen 2 ジョブは、クラウドプロバイダーから十分なインスタンスを取得できないため、通常よりも長い待機しました。
* 10月 8, 12:48 に 16:00 UTC:** Linux マシンのジョブとリモート Docker ジョブが最大 50 分待ってから起動します。 当社のクラウドプロバイダは、要求するインスタンスタイプが十分でなかったし、異なるインスタンスタイプを選択するロジックの欠陥は、代替手段を使用して私たちを保ちました。
これらの事件を待たせたジョブは、紛失してしまった。 14:24から15:21 UTCの10月7インシデント中に、ジョブがインフラストラクチャエラーに失敗した顧客は、それらを再実行することができます。
元のステータスページは以下のとおりです。
* [10月1日 - Gen 2 Dockerジョブの開始遅延](https://status.circleci.com/incidents/22mrv46g6n7g)
* [10月7日 - マシンジョブタスクの開始遅延](https://status.circleci.com/incidents/tj6wdnfjwr64)
* [10月7日 - 顧客ジョブの不正なレベルの上昇](https://status.circleci.com/incidents/0z31ldjd8m5v)
* [10月7日 - Docker Gen2のタスク待ち時間の増加](https://status.circleci.com/incidents/39rfrjmk5pvd)
* [10月8日 - 機械ジョブの昇降待ち時間](https://status.circleci.com/incidents/jn756xtsy4xg)
##**バックグラウンド**
CircleCI で実行される全てのジョブは、計算が必要です。 その計算が実行者に依存する場所。
Docker ジョブは、インスタンスのフリートに作業をスケジュールするサーバーのクラスターで実行されます。 スケジューラは、インスタンスが各ジョブを実行するかを決定するそれらのサーバー上のソフトウェアです。 Gen 2 Docker ジョブは、10月1日のインシデント時にこのようなクラスターで実行されます。 Gen 1 Docker ジョブは、複数のクラスターに分散します。
リモート Docker ジョブを含むマシンジョブ、専用の仮想マシンを取得します。 リモート Docker ジョブは、プロビジョニングによる投稿から Linux マシンジョブとして処理されます。 弊社のマシンプロビジョニングサービスでは、当社のクラウドプロバイダーから各マシンをマシンジョブに通常使用しています。 プロバイダが要求するインスタンスタイプを供給できない場合は、サービスが戻ります。異なるインスタンスタイプ、または異なる領域を要求します。 機械が利用できるまで待ちます。
ジョブが始まっていれば、その設定にジョブ設定サービスが要求されます。 そのサービスは、同じプログラムの小さなコピーであるPodのセットとして実行されます。 あまりにも多くのPodが止まると、残りのPodはより多くの負荷を運び、サービスが回復するまでジョブは起動できません。
これらのパスは、当社のスケジューリングシステムのスループット、クラウドプロバイダーからのインスタンスの供給、ジョブを開始したサービスのメモリとコピーの数に依存します。 それらのいずれかの欠点は、ジョブの待機または失敗をします。
## **何が起こっているか**
\(全回UTC\)
##**10月1日: Docker Gen 2 ジョブが最大 30 分遅れる
07:44 では、Gen 2 Docker ジョブが 90% の容量に上昇し、そこに滞在するサーバー上のディスクアクティビティ。 07:57 では、 Docker ジョブの数が成長し始めるのを待ちます。 自動化されたアラートは、オンコールエンジニアを 08:08 でページ しました。 弊社は、8時42分に事故を申し立てました。
エンジニアは、スケジューリングサーバーのハイディスクレイテンシを特定しました。 最初は、ディスクが負荷のために遅すぎると信じていたので、ディスクタイプが高速に変化しました。 09:01 では、2 つのワークストリームで合意したチームは、サーバーを高速なディスクに移動し、ジョブが 2 つのクラスター間で分割されるように 2 番目の Gen 2 クラスターを追加します。
09:41では、エンジニアは根本原因を発見しました。 各スケジューリングサーバーには、直接添付した高速ディスクが搭載されており、スケジューラは、その作業データを保管することを目的としています。 これらのサーバーは、セキュリティ強化されたオペレーティングシステムイメージで実行され、そのイメージでは高速ディスクが使用されていない。 スケジューラは、代わりにネットワークアタッチされたディスクを遅くするデータを書きました。 エラーなしで高速なディスクを設定するスクリプト、および失敗を隠すこれらのサーバーのログのギャップ。 ゲン2のトラフィックもますます激しくなってきました。 これらのバーストの間に飽和した遅いディスク、スケジューラが後ろに落ちました。
待ち時間 ピーク時 09:54, 時 ジョブ オン ジェン 2 中 リソース クラス まで 30 分. 09:55 では、エンジニアは高速ディスクを正しくセットアップする修正を加えました。 10:11 では、スケジューラはジョブを高速化し、サーバーが新しいジョブでバックアップできることを確認します。 Gen2媒体の待ち時間は10時14分に13分、10時17分に7分、10時20分に1分30秒。 ステータスページを10:24で監視し、10:45でインシデントを解決しました。
11:20 では、Gen 2 クラスターがジョブを実行し始めた。
##**10月7日、13:27から14:06:機械ジョブの昇格待ち時間**
急行・待ち時間を見ると13:27で事件を宣言しました。 13:31 のステータスページに掲載しました。 13:31 では、エンジニアはマシンジョブの仮想マシンを取得するために苦労していたことを見て、起動するジョブの数がマシンジョブを中心に高かったことを見ました。 13:34 時, 待ち時間は、実行者間で上昇しました.
13:48 では、より多くの機械が利用できるようになり、14:06 で事件を解決しました。
##** 10月 7, 14:24 に 15:21: ジョブの失敗とワークフローの遅延**
以前のインシデントが解決された後、実行システムに提出されたジョブの数の急激な低下による14:24で新しいインシデントを宣言しました。 14:26 では、エンジニアは、ジョブ設定サービスのPodが再起動されたことを確認しました。 サービスを再起動するPodは、リクエストに応答するためにサービスのコピーを少数に残し、繰り返した試みがインフラストラクチャエラーで失敗した後、その設定を取得できないジョブを復元します。 既に稼働していたワークフローは、起動していないジョブから更新を待ち受けていました。
14:35では、エンジニアはポッドに利用可能なメモリの量を増加させ、ポッドの数が増えました。これにより、より多くのコピーが負荷を共有しました。 また、ジョブの投稿が回復し始めたメモリの量を増加させ、通常のレベルに戻ったワークフローシステムで流れるメッセージの数が増えました。 14:44 では、ステータスページを監視に移動しました。
ジョブコンフィギュレーションサービスのPodは、メモリの制限と再起動に達しました。 メモリ割り当てとPod数の増加、サービスの回復。 15:13 では、Gen 2 Docker クラスターのインスタンス数が増加し、待機ジョブのバックログを素早く実行できます。 15:21に事件を解決しました。
##** 10月 7, 18:49 に 20:05: Docker Gen 2 ジョブの昇格待ち時間**
Docker Gen 2の待ち時間がバラになった18:49に新しいインシデントを宣言しました。 18:51 では、エンジニアは利用可能なインスタンスの不足が、待機時間を上げている、それらが十分な取得から私たちに保持されていることを確認しました。 リソースクラスサイズにより、待ち時間が異なります。
19:52年、平均待機時間が1時間前より下がっていましたが、短いスパイクは続行し、ステータスページを監視しました。 20:05に事故を解決しました。
##**10月8日:Linuxマシンとリモートドッカージョブが最大50分待ちます**
マシンやリモート Docker ジョブの待ち時間や待ち時間など、多くのジョブを待ってから 12:48 でインシデントを宣言しました。 12:49 では、エンジニアはクラウドプロバイダーが十分なインスタンスを提供できないと見ました。 調査したように、ディレイは登り続けました。
13:13 では、最初の選択肢が利用できなくなったときに、異なるインスタンスタイプまたは領域を選択するロジックを調べ始めました。 13:24 では、その論理の欠陥は、プライマリ領域の他のインスタンスタイプを使用して私たちを停止していたと疑ったので、フォールバック領域を無効化し、欠陥の原因を確認しました。 エンジニアは、14:49に固定してデプロイしました。 サービスは、他のインスタンスタイプをリクエストし、多数のマシンを始動させました。 14:58で、機械が着実に落ちるのを待っているジョブのキュー。 リソースクラスを横断する平均待機時間は、待機ジョブのバックログを通して働いたため、次の時間に引き続き低下します。
16:00 では、機械がクリアされ、待機ジョブのキューが正常に戻ります。 ステータスページを16:09に監視し、16:35にインシデントを解決しました。
##**未来の予防とプロセス改善**
私たちは、供給の多様化、フォールバックロジック、早期検出など、ジョブ開始時間の回復力を強化するために次のステップをとっています。
※コンピュートエリアを拡大しています。** 10月7日と10月8日のインシデントでは、クラウドプロバイダは使用した地域に十分なインスタンスを提供できません。 好ましい地域を損なう需要のスパイクを処理するために、新しい領域をフォールバックロジックに追加しています。
**異なるインスタンスタイプを選択するロジックを修正しています。** 10月8日、同地域の他のインスタンスタイプを使用してマシンプロビジョニングサービスを維持しました。 インシデント中に修正をデプロイし、このロジックを全体として見直し、テストで再ファクタリングするようになり、1つのインスタンスタイプの不足が別のインスタンスに移動します。
**弊社が提供するインスタンスタイプを拡大し、追加容量を確保しています。** クラウドプロバイダーと連携し、既存の地域に追加の容量を予約し、ジョブを実行できるインスタンスタイプを追加します。 高性能コンピューティングの需要が高まっています。 供給のバリエーションから、お客様が絶縁されるように、供給能力をどこに、どのように供給するかを多様化しています。
※Gen 2 Docker クラスターを2つ追加し、2つのクラスターにトラフィックバーストが配布されます。** また、サーバーディスクの飽和とスケジューラがジョブを配置する速度に関するアラートや、サーバーが使用中の高速ディスクなしで起動したときに発火するアラートも追加しています。 ディスクのセットアップスクリプトはエラーで失敗し、同様の問題がすぐに見えるように、これらのサーバーからログを復元しました。
顧客体験は当社の最優先事項であり、お客さまがどこにいるかを信頼するために、当社のシステムの信頼性を継続的に改善することにコミットしています。 弊社チームは、これらの事故を解決するために取り組んでいる間、お客様にご満足いただけることを心よりお礼申し上げます。 ご質問やご不明な点がございましたら、サポートチームまでお問い合わせください.
