システム障害の発生時に使えそうなフレーズをシリーズでご紹介してきました。そんな折，ありがたくもこのコラムを読んで下さった某氏いわく，「ミッキーさん，そんなこと言ったって，いざ障害が発生したら，赤ランプはピコピコ点滅するわ，アラームはビービー鳴るわで気が転倒して，悠長に上手な表現，ましてや英語でなんて頭が働きませんよ」。
確かにその通りかもしれませんね。
親が脳卒中で倒れた，子供が大怪我をした，なんて場面に遭遇すると，気が動転して救急車は110番なのか119番なのかもわからなくなり，自宅の住所さえ言えなくなってしまったなんて経験，ありませんか？
障害発生時の運用手順（COP）を整備しておく
皆さんはContingency Procedure（コンティンジェンシー・プロシージャ）というのをご存知ですか？ このContingencyとは緊急時，とか異常事態という意味です。（スケジュール表の中にcontingency periodと書いてあれば，予備日という意味ですが）
COPは障害が発生した時など，異常時の運用手順を指しています。例えば，衛星管制のコンティンジェンシー・プロシージャなら，様々な予期し得る故障や障害を想定し，その障害の特定方法や当座の対応措置などが明記されているマニュアルです。通信，放送，気象衛星など静止衛星の場合，20分ほどでバッテリ電源を使い果たし，衛星全損に至ることもあり得るので，障害発生時の対応は文字通り時間との競争なのです。アラームがガンガン鳴ってもパニクっている暇はありません。
Contingency Operations Procedure = 異常時運用手順 ＝ COP
例えば衛星管制のCOPでは，次のような運用手順が明文化されています。
・どのアラームが鳴っているのか
・（鳴っているアラームから判断して）どのパラメータを確認すればよいのか
・関連パラメータを様々な角度から総合判断した問題原因の特定方法
・対応措置の推奨案
・対応措置／復旧措置実行のためのコマンド列
問題の切り分け用に，判断ボックスが並んだフローチャートも必ず用意されています。頭の中がかなり混乱しているときでも，この手順書に従えば，適切な判断や行動が実行できるようになっているのです。
もちろん衛星運用担当者は，打ち上げ前からシュミレータを使って繰り返し障害時の対応を練習しており，パニックにならないように訓練しています。レスキュー隊の演習と同じで，日頃からの訓練がいざという時の沈着冷静，適切迅速な行動につながるからです。
衛星のみならず，システムやネットワークもDouble Faultと呼ばれる同時二重（多発）障害はない，という前提で設計されているのが普通です。確かに，個別の独立した二つの障害が同時に発生する確率は非常に低いと思います。けれども，連鎖反応で次々に障害が引き起こされていくという事象はよくあります。無いというほうがおかしいくらいです。だからアラームは単発で鳴ることよりも，一斉に複数のアラームが鳴る，一度止めてもまたすぐに鳴るという事態が起きるわけです。
災害対策だけではなく，障害対策は万全ですか？
システムマニュアルには，たいていエラーメッセージのリストが巻末に添付されていますよね。それをじっくりと読んだことがありますか？あるいは，どの障害が発生するとどのアラームとどのアラームがなるというマッピングをしたことがありますか？逆に，このアラームとこのアラームが鳴った時は，こういう障害の可能性があるという紐付けをしたことがありますか？
「災害対策ならバッチリですよ」とデータセンターの方はよくおっしゃいます。
災害対策 ＝ disaster preparedness
対策とは「準備できている」ということなのです。でも，地震，台風，火事などの災害は，めったに起きるものではありません。こうした自然災害への対策ではなくて，普段の運用で時々発生する障害に備えることを「障害対策」と言います。
障害対策 ＝ contingency preparedness
こちらの対策はいかがですか？システムや信号経路の冗長構成のみならず，普段の運用で時々発生する障害にも備えておく必要があります。
衛星運用の場合は，Contingency Teamというのが結成されていて，災害対策本部みたいな役割を果たしています。
災害対策本部 ＝ Disaster Command Post, Disaster Operations Headquarters
運用担当チーム（1次サポート）では対応しきれない，という判断に至った時，ホットラインでこの緊急運用チーム（2次，3次サポート）に連絡をするのですが，その時の一報の入れ方もあらかじめ作文しておくと障害対策（CP）が一層強化されます。
状況判断するためのデータが揃えば，データを解析（analysis）していきますが，何も手がかりがないところからスタートする場合は調査（investigate）となります。
商用環境でのコンフィギュレーション，運用状態と連動して障害が発生することもあるので，トラブルシューティングにはシステムログが不可欠です。バグのデータベースと同様に，障害データベースを構築し，その時に有効だったシスログ情報，あって欲しかったデータ，復旧までの所要時間，影響範囲と度合い，SLAに基づく罰金や復旧に動員したリソースの費用などを蓄積しておくと，障害対策を改善するときに役立ちますし，メーカーへの機能要求に反映させることもできます。
ところで，Preparednessとよく似た単語にReadinessというのがあります。
Shipping Readiness Review ＝ 出荷前審査Launch Readiness Review ＝ 打上前審査
ReadinessとPreparednessを比較した場合，Preparedは発生しないかも知れない，起きて欲しくない事象に対する対応準備がしてあるというニュアンスがあるのに対して，Readyはこれから行う行為に対する準備が整っているというイメージです。ReadyもPreparedも形容詞で，readiness， preparednessはその名詞形です。
“Are you ready?”“Not yet!” ＝ 「もういいかい？」 「まだだよ」
“Are you prepared?” “Of course!”＝「準備できてる？」「もちろん」
 衛星管制の異常時運用手順（マニュアル）。異常発生時の対応の仕方，問題の切り分け用の判断ボックスが並んだフローチャートなどが用意されている [画像のクリックで拡大表示] |
