この記事の要点
- 一次対応の目的は原因を突き止めることではなく、影響を確かめ、広がりを抑え、決めた相手へ早く知らせることです。
- クラウドの事業者の障害かどうかは、各社が用意する自分の環境向けの障害情報（AWS Health・Azure Service Health・Personalized Service Health）で確かめます。
- 夜間・休日は、手順書にもとづいて通知を受けて切り分ける役割と、営業時間内に原因を直す役割を分けると、少ない人数でも体制を組めます。
クラウドで障害が起きたときの一次対応は、影響の範囲を確かめ、クラウドの事業者の障害か自社の側の問題かを切り分け、手順書にある初動を行い、決めた相手へ連絡することです。一次対応の目的は、原因をその場で突き止めることではなく、被害の広がりを抑え、判断する人に早く正しい情報を届けることにあります。
障害のときに慌てないためには、何が起きたら誰が何をするかを、平常時に決めて書いておくことが欠かせません。この記事では、一次対応の流れ、クラウドの事業者の障害情報の確かめ方、連絡の流れ、手順書の書き方を説明します。セキュリティの事故を含めた対応の計画の全体は、セキュリティ事故に備える、初動の手順書のつくり方にまとめています。
一次対応の流れ
一次対応は、次の順番で進めます。
- 気づく：監視の通知や、利用者・社員からの連絡で、異常に気づきます
- 影響を確かめる：どのシステムの、どの機能が、どの利用者に使えないのかを確かめます
- 切り分ける：クラウドの事業者の障害か、自社の設定・アプリケーション・最近の変更が原因かを見分けます
- 初動を行う：手順書にある範囲の対応（再起動、切り戻し、利用者への案内の表示など）を行います
- 連絡する：決めた相手へ、分かっていることと分かっていないことを分けて知らせます
- 記録する：気づいた時刻、行ったこと、その結果を、時刻つきで残します
2つ目と3つ目は、同時に進めることもあります。大事なのは、手順書にない対応をその場の判断で次々に試さないことです。原因が分からないまま設定を変えると、障害が広がったり、後で原因を調べる手がかりが消えたりします。手順書の範囲で収まらないときは、判断できる人へ引き継ぎます。
6つ目の記録は、後で原因を調べ、再発を防ぐための材料になります。対応しながら記録するのは負担ですが、チャットの専用の部屋に時刻つきで書き込むなど、手軽に残せる形を決めておきます。
クラウドの事業者の障害かどうかを確かめる
切り分けで最初に確かめたいのは、クラウドの事業者の側で障害が起きていないかです。3つのクラウドは、それぞれ自分の環境に関わる障害の情報を見る仕組みを用意しています。
AWS：AWS Health
AWS Health は、自社の資源の状態と、AWS のサービスとアカウントの可用性を知らせる仕組みです。AWS Health Dashboard は、設定なしで、すべての利用者が追加の料金なしで使えます。障害の情報（イベント）は、Amazon EventBridge を通して、追加の料金なしで受け取ることもできます。
Microsoft Azure：Azure Service Health
Azure Service Health は、3つの仕組みの組み合わせです。Azure の状態のページは、すべての Azure のサービスと地域の全体の様子を示します。Service Health は、自社が使っているサービスと地域に絞って、障害・計画された保守・注意の情報を知らせます。Resource Health は、特定の仮想マシンなど、個別の資源の状態を示します。Microsoft は、全体の状態のページは広い範囲の障害の参考になるとしたうえで、利用者には Service Health で障害と保守の情報を受け取るよう勧めています。
出典：What is Azure Service Health?（Microsoft Learn）
Google Cloud：Personalized Service Health
Google Cloud の Personalized Service Health は、自社のプロジェクトに関わる障害の情報を示す仕組みで、Google は障害の情報の主な経路と位置づけています。障害の情報は Cloud Logging に記録され、新しい障害が報告されたときや、障害の情報が更新されたときに通知を受ける設定ができます。
出典：Personalized Service Health overview（Google Cloud）
どのクラウドでも、全体向けの状態のページだけを見るより、自分の環境向けの情報を見るほうが、自社に関わる障害かどうかを早く判断できます。障害の通知を、監視の通知と同じ受け先に届くように設定しておくと、切り分けの時間を短くできます。
クラウドの事業者の障害だと分かった場合、自社でできることは限られます。影響を受けている機能を確かめ、利用者への案内を出し、事業者の情報の更新を見守ります。別の地域に切り替える仕組みを用意している場合は、手順書に従って切り替えるかを判断します。過去の大規模な障害から学べる備えは、クラウドの大規模障害から学ぶ、備えておくことで説明しています。
連絡の流れを決めておく
障害のときは、誰に、どの順番で、何を伝えるかを、平常時に決めておきます。
| 決めること | 中身 |
|---|---|
| 連絡の相手 | システムの責任者、業務の責任者、経営者、委託先、必要に応じて利用者や取引先 |
| 連絡の基準 | どの程度の影響なら、誰まで知らせるか |
| 連絡の手段 | 電話・チャット・メールのどれを使うか、つながらないときの次の相手 |
| 伝える中身 | 起きていること、影響、行っている対応、次に知らせる時刻 |
伝える中身では、分かっていることと分かっていないことを分けて書きます。「原因は調査中です。次は30分後にお知らせします」のように、次に知らせる時刻を添えると、受け取った人が何度も問い合わせずに済みます。
利用者や取引先への案内を出すかどうかは、業務の責任者が判断できるよう、基準を決めておきます。個人の情報の漏えいが疑われる場合など、法令にもとづく報告が関わる場面は、一次対応の担当だけで判断せず、計画に沿って責任者へ引き継ぎます。個別の判断は弁護士などの専門家にご確認ください。
手順書（ランブック）の書き方
手順書（ランブック）は、通知を受けた人が、その場で読んで動けるように書きます。
- きっかけ：どの通知、どの症状のときに使う手順か
- 最初に確かめること：見る画面、確かめる指標、事業者の障害情報
- 行ってよい対応：再起動・切り戻しなど、一次対応の担当が判断なしで行ってよい範囲
- 行ってはいけない対応：データの削除や大きな設定の変更など、判断できる人に引き継ぐもの
- 連絡先：引き継ぐ相手と、つながらないときの次の相手
- 記録の残し方：どこに、何を書くか
手順書は、実際に使ってみると足りないところが見つかります。障害が起きた後や、訓練のたびに見直し、使えない手順書のまま置いておかないようにします。訓練の進め方は、復旧の目標（RTO・RPO）の決め方と、復旧の訓練をご覧ください。
夜間・休日の一次対応
夜間・休日も一次対応が要るシステムでは、通知を受けて切り分ける役割を、誰が担うかを決めます。社内に当番を置く方法のほかに、手順書にもとづいて一次対応を行う外部の専門の会社に任せる方法があります。
外部の会社に任せる場合は、手順書が一次対応の範囲を決める契約の中身になります。行ってよい対応と、引き継ぐ相手を手順書にはっきり書いておかないと、夜間に判断が止まったり、反対に、任せていない対応まで行われたりするおそれがあります。夜間・休日に受けて切り分ける役割と、営業時間内に原因を調べて直す役割を分けると、社内の担当者が毎晩起きている必要はなくなります。24時間の監視を仕組みと人の対応に分ける考え方は、クラウドの監視は何を見るのか。死活・リソース・アプリで説明しています。
当社のご支援
当社は、クラウドの障害のときの連絡の流れと手順書づくり、監視の通知の設計を、クラウドの構築と運用管理でお手伝いしています。運用管理をお任せいただく場合、夜間・休日の通知の受け付けと一次対応は、当社が作った手順書にもとづいて外部の専門の会社が担い、原因の調査と再発の防止、月次の報告は当社が営業時間内に行います。夜間・休日の監視と初動は、内容に応じてお見積りします。
- 障害対応
- クラウド
- 運用
- 手順書
この記事に出てくる用語
このコラムは一般的な情報の提供を目的としたもので、個別の状況への助言ではありません。製品・サービスの名前と内容は、記事の更新日の時点のものです。