前回は，障害発生の検知と，障害対応手順書に従った対処で状況が改善しなかったところまで紹介した。障害対応において，対応手順の確定していないケースに遭遇した場合，状況に合わせて適切かつ迅速な判断が求められる。判断を誤ると重大な二次障害，三次障害を招きかねないのである。今回は，タイムリミットを目前にしてどのような判断を行なったか，そして手詰まり状態の中どのような対応方法を選択したのかまでを紹介する。
私たちは，障害対応手順書に従って対処を行なったが状況は改善しなかった。依然管理ツールによるメールボックスの表示は出来ないままであり，当然リモートからのIMAPによるメールボックスへのアクセスも出来ない。さて，どうしたものだろうか。
「ツールの実行をリトライしてみましょうか？」
対処で使用したツールは，いくつかのパラメータを指定して実行する。従って，パラメータを変更して再度実行することで効果が得られる可能性は残されていた。
「でも時間が厳しいですね」
そう私は答えた。復旧のタイムリミットまで後1時間少々である。ツールの実行に約1時間かかるので，間に合うかどうかぎりぎりである。それに，ツールを実行することで確実にメール・サーバーが復旧する保証は無い。このまま黙ってツールの実行終了を待つわけにはいかなかった。
「とりあえずツールは実行してしまいましょう。その上でタイムリミットのバッチ処理を別の方法で確認する準備に入りましょう」
私たちはツールを実行した後，既に帰宅していた運用担当チームの責任者に連絡を取った。既に障害発生の連絡は済んでいたが，改めて状況を報告するとともに，いったんメール・サーバーの復旧作業をストップし1時間後に迫ったタイムリミットを回避する作業に注力することで問題ないか，確認を行った。
「お客様へ提供しているサービスを維持することが最優先です。すぐにバッチ処理の確認準備を始めてください」
責任者の指示を受けた私たちは，直ちにバッチ処理の確認準備に取りかかった。
障害対応の現場では，多くの要素を基に柔軟かつ迅速な判断が求められることは前述したが，これはその一例だろう。障害の内容がシステムの提供するサービスに影響を与えるものである場合，障害原因の究明とその対処より先に，暫定的な方法でサービスへの影響を回避しなければならない場合が多い。障害対応において，様々な状況下でそれぞれどのように対応すべきか，という判断は非常に重要であり，必ず運用担当チームの責任者あるいはそれに代わるあらかじめ定められた役割の人間の判断を仰がねばならない。これを怠ったがために，後々重大な問題に発展した事例を筆者はいくつも見てきた。
今回の障害では，運用担当チームの責任者に連絡が取れたため迅速に正しい判断をあおぐことが出来たが，何らかの理由により運用責任者あるいはそれに代わる人間に連絡がとれない場合もあるだろう。そのようなときのために，判断を下すことができる人間を複数定めておき，連絡の順位付けを行なった緊急時の連絡フローをまとめておく必要がある。
また，障害の種類によっては障害対応において発生する状況と，その状況下でとるべき対応がパターン化されるものもあると思う。そのようなものについては状況ごとに対処緊急度のランクを定めておき，取るべき対応との対応付けを行い，責任者の承認を得た上で障害対応手順書に添付しておくとよい（表1）。そうすることで，責任者に連絡をとりながら次に行うべき作業の準備を進めたり，場合によっては最初に障害発生を検知した担当者が初動を開始しつつ責任者に事後連絡を行ったりするなど，より効率の良い対応が可能になるだろう。
| 緊急度 | システム状態 | インシデント例 | 一次対応例 |
|---|---|---|---|
| A | 全サービス停止 | ・ネットワーク障害 ・外部からのDoS攻撃 |
（対応時間：24時間） ・緊急連絡網に従い各所へ連絡 ・直ちに現地へ向かい，一次切り分け開始 |
| B | サービス一部機能停止 | ・非冗長化機器の異常 ・冗長化機器の両系異常 ・外部の連携システム障害 |
（対応時間：24時間） ・緊急連絡網に従い各所へ連絡 ・リモート（必要に応じて現地）で一次切り分け開始 |
| C | 縮退運転によるサービス継続 | ・冗長機器の片系異常 | （対応時間：24時間） ・責任者へ連絡 ・リモートから縮退運転の正常性を確認 ・必要に応じてベンダー保守へ連絡 |
| D | サービス継続 | ・バッチ処理失敗 | （対応時間：営業時間） ・責任者へ連絡 ・対応手順書に従い復旧対応 ・対応終了後，関係者へ対応完了報告 |
