障害レベルの定義

レベル定義目標復旧時間
Critical全社業務が停止インターネット回線の全断、基幹システム停止、ランサムウェア1時間以内
High部門・特定業務が停止メール障害、特定SaaSの停止、サーバー障害4時間以内
Medium業務に支障があるが代替手段ありプリンター故障、Wi-Fiの一部不安定翌営業日
Low軽微な不具合画面表示の乱れ、非重要アプリの遅延1週間以内

対応フローの全体像

IT障害対応は「検知 → 切り分け → エスカレーション → 復旧 → 報告」の5ステップで進めます。各ステップで判断基準を明確にし、迷わず行動できる体制を構築します。

Step 1:検知

検知ソース

  • 監視ツール:Zabbix、Datadog、Azure Monitor等による自動検知
  • ユーザー報告:ヘルプデスクへの問い合わせ
  • SaaSステータスページ:Microsoft 365 Service Health、AWS Health Dashboard

監視ツールからTeams/Slackへのアラート通知を設定し、障害を最速で検知できる体制を構築します。

Step 2:切り分け

切り分けの手順

  • 影響範囲の確認:全社か、特定部門か、特定ユーザーか
  • 原因箇所の特定:インターネット回線か、社内NWか、SaaS側か、端末側か
  • 直前の変更確認:障害発生直前にシステム変更やアップデートがなかったか
  • SaaS障害の確認:ステータスページ、Down Detector等で外部起因を確認
💡 切り分けの鉄則

「自社起因か、外部起因か」を最初に判断します。M365やAWSの障害であれば復旧はベンダー側の対応を待つしかなく、自社でできるのは影響範囲の把握と代替手段の提供です。

Step 3:エスカレーション

障害レベルエスカレーション先タイミング
Critical経営層 + 外部ベンダー(緊急)即時(検知から15分以内)
HighIT部門長 + 外部ベンダー30分以内
MediumIT部門内で対応翌営業日のMTGで共有
LowIT部門内で対応週次報告に含める

Step 4:復旧

  • 暫定対応:代替手段の提供(例:Wi-Fi障害→有線接続に切り替え、SaaS障害→モバイル回線でアクセス)
  • 恒久対応:根本原因の修正(機器交換、設定変更、ベンダーへの修正依頼)
  • 復旧確認:障害が解消されたことをユーザーに確認
  • 周知:全社への障害報告と復旧報告

Step 5:報告とポストモーテム

障害報告の記録項目

項目内容
障害番号INC-2026-001
発生日時2026/03/01 10:00
検知日時2026/03/01 10:05
復旧日時2026/03/01 11:30
影響範囲営業部20名のメール送受信不可
原因Exchange Onlineのサービス障害
対応内容Microsoft側の復旧を待機。OWAでの暫定対応を案内
再発防止策Service Healthアラートの自動通知を設定

SLA設計の考え方

社内向けのSLA(サービスレベルアグリーメント)を定め、IT部門の対応品質を可視化します。

指標定義目標値例
初回応答時間報告を受けてから最初の応答までCritical: 15分、High: 30分
復旧時間障害発生から復旧まで障害レベルごとに設定
可用性月間のサービス稼働率99.5%以上

BTNコンサルティングの支援

IT障害対応フローの策定、監視環境の構築、SLA設計、ポストモーテム運用の導入を支援します。

まとめ

IT障害対応は「検知→切り分け→エスカレーション→復旧→報告」の5ステップで体系化します。障害レベルの定義とエスカレーション基準を事前に決めておくことで、パニックなく冷静に対応できます。

障害対応の準備と振り返り

障害発生時に迅速に対応するためのツールを事前に整備しましょう。検知にはM365サービス正常性ダッシュボードが有効です。コミュニケーションにはTeamsの障害対応チャネルを事前作成します。記録にはSharePoint Listsのインシデント管理リストで発生日時・影響範囲・対応状況・原因・再発防止策を一元管理します。インシデント解決後72時間以内にポストモーテムを実施し、タイムライン整理と根本原因分析を行いましょう。