導入
Webサイトのダウンは、サービス停止だけでなく、ユーザ信頼の喪失、売上減、ブランド価値の低下につながります。数時間、あるいは数日間の障害は、ビジネスにとって致命的です。そこで本稿では、障害が発生した際に「即座に状況を把握」、適切に「対処し、再発を防止する」ための完全マニュアルをまとめます。
現場で何を、いつ、誰が行うべきかをチェックリスト化し、緊急時に慌てないようにします。
1. 障害発生のサインと初期情報収集
- アクセス数の急激低下
- 例：ログ平均アクセス数（1/2時間）と比較し、閾値（例 ‑ 70％）を下回るとアラート
- エラー率の急増
- 500系ステータスコードが10分間で3倍以上増加
- サーバレスポンス遅延
- Ping / traceroute で応答時間が1 sを超える場合
- バックログの発生
- RabbitMQ / Kafka のキューが数倍増大
初期情報収集は「Who / When / What」を素早く掴むことが鍵です。
# サーバ状況の確認
top -bn1 | grep -i cpu
df -h
uptime
また、ログを一括取得するスクリプトを用意し、即座にログファイルを集約してもらうことが推奨されます。
2. 初期対応フロー（SLA: 5 分以内）
| 時間 | タスク | ステータス |
|---|---|---|
| 0‑1 min | インシデント発報 → Incident Owner を決定 | ✅ |
| 1‑3 min | 可用性チェック → サーバ/サービス が応答しているか | 🟠 |
| 3‑5 min | 失敗箇所特定 → エラーログ を 1 min ごとに取得 | ⏳ |
| 5‑10 min | Fallback への切り替え → CDN キャッシュ/読み込み先の切替 | ❕ |
2‑1. サービスステータスページの更新
ユーザーはダウン情報を一目で把握できるように、[statuspage.io] などの専用サービスで「Maintenance」状態を表示。
2‑2. モニタリングダッシュボードの点検
Prometheus・Grafana（または New Relic, Datadog）のダッシュボードで、
- CPU / Memory
- I/O
- ネットワーク帯域
- DB スロークエリ を確認。
3. コミュニケーション & 連携
- 社内: Slack #incident、Teams channel で情報共有。
- 顧客:
- Web: 「現在障害が発生中です。ご迷惑をおかけします。」
- SNS: Twitter, LINE公式アカウントで進捗報告。
- パートナー: API を経由するサービスに対し、Webhook で障害情報を送信。
- 運用チーム: PagerDuty / Opsgenie でオンコール担当へ自動アラート。
4. 原因究明（根本原因分析）
4‑1. データ収集
- ログ：/var/log アクセス/エラーログ、application logs
- メトリクス：Prometheus の tsdb, ElasticSearch
- トレース：OpenTelemetry、Jaegerで分散トレース
4‑2. 分析手順
- 時間軸に沿って エラー発生時刻 をピンポイント化。
- リソース枯渇（メモリ/CPU）か、インフラ障害（ハードウェア、ネットワーク）かを判断。
- トランザクション経路を逆解析し、ボトルネック箇所を特定。
- コード/設定の変更・デプロイが影響していないかを確認。
4‑3. 根本原因の記録
Post‑mortem 形式で、問題点・修正点・再発防止策をまとめ、GitHub Wiki へリポジトリ化。
5. 再発防止策（対策の実装）
| カテゴリ | 対策 | チェック項目 |
|---|---|---|
| インフラ | オートスケーリング、マルチAZ配置 | 各 AZ の稼働率、スケールアウト閾値 |
| ネットワーク | WAF, CDN で DDoS 保護 | 2GBit 以上の帯域設定、リクエストレート制限 |
| データベース | 10% 余裕のリダンダンシー、リードレプリカ | レプリケーション遅延低減 |
| サービス | Blue/Green デプロイ | 0.1 以上のトラフィックでステージング |
| モニタリング | すべてのエンドポイントでアラート | 30 秒ごとのヘルスチェック |
| コード | 静的解析、CIテスト統合 | 静的コード解析ツール（SonarQube）で CVE 発見 |
| 運用 | 定期的な DR Drills | バックアップ・復旧の 90 % 成功率 |
6. 監視とアラート設計
- メトリクス
- HTTP Response Time (P95, P99)
- Error Rate (500, 502, 504)
- Database Connection Count
- Disk I/O Latency
- アラート閾値
- 警告: 3分連続で Error Rate > 5%
- 致命: 5分連続で CPU > 90% かつ Response Time > 2s
- アクション
- 自動スケールアウト
- Auto‑heal スクリプト（例：
systemctl restart nginx） - PagerDuty で 5min 以内にオンコールへ通知
7. インフラ設計のベストプラクティス
| スタック | 推奨構成 | 補足 |
|---|---|---|
| Webサーバ | Nginx + 3台以上 | ロードバランサー前に配置、HTTP/2 Enable |
| アプリサーバ | Docker Swarm / Kubernetes (K8s) | Liveness/Readiness Probe で自動再起動 |
| DB | PostgreSQL / MySQL + 2 リードレプリカ | ストリングリーダーのフェイルオーバー自動化 |
| Cache | Redis Cluster | スラッシュリクエストは 2 秒以内に応答 |
| Storage | AWS S3 + CloudFront | 静的コンテンツは CDN 配信、オリジンがオフライン時は 302 リダイレクト |
8. コミュニケーション戦略（顧客向け）
- 即時通知：障害発生確認後10分以内に「障害報告」を送信。
- 進捗報告：10分ごとに状況を更新し、次のステップを明示。
- 謝罪・説明：原因と対策を簡潔に説明し、再発防止策を約束。
- 事後対応：障害復旧後に調査レポートを公開、FAQを更新。
- フィードバック：顧客からの意見を次回改善に反映。
9. コード品質とデプロイの安全策
- CI/CD パイプライン
- ビルド → スタティック解析 → ユニットテスト → スモークテスト → ステージング → 本番
- コードレビュー
- 変更提案は必ず 2 人以上のレビュー担当が同意。
- テスト網
- 単体テスト 80% 以上、統合テスト 70% 以上、パフォーマンステスト（JMeter）
- リグレッション
- 本番データベースに影響が無いよう、Shadow Deploy（実際には走らせない）
10. ビジネス継続計画（BCP）とディザイルプラン
- バックアップ：DB データは 15 分ごとにスナップショット、 S3 で 5 か月の保持。
- フェイルオーバー：DNS TTL 10 秒で切り替え。
- ディザイルリハーサル：年 2 回、サーバ停止を想定した全社演習。
11. ドキュメント化と運用の定期見直し
- インシデントレポート（Incident Report）を GitHub Issue 生成し、ラベル付け。
- Post‑mortem では Lessons Learned を「改善」「次回対策」に分ける。
- 監視アラートは 3 年ごとに再評価。
- 主要依存ライブラリの依存関係を Dependabot で監視。
12. ケーススタディ
- 大規模なトラフィック増
- 原因：WAF で正規リクエストをブロック。対策：WAF のルールを緩め、同時に CDN キャッシュ時間を延長。
- DB 接続数 失敗
- 原因：接続プール数不足。対策：
max_connectionsをリードレプリカに合わせて増やし、アプリ側でもプール設定をチューニング。
- 原因：接続プール数不足。対策：
まとめ
Webサイト障害対応は準備と即時行動が不可欠。
- 準備：インフラ冗長化、モニタリング、自動復旧スクリプト
- 即時：SLA 5 分以内に情報共有とファンクション切替
- 再発防止：根本原因分析＋PDCA サイクルで改善を継続
このマニュアルに沿ってインシデント時の手順を固めることで、ダウンタイムの影響を最小化し、顧客信頼を維持できます。ぜひ、社内で共有し、年 2 回の演習で実装を検証してください。
コメント