出典: Profit_Image via Shutterstock
開発者やDevOpsチームが、DevOpsパイプラインからコード生成AIモデルまで、さまざまなクラウドベースのサービスにますます依存する中、障害がアプリケーションに混乱を引き起こす可能性が高まっており、専門家は大規模なインシデントが発生するのは時間の問題だと考えています。
ある程度、これらの問題はすでに小規模ながら影響を及ぼしています。例えば9月10日には、AnthropicのClaude.aiおよびConsoleサービスと関連APIがシステム全体の障害に見舞われ、約30分間停止しました。これにより、ユーザーは「『LLMダウン』は新しい『コンパイル中』だ」や「原始人のようにコーディングせざるを得ない」などと冗談を言っていました。7月には、開発プラットフォームのGitHubが「API、Issues、GraphQL、Pull Requestsなど複数のサービスでパフォーマンス低下」を報告し、約4%のリクエストが失敗しました。
このようなパフォーマンスの低下—完全な障害ではなく—は典型的であり、一部のユーザーやサービスのみに影響を与えると、GitHubのエンジニアリング担当シニアバイスプレジデント、Jakub Olesky氏は述べています。
「私たちは、障害を優雅に処理し、ダウンタイムを最小限に抑えるための取り組みに深くコミットしています」と彼は言います。「つまり、スケール、安全なデプロイ、レジリエンスへの投資を優先し、すべてのインシデントからの改善に対して確実なタイムラインを設けています。」
しかし、業界の一部専門家は、開発者に数時間から数日に及ぶダウンタイムをもたらす大規模なインシデントが発生するのは時間の問題だと主張しています。ある意味で、Shai-Huludワームがそのような障害を引き起こしました—このワームによるNodeパッケージマネージャ（npm）エコシステムの汚染は、500以上のパッケージの侵害と、多くの開発者の作業を停滞させる大規模なクリーンアップ作業をもたらしました。
ロード中...
これらの障害やインシデントは、アプリケーションチームが共通インフラにますます依存する中、重要なクラウドサービスに問題が発生すると波及効果が生じる可能性があることを示していると、バックアップやレジリエンスサービスを提供するGitProtect.ioのサイバーセキュリティストラテジスト、Daria Kulikova氏は述べています。
ソフトウェアチームは、GitHubのようなソースコードホスティングサービス、継続的インテグレーション/継続的デプロイメント（CI/CD）パイプライン、統合開発環境（IDE）、AI支援のコーディングプラットフォームなど、クラウドベースのツールにますます依存しているとKulikova氏は言います。これが現代のソフトウェア開発におけるシステミックな単一障害点を生み出していると彼女は説明します。
「たとえ小さなクラウド障害や遅延でも、複数のチームやプロジェクトに連鎖的に影響し、開発パイプラインを停止させたり、コードレビューを妨げたり、リリースを遅延させたりすることがあります」とKulikova氏は述べています。
DevOpsサービスは概ね信頼できる
全体として、開発やデプロイメントサービスは非常に信頼性が高いです。MicrosoftのAzure DevOps（ADO）の障害にどう備えるべきかという議論では、多くのコメント投稿者が、このサービスで重大な問題が発生したことはほとんどないと指摘しています。
「ADOの稼働率は、私たちのオンプレミスサービスのどれよりもはるかに高いと確信しています」と、ある投稿者は述べています。
これまでのところ、DevOpsサービスの障害はほとんどが小規模で、ソフトウェア開発に深刻な影響を与えることはありませんでした。情報サービスプロバイダーIsDownの2024年障害レポートによると、平均的な障害は2時間未満（106分）で解消しています。
それでも、2025年前半には、DevOpsプラットフォームで合計330件のインシデントが発生したと、GitProtect.aiが収集したデータによって報告されています。10億人以上のユーザーを持つAzure DevOpsは、今年前半に74件のインシデントを経験し、その中には159時間に及ぶ最長のパフォーマンス低下も含まれていました。GitHubのインシデントは前年同期比で58%増加し、109件の報告のうち17件が重大とされ、合計100時間以上の障害が発生したとレポートは伝えています。
GitLabは前年よりも前半に修正した脆弱性が少なかったものの、依然として59件のインシデントが発生し、合計1,346時間の障害が発生しました。同プラットフォームは99.8%の稼働率サービスレベル目標を掲げており、直近3カ月ではこれを上回っていると、GitLabの最高技術責任者Sabrina Farmer氏は述べています。
「GitLabは過去5年間で大規模な全体障害を経験していません」と彼女は言います。「最も重大な障害は、2017年にメンテナンス中の人的ミスによるデータベースインシデントでした。それ以降、同様のインシデントを防ぐために複数の安全策を導入しています。」
開発にさらなるレジリエンスを
「事前に、人々は何が起こるか、どう対応するか、自分の役割は何かを知っておくべきです」と彼女は言います。「レジリエンスは、技術的な柔軟性と規律ある運用慣行を組み合わせることで生まれます。」
DevOpsチームは、ワークフローにレジリエンスを組み込むべきです。GitHubのOlesky氏は、ローカルファーストのワークフローの利用、CI/CDパイプラインへのフォールバックやフェイルオーバー設計、依存関係のキャッシュなど、障害へのレジリエンスを構築する方法を指摘しています。
GitLabのFarmer氏は、AIコーディングアシスタント、CI/CDサービス、テストプラットフォームへの依存が高まることで、障害への備えが開発チームにとってさらに重要になっていると主張します。
「単一のベンダーに依存したり、優雅な劣化を実装しなかったりするチームは、生産性や場合によってはユーザー体験を危険にさらしています」と彼女は言います。「特にAIは、これまで解決されてきたインシデントを再び経験する可能性が高く、多くのユーザーが技術や新しいインフラの限界を試している段階です。多くのプロバイダーがようやく大規模展開を始めたばかりなのです。」
最近のAnthropicの障害時、ある人物はAI推論システムのオンサイト冗長性の利点を認識し、オンライン掲示板に投稿しました。「社内のロードバランシング/フェイルオーバーLLM推論システムがあるので、この障害で本番環境が落ちることはありません。」
開発チームは、ワークフローをレジリエントにし、適切な箇所に冗長性を追加し、重要なデータのバックアップを持ち、迅速に切り替え可能な代替テスト・ビルド環境を用意することに注力すべきだと、GitProtectのKulikova氏は述べています。彼女は、これらのフェイルオーバー戦略をストレステストし、障害をシミュレーションして、実際のインシデント時に開発を停止させる可能性のある隠れた依存関係やボトルネックを明らかにすることを推奨しています。
「事前に、人々は何が起こるか、どう対応するか、自分の役割は何かを知っておくべきです」と彼女は言います。「レジリエンスは、技術的な柔軟性と規律ある運用慣行を組み合わせることで生まれます。」
