CrowdStrikeの障害： ITアップデートに関する厳しい注意喚起を
多くの方は、何が起こったかご存知だと思いますが、念のため簡単に説明します： CrowdStrikeがソフトウェアのアップデートを行ったところ、特定のWindowsマシンでブルースクリーン・オブ・デス（BSOD）が発生し、起動できなくなりました。これにより、運輸業を含む多くの分野で大規模な障害が発生し、CrowdStrikeのユーザはシステムをロールバックするか、システムを正常な状態に戻すための回避策を実施するために奔走しました。
責任はどこにあるのでしょうか？
何が起こったかを推測し、CrowdStrikeとそのユーザにとってすでに困難な状況に責任を押し付けるのではなく、いずれ起こるこのような出来事に備える責任がIT関係者全員にあると思います。完璧な世界であれば、このようなミスは決して許されません。しかし、ITはまだまだ完璧には程遠いことを我々は知っています。私たちは、このような事態を防ぐだけでなく、その被害を軽減する責任があるはずです。
アップデートのテストは双方向
アップデートを発行するソフトウェア開発者だけがソフトウェアをテストする責任を負っているわけではありません。システムをアップデートするIT担当者も、本番環境にアップデートを展開する前に、アップデートをテストする責任を負っています。ソフトウェア開発者は、ユーザのIT環境で使用しているソフトウェア要素のユニークで特定の組み合わせを予測することはできません。また、可能性のあるすべてのシステム構成をテストしたくてもできません。もちろん、今回のCrowdStrikeの障害の場合、多くのシステムをダウンさせることができたのはWindowsの基本的な構成に影響を与えたからであり、これはさほど大きな要因ではないでしょう。
ワークステーションであろうとサーバであろうと、すべてのソフトウェアアップデートをテストすることは、混乱を避けるための重要なステップです。同じシステム上で動作する2つのソフトウェアが競合する可能性は常にあります。自社のシステムにアップデートを展開する場合は、まず本番環境にできるだけ近い隔離環境でテストする必要があります。しかし、企業内のすべてのシステムやワークステーションに同じソフトウェアが搭載されているとは限らないため、これは必ずしも容易ではありません。
仮想化環境では、オンプレミスでもクラウドでも、本番環境を迅速かつ正確に再現することが可能です。リアルタイムでレプリケートされたバックアップやリカバリーデータを使用することで、テスト用に分離された状態で、現在の本番環境の構成とプロファイルを使用して、ワークロードを仮想環境で迅速に再現（クローン化）することができます。テストにこのような分離されたレプリカ環境を使用することで、テストの検証と保証が強化されます。正確なパフォーマンス負荷など、すべてをテスト環境で正確に再現できるわけではありませんが、隔離されたテスト環境では可能な限りそれに近づけます。
このような分離された環境は、テストを可能にするだけでなく、本番環境に影響を与えることなくテストを行うことができます。分離されたネットワーキング、ストレージ、コンピュート・リソースは、本番環境に混乱や影響を与えません。この方法を使えば、主要な営業時間中であろうと営業時間外であろうと、利用者や顧客に影響を与えることなく、いつでもテストを行うことができます。ソフトウェア・アップデートを組織内でロールアウトする前にテストできないという言い訳はできないはずです。
ロールバック能力
どのようなテストシステムも100％効果的ではありません。必然的に、ソフトウェアの更新や構成の変更によって予期せぬ問題が発生し、混乱が生じます。問題は、いかにして中断前の時点に戻すかです。もちろん、これは何が原因で混乱が生じたかにもよります。単に設定をどこかに戻せば直るかもしれませんが、それほど単純ではないかもしれません。そのためには、体力を使ってディザスタリカバリーを行い、システムを復旧させる必要があるかもしれません。数百人、数千人のユーザーや顧客が重要なシステムにアクセスできなくなるような程度の規模の災害であるかもしれません。
CrowdStrikeの障害では、数千台のワークステーションが直接影響を受け、それぞれのワークステーションを個別に修復する必要がありました。数千のユーザや顧客が、1つのサーバの障害によって同様の影響を受ける可能性があり、その場合は、その特定のサーバだけを修復する必要があります。事故ごとに異なる可能性があるため、構成設定の変更から1つまたは複数の本番ワークロードまで、リカバリデータからロールバックできるように準備しておく必要があります。予期せぬアップデートによる稀な混乱は、完全な災害宣言とDRサイトへのフェイルオーバを必要とするほど深刻な場合もあります。
残念ながら、ワークロードを以前の時点にロールバックすることは痛みを伴うことがあり、特にロールバックによって数時間または数日分のデータが失われる場合はなおさらです。幸運なことに、継続的なデータ保護技術を使えば、更新が行われた時点から数秒以内にリカバリポイントを利用できます。従来のバックアップやスナップショット技術を使用する場合は、システム更新を行う前にバックアップやスナップショットを取得し、より最新のリカバリポイントが利用できるようにすることを推奨します。
ソフトウェア・ベンダーの責任は？
もちろん、ソフトウェアベンダーには、顧客のシステムを混乱させるようなアップデートを提供しない責任があります。我々皆不完全な人間であり、ミスは起こるものです。しかし、先に述べたように、ソフトウェア・ベンダーはあらゆる環境をテストすることはできません。今回のCrowdStrikeの障害に限らず、ベンダーが知り得ないような設定やソフトウェアの組み合わせによって、アップデートが独自のIT環境に特有の予期せぬ問題を引き起こす状況はいくらでもあります。このため、ソフトウェアアップデートがお客様の環境にどのような影響を与えるかを具体的に知ることができるように、配信プロセスの両端でのテストが重要なのです。
まだ導入していない場合は、迅速かつ容易にテストを行い、ロールアウトが計画通りに進まなかった場合にロールバックできるよう、あらゆる種類の管理ツールやリカバリツールを活用しましょう。中断のないテスト環境を提供し、中断が発生する数秒前にロールバックできるリカバリ・ソリューションを使用する。本番環境にロールアウトする前に、すべてのソフトウェア・アップデートのテストを優先します。障害発生を100％防ぐことはできません。しかし、そのほとんどを防ぎ、発生した障害の影響を軽減することは可能です。
参考
●クライムが提供する仮想化・データ保護ソリューション
●Veeam社独自の高速リストア機能「インスタントVMリカバリ」の仕組み