誰もがいつどこでビジネス継続計画の実施を開始するかを知っているわけではありません。 私は通常、これを言います：可能性のある損失が脅威に対抗するコストよりも高い場合、対策を講じる時が来たので、コストは適切になります。 そしてその逆。 対抗のコストが多かれ少なかれ明確であれば、損失の推定は重要な作業です。 緊急事態のビジネスへの影響を評価するプロジェクト（ビジネスインパクト分析-BIA）の舞台裏に招待し、大手小売業者の例を使用してITの継続性を確保するための戦略を開発します。 行きましょう。
開始する
ロシア最大の小売業者であるX5 Retail Groupのプロジェクトに参加しました。 同社は、Pyaterochka、Carousel、Crossroadsネットワークを運営しています。
彼女はすでに、次のような独自の中断リスク管理ポリシーを持っています。
- リスク保険;
- 危機管理の形成;
- 人々の生命と健康に対するリスクの最小化;
- ビジネスの管理性リスクの制御。
- ITシステムの緊急復旧計画の準備。
このポリシーに従って、集中型ITインフラストラクチャでは、ITサービスの継続性と災害復旧計画の開発が必要でした。 理想的なソリューションは、バックアップデータセンターを構築し、同期レプリケーションをセットアップし、緊急転送の自動化をセットアップし、ITシステムがバックアップデータセンターに移動し、緑色のライトが点灯する様子を1時間で「H」に見て、ビジネスに危険がないことを知らせることです。
しかし、プロセスの経済性を考慮して、同社は、店舗が機能せず、重大な経済的損失を伴う最も重要なITシステムのみを確保することが、緊急の場合の適切な手段であることを提案しました。 重要な問題が発生します-どのシステムをどのくらいの期間復元する必要がありますか？
顧客のIT部門は、ITシステムの分類と各システムの許容可能な回復時間を決定しました。 ただし、後に、ISO 22301およびベストプラクティスに従って、緊急事態が会社のビジネス（BIA）に与える影響を完全に評価することが決定されました。
ボリュームと境界
劇場はハンガーから始まり、BIAは仕事の範囲の定義から始まります。 これを行うには、会社のビジネスプロセス、そのサービス、財務諸表、パートナー、顧客、請負業者との関係を調べる必要があります。 次に、プロジェクトの境界内に収まる主要なビジネスプロセスとサービスを特定して調整します。 BIAの期間とコストは、ボリュームによって異なります。 ただし、私たちの経験から、プロジェクトを9か月以上延長しないでください。
私たちの場合、顧客は取引活動のために最も重要なビジネスプロセスを選択することにより、すでに境界を決定しています。
インタビュー
BIAの境界とフレームワークが修正されると、面接を実施するビジネス部門およびその他の部門の利害関係者のリストが決定されます。 社内のプロセスの客観的な状況を把握し、それらがどのように機能するかを理解し、「…がどうなるか」の評価を得るために、さまざまな部門から情報を収集することが非常に重要です。 この段階では、ビジネスプロセスがITにどの程度依存しているかに関する情報を取得し、これらの依存関係のマトリックスを構築します。 また、ビジネスプロセスに関心のあるビジネスの代表者および関係者は、結果、考えられる損害、考えられるシナリオを評価します。 このために、特別なアンケートを作成し、約50人の回答者にインタビューしました（プロジェクト自体に関する50のプレゼンテーションを提示し、完了したすべてのアンケートを実施、受信、処理しました）。
業務プロセス
面接と並行して、個々の業務を完了するのにかかる時間と詳細な分析の深さを考慮して、ビジネスプロセスを説明しました。 ITシステムが特定のプロセスに1日のさまざまな時間および1年のさまざまな時間にどのように影響するかを理解するには、プロセスをより小さなコンポーネントと特定の操作に分割する必要があります。 この段階では、GOSTまたは別の方法論に従ってビジネスプロセスを説明していないことを理解することが重要です。 私たちはビジネスプロセスを最適化せず、通常、少なくともBIA内でビジネスプロセスを改善するための推奨事項を提供しません。 損失を計算する方法論を正当化し、いくつかの基準に従って損失を評価できるように、ビジネスプロセスを詳細に説明します。 グラフィカルな説明のために、表記としてEPC、ARIS、およびMS Visioがツールとして使用されました。
しきい値
客観的な目標復旧時間を決定するために、海岸で被害を評価する基準とそのしきい値について合意する必要があります。 これらのしきい値を超えた場合、損傷が重大であると見なされ、しきい値に達する時間間隔が目標回復時間になります。 次の2つのオプションが提案されました。
- RTOを1つの基準（経済的損失）で決定します
- RTOを、経済的損失、評判の損失、ビジネスプロセスの制御性の損失という3つの基準で決定します。
損失は条件付きでお金に変換できるため、1つの基準を持つ最初のオプションが望ましいようです。主なことは、再計算式に同意することです。 しかし、慣例が示すように、評判の損失を金銭的損失に具体的に振り返る人はいないため、そのような式の承認には無期限の時間がかかる可能性があります。 両方のオプションの回復時間を考慮することが決定され、結果を提示する段階で、顧客自身がどちらが現実をより客観的に反映するかを決定します。
今後、1つの基準で最初のオプションを使用すると、たとえば「価格設定」プロセスのRTOが10日間に達する可能性があることがわかりました。 2番目のオプションを計算するとき、RTOは24時間を超えませんでした。 いずれにせよ、管理上の決定-どの損失を考慮し、どの損失を考慮しないか-は顧客に残ります。
リスク
顧客とともに、オペレーショナルリスクのリストを決定しました。 つまり、ITに影響を与えるもの、さらにはビジネスプロセスに影響を与えるものです。 緊急事態は真空中の球形の馬とは見なされないため、この段階は重要です。彼らは、ITを失うと祖国と私たちに何が起こるかを述べています。 リスクはグローバルとローカルに分けられました。 それぞれについて、インタビューの結果を考慮して、開発シナリオと会社のプロセスへの影響を決定しました。 明らかに、障害が発生した場合の同じITシステムが複数のビジネスプロセスに影響を与える可能性がありますが、プロジェクト内で非常に心配したのは2つのプロセスだけです。 次に、次のパラメーターに従ってクレームを評価しました。
- 脅威の広がり;
- 警告する機能;
- 暴露時間;
- 発生確率;
- 推定損傷。
その結果、ヒートマップを作成し、各アプリケーションはダウンタイム中にビジネスがどれだけ熱くなるかを予測しました。 たとえば、個々のSAPモジュールの4時間のダウンタイムの場合、会社は依然として深刻な問題を受け取りませんが、ヒートマップ上のキャッシュレジスタソフトウェアのダウンタイムの最初の1時間でさえ、赤くマークされます。
リスク評価とさらなるランキングは専門家グループの助けを借りて形成され、顧客にとって最も重大な状況を判断するために必要であることを明確にする必要があります。
偶発的なリスクとシナリオ。 データセンターの火災：サーバールームが完全に燃え尽き、「補充」プロセスに関係するSAPモジュールが使用できなくなります。 これは、毎日、燃やされたSAPモジュールが復元されるまで、製品範囲が縮小されることを意味します。 まず第一に、これは傷みやすい製品、第二に大きな需要のある製品（たとえば、穀物やパン）、第三に家庭用化学品に関係します。 明らかに、この状況は店舗の収益の減少につながります。 しかし、これは完全には明らかではありません。ビールやタバコを求めて来た買い手は、商品がなくてもほとんど何も買えないでしょう。 価格設定プロセスについても同様です。 水曜日の午後12:00に割引について知る条件付き買い手が午後に店に到着し、「価格設定」プロセスが機能しない場合（つまり、割引なしの価格）、彼は：
A）何も買わない（=経済的損失）;
B）ストアを詐欺（=評判の喪失）で告発する
B）規制当局への不満（=不公平な広告に対する罰則）。
損失推定手法
上記からおそらく理解したように、経済的損失を計算するためにも、割引、プロモーション、時間帯、繁忙期（たとえば、12月末の興奮）を考慮した計算方法と計算式を開発する必要があります。 テクニックには、わかりやすいように表とグラフに加えて、説明的な部分（それがどこから来て、なぜ重み係数を掛けるのか）を含める必要があります。
この手法では次のことも説明しています。
- ビジネスプロセスの回復時間の決定方法
- ビジネスプロセスの復旧時間がITシステムのRTO / RPOにどのように変換されるか。
- 重要度クラスと回復クラス-これが必要な理由。
さらに進んでいます。
RTO計算
すべてのインタビューが実行された後、ビジネスプロセスが記述され、リスクが評価され、方法論が定義および承認され、損失が計算されます。 Pyaterochka、Carousel、Crossroadsのビジネスは少なくとも規模が異なるため、ネットワークごとに独自のテーブル、スケジュール、損失計算を開発しました。
ビジネスプロセス全体では、損失がしきい値を超えると、回復時間が決定されます（方法論を参照）（しきい値を参照）。 この回復時間は、ビジネスプロセスに関係するITシステムに割り当てられます（インタビューと依存関係マトリックスを参照）。 連続性のパラメータが定義されているように思われます-プロジェクトは完了しています（境界とフレームワークを参照）。 ただし、「プロセスは12時間以内に復元する必要があります」と言うだけでは不十分です。 これが今どのように機能するかを決定することが重要です。 今日、ITシステムは何時間回復できますか？ また、現在の回復時間がターゲットよりも長い場合、または大幅に長い場合はどうなりますか？ まだ理性と集中力を保っている人のために、GAPへようこそ！
GAP分析とアクションプラン
前の手順の結果、プロセスとTO TOシステムの状態、つまり理想的な状態を判断しました。 現在の段階では、「現状のまま」の状態を判別します。 同時に、私たちはビジネスプロセスにあまり手を加えず、ITコンポーネントに集中します。 顧客のために、緊急事態からの回復の観点から現在のソリューションを評価しました。 さらに、この場合、タイマーを使用して実際のリカバリを実行する必要はありませんでした。 目標のRTOが達成不可能であることを理解するために、詳細と十分なデスクトップテストを深く掘り下げるだけで十分でした。
その後、一般的な性質（ITの継続性を確保するため）、およびITシステムとそのアーキテクチャに直接関連する多くの推奨事項を作成しました。 これらは、技術的な解決策のスケッチとその実装のコストの大まかな見積もりです。 実際、今では決定の根拠があります。 スケールの一方の側-損失、および他方-対策のコスト。
一部のITシステムがGAP分析に合格しない場合、またはその回復時間が目標よりも長い場合は、目標の状態を達成するためのプロジェクトのプログラムを作成します。または、必要に応じて、プロジェクトのシーケンスを正当化するロードマップと、組織の持続可能性を改善する暫定的な評価を作成します。
さらに、お客様のために、継続性計画と災害復旧計画を作成するための方法論資料とテンプレートを開発しました。
戦略
待って、待って、もうほとんど終わった。
BIAの結果として、IT継続戦略を策定しました。 継続性戦略では、2つの重要なポイントを説明しました。
- 会社の活動に影響を与えるITリスクと考慮されていないITリスク（つまり、継続性の枠組みで私たちが恐れているもの、決定するもの、恐れていないもの、そしてそのためにインシデント管理があります）
- どのような組織、建築、インフラ、その他のソリューションが脅威から防御しますか。
戦略により、1石で2羽の鳥を殺します。 まず第一に、会社の全員が、どのように、そして何から自分を守るのかを理解しています。 第二に、ITの非専門家（たとえば、金融業者）にとって、IT災害復旧ソリューションの予算編成プロセスはより透明に見えます。 そして、どんなに哀れなように聞こえても、戦略は正しい経営上の決定を下すのに役立ちます（DRにお金をかけないという選択肢が常にあります。そして、これが事故の際に会社にどのように影響するかを正確に知っています）。
次は？ 他のビジネスプロセスおよびITシステムの継続性戦略およびビジネスインパクト分析のさらなる実装。 継続性計画の開発、これらの計画の定期的なテスト、これは完全に異なる話です。
Igor Tyukachev、コンサルタント、Jet Infosystems、コンピューティングコンプレックス設計センター