ITの事業継続計画(BCP)策定(知識編)
IT部門/経営層向け
<概要>
本コラムでは、前半にて事業継続計画(BCP)について知識レベルとして紹介し、後半にて男性従業員が育休を取得する際のスキームについて、BCPにおけるRPO+RTOの概念を参考に考察します。
1,BCPとは、いつ頃から言われるようになったのか
事業継続計画(BCP)は、2001年の『911テロ』以降、IT業界が海外から持って来た外来語です。2001年以前は、災害復旧/災害対策などと呼ばれており、事務センターの2拠点化などは2000年以前に既に実装されていました。しかし、BIA(ビジネス・インパクト・アナリシス)やRPO/RTOの算出などのフレームワークは国内に、まだ存在しませんでした。
図1、事業継続計画(BCP)の策定がIT業界より誕生し20年が経過
近年、「事業の継続」という解釈を株主総会で、BCPから「サステナビリティ」(備考1参照)に変わりつつあります。その結果経営側は、環境問題を優先とし「短期的な事業の継続」よりも「(環境を含んだ)長期的な事業の継続」に意識が変わろうとしています。
備考1:サステナビリティ(sustainability)
日本語では「持続可能性」と訳される。環境活動を行うことで長期的に持続させること。 「Sustain(維持する、持続する)」と「Ability(~する能力)」を組み合わせた造語
2, BCPは2024年現在どのように実践されているか
先の「サステナビリティ」は、確かにBCPを包含したような用語ですが、BCPのフレームワークを実装しているわけではありません。2024年現在、このBCPをIT部門はどのように考えているのでしょうか。
図2、リスク別BCPの策定・運用状況
図2では、BCPが20年経過した現在どのようなカテゴリで「BCP策定ができていないか」集計したものです。赤枠が「策定していない」部分で、『風評被害/テロ(予告・破壊行為)/カントリーリスク』などが約60%程度に上ります。国内では発生可能性の低いリスクとして考えられていると思われます。
またこれ以外にも、「専門家の不足」という話となれば、
IT人材の『内製化』神話|Dirbato公式 (note.com) なども参考になります。
例えば、私が担当しているガバナンス/リスク分野では、「2025年の崖(がけ)」(備考2参照)という問題が提唱され、スキルを持った人材が退職始めているのも事実です。
備考2:「2025年の崖(がけ)」
IT業界で2025年に大量に定年退職が始まることを警鐘した用語。2025年までに「人材を揃えること」を目標にしている。丙午(ひのえうま)が誕生する前年の1965年前後生まれの従業員を対象としている。
https://japan.zdnet.com/article/35105748/
「平均年齢は60代? IT部門が直面する現実と忍び寄る変化
(中の寄稿を読むにはログインが必要です)
3,BCPの定義はどのようなものか
表1では、国内でのBCPが使われるまでの用語(例)です。
表1、防災/災害対策/事業継続計画(BCP)に関する用語の定義
先のBCPの用語が定着し、20年が経過するまで表1のような用語でITの災害対策を定義していたのは事実です。このような用語を定義して来たのは、国内のコンサルファーム(備考3参照)やSIer/ベンダーなどがあげられます。
備考3:国内のコンサルファーム
セキュリティ・ビジネス・モデルとは(後編)|Dirbato公式 (note.com)
図8,日本国内でのコンサル・ファーム、リサーチ(総合研究所)の変遷を参照
4,ディザスタ・リカバリの基本形
BCPがITを前提とした話になるのは、「復旧」「リカバリ」が「データ」の復旧を前提として、フレームワークを作っているからです。そのため、火災は「消化/現場検証」、防災は「家屋解体/立て直し」などの復旧となります。火災/防災復旧に「データ」のリカバリの話は存在しないはずです。
BCPは、企業の事業を継続させる「営業的な戦略」のようなフレームワークではないことが分かります。また、表1のディザスタ・リカバリの基本を図にすると図3のようになります。
図3,ITに特化したディザスタ・リカバリの基本形
IT業界を担当していれば、上記のホット・サイトに相当するディザスタ・リカバリを実装された人もいるでしょう。最近では、私が担当しているセキュリティ分野でのランサムウエアからの復旧で使われることもあります。
https://note.com/dirbato/n/n9e1403acebc7
セキュリティでのレジリエンス(回復力)の重要性
5,BCPのフレームワークで登場するRPO/RTOの算出とは
データを復旧させる際、そのデータの鮮度を係数(時間)で数値化することが、図4の方法論です。
図4,RPO/RTOの算出とは
RPOは、データのバックアップ・サイクル
RTOは、リカバリ目標時間(復旧までにかかる時間)
を計測します。図4では、RPOとRTOを算出し、復旧するまでの見積時間を算出します。
6,IT業界での復旧(リカバリ)の解釈
事業継続計画(BCP)は、2001年の『911テロ』以降、IT業界で誕生し、その中のフレームワークでRPO/RTOの算出という「復旧」までの時間を数値化する方法論が誕生しました。この復旧は、一般的な復旧と、どのように違うのでしょうか。
表2、『復旧(リカバリ)』のIT業界/一般用語との違い
表2の「ディザスタ・リカバリ」に関してIT業界では、「データを前提」とした復旧の方法論が始まります。そのため、IT業界の中でも「データセンターを立て直す復旧」「入退出装置を復旧」させる一般的な復旧の用語と使い分けて利用します。
7, RPO/RTOを実際に算出すると、どのような計算式になるか
それでは、実際にRPO/RTOを算出してみましょう。図5では、毎日「差分バックアップ」を取得し、週末のみ「フルバックアップ」をした企業の場合です。この企業では、「夜間地震があり、近くの原発より避難命令が出たため、マシンを事前に準備したセカンダリ・サイトにフェールオーバー」させます。
図5、実際のRPO/RTOの算出(例)-セカンダリ・サイトにフェールオーバー
図5では、深夜のバックアップ中に停電が発生したものの、CVCFなどの蓄電池で電源喪失をしないデータセンターを設計していました。しかし、瞬電と思われる状態にあり、バックアップ・サーバーなどがrebootをしました。そのため、バックアップがエラーとなり、最新のバックアップは、2日前(RPO=2日)となります。
次に、報道発表で原発の半径100kmの避難指示が出たため、マシンルームは原発の対象地区ではありませんが、今後のために予防措置として、1日目にフェールオーバーを決定しました。
セカンダリ・サイトは、ウオームサイトなので、OSはインストールされていません。2日間かかり、主なシステムを再インストールした状態です、現在、地震発生後3日目(RTO=3日)となりました。この状態では、RPO+RTO=5日と算出されます。
8,静的なデータを毎日バックアップする
図5では日次のバックアップに関し、オンラインを止め、データベースを一旦、静的なファイルにエクスポートなどして、バックアップを取得したのか。それともスナップショットを利用し、オンラインを止めず、リアルタイムでバックアップを取得したのか、記載されていません。
実は、「データの復旧」で最も重要なのは、皆忘れているだろう、バックアップの取得方法(静的か、動的か)です。例えば、wordやExcelを画面で操作中に(仕掛りに)、PCの電源が落ちた時、直前のディスクにあったファイルから手で復元するでしょう。(動的)
これと同じように、企業のデータベースも、顧客が秒50件でオンライン更新をしている最中に、データベースが止まったので、「仕掛り中のデータ」は、想定では50件程度は発生するはずです。この「仕掛中のデータ」をどのように復元するのでしょうか。
9,「仕掛中のデータ」はデータベース更新のコーディングで決まる
図5では、「動的な復元」として、オンライン中にデータベースが止まった際、直前の「仕掛中のデータ」を無効にして、更新を無かったことにするRollback(ロールバック)と、データベース起動後に「仕掛中のデータ」を再度、更新するRoll Forward(ロールフォワード)を1件単位で説明しています。
災害ではなく通常のrebootの場合、この状態となります。しかし今回は、災害のためセカンダリ・サイトにフェールオーバーした場合です。「仕掛中のデータ」がセカンダリ・サイトに届いているのでしょうか。このレプリケーションの話はまた次回にしましょう。
この「仕掛中のデータ」を「ロールバック(Rollback)」するか「ロールフォワード(Roll Forward)するかは、IT業界だけの話ではありません。最近身近な例として、「男性社員が育児休業制度を利用し、会社に復帰した際の評価(状態)」の確認としても使えます。