CrowdStrikeが引き起こした「Windows」のシステム障害から、企業のソフトウェア開発者は何を学ぶべきか。現代のシステム運用における新たなリスクと、その対策とは。
セキュリティベンダーCrowdStrikeのエンドポイントセキュリティツール「CrowdStrike Falcon」が、MicrosoftのOS「Windows」を搭載した世界各地のデバイスでシステム障害を起こしたのは2024年7月のことだ。この事態は、現代のソフトウェア開発とテスト戦略が抱える本質的な課題を浮き彫りにした。単なるバグ修正や機能テストだけでは見逃してしまう重大な問題が、システムの信頼性を脅かしている可能性がある。今回のシステム障害から得られた具体的な教訓と、実践的な対策を解説する。
テストと品質管理は「保険」と考えるべきだ。つまり、後で何か問題が発生した時に被害を軽減できるよう、前もって保険をかけておく行為だと言える。何も起こらなかった場合、保険が不要だったと感じても、それは問題ない。無保険のリスクは計り知れない。
今回の事故を経て、今考慮すべき教訓を紹介する。リスクとその影響について考えることが、リスクを軽減するために、経営陣が自ら考え、行動するために役に立つかもしれない。
起こり得る最悪の結果を想定し、そこから逆算してリスクを測定、評価する。極端なシナリオを用いたテスト手法「ソープオペラテスト」や、予期しない劇的な状況を分析する「ソープオペラ分析」は、部門横断的なワークショップとして数時間で実施できる。
信頼性は、継続的な稼働時間、高可用性、不具合がないことを重視する。レジリエンス（回復力）は、障害は避けられないものと考え、被害を最小限に抑えるために、迅速な問題発見、サービス復旧、バックアップ、切り替え、冗長性に重点を置く。
CrowdStrikeは「move fast and break things」（素早く動き、破壊せよ）という、開発と運用に関するマーク・ザッカーバーグ氏の言葉を重視し過ぎていたように見える。問題が起きれば、更新をロールバックすればよいと考えていたようだ。Micorosftは、今回被害を受けたWindows搭載デバイスは、全体の1％未満だったと推測している。CrowdStrikeは、Windowsが他のシステムと、どれほど異なる特別なものかを想定していなかった。この機会に、本番環境と人手による分析の両方を見直す必要があると言える。
テスターは不要な存在や余計なコストのように扱われがちな一方で、企業はテスターがいれば発見できたはずの不具合を見落としている。テスターの採用が難しいのであれば、開発者がお互いの仕事を相互チェックしたり、互いを知らない人の気持ちになって仕事を相互テストする「クロスチームテスト」を実施したりするとよい。
バグ追跡ツールで捕捉できず、本番環境に展開してしまった直近の不具合を幾つか振り返ってほしい。そこにはコーディング要件の誤りに起因しているものがあるはずだ。不具合をチェックするプロセスを自動化できていなかったからではなく、誰もそれをテストしようとは思わなかったことが原因だ。想像力が不足していたのだ。
CrowdStrikeの障害は、自社は誰がテストに関するアイデアを出しているのか、アイデアがどのようにふるいにかけられているのか、誰が採用するものを決めているのかを再考するきっかけになる。これはテスト戦略の見直しだ。一貫した明確なテスト戦略がないことに気付く企業もあるだろう。単体テスト、機能テスト、ストレステスト、E2E（エンドツーエンド）テストなど、いろいろなテストを実施していたとしても、それは一貫したテスト戦略とは言えない。今回の障害は、一貫したテスト戦略を策定するチャンスだ。
企業がテストに投資している金額は、意識的に決めたのではなく、無意識の選択が重なることによる、わずかな出費がたくさん積み上がった結果のはずだ。このようなやり方では、きちんと手入れをしていない畑で、収穫物の品質、大きさ、風味について文句を言うようなものだ。テスト戦略を策定したら、コストではなく投資している時間と投資効果を測定し、適切かどうかを確認する。
障害発生後、CrowdStrikeは状況を乗り越えるために努力してくれたパートナー企業や従業員に対し、感謝のしるしとして、10ドル相当のギフトカードを送ったと報じられている。このような状況に見合わない対応は、かえって混乱や不信を引き起こした。
これは広報チームが独断的に決めた不適切な動きだった可能性はある。とはいえ企業は、深刻なシステム障害が発生した場合に外部パートナーと連携する方法を前もって検討しておくべきだ。
商用ソフトウェアで発生する障害のリスクと被害の最小化のために、企業ができることを列挙する。
やはり問題はリスク、リターン、労力、タイミングのバランスだ。SaaS（Software as a Service）の場合、ステージング環境でテストできないことがある。その場合は、SaaSベンダーがリスクを抑えるために実施していることと、自社でできることを再検討しよう。
アプリケーションやOSについて、特定のシステムには段階的に展開することを検討する。障害が発生しても問題ないシステムから更新を開始し、高可用性システムやミッションクリティカルなシステムの更新は最後に実施するとよい。
インターネットに接続した全てのデバイスをベンダーが強制的に更新できる場合、段階的ロールアウトは役に立たない。この場合は、起こり得る事象を調査し、ミッションクリティカルなシステムはインターネットに接続させないなど、追加の対策を検討する。
品質保証ではなく、サイバー保険を提供している企業もある。自社でソフトウェアを開発せず、運用をベンダーに任せている企業には有力な選択肢だ。
DevOps（開発と運用の融合）と自動化は、少なくとも理論的には、一貫性がなくエラーを起こしやすい人への依存を減らし、リスクを軽減できる。だが結局のところ、自動化プログラムを書くのは人だ。そして、人が書いたプログラムにバグは付き物だ。CrowdStrikeの障害をきっかけに、セキュリティと品質について再検討しよう。
米国TechTargetの豊富な記事の中から、開発のノウハウや技術知識など、ITエンジニアの問題解決に役立つ情報を厳選してお届けします。
Copyright © ITmedia, Inc. All Rights Reserved.
2024年の消費者購買行動変化 「日本酒」に注目してみると……
2023年と比較して2024年の消費者の購買行動にはどのような変化があったのか。カタリナマ...
FacebookやXなど主要SNSで進む「外部リンク制限」の実態 唯一の例外は？
ソーシャルメディアはかつてWebサイトへの重要な流入経路であった。しかし、最近は各プラ...
生成AIとAR／VRで失った個性を取り戻す――2025年のSNS大予測（Instagram編）
万能だが特徴のはっきりしない「何でも屋」と化したInstagram。2025年の進化の方向性を予...
ITmediaはアイティメディア株式会社の登録商標です。
