顧客サービス向上のためのBCP対策
大規模かつ徹底したリハーサルも実施
3段階で実現した「最上級のBCP」
東日本大震災の発生で
抜本的なBCP強化計画に着手
2011年に発生した東日本大震災は多くの企業にBCPの再考を迫ることになった。ソニー生命も例外ではない。同社のBCPはこの未曽有の大災害を契機に大幅に見直され、「最上級のBCP」を目指して動き出すことになる。
ちなみに当時の同社のBCPが、同業他社と比べて大きく遅れをとっていたわけでは決してない。基幹システムを運用するIBMメインフレーム、それに多数のオープン系サーバー（UNIX、Windows）を導入した本番センターに対し、メインフレームおよび一部のオープン系サーバーをバックアップ用に準備した災対センターが設けられていた。
両センターはどちらも関東地方に設置されていたが、県は異なり、相応の距離もある。またデータについては、日次で取得したバックアップテープを磁気テープに保存し、遠隔地に輸送して保管していた。一定水準のBCPは実施されていたのである。
保険会社の最重要業務は支払処理であると言われるが、従来のBCPでは、災害発生時に支払業務を滞りなく継続することを目標に設計されていた。しかし改めてBCPを見直したところ、RPOを指標とするデータの鮮度は約1日。つまり前日までのデータしか復元できない。また遠隔地からテープを取り寄せ、バックアップ用のメインフレームを稼働できる状態に準備が整うまで、RTOとして約7日を要すると試算された。最も重要な支払業務でさえも、災害発生から7日後に、災害発生前日のデータでシステムを復旧させるのが限界である。
ましてやバックアップ用サーバーが十分に用意されていない業務システムについては、迅速な復旧は望めない。保険の営業職は顧客の面前で新契約・保全の手続きを行う。クライアントPC側に個人情報に関わる重要データを残さないよう、センターに接続しないと業務システムは動かせない。つまりサーバーが停止していると、まったく業務が進まないことになる。
「オープン系サーバーで新規システムが相次いで構築され、システム環境が急速に変化するなか、現状のBCP対策では全システムの迅速な復旧は望めないとの結論に至りました。支払業務の場合でも、ユーザーは通常とは異なる業務フローで処理することになり、大きな混乱が生じるのは確実です。東日本大震災により、被災発生時に当社が直面することになる現実を突きつけられ、抜本的なBCP強化計画の策定に着手することになりました」と語るのは、当時のIT戦略本部 基盤システム統括部 基盤更改課で、統括課長としてBCPプロジェクトを担当した青木久美子氏（現・ITデジタル戦略本部 グループウェア開発部 担当部長 兼 同部 IS開発8課 統括課長）である。
第1弾は災対センターの再整備
サーバー設備を大幅に増強
同社が描き直した新たなBCPは、以下の3つの段階を経て実現している。
①災対センターの再整備（2013年8月〜2014年5月）
②本番センターの移転（2015年8月〜2017年1月）
③災対センターの移転（2017年4月〜2018年1月）
BCP高度化の第１弾は、災対センターの再整備である（図表1）。本番センターで運用している全業務サーバー（開発機を含む）を災対センター側に準備する。日次のバックアップ取得に代えて、Global Mirrorと呼ばれるストレージ機器が備えるデータ同期機能を利用して、本番・災対センター間をリアルタイムに同期し、全データについてRPOを5〜10分に定める。これで被災直前のデータ状態からシステムを再開できることになる。
メインフレームやオープン系サーバーが用途別に保持していた全ストレージ機器を対象に、伝送量が他の通信回線に影響を与えないようデータ同期の専用回線も整備する。またGlobal Mirrorのリアルタイムな同期により、被災からのシステム復旧目標であるRTOを従来の7日から24時間以内へと大幅に短縮する。
上記の提案は、それまでのBCPを大きく描き直す高水準な内容で、相応の予算と工期が必要とされる。そのため社内稟議は難航し、事前協議も含めると、経営陣からの承認を得るまでに約6カ月を要したという。
2013年7月に経営側からの最終承認を得て、災対センターの再整備は同年8月にスタート。8カ月のプロジェクト期間を経て、2014年5月に完了している。
第2弾は本番センターの移転
災対センターと同時に入れ替える
続く第2弾は、本番センターの移転である。より正確に言うなら、本番センターと災対センターを同時に入れ替える前例のない取り組みであった。
もともと本番センターとして借りていたデータセンターは老朽化が著しく、またFISC安全対策基準に照らし合わせると防火・防災体制に改善すべき点が多かった。別センターへの移転は、早くから検討課題に上がっていたようだ。
データセンターの移転は通常、現行環境への影響や移行時のリスクを最小化するため、まず移転先となるセンターに稼働環境を用意し、時間をかけて段階的に実施するのが一般的である。しかしその場合、一時的とは言え本番、災対、新本番の3つのセンターを保持することになり、移行期間やコストの増大を招く。
そこで同社では本番センターと災対センターを同時に入れ替える、つまりそれまでの本番センターを災対センターとして機能させ、同時にそれまでの災対センターを本番センターに変更する方式を採用した。災対センターの設備環境を大幅に増強したので、本番センターとしての運用が可能であり、両センターがリアルタイムにデータを同期していることから、理論的には実施可能であると考えられた。
「ただし両センターの同時入れ替えは、国内はもとより海外でも例のない先進的な取り組みで、他社事例は参考にできませんでした」（青木氏）
確かに工期・コスト面のメリットは大きいが、伴うリスクもまた大きい。メーカーの担当者が「前代未聞」と驚いた移行自体のリスクに加え、プロジェクトの難易度を上げる追加的な要件も加わった。たとえば移転実施時に災害が発生しても、高度なBCP基準を担保できること。通常、移転実施中は同期処理を停止して静止点を確保するが、その場合、両センターでデータの差異が生じる。もし災対センターへ最新データが反映されない状態で被災した場合、本番データの消失を招く危険がある。
「一般には、こうした移転期間中の被災リスクを受容する企業のほうが多いですが、当社ではお客様の面前で進めている手続き結果が万一にも消失することは許容できないとの経営判断があり、移転実施中も高度なBCP基準を担保することが決定されました」（青木氏）
また移行は年末年始を予定していたが、同社の営業職はこの時期も精力的に活動しているため、移転作業時間を極小化し、かつ一部のサービスは移行作業中も継続することが要件に加えられた。
これらの要件をクリアする対策の1つとして、同社が選択したのは「コの字型」のデータ同期構成である。
図表2にあるように、ここではまず両センターにストレージ機器を1セットずつ追加する。Global Mirrorを使って本番センターから災対センターへ通常のデータ同期を実施する（①）と同時に、災対センターのストレージから筐体内コピー機能を使って、別ストレージ（新・本番ボリューム）にデータをコピーする（②）。さらにそこから移転後の使用を想定し、新・本番ボリュームから本番センター側にある別ストレージ（移転後の新・災対ボリューム）へGlobal Mirrorを使って同期する（③）。
そして通常のデータ同期を継続しながら、新・本番ボリュームからシステムを起動し、リハーサルを実施し（④）、移転実施のタイミングで、データ同期のセットを切り替えるという流れである。
これにより、たとえ移転実施中やリハーサル実施中に、どちらかのセンターが被災しても、本番・バックアップ双方のデータが消失するリスクは完全に避けられることになる。
大規模かつ徹底した
リハーサルを実施
データセンターの移転は、個別のシステム構築プロジェクトと異なり、最悪の事態が発生した場合、事業継続を困難にする。災害に備えるためのプロジェクト自体が、同社にとって大きな災害に変わる可能性があるわけだ。
難易度の高いこの移転プロジェクトを成功に導くべく、システム構築・設計面から、そしてプロジェクト態勢面から、さまざまなリスク対策を実施した。たとえばその 1つに、大規模かつ徹底したリハーサルが挙げられる（図表3）。
リハーサルの範囲は、以下の3つに分けられる。2016年5〜6月および7〜8月に実施された「基盤リハーサル」では、システムの起動・停止、データ同期方向の切り替えといった作業を対象にした。また同年9〜11月に実施された「業務リハーサル」ではオンライン処理、バッチ処理、対外接続業務、運用業務、高負荷処理などの業務システム処理を対象にしている。
さらに同年10〜11月に実施された「移行ランスルー」（移行当日リハーサル）では、移行当日の全作業を対象に、当日と同じ曜日・時間を選択して、タイムチャートの全工程を実施する。
移行作業は2016年12月31日の午前2時から2017年1月2日午前9時までの55時間で実施し、この間、社内メールシステムとスマートフォンからの顧客情報参照を除く全システムが停止する（この2つのシステムは12月31日午後3時〜1月1日午前0時までは利用を可能にした）。この55時間のタイムチャートに沿って、全工程をリハーサルしたのである。
いずれのリハーサルも、実際の作業・処理と限りなく同じ内容とするよう注意し、非機能要件も盛り込んで品質を担保した。作業失敗時に備えた切り戻し作業についても、もれなくリハーサルを行っている。
また態勢面からのリスク対策としては、①社内のリスク管理部門やシステム統合・移転に豊富な実績をもつ第三者機関を交えた基本計画の徹底レビュー、②移転完了前および移転完了後を想定したコンティジェンシープラン（緊急時対応計画）の策定、③システム部門だけでなく各業務部門を対象に、移行の内容や想定される障害、その予兆などを全社に徹底周知し、全社的なプロジェクト推進態勢を確立、などが挙げられる。
こうして2017年1月2日午前9時、新・本番センターが無事に稼働を開始し、新・災対センターへのデータ同期も問題なくスタートした。
その後、第3弾として、2017年度の約1年を費やし災対センターを西日本に移設するプロジェクトが実施された。新・本番センターの稼働から1年後の2018年1月に、西日本で新しい災対センターが無事に本稼働を迎えている。本番センターは東日本に残したので、これによりプレートの異なる東・西でのBCP体制が実現した。
こうしてBCPの高度化を達成した以降も、同社では定期的にBCP対策の見直しを行っている。
また基幹システムのクラウド化が進展し、オンプレミス環境と連携する複雑なIT環境のなかで、クラウドを前提にしたBCPをどう策定するかも重要なテーマである。
約5年にわたるBCPプロジェクトにより、平時・災害時にわたる万全の体制を築き、ソニー生命の理念を支えるインフラを完成させた。経営層の協力も得た難易度の高いプロジェクトを成功させた経験は、同社のプロジェクト推進スキームを大きく前進させたに違いない。
［IS magazine No.25（2019年９月）掲載］
････････
◎特集｜ソニー生命の挑戦 CONTENTS
PART 1 COBITに改めて注目し、4つのテーマと4つの柱を掲げる
PART 2 個別最適の流れに歯止めをかけ、「Web標準プラットフォーム」を策定
PART 3 あえて基幹システムから「ビッグ」スタートを切る
PART 4 運用改善専任チームの結成と「全運用担当者との面談」という手法
PART 5 業務の詳細な「手順化」により、コスト削減・開発スピード向上を目指す
