自社のログには異常が見つからず、クラウドサービスの状況ページを開いて「うちじゃないかもしれない」と確かめている保守運用の担当者
障害対応・運用監視約14分

クラウド・SaaSの障害を疑うとき｜確認手順と社内への説明

朝からシステムが不安定で、問い合わせが増えている。 ログを見ても、いつもと違うエラーは出ていない。デプロイもしていない。設定も触っていない。

——これ、たぶんうちじゃない。

そう思っても、確証がないうちは言い出しにくいものです。「他社のせいにしている」と受け取られたくないし、あとで自分側の問題だと分かったときが気まずい。だから確認を続けるのだけれど、その間も「まだ直らないの」という視線は自分に向いている。

この「言い出しにくさ」は、あなたが弱気だからではありません。他社側の障害は、こちらから直接見えない場所で起きている——ただそれだけの理由で、確認にも説明にも一手間かかるだけです。この記事では、その一手間を短くする順番と、確証がない段階でも誠実に伝えられる言い方を一緒に整理していきます。

結論：やることは3つです。①「自分側で説明がつくか」を先に短く潰す（直近の変更・自分だけの環境・リソースの3点）、②止まっていそうな場所を「自分側・サービス側・回線」の3層に分けて、公式のステータスページから順に見る、③確証が取れる前でも「今わかっていること／わかっていないこと／次にわかる時刻」の3点だけ社内に出す。原因が他社側かどうかより、待っている人を放置しないことのほうが先です。

なお、使っているクラウドやSaaSによって、見る場所も情報の出方も変わります。ここで挙げるのは順番の型です。自分の現場で契約しているサービスに置き換えながら読んでみてください。

なぜ「他社側かもしれない」は判断がむずかしいのか

腕の問題ではなく、構造として見えにくい事情がそろっています。

だから最初にやるのは、他社側の証拠探しではありません。自分側の可能性を短く潰して、疑う場所を絞ることです。ここを飛ばすと、ステータスページを何度も更新しながら時間だけが過ぎていきます。

ステップ1：まず「自分側で説明がつくか」を短く潰す

他社を疑う前に、自分側を疑います。順番が逆だと、あとで自分側の原因が見つかったときに戻れなくなるからです。ただし、時間はかけません。次の3点だけです。

  1. 直近で何か変わっていないか。自分のデプロイだけでなく、他の人の作業、自動更新、証明書の期限、cronの追加も含めて見ます。変更管理台帳を付けていれば、ここは数分で終わります。
  2. 自分の環境だけの話ではないか。別の回線（スマホのテザリングなど）、別のブラウザ、別の端末から同じ症状が出るかを試します。社内からだけ遅いなら、社内ネットワーク側の話かもしれません。
  3. サーバーのリソースが足りているか。CPU・メモリ・ディスク・プロセス数をひととおり。ここが原因なら他社は関係ありません（ロードアベレージの読み方、ディスク使用率の監視が土台になります）。

3つとも空振りなら、ここで初めて「自分側では説明がつかない」と言える状態になります。この一言が言えるだけで、社内での説明はぐっと楽になります。「調べたけれど分からない」ではなく「調べた結果、自分側では説明がつかない」は、まったく別の報告です。

ステップ2：止まっていそうな場所を3層に分ける

障害の発生場所を「自分側」「サービス側」「回線」の3つの層に分けて順番に確かめる考え方を示した図
疑う場所を3つに分ける。層が決まると、見にいく情報源も自然に決まる

自分側で説明がつかないと分かったら、残りを3つに分けます。

分ける意味は、層ごとに見にいく情報源が違うことにあります。サービス側なら公式のステータスページ、回線ならプロバイダの障害情報と経路の確認。分けずに探すと、どこを見ればいいのか決まらないまま検索を繰り返すことになります。

見分けの目安は、「どの機能が壊れているか」です。

ステップ3：公式のステータスページから順に見る

層が絞れたら、情報源を順番に見ます。先に公式、あとから外の声です。逆にすると、噂に振り回されて判断が遅れます。

1. 各サービスの公式ステータスページ

主要なクラウドは、自社で稼働状況を公開しています。AWSなら「AWS Health Dashboard」、Google Cloudなら「Google Cloud Service Health」、Microsoft Azureなら「Azure Status」といった名前で提供されています。国内のホスティング事業者やSaaSも、たいていは「障害情報」「メンテナンス情報」のページを持っています。

見るときのコツは3つです。

2. ベンダーの公式アナウンス窓口

ステータスページとは別に、公式のお知らせページやサポート窓口があります。契約しているサービスなら、問い合わせる権利があります。「障害ですか」と聞くのは、クレームではなく正当な確認です。遠慮しなくて大丈夫です。

3. 外の声（利用者の投稿・障害情報の共有サイト）

公式に出る前は、ここがいちばん早いことがあります。ただし裏が取れていない情報なので、社内に伝えるときは必ず「公式ではまだ発表されていない」と添える。ここを省くと、あとで訂正することになります。

4. 自分側からの実測

情報を待つ間、こちらでも測っておきます。エラー率・応答時間・失敗した時刻を記録しておくと、あとでベンダーに問い合わせるときの材料になり、社内向けの説明にも使えます。

# 対象サービスの応答時間を1分おきに記録しておく（記録が説明の材料になる）
while true; do
  printf '%s ' "$(date '+%Y-%m-%d %H:%M:%S')"
  curl -o /dev/null -s -w 'code=%{http_code} time=%{time_total}\n' \
    https://api.example.com/health
  sleep 60
done | tee -a /tmp/health-check.log

エラーの出方が「たまに失敗する」タイプなら、タイムアウトがどこで起きているかの切り分けや外部API連携の切り分けも合わせて見ると、層の判断がはっきりします。

ステップ4：確証がなくても、社内には出す

いちばん悩ましいのがここです。「他社側だと思うけれど、確証がない」段階で、何と言えばいいのか。

答えはシンプルで、確証がないことも含めてそのまま伝えるです。推測を断定に変える必要も、黙って抱える必要もありません。出すのは次の3点だけです。

  1. 今わかっていること（症状・範囲・発生時刻）
  2. 今わかっていないこと（原因と復旧見込み）
  3. 次に報告する時刻

文例です。そのまま調整して使ってください。

【第一報】○月○日 ○:○○ 現在、△△機能でエラーが発生しています。

・症状：○:○○ ごろから、△△の処理が断続的に失敗しています（成功する場合もあります）。
・範囲：△△機能のみ。他の機能は通常どおり動作しています。
・現在の状況：当社システム側では変更・異常を確認できておらず、利用している外部サービス側の不具合の可能性を確認中です。外部サービスの公式発表はまだ出ていません。
・対応：ベンダーへ確認を依頼し、あわせて当社側でも調査を続けています。
・次のご報告：○:○○ ごろ、状況が変わらない場合も改めてご連絡します。

伝え方のポイントは3つです。

具体例：「朝から画像のアップロードだけ失敗する」

ある朝、「商品画像を登録しようとするとエラーになる」という問い合わせが数件届いた、という場面で追ってみます。

ステップ1（自分側を潰す）：直近のデプロイなし。設定変更なし。証明書の期限も先。ディスクにもメモリにも余裕あり。自分の端末からも同じ症状が出るので、特定の人の環境の話でもない。——自分側では説明がつかない。ここまで10分。

ステップ2（層を分ける）：壊れているのはアップロードだけで、閲覧も注文も動いている。特定の機能だけなので、その機能が使っているもの——外部のストレージサービス——を疑う層に置く。

ステップ3（情報源を見る）：使っているクラウドのステータスページを開くと、自分のリージョンのストレージサービスに「調査中」の表示。更新時刻は15分前。ここで、当たりがついた。

ステップ4（社内に出す）：確証としては「ベンダーが調査中と発表している」段階なので、そのまま書く。「アップロード機能のみ停止中。利用しているストレージサービス側で障害が発生していると発表がありました。復旧見込みは未定です。次は11時に報告します」。あわせて、アップロードだけを一時的に止めて案内文を出すか、業務側と相談する。

ここで大事なのは、11時までにやることが決まっていることです。ベンダーの復旧を待つ間、こちらは記録を取り、影響範囲を数え、代替手段があるかを業務側と詰める。待っている時間も、手ぶらではありません。

影響：判断の順番を持つと、何が変わるか

他社側の障害は、こちらの努力では復旧できません。だからこそ、復旧できない時間に何をしたかが仕事になります。

明日やること：確認先を1枚にまとめる

障害が起きてから探すと、それだけで15分溶けます。平時のうちに1枚作っておきます。

作るのは、こんな表です。

使っているサービス用途（止まると何が壊れるか）確認先（ステータスページ・お知らせ）問い合わせ窓口契約者・アカウント
クラウド（サーバー・ストレージ）全体公式ステータスページサポート窓口誰の契約か
決済サービス決済のみ障害情報ページ加盟店サポート契約担当
メール配信通知メール障害情報ページサポート窓口契約担当
回線・プロバイダ通信全体障害・工事情報法人窓口契約担当

ポイントは、ステータスページのURLをブックマークに入れておくこと、そして「止まると何が壊れるか」を先に書いておくことです。症状から逆引きできるので、障害の最中に「これはどのサービスだ」と考えずに済みます。

サービスの棚卸しがまだなら、サーバー・サービスの構成情報を1枚にまとめる方法や運用の年間スケジュールと同じ紙にまとめてしまうのが早いです。項目が増えすぎたら、まずは止まると困る上位3つだけで構いません。

「他社側の障害を疑うとき」チェックリスト

全部そろわなくても大丈夫です。上から3つできていれば、その障害対応はもう十分に前へ進んでいます。

よければ、こちらも

障害の原因が外部サービス側だと確認できて、社内への報告を書き終え、肩の力が抜けた保守運用の担当者

他社側の障害は、直せません。自分でボタンを押して復旧させることができない、保守運用の中でもいちばん歯がゆい時間です。

それでも、あの朝に「うちじゃないかもしれない」と気づいて、順番に確かめて、待っている人に途中経過を伝えた——その一連は、確実に誰かの不安を減らしています。復旧させた人だけが仕事をしたわけではありません。分からない時間を、分からないまま丁寧に扱えることも、立派な技術です。

明日は、よく使うサービスのステータスページをブックマークに1つ入れるところからで十分です。次に同じ朝が来たとき、15分早く落ち着けます。

ほかの実務ヒントは記事一覧からどうぞ。保守運用の小さな備えを、メールでも少しずつお届けしています。

関連用語