🎬 事象概要（現場シナリオ）
午前10時ごろ。社内チャットツールで次のような報告が相次ぎました。
「勤怠システムにログインできません」
「社内Webツールの画面が開かないです」
「TeamsやSlackは動くのに、自社アプリだけエラーになります」
ネットワーク監視ツールを見ると、
ルーター・スイッチ・社内LANすべて正常稼働（グリーン）。
他の外部サイト（Google・Yahoo）は問題なく閲覧できる状態です。
つまり――
🧩 社内の通信経路は正常なのに、“特定のサービスだけ”使えない。
この時点で疑うべきは、
クラウド（AWS）側での障害 です。
🧭 トラブルシューティングの目的
「社内ネットワークではなく、AWSなど外部サービスが原因かどうかを切り分ける」
を目的として、以下の手順で確認します。
🪜 ステップ①：ネットワーク層の確認（自社側は正常か）
まずは、物理・LAN・インターネット接続を確認します。
ping 8.8.8.8
✅ 応答あり → インターネット接続は正常。
tracert 8.8.8.8 # Windows
traceroute 8.8.8.8 # Mac
最終ホップまで経路到達 → ルーティング問題なし。
👉 この時点で社内LAN・ゲートウェイ・外部回線は正常。
⚙️ ステップ②：社内サービスの通信確認
社内で使っているWebツールのドメインにpingを打ちます。
例：
ping internal-app.company.co.jp
📋 結果：
Ping request could not find host internal-app.company.co.jp.
Please check the name and try again.
➡ 名前解決できない／応答なし。
DNSまたはAWS上のロードバランサーに到達していない可能性。
🧪 ステップ③：経路追跡でAWS側を確認
tracert internal-app.company.co.jp # Windows
traceroute internal-app.company.co.jp # Mac
📋 結果例：
1 <社内ルーター> 192.168.10.1
2 <プロバイダゲートウェイ>
3 <AWSリージョン内IP> 13.115.xxx.xxx
4 要求がタイムアウトしました
➡ AWSリージョン（東京など）までは到達するが、
その先（EC2/ALB）で応答が途絶。
AWS側の障害を疑う状況です。
🔍 ステップ④：ポート・セッション状況を確認
ネットワーク層ではping通るが、アプリ層が反応しない場合、
アプリポート（例：443/TCP, 80/TCP）での疎通を確認します。
🪟 Windows
netstat -an | find "443"
🍎 Mac
netstat -an | grep 443
結果：
- TIME_WAIT／SYN_SENTが大量発生 → サーバー応答がない状態
- ESTABLISHEDが存在しない → コネクション確立不能
💡 つまり、通信経路は生きているが、AWS側サーバーが応答していない。
☁️ ステップ⑤：外部障害情報の確認
AWSやクラウドサービスの障害は、自社ではどうにもできません。
まずは、外部障害情報サイトで最新情報を確認します。
🔗 DownDetector（ダウンディテクター） - AWS障害情報
または
🔗 AWS Service Health Dashboard（公式）
📋 例：
AWS Tokyo Region で EC2／ALB／Route53 の障害が報告されています。
一部のWebサービスで接続不能が発生中。
✅ 自社サービスはAWS上で稼働しており、障害の影響を受けていた。
🧰 ステップ⑥：対応と社内アナウンス
1️⃣ 確認したこと
- 社内ネットワーク・回線：正常
- 他サイト（Google等）：正常
- AWSホスト：応答なし
- 外部障害サイトでAWS障害を確認
2️⃣ アナウンス例
現在、AWS東京リージョンの障害により、
社内Webツール・勤怠システム・経費管理などが一時的に利用できません。
復旧までしばらくお待ちください。
社内ネットワークには問題ありません。
3️⃣ 復旧確認
AWS側の障害復旧報告後、再度ping／tracertを実施。
サービス応答を確認して、ユーザーに通知。
🧾 ステップ⑦：社内報告書
【ネットワーク障害対応報告】
- 発生日：2025年10月22日 10:10
- 対象：社内クラウドサービス（AWS上）
- 現象：社内Webツール・勤怠システムが接続不可
- 調査結果：
- 社内LAN・回線：正常
- 外部サイト（Google, Yahoo）：正常
- ping/tracert：AWSリージョンで応答停止
- netstat：443/TCPコネクション未確立
- 外部情報：AWS東京リージョン障害発生中（DownDetector確認）
- 原因：AWS側の一時的な障害（EC2/ALB停止）
- 対応：社内アナウンス実施・障害復旧後動作確認済み
- 再発防止：AWSステータス監視・外部通知体制の強化
✅ まとめ（学びと教訓）
| 項目 | 内容 |
|---|---|
| 💡 切り分け | 社内LANが正常なら外部（クラウド）障害の可能性を疑う |
| 🌐 コマンド | ping / tracert / netstat を組み合わせて判断 |
| ⚙️ 外部確認 | DownDetector や AWS公式ページで確認 |
| ☁️ 原因 | クラウド事業者側（AWSなど）の一時的障害 |
| 🧾 対応 | 社内通知＋監視継続、復旧確認を必ず行う |