|
Launch発射後、順調に飛行を続けていたアポロ13号、地球の周回軌道を抜け出し月へ向かいます。宇宙船内の模様を地球へ中継などしながら余裕の順風満帆の飛行を続けていました。ところが、そろそろ月へ近づきかけた頃、宇宙船で爆発が起こってしまいます。宇宙船からは粉砕された細かな部品や液体が噴出しています。インシデント発生です。
|
宇宙船内の飛行士は爆発を体で感じ、そして宇宙船内の全ての警告ランプが点灯する状態ですので直ちに地上の管制センターへ報告するとともに、何が起こったのかを突き止めようと努力します。地上の管制センターでも全ての機器の状態をリモートで監視しているので、全てのエリアで警告ランプが点灯すると同時に計測用計器の各目盛りが異常値を指し示す状態であることを認識します。初期段階では地上の各エリアマネージャは混乱し、その原因を推測し合う状況に陥ってしまいます。そこで、管制責任者が、「推測で判断し間違ったアクションを起こすな。落ち着いて正しい状況把握をおこなえ。」と指示します。初めは、全ての計器が異常を指し示すなどというのは単にコンピュータの異常ととらえ、リセットすれば復旧できるのではないかと地上では楽観的に判断しますが、すぐに酸素タンクが爆発したことが判明し、ただごとではないことに気づきます。
|
 |
|
すぐさま、管制責任者はミーティングを招集、各エリアマネージャや宇宙船のメーカ技術者などが集まります。検証の結果、爆発は酸素タンクで発生し、その為に飛行士たちの呼吸用酸素と、宇宙船の暖房、コンピュータ用の燃料電池が欠乏する事態であること、指令船のロケットが使用できないことなどの事態を参加者全員で確認し、今後の対策を協議します。指令船は使えず月着陸船へ緊急的に飛行士を避難させ（指令船と月着陸船はドッキングした状態でつながっていました）、電力をどのようにしたら最低限の消費に抑えられるか、月着陸船のロケットでどのように地球まで帰還させるかなどが議論されるのです。
そのなかで管制責任者が月着陸船のロケットを使って地球に帰還させることができないかを検討する場面で「何のために設計されたのではなく、何の為に使えるかを考えろ」、また、二回目のミーティングでは電力を削減するために「トランジスタ、電球それらを設計した者、取り付けた者すべてを召集して、どうしたら電気を使わずにすむか考えろ」と指示を出します。
さてさて、ITILではインシデントを次のように定義しています。
「サービスの標準の運用に属さないイベントであり、サービス品質を阻害、あるいは低下させる、もしくはさせるかもしれないあらゆるイベント。」
酸素タンクの爆発はまさに宇宙船運用の標準に属さないイベントでありインシデントです。物語の中では、インシデントがどのようなものなのかまずは分類が行われ、その次に優先度が明確にされます。このインシデントは飛行士の生命にかかわるクリティカル・インシデントと言うことになりますね。すぐさま、インシデント管理ミーティングが開かれ、酸素タンクの修復ではなく、どのように緊急的なアクションをとりながら人命を守り地球に戻すかと言うワークアラウンドが検討されます。ITILのインシデント管理では、インシデントの原因となった問題を直すのではなく、一刻も早くビジネスを復旧させると言うことが第一目標となっています。「何の為に設計されたのかではなく、何の為に使えるのか」というのはまさにITILのインシデント管理そのもので、ワークアラウンドを次々と考え出しているのです。電力を削減するために「トランジスタ、電球それらを設計した者、取り付けた者すべてを召集して、どうしたら電気を使わずにすむか考えろ」というのはITILのインシデント管理のエスカレーションプロセスです。何かインシデントが発生する度にシステムの設計者やプログラマを呼んでいたのでは、彼らが本来しなければならない新規開発などが効率的でなくなり、反面いつまでたっても運用要員のスキルが向上しなくなります。エスカレーションはインシデントの優先度によって決定されなければなりません。
|
|
ITILでは優先度を明確に定義していますが、実運用の場面では時々混乱してしまいます。アポロ13号の物語の中ではこのような場面があります。飛行士3名が月着陸船へ緊急避難するのですが、もともと2名用に設計されていました、従って飛行士が吐き出す二酸化炭素用のフィルターも2名で設計されていました。時間がたてば船内の二酸化炭素の濃度は上昇してしまいます。地上には設計者がおりリモートでモニターしているのでこれに早くから気づいていましたが、あえて飛行士自身が気づくまではそのことは伝えていません。これが重要度（ビジネスインパクト）と緊急度の意味するところです。二酸化炭素の問題は放っておけば生死にかかわる非常に重大な問題ですが、二酸化炭素の濃度が上がるまでにはある程度の時間がかかる為、緊急度はその時点では低かったと言えます。すなわち優先度がつかなかったわけです。飛行士達にその事実を伝えることよりも飛行士達には他の事をさせ、考えさせ、そして休ませる方が優先度が高かったのです。
|
行っていますかインシデント管理？ |
|
今回のインシデント管理についてのポイントは…
- インシデント管理ミーティングの召集
- 各エリアマネージャが正しくインシデントの状況を把握し、ワークアラウンドなどの対策の確認その場凌ぎのアクションで、結果として、新たなインシデントを起こしている可能性があるか
- インシデントの分類、優先度の設定
重要なビジネスプロセスに対してはワークアラウンドをビジネス側と協力して準備することが必要です。ワークアラウンドがあるとすぐにビジネスを復旧させるか、またはビジネスインパクトを最小限に抑えることができます。また、インシデントの復旧には時間をかけて正しいプロセスにのっとって行うことができ、復旧作業が新たなインシデントを起こす、いわば２次災害的なことが防げます。
また、エスカレーションのプロセスは守られていますでしょうか？インシデント発生の度に設計者やプログラマを巻き込んでいてはIT全体の効率化が進みません。
インシデント管理はシステムを直すということよりも、まずはビジネスを支えることが最大目標であることをITとして認識することが重要なのです。
地上ではなんとか3人の飛行士達を無事に帰還させようと次々とアクションを起こしていきます。そのアクションを効果的に支えているのが「構成管理」です。アポロ13号を観ていると構成管理の重要性を再認識しますね。ということで次回はアポロ13号にみる「構成管理」をお話したいと思います。
# # #
 PDFファイルをご覧いただくには、Adobe® Reader®が必要です。アドビシステムズ社のウェブサイトより、ダウンロード（無料）の上ご覧ください。
|
印刷用画面へ
