大規模インシデント管理 - 変更が大失敗したときに備えるために

企業が大規模インシデントのプロセスを策定する際には、まず大規模インシデントの構成要素を検討します。組織は、ハッカーやサイバー攻撃によってネットワークが破壊され、データセキュリティ上の問題が発生する可能性があることに外部から注目する傾向があります。そのため、インシデントの優先順位を外部原因に重点を置いて定義します。

これは妥当な懸念です。今日の企業環境では、システム侵害の被害は、必ずしも「もしも」ではなく、「いつ」という問題です。そのため、企業はシステム侵害の責任を メジャーインシデントマネジメント サービス停止を引き起こす可能性のある外部要因について、チームで検討します。しかし、大規模なインシデントは、システム障害や外部からの攻撃だけが原因ではないことを忘れがちです。大規模インシデントは、システム障害や外部からの攻撃だけではなく、計画された変更が失敗に終わった場合にも起こり得ます。

チェンジマネジメントが原因で重大なインシデントが発生した場合

まず第一に、ユーザーが影響を受けるだけでなく、プロセス、役割、責任についても混乱が生じる可能性が高いことを認識する必要があります。

変更によって大規模なインシデントが発生した場合、システムの状態が異なることが多く、計画されたダウンタイムのために多くのステークホルダーが関与しなくなります。変更管理プロセスとインシデント管理プロセスは並行して運用する必要があり、チームごとにプロセスオーナーが異なる場合もあります。このような複雑な状況では、ビジネスへの影響が大きい時にインシデントを管理することが非常に困難になり、ビジネスにとってリスクの高い状況になってしまいます。

このシナリオを事前に検討し、どのように対処するかを考えておかないと、変更管理プロセスとインシデント管理プロセスが衝突してしまう可能性が高くなります。そうなると、テクニカルサポートスタッフや経営陣は、誰がコントロールしているのか、誰がコミュニケーションを取るべきなのか、そして、できるだけ早くサービスを復旧させるためにはどのように意思決定をすべきなのか、といったことが分からなくなってしまいます。


大きな事件が起きたときに備えて ツールキットのダウンロード


変更管理とインシデント管理の計画を一致させる方法

変化に起因する大規模なインシデントに対応するための自社の計画を分析・準備するにあたり、通常の変更管理とインシデント管理のアプローチが異なり、調整が必要となる重要な領域を以下に示します。

コミュニケーション - 最初に衝突するのは、コミュニケーションの分野です。通常の変化のある環境では、コミュニケーション計画は台本に沿った日常的なものであり、頻度も低く、状況や活動内容、業務への影響などの技術的な詳細は省かれます。しかし、大規模なインシデントが発生した場合、コミュニケーションの必要性はほぼ逆になります。その代わりに、ステークホルダーに影響、診断活動、状況を頻繁に知らせることに重点を置きます。これにより、サポートチームが問題を掌握していることをステークホルダーに確信させることができます。

また、これらのシナリオが衝突した場合、コミュニケーション手法の違いにより、解決までの時間が長くなることもあります。この2つの状況が同時に発生した場合、誰がどのくらいの頻度でコミュニケーションを取るべきかを確立することが重要です。また、それぞれのコミュニケーションの焦点を明確にします。最も重要なことは、混乱や混乱を招かないように、すべての最新情報の要求は、指定された連絡先を通すことです。

意思決定の仕組み - 変更管理のための意思決定機関は、通常、定期的に行われ、標準化された文書が作成され、提言の信頼性に焦点を当てた高度な構造になっています。一方、大規模なインシデントが発生した場合には、インシデントを解決するために、コスト/ベネフィット、トレードオフ、リスクを考慮しながら、リアルタイムで意思決定を行う必要があります。

混乱を避けるためには、意思決定の権限が変更管理からインシデント管理に切り替わるタイミングを明確にし、インシデントが解決した後、どのように変更管理に戻すかを明確にする必要があります。

ロールフォワードとロールバック - ほとんどの変更管理プロセスにおいて、失敗した変更に対処するための一般的なアプローチは、変更をロールバックして、システムの以前の作業構成に戻すことです。これは、大規模なインシデントが発生しない限り、サービスの回復を確実にするためには、ほぼ成功します。

大規模なインシデントが発生した場合、あなたの会社では、ロールバックではなくロールフォワードという異なる選択肢を検討する必要があるかもしれません。新しい変更を開発して展開することで、解決までの時間を短縮できる可能性があります。ロールフォワードを決定するのは、ロールバック計画が失敗した結果であることもあります。また、計画された変更を実施することのビジネス上の重要性を再定義したり、さまざまなオプションのコスト/ベネフィット/リスクプロファイルを比較評価した結果であることもあります。

根本原因分析 - 変更が原因で重大なインシデントが発生した場合、行わなければならない根本原因の分析作業は2つあります。1つ目は、変更がなぜ失敗したのか、問題を修正して再発を防ぐためには何をすべきかを理解するための変更の技術的な分析です。2つ目は、変更管理プロセスの分析で、欠陥のある変更がどのようにしてリリースを承認されたかを調べます。この2つ目の作業は、開発・テストプロセスの問題を明らかにし、変更管理プロセス内のプロセスコントロールを強化するために重要です。

変化によって引き起こされる重大なインシデントは、企業にとってハイリスクなシナリオであり、発生する可能性も高く、発生した場合の影響も甚大です。これらは、収益の損失につながり、さらに重要なことには、お客様からの信頼を失うことになります。

チェンジマネジメントに起因する大規模なインシデントに対する最善の備えは、こうしたシナリオが発生したときにチームがどのように対応するかを計画し、事前に練習しておくことです。まだ計画を立てていない場合は、基本的な事項(コミュニケーション、意思決定、技術的な選択肢、継続的な改善/原因分析)に焦点を当てることから始めるのがよいでしょう。既存のプロセスがある場合は、ビジネスへの影響を最小限にするためにプロセスを改良・調整し、対象となるステークホルダーとのコミュニケーションを行い、診断と意思決定が行われている間に根本原因分析の情報を取得する手順を追加します。


大規模災害への備えについては、こちらをご覧ください。 ツールキットのダウンロード


関連記事

ブログ画像1
メジャー・インシデント・エッセンシャルズ。コミュニケーションと効果的なアクション。助けて!どうすればいいの?
ブログ画像1
重大インシデント対応。大規模インシデント対応の計画に待ったをかけるな
ブログ画像1
インシデントとトラブル、表裏一体の関係
ブログ画像1
インシデントを解決するか、問題を解決するか。

私たちは以下の専門家です:

お問い合わせ

お問い合わせ、詳細、ご提案はこちらから