トップ → Blog → ベンダーインシデントの管理—自社の責任ではない顧客への影響

ベストプラクティス・TIPs

ベンダーインシデントの管理—自社の責任ではない顧客への影響

2025.10.03更新

クラウドコンピューティングの基本理念と現実

クラウドコンピューティングの最初の重要な原則の一つは「you own your own availability（可用性は自社の責任）」という考え方でした。これは、パブリッククラウドプロバイダーがインフラストラクチャを提供する一方で、組織の目標を達成するために何を使用し、どのように使用するかを決定するのは自社の責任であるという意味です。クラウドプロバイダーは、あなたのアプリケーションやそのKPIについて何も知りません。

過去10年ほどで、多くの組織が技術スタックのコア機能において、クラウドコンピューティング施設やその他のSaaSプロバイダーにますます依存するようになりました。チームは価値を生み出す、個々のビジネスに収益をもたらすコアビジネス機能に集中できるようになり、技術スタックのより平凡な要件について心配する必要がなくなりました。

ベンダー起因のインシデントへの対処

しかし、この依存関係はリスクももたらしました。クラウドプロバイダーは、設定エラー、分散サービス拒否攻撃（DDoS）、さらには壊滅的な火災などにより、障害を経験しています。

上流プロバイダーに起因するインシデントをチームはどのように処理すべきでしょうか？自社のインシデント処理経験から何を学べるでしょうか？

これらのタイプのインシデントを自社だけで修正することはできません。多くのチームは座って問題が解決されるのを待つことになります。他のチームは移行やフェイルオーバーのコストを検討し、一部のチームは他のチームが問題に気づく前に既に対応を完了しているかもしれません。

ベンダーインシデント管理とは？

ベンダー依存のリスク

自社でコントロールできないベンダーの障害は、以下のような影響をもたらします。

サービスの停止または性能低下
顧客への影響と信頼性の低下
収益の損失
対応リソースの消費

インシデント時の責任の所在

ベンダー関係の管理は、多くの場合、調達、財務、法務チームが関わります。ベンダー管理の多くは契約、支払い条件、SLAに関するものです。しかし、ベンダーインシデント発生時には、ベンダーの製品と直接統合しているチームがベンダーとのコミュニケーションのループに入る必要があります。

クラウドインフラストラクチャベンダーで障害が発生している場合、SREチームが通知とステータス更新を担当するかもしれません。請求ベンダーが関わっている場合は、支払い処理フローを管理するチームが対応するでしょう。開発者ツールやDevOpsチームは、バージョン管理システム、ビルド・デプロイ、監視システムの問題に注意を払う必要があります。

どのチームがどのベンダー関係を担当するかを事前に把握しておくことは、組織がベンダーインシデントの影響を受けているかどうかを確認し、インシデントが完全に軽減されサービスが完全に復旧したタイミングを知り、インシデントがユーザーに与えた影響を判断するために重要です。

この情報を手元に置き、インシデント準備の一環として最新の状態に保つようにしてください。PagerDutyでは、ベンダーを表すサービスを定義し、連絡先情報、ランブック、その他のデータをサービス定義に追加して対応を支援できます。また、ベンダーとインターフェースするチームに通知するエスカレーションポリシーも設定できます。

なぜベンダーインシデント管理が必要か

事前準備の重要性

ベンダー障害は予期せず発生します。事前の準備がない場合、次のようなことが起こり得ます。

適切な連絡先が分からない
契約内容やSLAの確認に時間がかかる
社内の情報共有が混乱する
顧客への説明が遅れる

顧客への説明責任

ベンダー起因の障害であっても、顧客から見れば自社のサービス障害です。迅速かつ透明性のある対応が、顧客の信頼を維持する鍵となります。

ベンダーインシデントに備える5つのポイント

ポイント1：インシデント時の責任者を明確にする

推奨事項

特定のベンダー関係を監視する責任チームを定義
PagerDutyでベンダーサービスを定義し、連絡先情報と手順書を含める
技術チームと管理部門の連携体制を構築

ポイント2：情報源を確立する

大規模なインシデントや主要な障害では、その出来事がその日の主要な技術ニュースになることがよくあります。情報は主流メディア、ソーシャルメディア、特定の製品や一般的な障害に特化した専門メーリングリストに掲載されます。

主要ベンダーの情報源

生産性や収益創出パスに位置する主要ベンダーについては、ステータスページをホストしているかどうか、そしてその場所を知っておく必要があります。ベストプラクティスでは、これらのステータスページはメインドメイン名以外でホストされることが推奨されているため、company.com/statusでは見つからない可能性があります。また、サービスステータス更新専用のソーシャルメディアアカウントを持っている場合もあります。

ステータスページがない場合は、購読する必要がある顧客通知メールリストがあるかもしれません。

組織のチャットプラットフォームでは、チームがベンダーのステータスページと統合できるため、チームメンバーがベンダーでインシデントが発生しているかどうかを判断する別の手段を提供できます。

サードパーティの報告プラットフォーム

追加情報を提供するサードパーティの報告プラットフォームも多数あります：

Downdetector – 大規模な商用サイトやモバイルプロバイダーの障害を追跡
Down for Everyone or Just Me – 問題が自分だけの問題なのか、より広範囲の問題なのかがわからない人にとって非常に使いやすく有用
Internet Weather Map – グローバルなネットワーク遅延を報告。顧客が世界中にいる場合に有用。ネットワーク愛好家向け

ポイント3：ベンダー専用ランブックを準備する

ベンダーでインシデントが発生した場合、顧客として手元に置いておきたい情報があります。主要ベンダーのランブックを確立し、誰に連絡し、どのように連絡するかを把握しておきましょう。

含めるべき重要情報

組織のアカウント番号またはID – サポートに連絡する際に参照できるように
アカウントマネージャーとベンダーのサポートチームのメールアドレスまたは連絡先情報
契約情報 – 購入したパッケージや機能、およびサポートレベル（該当する場合）。高度なサポートパッケージを持っている場合は、それを認識しておく必要があります。特別な連絡先が含まれている可能性があります
アカウントのステータスと更新日 – 問題を報告する前にアカウントが期限切れでないことを確認
ベンダー固有の報告要件 – 収集に役立つ可能性のあるエラーコードやスタックトレースなど

また、ベンダーにいつ連絡することが重要かを把握している場合は、ベンダーランブックに記載してください。数百または数千の顧客に影響を与える大規模な障害では、ベンダーに連絡する必要がないか、連絡したくない場合があり、公開ステータス情報に依存することになります。より大きな影響の兆候がないインシデントでは、チームは連絡を取りたいと思うでしょう。

ポイント4：待機中の対応策を定める

公開インシデントは、組織の人々にとって非常に興味深いものになる可能性があります。劇的で、ニュースになり、誰もが気を取られます。

これらの理由から、インシデントは組織全体で時間の大きな無駄になる可能性があります。ベンダーがインシデントを起こしているために仕事ができないと感じる人がいる場合、チームは人々に情報を提供し続けるためのコミュニケーション計画が必要です。

主要インシデントワークフローは、チームが積極的に修復を管理していない場合でも、気を散らすことを最小限に抑えるのに役立ちます。

ベンダーインシデント中の推奨事項

社内の窓口担当者を確立

関係を所有するチームから誰かを指定し、ベンダーと連絡を取り続けるか、ベンダーのステータスを監視する
インシデントが継続する場合は、数時間後にこの責任を引き継ぐ

情報共有方法を確立

既存のステークホルダーコミュニケーションチャネルを使用し、チームが予期しない場所で情報を探すことがないようにする

顧客への影響がある場合の対応

ベンダーインシデントが顧客に影響を与える場合は、顧客通知と自社のステータス更新についてサポートチームと連携する

小規模なインシデントへの対応

多くのベンダーインシデントは比較的迅速に解決されます。AWS、Azure、GitHubなどの大規模で複雑なシステムは、サブシステム周辺で定期的に小さなインシデントを起こします。これらは待機するのに十分簡単ですが、生産性に影響を与える可能性があります。これらのインシデントについて考慮すべき点：

デプロイ凍結の判断 – チームがいつ、またはデプロイ凍結を呼び出すべきかを決定し、経営陣レベルのサポートを含むその決定を行う権限を持つ人を決定する
内部コミュニケーションの場所 – 内部コミュニケーションがどこで行われるかを決定し、全員が何が起こっているかを知るようにする
ベンダーステータス監視 – ベンダーステータスを監視し、全員に安全宣言を出すチームメンバーを指定する

大規模なインシデントへの対応

より大規模で広範囲、または長期間のインシデントでは、災害復旧（DR: ディザスタリカバリ）計画が必要になる場合があります。

DR計画で完全なカバレッジを得ることはおそらくないでしょう。少なくとも短期間では、すべてのプロバイダーの完全な冗長性を持つことは稀です。長期間の障害中でも、バージョン管理システムプロバイダーやビルド・デプロイプロバイダーを切り替えるのは困難を伴います。

インフラストラクチャとデータのDR計画はより一般的で、多くの人が可用性を自社で管理する際に念頭に置いているものです。基本的な要素として、次の内容を検討しましょう。

災害宣言とフェイルオーバー開始のタイミング – 顧客への影響、収益への影響、その他の主要指標のしきい値を確立
経営陣の責任とコミュニケーション – 経営陣の責任とコミュニケーションを確立
主要インシデントまたはDRインシデントの開始 – 主要インシデントまたはDRインシデント（持っている場合）を開始し、すべてのチームが警戒態勢に入る
事前定義された成功とQAテスト – 事前定義された成功とQAテストを準備しておく

ポイント5：事後レビューを実施する

重要なベンダーインシデントの後、チームはベンダーが顧客としての信頼を失ったかどうかを判断する立場にあります。この時点で、調達、財務、法務の担当者が関与し、SLA違反があったかどうか、会社がベンダーからクレジットや払い戻しを受ける権利があるかどうかを判断する必要があります。

ベンダーを利用しているチームは、インシデントがベンダー変更を引き起こすのに十分な影響があったかどうかを評価すべきです。インシデント（複数）のコストと切り替えコスト、利用可能な機能を比較検討することは、チームがベンダーが最初から最後までインシデントをどのように処理したかを完全に評価できる、インシデントが終了した後に処理されるべきです。

ポストインシデントレビュー（PIR）の実施

あらゆるPIRと同様に、あなたの行動が効果的だったかどうかを判断し、手順書に必要な更新を行ってください