要約

  • Cloudflare は8月3日14時20分（UTC）、複数顧客に影響する可能性がある Workers のビルド失敗について調査を開始した。
  • 対象として示されたのは Workers Builds であり、GitHub または GitLab の選択ブランチへのプッシュから自動デプロイできる Cloudflare のネイティブ CI/CD 機能である。
  • 15時22分に問題を特定して修正を実装中としたが、原因、顧客数、失敗件数、影響したデプロイ経路は公表されなかった。
  • 15時38分にはビルドが失敗しなくなった一方、遅延が残る可能性を明記し、エラー停止と処理能力の完全回復を区別した。
  • 16時02分に修正を監視段階へ移し、16時12分に解決済みとした時点で、Workers Builds は性能低下から運用中へ戻った。
  • 影響分類は Cloudflare による「minor」だったが、失敗・遅延したジョブの最終状態、自動再試行、実行中 Worker への影響、事後報告の予定は示されていない。

復旧判定は四つの関門に分けられる

最初の関門は、新たな失敗が止まったかである。二つ目は、遅延している仕事を通常の速度で処理できるか。三つ目は、修正後の状態が一定時間安定しているか。四つ目は、顧客が意図したリビジョンが正しい環境まで到達したかである。

Cloudflare の公開時系列は、最初の三つを段階として示した。調査中から特定済みへ進み、15時38分には失敗停止と遅延継続を同時に伝え、16時02分から監視し、16時12分に解決した。しかし四つ目は各顧客の記録でしか確かめられない。

「解決済み」は事業者がインシデントを閉じた状態であり、その時間帯に送信された全ジョブの成功証明ではない。この区別を保てば、復旧を過小評価することも、緑色表示だけで過大評価することも避けられる。

ビルド経路は変更を運ぶ供給線である

Workers Builds は、ソースリポジトリからビルドを作り、変更を自動的にデプロイする経路として説明されている。この経路が止まると、すでに稼働している版が直ちに停止しなくても、次の修正版を届ける能力が失われる。

公開情報は、すべての Workers 実行が停止したとは述べていない。すべての Cloudflare サービスや全デプロイ手段が使えなかったとも述べていない。一方で、本番実行が無影響だったという明示的な説明もない。沈黙を「影響なし」の証拠に変えてはならない。

確認できる範囲は Workers Builds に限られる。依存する顧客は、少なくとも一時的にその経路で変更を届けにくくなった。既存版の稼働状態は、顧客自身の監視で別に確認する必要がある。

再試行の前に正本を一つ決める

障害中に複数のコミットが送られ、失敗確認のためにさらにジョブが追加されると、復旧時には「どの版を出すか」という統制問題が生じる。古いジョブが新しい緊急修正より後に完了すれば、完了順と意思決定順が逆転する可能性がある。

安全な手順は、不要なプッシュを止め、失敗または遅延したジョブ ID を保存し、正本となるコミットを明示するところから始まる。その後、再試行を一度の管理された操作として行い、生成物のハッシュと対象環境の実行版を照合する。

今回、順序逆転、重複デプロイ、誤った成果物が起きたという証拠はない。また、Cloudflare はジョブが自動再試行されたかも説明していない。これらは事実として書く対象ではなく、復旧時に顧客が検査すべき項目である。

ロールバック能力も復旧品質の一部になる

ビルドが再び通ったとしても、新しい版が期待通りに動くとは限らない。通常時と同様、リリース後の検証とロールバック条件が必要である。障害直後は時間的圧力が強く、複数の再試行が混在しやすいため、その重要性はむしろ増す。

ロールバックは単に前の版を保存することではない。どの版が現在稼働し、どの版へ戻せるか、設定やシークレットに互換性があるか、誰が判断するかを事前に決める必要がある。ビルドサービスの復旧を理由に、この検証を省略してはならない。

ステータスページは顧客のロールバック実施について何も述べていない。そのため実施件数や必要性は不明である。ここで導けるのは、復旧直後のリリースほど、版の同一性と戻し方を明示する必要があるという運用原則である。

遅延はエラーより判断を難しくする

失敗は終端状態として見つけやすい。遅延は、処理中なのか停止しているのか、いつ終わるのかが曖昧になりやすい。緊急修正にとって、最終的に成功する一時間遅れのビルドは、技術的成功でも業務上は遅すぎる場合がある。

15時38分の更新は、まさにこの不確実性を残した。顧客は待つか、再試行するか、別経路を使うかを決めなければならないが、公開ページにはキューの深さ、最古ジョブの年齢、処理速度がない。積み残しの規模を推定する根拠はない。

したがって復旧監視には、成功率だけでなく待ち時間とスループットが要る。エラーがゼロでも、到着量より処理量が小さければ遅延は増える。サービス運用中という表示と、期限内にリリースできる状態は同じではない。

「minor」は顧客ごとの緊急度を表さない

Cloudflare は影響を minor と分類した。これは事業者がサービス全体を評価したラベルで、各顧客の変更内容まで採点したものではない。予定リリースがない組織と、重大な不具合を直そうとしている組織では、同じ111分の意味が異なる。

特に小規模事業者は、ビルド環境、認証情報、リポジトリ連携、デプロイ自動化を一つの管理サービスへ集約しやすい。運用負担は下がるが、変更能力の集中点が生まれる。重要なのはラベルに反論することではなく、自社の許容停止時間を別に定義することだ。

代替経路を持つ場合も、普段から試験されていなければ安全とは限らない。古い依存関係や権限、設定差が新たな事故を生むことがある。短い障害なら、未検証の手動経路へ急いで移るより、変更を止めて待つ方が合理的な場合もある。

公開情報の空白は空白のまま扱う

Cloudflare は原因、失敗ビルド数、影響顧客数、キュー量、データ損失、顧客操作の要否を公表していない。事後分析を出すとも約束していない。したがって、攻撃、セキュリティ侵害、世界的停止、金銭被害を推測することはできない。

「複数顧客に影響する可能性」という初報も、確定顧客数ではない。minor という分類も、誰にも重要な影響がなかったことを証明しない。確定した文言と未確定の範囲を分けることが、短いステータス情報から過剰な物語を作らないための基本となる。

今後 Cloudflare が原因と再発防止策を説明すれば、依存リスクを改めて評価できる。説明がなくても、顧客は14時20分から16時12分までに送ったジョブを照合し、自社の範囲を閉じることができる。

変更能力を独立した SLO として測る

通常の稼働率は、すでに配置されたコードが応答した時間を測る。しかし、修正を本番へ届けるまでの時間も事業継続には重要である。ビルド成功率、キュー年齢、成果物の追跡可能性、デプロイ所要時間を別の目標として持てば、見かけ上オンラインのまま変更不能になる状態を捉えられる。

今回の記録が証明するのは限定的である。Workers Builds で失敗が発生し、失敗停止後も遅延の可能性が残り、監視を経て解決した。実行面全体の停止や無影響は証明していない。その限定性こそ、正しい管理判断の土台になる。

ソフトウェアの可用性は現在形だけではない。次の変更を安全に作り、確認し、届ける未来形も含む。四つの復旧チェックポイントを分けることで、その未来形を測定可能な運用対象にできる。

情報源