[No1][A.1.2]可用性＞継続性＞業務継続性
今回は、業務継続性について紹介する。業務継続性は、システムに障害が発生しても、どのくらい業務を継続できるようにするのか、の程度を表している。
業務継続性に関して決めるべき項目は3点存在する。
- 対象業務範囲
- サービス切替時間
- 業務継続の要求度
以下、順に説明する。
①対象業務範囲
対象業務範囲というのは、対象業務の種別のことを表している。対象業務範囲として、下記の2点を明確化する必要がある。
- その業務は、バッチ処理かオンライン処理か
- その業務は、他のシステムと連携するかどうか
バッチ処理とオンライン処理に関しては、下記の記事を参照されたい。他のシステムと連携するかどうかに関しては、他のシステムとデータをやり取りするかどうか、という観点で考えるとよい。
②サービス切替時間
サービス切替時間というのは、システムの部品が故障して業務停止してから、再開するまでに要する時間を指す。次回以降の記事で出てくる、RTO(目標復旧時間)との違いがわかりにくいので、下記に整理しておく。
サービス切替時間：
想定できる障害に対して対策(※)を施している場合における、業務再開までに要する時間
RTO(目標復旧時間)：
対策(※)を実施しているケースの範疇外で、業務停止を伴う障害が起こった場合の復旧までに要する時間
※PCを複数台用意し、故障時にPCを自動で切り替えるなど
③業務継続の要求度
業務継続の要求度に関しては、障害時の業務停止を許容するかどうかで、求められるレベルが異なる。また、障害時の業務停止を許容しない場合においては、
- パターン１(単一故障対策)：その部品が壊れても動くようにすること
- パターン２(二重故障対策)：その部品が壊れたうえに、さらにその代替部品も壊れたとしても動くようにすること
という２パターンの要求レベルが存在する。
ちなみに、
みずほ 大規模システム障害 “二重故障”想定せず復旧遅れ | NHKニュース
のケースでは、みずほ銀行が暗黙的にパターン２(二重故障対策)レベルの非機能要求レベルを求められていたにも関わらず、二重故障でシステムが停止している。二重故障を想定していなかったということだ。あらかじめ要求が明確化されていれば、このような障害は発生しないと考える。非機能要求レベルを適切に文書化して、作りこみを行っていくことが大切だとわかる良い事例だ。
業務継続性に関するまとめ
今回は業務継続性について紹介した。対象業務範囲、サービス切替時間、業務継続度の要求度に関して、あらかじめすり合わせを行っておけば、いざ障害が発生しても、落ち着いて対処できるはずである。顧客側、ベンダ側で、下記3点について、すりあわせておこう。
- 定期的にまとめて行う処理かどうか＋他システムと連携するかしないか
- 想定できる障害時に業務を再開させるまでに要する時間
- システムの部品がどのくらい故障(1個、２個)しても業務を継続させるかどうか
