システム障害の発生から完了までのプロセス – ５つのSTEPと作業内容

はじめに

システム障害は突然発生します。
また、障害内容には軽微な事象から事業継続に影響ある大きなトラブルまで幅広く、何が起きるかわかりません。

しかし障害対応は迅速、かつ的確に行うことが要求されます。
発生時点で即時対応することで被害を最小限に食い止めることもできます。
逆に対応を誤ることで被害が拡大することもあります。

そのため障害対応ではあらかじめトラブルに備えた事前準備と、正しい処置プロセスの整理している必要があります。

トラブルの事前準備については「システム障害に備えた事前準備」で解説しているので、ここでは正しい処置プロセスについて解説します。

この処置プロセスは次の５つに分けられます。

• STEP1：初動対応
• STEP2：影響調査
• STEP3：原因調査
• STEP4：復旧対応
• STEP5：事後対応

まず、解説に入る前にシステム障害の定義を確認します。

システム障害
システム障害とは、情報システムがアプリケーションの不具合やインフラ故障などの問題が発生し、正常なサービス提供ができない状態です。
もちろんマルウェア感染やセキュリティインシデントでトラブル発生することも同様です。

システム障害が発生すると、業務やサービス提供に影響することが多いです。
もし影響が出ていなくても、放置しておくと将来的に悪影響が出る場合もあるため対策が必要です。

システム障害対応
システム障害対応の目的は、故障部分を修理したり、不具合プログラムを修正リリースすることではなく、業務やサービスを継続できる状態にすることです。

ユーザはシステムを使うことが目的ではなく、業務遂行であったり、サービスを受けたいためにシステムを利用するのです。
システムを正常にするために修理やリリース作業を行うのですが、業務やサービス提供の影響を最小限となるような取り組みが求められます。

STEP1：初動対応

システム障害が発生したときに、まず最初にやるべきことを記載します。
この初動対応を誤ると復旧まで時間がかかったり、２次被害が発生する可能性があります。

まずシステム障害に備えた準備として、初動対応するための運用フローや調査手順はあらかじめ用意すべきです。
障害対応は一刻を争う状態なので、現場担当の判断に任せるのではなくルール化することで、迅速な対応と判断誤りの抑止につながります。

事象確認

監視ソフトによる検知、またはユーザから障害レポートを受けたとき、障害の事象を概要レベルで確認します。
詳細レベルまで調査を始めると初動対応が遅れるため、要点を絞って調査をします。
確認ポイントは以下のとおり。

• 対象（画面やサーバ名称など）
• 発生している事象
• 発生時刻
• 障害レポートの発生元
• 障害レベル（緊急性、影響範囲、業務影響）
• 再現性（特定ユーザか全体か。同現象が再現させられるか）

ちなみにシステム構築時の非機能要件において、障害検知の監視方法を定義します。
システムの監視がないとトラブル検知が遅れて被害拡大する可能性があります。
無料で利用できる統合監視ツールもあるので検討しましょう。

エスカレーション

障害発生時、あらかじめ計画を立てた報告ルートに則ってエスカレーションします。

もしルールが決まっていなければ、リーダやPM、顧客に報告しますが、エスカレーション先を誤ることで現場が混乱したり、後から大問題になる可能性があります。
障害レベルによってエスカレーション先も異なってくるため、エスカレーションルールは用意しておくべきです。

エスカレーションでは、詳細情報を伝えるより迅速な報告が必要です。
特に緊急性の高い障害の場合は一分一秒を争う場合もあります。
まずはシステム障害対応の責任を取れる人まで報告することが大切です。

ここで「詳細情報を伝えるより」と言いましたが、誤った情報や曖昧な表現は厳禁です。
わからない点は「わからない」とはっきり伝えます。
また中途半端に断片的な情報を伝えるのは誤解を招く恐れがあります。
例えば、A、B、Cの機能があったとして「Aは問題ありません」とだけ伝えると、聞く人によっては緊急度が低いと感じてしまうかもしれません。
後から「A、Bは問題ないがCに問題あった」と言われても困ります。
そのため「Aは問題なし。B、Cは調査中」のように、確認していることは抜け漏れなく報告するようにします。

エスカレーションしたら、今後の対応方針を報告先と調整します。
まず回避策を取るべきなのか、先に調査すべきことがあるか、など直近タスクの認識合わせを行います。

回避策（ワークアラウンド）

システム障害が問題なのは業務継続できなかったりサービス提供が止まるためです。
もし業務継続するための回避策があれば、その対処をします。
例えばサーバ故障が発生したときに、サーバが冗長化されていればサーバ切り替えで運用継続させます。
もしアプリ不具合で申請業務ができない場合、紙で代替運用することも該当します。
とにかく業務影響を最小化することを第一に考えます。

システムが冗長化されている場合、稼働サーバの切り替えなどで業務継続することを最初に考えます。
冗長化については、別記事「冗長化の目的と種類、構成」を参考にしてください。

情報収集

影響調査や原因調査を行うための情報を採取します。
システム障害発生時に採取しないと失われる情報もあるため、漏れなく情報収集を行います。
しかし情報収集のために業務再開ができないというのも本末転倒なので、あらかじめ障害発生時に採取すべき情報と、落ち着いてから採取する情報など整理する必要があります。

慌てて情報取得しようとして２次被害が発生することもあるので、採取方法は手順書やツールを事前準備しておきます。

STEP2：影響調査

業務影響調査

システム障害の発生により、ユーザに影響を与える範囲を調査します。
確認するのは「利用しているユーザや業務で問題が発生していないか」という観点で調べます。
ここで確認した業務影響の内容によって緊急度や体制にも影響が出てきます。

例えばシステム停止という障害が発生した場合、サービス利用時間なのか、利用時間外なのかによって対処が変わってきます。
またアプリケーション不具合で登録処理に問題があった場合、登録エラーで先に進めない場合と、誤った内容でデータ更新する場合でも異なります。
後者の場合、時間が経つほど被害が大きくなるためシステム全体を停止することも視野に入れます。

他システムへの影響確認

障害が発生したシステムと関連している他システムに影響が波及していないか確認します。
もしデータ連携している他システムがある場合、データを受け取れないことで相手側のシステムに悪影響を与えるかもしれません。
または誤ったデータを送り続けることで、相手側に取り返しのつかない被害を与える可能性もあります。

他システムと連携している場合、相手先との連携方法を把握すること、また相手の連絡先を整理することは大切です。
トラブル発生時に慌てて調べるようなことがないように準備しておきます。

STEP3：原因調査

システム障害の原因を調査するときはログやシステムの各種レポートを調査しますが、すぐに原因特定できるとは限りません。
原因特定の目途が立っていない場合、基本的に次の流れで調査を進めます。

類似障害の確認

過去に類似障害が発生していないか確認します。
障害管理台帳などシステム障害の情報があれば参考にします。
まったくの同一障害でなくても、似ている障害があればピックアップします。
もし類似する他システムがあれば、そちらの障害管理台帳も確認すると良いでしょう。

原因の仮説をたてる

調査で得た情報をもとに仮説をリストアップし、検証を繰り返していきます。
このリストアップではメンバが集まり、意見を出し合うと効率的です。
合わせて「可能性の高さ」「確認作業の難易度」をもとに調査の優先度をつけていきます。

この仮説検討では、ホワイトボードを活用するのが有効です。
ホワイトボードを使うと処理フローやサーバ間の関連図など何かしら図を描きながら検討すると全体イメージが可視化されるので解決の糸口を見つけやすくなります。
メンバ間で状況を共有するためにも有効です。

原因の絞り込み

上記で洗い出したリストを優先順に検証します。
検証結果は、問題が起きる条件だけではなく問題が起きない条件も整理します。
ある程度絞り込めたら、メンバを集めて検証内容や方法に問題ないか確認します。
この時点で原因特定できなければ、検証結果をもとに仮説をたてなおします。
この繰り返しを行うことで原因を絞り込みます。

この検証では仮説と事実が混同しないように注意します。
また検証中に誤操作を起こして２次被害が発生したり、メンバの作業タイミングが悪くて正しく検証できないなどの問題を抑止するため、検証手順を作成しながら進めます。

STEP4：復旧対応

暫定対応

システム障害の最優先目的は業務への影響を最小化することなので、とにかく業務やサービスが継続できるように一時的な対応を行います。
暫定対応といっても本番環境で作業を行うことなので、当然ながら責任者と調整して慎重かつスピーディーに対処します。
暫定対応において、手順書作成など準備する時間がない場合、以下の点に注意して作業を行います。

• 原則、複数人でクロスチェックしながら作業する
• 必ずバックアップを取り、後からリストアできるようにする
• 作業ログを取る（実行コマンドのメモ、作業時間の記録など）

緊急事態の時は作業手順書の作成が間に合わない場合はあるでしょう。
しかしログ採取方法やデータのバックアップ方法といった基本操作については事前に準備することができます。
これらの操作手順があるだけでも作業の精度は格段に高くなります。
緊急時に慌てないよう、平時に準備しておきましょう。

恒久対応

原因が特定され、対策方法が決定したら恒久対応を行います。
恒久対応は暫定対応と異なり作業計画や作業手順を作成して進めます。
また恒久対応後、本当に問題が解消されていることを確認する方法も大切です。
本番環境なので業務に影響を与える確認は取れない場合もあるので、その時は何をもって問題解消したと判断するか、あらかじめ関係者と認識合わをします。

STEP5：事後対応

報告書

暫定対応や恒久対応が終わった時点で関係者に完了報告します。
相手や状況によって報告内容は異なりますが、以下の内容を報告書にまとめます。
※障害対応中の中間報告でも使います。

• 障害の概要
• 時系列の事象説明
• 業務の影響範囲
• 暫定対応の実施内容（対応している場合）
• 障害原因
• 対策
• 恒久対応の実施内容
• 再発防止

障害分析

障害対応が完了したら再発防止、そしてメンバ育成のためも障害分析します。
分析でよく使うのが「なぜなぜ分析」で障害が発生した真の原因を確認します。
なぜなぜ分析については、別記事「なぜなぜ分析の目的と進め方」で解説しています。

おわりに

もし保守運用を対応されている場合、システム障害が発生したときに調査や対応の進め方が整理されて全体合意されているか、再確認していただければと思います。

システム開発を行っている方は、運用開始前にルールが策定されているか確認することをオススメします。
運用ルールや手順が後回しになったまま運用開始するケースを見かけますが、保守運用に入ってから資料を作るのはメンバの作業負荷や費用面から難しいです。
開発体制のあるうちに作成するのが現実的です。

システム障害発生への対応を見れば、チームやリーダの実力がわかります。
トラブル発生時、何も準備しておらず慌てているチームを見て、クライアントはどう思うでしょう。
逆にテキパキと対処することで業務影響を最小限にすることができれば信頼を勝ち取ることもできます。

過去の経験則だけではなく、正しいプロセスを理解して対処できるようになりましょう。