PR

 前回では、災害発生時のシステム復旧を確実にするには、IT知識の属人性を排除しなければならないこと、そのためシステム復旧に必要なマニュアルやパスワードなどを隔離する方法は、物理的なセキュリティ手段がふさわしいことを説明した。

 システム復旧を確実にするには、属人性の排除と並んで、「災害発生時に起こるであろう障害」を事前に予想して手当てすることも大事だ。ところがこの「想定」が決して簡単ではない。

 今回は、外部のシステムと自組織のシステムが連携している状態の下で広域災害が発生すると、想定外のトラブルの発生確率が高いことを説明する。自組織内のシステムだけならともかく、連携先のシステムに何が起こるかまで想定するのは、非常に難しい。だからといって「先方は大企業だから災害時も停止しないだろう」「地方自治体の公共システムだから、堅牢なはずだ」などと勝手に思い込むと、有事の際に大きな問題が発生するという教訓が東日本大震災では残った。

被災地の病院が経験した「想定外」

 連携先のシステムを過信したことが、重大な問題を引き起こした事例を、東日本大震災に襲われた地域の病院に勤務する知人から聞いた。

 知人の勤務先は、東北地方南部の総合病院であり、周辺地域で唯一の救急指定病院である。その病院は、消防署の救急搬送システムと連携する急患受け入れシステムを備えていた。

 その仕組みはこうだ。

  • 消防署が「急患発生」のトランザクション(処理要求)を病院に送る
  • それを受けた病院側は、担当医の所在や空きベッドの状況を消防署に返答する
  • 再び消防署が「受け入れ要請」を送る
  • 要請を受けて病院側が受け入れ準備を始める

 もともと病院では、無停電電源装置や免震構造などの対策が講じられていた。そのおかげで東日本大震災直後に、すぐ主要機能もシステムも復旧した。

 病院内のスタッフは、震度6強という報道や、窓から見える建物が倒壊した事実から、数多くの急患受け入れをすぐに覚悟した。ところが、消防署からの急患発生のトランザクションはなかなか来なかった。それでも、エレベーターの停止/手術の中断/医薬品の在庫確認といった重要問題の対処に追われていた病院スタッフには、「消防署のシステムがダウンしている」などとは考える余裕が無かった。

 しかし実際はそのころ、消防署の救急搬送システムは実質的にパンクしていた。救急車の出動要請や住民からの救急指定病院の問い合わせといった非常に多くのトランザクションを受け付けていたものの、様々な要因によって処理のバックログ(やり残し事項)が雪だるま式に増えていたのである。

他の病院のシステムダウンが広く影響

 救急搬送システムで発生していた事象はこのようなものであった。

  • 救急搬送システムからの照会に対して、一部の病院から応答が来なくなった(それらの病院のシステムがダウンしていた)
  • 照会処理がタイムアウトになるまで、救急搬送システム側では処理は滞留する
  • 処理の滞留に引きずられて、正常稼働している病院のシステムとの間の処理が待たされる
  • システム経由で情報が取れないので、ボトルネックとなっている病院の状態を確認するためにオペレーターが介入して電話で状況確認をしようとしても、電話がつながらない

 このような負の連鎖によって、救急搬送システムの機能が停止した。急患を乗せた救急車のスタッフは「あの病院に向かえば、何とかなるだろう」という勘に頼った選択をせざるを得なくなった。そのため、知人の勤める病院には急患が押し寄せ、大混乱となった。

 混乱が収束に向かったのは、消防無線を持った消防署のスタッフと病院のスタッフが連携し、救急車のスタッフと無線で連絡を取り合いながら急患の搬送をコントロールしてからだった。すなわち、大混乱から現場を救ったのは、ITではなく、病院や消防署のスタッフの機転と、数十年前から存在する無線技術だったのである。