数週間前のある朝、Android端末に34個のソフトウェアアップデートがあることに気付きました。さらに、ノートパソコンにはMicrosoftの最新パッチをインストールした後の再起動が求められており、タブレット端末も最新のファームウェアアップデートと再起動が必要になっていました。サーバにもRed Hatの最新パッチを適用するよう警告が表示されていました。
使用するテクノロジが増えるにつれて、ソフトウェアアップデートの適用作業が、ほとんど日常的な活動になっています。テクノロジ業界で働くすべてのプロフェッショナル、特に大規模な企業ITシステムのパッチ管理を行っている担当者についても同じことが言えます。
私たちは、昨今の大量に発生するパッチに組織がどのように対処しているのかが気になり、このトピックに関する調査を行いました。すると予想どおり、多くの組織では、継続的に追加される膨大な数のパッチを処理するための対応に、大変多くの問題を抱えていることがわかりました。
多くの人にとって、パッチの適用は簡単な作業に見えるかもしれません。ボタンをクリックするだけで済む作業ではないかと。実際はそうではありません。パッチのインストールの難しさはプラットフォームによって異なり、最も簡単なインストール方法 (ボタンのクリック) から、イベントの順番に最新の注意を払う必要のある複雑なシナリオまでさまざまなものが含まれます。
しかし、パッチ適用作業の難易度だけが問題なのではありません。パッチのテストも重要な作業工程の一つであり、現代のエンタープライズITのパッチ管理業務において規模と共に作業の難易度を上げている要素の一つです。
企業は、パッチのもたらす潜在的な影響を把握することなしにやみくもに適用作業を実施するわけにはいきません。パッチプログラムは環境を破壊してきた歴史を持っており、環境の破壊は企業にとってカオスを意味します。
私たちは483人のIT担当者にパッチ管理に関する調査を行いました。その結果、パッチ管理に携わっているプロフェッショナルの約半数は、パッチを展開する前に必ずテストを実施、およそ30%はテストするかどうかはパッチによって異なると回答していました。まったくテストしない担当者は20%未満でした。
別の質問では、デスクトップとサーバのパッチテストに費やす時間について調査しました。図1に見られるように、ほとんどの組織が自社の環境でパッチのテスト作業に1週間近くの期間を費やしています。
図1: パッチのテストにかかる時間。
先月、私はTWiETチャンネルの「Padre」のインタビューを受けました。トピックは「エンタープライズ環境でのパッチ運用の負担」でしたが、Padreが尋ねた問いの1つは企業内への展開前にパッチを徹底的にテストすることの実現可能性に関するものでした。
徹底したパッチテストを実施する組織の能力は、規模とリソースに依存します。優れたパッチ管理ソフトウェアと脆弱性管理ソフトウェアを仮想化テクノロジやオーケストレーションテクノロジと組み合わせることは、組織が徹底的なパッチテストを行う環境を整える上でのサポートになります。
それでも、考えられる全てのパターンをテストすることはどんな組織にとっても困難であることに変わりはありません。規模が大きくなるにつれて、その作業は不可能になります。ノードが増えることは、つまりテストシナリオの数が増大することを意味します。これらの検討事項は、たちまち手に負えなくなります。
そこで私たちが得た結論は、「パッチテストは現在ベストエフォート～最善の努力ベースで行われており、大半のソフトウェアのテストと同様に、全般的なテスト用環境でテストケースの一部分しかテストの対象になっていない」と言うことです。ここで発するべき重要な問いは「システムの接続性がますます高まる将来においても、このシナリオは通用するのか」ということです。
IoTやインダストリアル・インターネット、そしてサイバー物理システムなどの現在のトレンドは、近い将来飛躍的に増加するデバイスのオンライン化による規模拡大の限界に達しようとしています。
例えば、オーストラリアのデータセンターでパッチ適用の失敗により、娯楽番組サービスセンターの誤動作が生じ、操作がきかなくなるということも考えられます。他にもさまざまな障害が発生する可能性があり、技術者はこの種の課題を検討する必要があります。
パッチテスト問題の軽減に役立つ新しい技術やイノベーションがこれから出現することは明らかであり、自動化テストプロセスに関する高度な研究がこの分野で確実に役立つと信じています。未来の発展がパッチ適用の分野に新たな技術をもたらす可能性についても大変興味深いところです。
Title image courtesy of ShutterStock
元の記事はこちらからご覧いただけます。
