クラウド停止で“現場崩壊”を防ぐには？ 情シスが築くべき「4つの防衛線」：クラウド障害で情シスはどう動くべきか【後編】
システム障害は避けられないが、その後の致命的な混乱は防ぐことができる。パニックを防ぎ、経営層への報告を乗り切るために不可欠な「インシデント対処計画」と、障害に耐え得る「アーキテクチャ」の正体とは。
「Amazon Web Services」（AWS）や「Microsoft Azure」といった主要クラウドサービスであっても、大規模障害を完全に防ぐことはできない。クラウドサービスへの依存が深まる現代、ひとたび障害が発生すれば、その影響は企業の事業運営を根幹から揺るがすことになる。「いつ直るのか」という電話が鳴り止まず、担当者は状況確認に追われ、経営層への報告もままならないのが現実だ。「障害は起きない」という前提はもはや通用せず、システムが停止してもビジネスを継続させるレジリエンス（回復力）の確保が急務だ。
システム自体の復旧は、あくまでスタートラインだ。混乱の中で統制を取り、業務への影響を最小限に抑えるためには、「誰が、何を、どの順番で判断するか」をあらかじめ設計しておく必要がある。本稿は、有事の際に現場をパニックから救うインシデント対処計画の4要素と、投資対効果に見合うレジリエンス設計の具体論を解説する。
現場の迷走を防ぐ「インシデント対処計画」に必須の4要素
併せて読みたいお薦め記事
連載：クラウド障害で情シスはどう動くべきか
ベンダーでシステム障害が発生したら
クラウドサービス中心のシステムにおいて、クラウドサービス障害への備えと初動対応は極めて重要だ。事前に定義された計画があれば、障害によって混乱が発生した際にも、企業は業務の効率と企業性を維持できる。これらの計画によって、通常業務への復帰を早め、財務損失やブランドの毀損（きそん）、顧客への悪影響といったリスクを軽減できる可能性が高まる。
インシデント対処計画を構成する主要な4つの要素は以下の通りだ。
1．検出
インシデント検出に対して能動的（プロアクティブ）であることは、問題が深刻化する前の早期発見につながる。企業はシステムヘルス、ベンダーのステータス、連携ポイントの継続的な監視といった検出手段を用意すべきだ。自動アラートを活用すれば、検出を効率化し、問題に迅速に対処できるようになる。
2．エスカレーション
社内でインシデントをいつエスカレーション（上位担当者への報告、相談）すべきか、誰に通知すべきかについての明確なガイダンスがあれば、混乱の中でも組織的な統制を保つことができる。「最初のステップは、エスカレーションの判断基準を特定し、通知すべき相手と意思決定に必要な最低限の情報について合意を得ることだ」と、コンビニエンスストアチェーンWawaでシニア事業継続アドバイザーを務めるジャスティン・ケイツ氏は言う。
3．連絡／コミュニケーション
強固なインシデント対処計画には、インシデント発生中に誰が情報を把握しておく必要があるか、いつ、どのように情報を伝達するかを明記すべきだ。必要なコミュニケーションは、サイバー攻撃かシステム障害かといったインシデントの種類によって異なる場合がある。影響を受ける事業部門や外部関係者への周知も忘れてはならない。
4．フェイルオーバー
冗長化されたサーバや代替ベンダーへの切り替えといったフェイルオーバー（待機系への自動切り替え）戦略は、システムのダウンタイム（停止時間）を最小限に抑え、事業継続性を維持するために不可欠だ。フェイルオーバー戦略は、インシデントからの復旧中に業務への支障を抑えるため、事前に決定して文書化しておくべきだ。インシデント対処計画が確実に機能するよう、フェイルオーバーの手順を定期的に見直し、テストする必要がある。
インシデント対処計画は、関与する全チームを巻き込んで訓練されるべきだ。インシデント対処ツールベンダーCYGNVSのCEO兼創設者であるアルビンド・パルタサラティ氏は、同社の顧客である大手グローバルサービスベンダーを例に挙げる。その顧客企業は、毎月手短な机上演習を実施している。法務や営業といった部門との演習、取締役会との演習、外部顧問との演習だ。「演習プロセスを反復可能で小規模なものにしたことで、今では企業文化の一部として定着した。演習のたびに、企業全体の連携が強化されている」と同氏は効果を語る。
ただし、演習を実りあるものにするためには、テストは現実的でなければならない。「シナリオを用いてチームに対処手順をシミュレーションさせることで、本番のプレッシャーがかかる前に、計画、チーム、あるいは演習の欠陥を特定できる」とケイツ氏は言う。演習後には「非難しない振り返り」（ポストモーテム）を実施し、改善点を洗い出して計画や手順を改善することも欠かせない。
「レジリエントなアーキテクチャ」を設計するには
障害に対して強固なアーキテクチャは、事業継続戦略に不可欠だ。ITコンサルティング企業Accentureのグローバルサイバーインテリジェンスリードであるライアン・ウェラン氏は、「大規模なクラウドサービス障害中に事業を継続させるには、受動的な監視から能動的なレジリエンスへと意識を変える必要がある」と説く。
システムアーキテクチャには、インシデントの影響を緩和し、障害から迅速に復旧できる回復力が求められる。「最も重要なアプリケーションとデータはパブリッククラウド、プライベートクラウド、オンプレミスシステムを組み合わせて活用し、事業のレジリエンスと費用のバランスを取る戦略が、企業に浸透しつつある」とウェラン氏は指摘する。
複数のクラウドサービスを併用するマルチクラウドは単一ベンダーへの依存を減らし、クラウドサービス間で戦略的に業務を分散できる。これによってあるシステムで障害が発生しても、他の中核的な事業機能は滞りなく継続できるようになる。
ハイブリッドクラウドは、パブリッククラウドとオンプレミスインフラを併用することで、ベンダーへの依存を減らし、ベンダーのトラブルに起因するリスクを低減する上で有用だ。オンプレミスインフラは、サイバー攻撃などのセキュリティインシデント発生時にも、データの安全性とセキュリティを確保する役割も果たす。
レジリエンスを確保できるアーキテクチャには冗長性を組み込み、重要な業務を複数の環境で扱えるようにすることで、業務を中断させるリスクを回避すべきだ。
こうしたアーキテクチャの構築は初期費用がかさむように見えるが、システム障害が発生した際に、業務が完全に停止するか、中核機能を維持できるかの分かれ目となる。「耐障害性があるアーキテクチャは、投資に対して十分に元が取れる」とパルタサラティ氏は言う。同氏は、危機の収束までの時間が数日から60分未満に短縮され、平均修復時間（MTTR）も数日単位で短縮されるのを目の当たりにしてきた。コンプライアンスや証拠保全のために、全てのアクションを記録することも選択肢だ。
リーダーシップとガバナンスを発揮するには
ベンダーのシステム障害が、ITの領域を超えて重大な影響を及ぼすことは明らかだ。顧客サービスから業務運営に至るまで、さまざまな場面に影響を与える。だからこそ、CIO（最高情報責任者）やCTO（最高技術責任者）といった経営層が、システムの監視やリスク評価から取締役会への報告に至るまで、あらゆる局面に関与することが重要だ。
パルタサラティ氏によれば、システム障害やそれに関する事象に対して、取締役会や経営幹部は関わりを持とうと関心や意欲を示し始めている。「彼らは遠くからの傍観者であることを望んでいない。危機が発生した際、それが事業に直結する出来事であるからこそ、自身の役割を理解し、当事者として参画したいと考えている」（同氏）
システム障害は避けられないが、それが事業に与える影響の度合いは、ITリーダーがいかに準備できているかにかかっている。机上演習や事後検証を実施することで、インシデント対処計画が最適化され、障害発生時に即座に動ける状態を保つことができる。
インシデント管理ツールベンダーPagerDutyのエンジニアリング担当シニアバイスプレジデントであるルクミニ・レディー氏は、復旧チームが意図的な障害を発生させ、隠れた依存関係をあぶり出すことに注力していると説明する。具体的には、システムが不安定な状況でも継続して動作できるよう、意図的に本番環境に障害を引き起こすテスト手法「カオスエンジニアリング」や、毎週金曜に意図的に障害を起こす訓練「フェイラーフライデー」（障害金曜日）などだ。これらを通じて復旧メカニズムを検証し、インシデント対処の「基礎体力」を強化しているという。同氏は次のように述べる。「AI（人工知能）技術の進歩に応じて、AI技術がシステムの運用と復旧のワークフローに深く組み込まれるにつれ、レジリエンスはますます人間の判断力に依存するようになっている。つまり決して折れることなく、しなやかに適応できるシステムとチームを構築することが重要だ」
システムのレジリエンスの構築を、後付けの対策で終わらせてはならない。企業の中核的な能力（コアコンピテンシー）として、事業の根幹に据えるべきだ。クラウドサービスの停止やシステム障害を乗り越え、成長するための力に変えるためには、インシデント後の監査やシミュレーションを通じて、定期的にシステムの運用と復旧の体制、計画を見直さなければならない。
Copyright © ITmedia, Inc. All Rights Reserved.