JP2022520005A - ハイブリッド・コンピューティング環境におけるパッチ管理 - Google Patents

Abstract

コンピューティング・プラットフォームに関連付けられたワークロードに対するパッチの実行を管理するための技術が提示される。パッチ識別コンポーネントは、コンピューティング・プラットフォームに関連付けられたワークロードを識別することができる。このワークロードは、パッチの第１のサブセットをオフラインで実行できる第１のワークロード部分およびパッチの第２のサブセットをオンラインで実行できる第２のワークロード部分を含むことができる。パッチ管理コンポーネントは、第１のワークロード部分に関して、パッチの第１のサブセットのパッチの脆弱性スコアに基づいて、オフラインであるときに保守時間ウィンドウ内で実行できるパッチの第１のサブセットの一部を決定することができ、第２のワークロード部分に関して、オンラインであるときに実行できるパッチの第２のサブセットを決定することができる。パッチ管理コンポーネントは、パッチの重要度に基づいてパッチの第１のサブセットのパッチの脆弱性スコアを決定することができる。

Description

本開示は、コンピュータ関連システムに関連しており、より詳細には、ハイブリッド・コンピューティング環境におけるパッチ管理に関連している。

以下に、開示される対象の１つまたは複数の実施形態の基本的理解を可能にするための概要を示す。この概要は、主要な要素または重要な要素を特定するよう意図されておらず、特定の実施形態の範囲または特許請求の範囲を正確に説明するよう意図されていない。この概要の唯一の目的は、後で提示されるより詳細な説明のための前置きとして、概念を簡略化された形態で提示することである。本明細書に記載された１つまたは複数の実施形態では、システム、デバイス、構造、コンピュータ実装方法、装置、またはコンピュータ・プログラム製品が、コンピューティング・システムのワークロードに関連付けられたパッチの適用の管理を容易にすることができる。

一実施形態によれば、コンピュータ実装方法は、プロセッサに動作可能なように結合されたシステムによって、コンピューティング・プラットフォームに関連付けられたワークロードを決定することを含み、このワークロードは、パッチの第１のサブセットが実行される第１のワークロード部分を含む。コンピュータ実装方法は、システムによって、パッチの第１のサブセットのパッチの脆弱性スコアに基づいて保守時間ウィンドウ内で第１のワークロード部分の一部に適用するためのパッチの第２のサブセットを決定することも含み、パッチの第１のサブセットは、パッチの第２のサブセットを含む。

一部の実施形態では、開示される方法に関連して説明される要素が、システム、コンピュータ・プログラム製品、または別の形態などの、さまざまな形態で具現化され得る。

別の実施形態によれば、システムは、コンピュータ実行可能コンポーネントを格納するメモリと、メモリに動作可能なように結合された、コンピュータ実行可能コンポーネントを実行するプロセッサとを備えることができる。コンピュータ実行可能コンポーネントは、コンピューティング・プラットフォームに関連付けられたワークロードを識別する更新識別コンポーネントを含むことができ、このワークロードは、更新の第１のサブセットが実行される第１のワークロード部分および更新の第２のサブセットが実行される第２のワークロード部分を含む。コンピュータ実行可能コンポーネントは、第１のワークロード部分に関連付けられた更新の第１のサブセットの更新の脆弱性スコアに基づいて保守期間内に第１のワークロード部分の一部に適用するための更新の第３のサブセットを決定する更新管理コンポーネント含むこともでき、更新の第１のサブセットは、更新の第３のサブセットを含む。

一部の実施形態では、開示されたシステムに関連して説明される要素が、コンピュータ実装方法、コンピュータ・プログラム製品、または別の形態などの、さまざまな形態で具現化され得る。

これらおよびその他の特徴は、以下の詳細な実施形態例の説明から明らかになり、その説明は添付の図面と併せて読む必要がある。

開示される対象のさまざまな態様および実施形態に従って、コンピューティング・システム上でパッチを効率的に管理して適用することに利用され得る、例示的な非限定的システムのブロック図を示す図である。 開示される対象のさまざまな態様および実施形態に従って、複数のディメンションにわたることができるワークロードを含んでいる例示的な非限定的コンピューティング・システムを示す図である。 開示される対象のさまざまな態様および実施形態に従って、パッチに関連付けられたワークロードがオフラインであるときに、保守時間ウィンドウの間にパッチを適用するための例示的なパッチ・シーケンスのブロック図を示す図である。 開示される対象のさまざまな態様および実施形態に従って、ワークロードのリソース間の依存関係の決定およびパッチ管理に関連して例示的なアプリケーション・トポロジーを示す図である。 開示される対象のさまざまな態様および実施形態に従って、ワークロードのリソース間の依存関係およびパッチ管理に関連して、コンピューティング・システムに関連付けられた例示的なワークロードに関して例示的なパッチ選択を示す図である。 開示される対象のさまざまな態様および実施形態に従って、例示的なパッチ管理コンポーネント６００のブロック図を示す図である。 開示される対象のさまざまな態様および実施形態に従って、コンピューティング・プラットフォームに関連付けられたパッチを管理するための別の例示的な非限定的方法のフロー図を示す図である。 開示される対象のさまざまな態様および実施形態に従って、コンピューティング・プラットフォームに関連付けられたパッチを管理するための別の例示的な非限定的方法のフロー図を示す図である。 本明細書に記載された１つまたは複数の実施形態を容易にすることができる例示的な非限定的動作環境のブロック図を示す図である。

以下の詳細な説明は、例にすぎず、実施形態、または実施形態の適用もしくは使用を制限するよう意図されていない。さらに、先行する「背景技術」または「発明の概要」のセクション、あるいは「発明を実施するための形態」のセクションで提示された、いずれかの明示されたか、または暗示された情報によって制約されるという意図はない。

ここで、図面を参照して１つまたは複数の実施形態が説明され、図面全体を通じて、類似する参照番号が、類似する要素を参照するために使用されている。以下の説明では、説明の目的で、１つまたは複数の実施形態を十分に理解できるように、多数の特定の詳細が示されている。しかし、これらの特定の詳細がなくても、さまざまな事例において、１つまたは複数の実施形態が実践され得るということは明らかである。

マルウェア攻撃は、コンピュータ関連システムをダウンさせることができ、ダウンタイムおよび回復のコストにおいて、企業およびその他の実体に多額の（例えば、数千ドル、数万ドル、数十万ドルなどの）負担をかける可能性がある。通常、企業は、多数のシステム（例えば、コンピュータ関連システム）にパッチを適用するための時間およびリソースを持っておらず、一方、その他の企業は、不適切なほど余裕がある時間およびリソースを費やしている。

コンピュータ関連システムの自動化されたパッチ適用は、コンピュータ関連システムの手動のパッチ適用の損失およびコンピュータ関連システムにパッチを適用しないことのリスクに対する、コスト効率の高い代替手段になることができる。コンピュータ関連システムおよびその一部にパッチを適用することおよびパッチを適用しないことのコストをリスクのレベルに対して測定し、リスクに対するコストのそのような測定から、いつパッチを実行するべきか、およびどのパッチを実行するべきかを決定することは、有用かつ望ましいことであり得る。

パッチ適用に関する別の考慮事項は、パッチ適用時間が通常は一定でなく、複数の要因がパッチ適用に影響を与える可能性があるということである。システムの不均一性（例えば、システムのプラットフォーム、構成、およびデプロイされるアプリケーションにおける変化）は、非標準のシステムをテストすることが相対的に困難であることがあるため、少なくとも一部のパッチが失敗する可能性を増大させることがある。

さらに別の考慮事項は、パッチを実行するコストがパッチを適用しないコスト以下になることができる最も早い時点でコンピュータ関連システムまたはその一部にパッチを適用することが、通常はより良いことである可能性があるということである。コンピュータ関連システムの利用が公開された後に、パッチが適用されていないコンピュータ関連システムのリスクが、一般に、著しく（例えば、劇的に）増大することがある。

さらに別の考慮事項は、コンピュータ関連システムに対するパッチが、不具合を含んでいることがあるということである。その結果、パッチが実施された後に、パッチまたはパッチが実施されたコンピュータ関連システムが容認できる状態で機能していることの妥当性を確認できるのが望ましいことがあり、パッチまたはコンピュータ関連システムが容認できる状態で機能していない場合、パッチのロールバックまたは取消しを実行して、コンピュータ関連システムをパッチが実施される前の状態に戻すのが望ましいことがある。

コンピュータ関連システムのハイブリッド・ワークロードに対してパッチを実行する場合、重要な課題がさらに存在することがある。計算の条件および仕様が変化することがあり、ワークロードも変化することがある。ハイブリッド・ワークロードは、例えば、複数のクラウドまたは複数のオペレーティング・システム・アーキテクチャ、クラウド・デプロイメント・モデルの一種（例えば、従来のコンピューティング・インフラストラクチャ、プライベート・クラウドまたはパブリック・クラウド、オンプレミスおよびオフプレミス、専用または共有など）、デプロイメントの一種（例えば、ベアメタル・マシン、仮想マシン（ＶＭ：virtual machine）、コンテナ、外部サービスなど）、ワークロードの一種（例えば、バッチ・ワークロード、トランザクション・ワークロード、分析ワークロード、高性能のワークロード、データベース・ワークロードまたは中央処理装置（ＣＰＵ：central processing unit）、ディスク負荷またはプロセッサ負荷の大きいワークロードなど）、パッチを実行する頻度（例えば、毎月または月末のパッチ適用、パッチ適用の季節変動など）、あるいは開発および運用（ＤｅｖＯｐｓ：development and operations）プロセスを含んでいる複数のディメンションから成る（例えば、複数のディメンションにわたる）ことができる。ワークロードの複数の層（例えば、ノード）間には、依存関係が存在することもある。

さらに、ノードのパッチ適用は、例えばクラスタ化されたサービスまたは常時接続のサービスに関しては、オンラインまたはライブで実行することができ、あるいはオフラインで実行することもでき、その場合、ノードおよび関連するアプリケーションがオフラインであるときに、パッチ適用が実行される。通常、オフラインであるときにノードおよび関連するアプリケーションに対してパッチを実行できる使用可能なダウンタイム・ウィンドウが制限されているという、別の課題が存在することがある。考慮するべきさらに別の課題は、例えば、あるパッチが高い重要性を有し、他のパッチが中程度の重要性を有し、さらに他のパッチが比較的低い重要性を有することがあるため、パッチに関連付けられた重要性、優先度、または脆弱性（例えば、脆弱性スコア）における変動が存在することがあるということである。また、現在、適用可能なインフラストラクチャの制約の範囲内でオペレーティング・システム、ミドルウェア、およびアプリケーションに別々にパッチを適用することに対して、通常はユーザ（例えば、顧客）が責任を負う可能性があるということに注意する。

そのような目的で、本明細書におけるさまざまな実施形態は、例えばハイブリッド・コンピューティング環境（例えば、ハイブリッド・クラウド・コンピューティング環境）などの、コンピューティング環境内でパッチを管理するための手法に関連している。パッチ識別コンポーネントは、コンピューティング・プラットフォームに関連付けられたワークロードを識別することができる。このワークロードは、パッチの第１のサブセットをオフラインで実行できる第１のワークロード部分およびパッチの第２のサブセットをオンラインで実行できる第２のワークロード部分を含むことができる。パッチ管理コンポーネント（ＰＭＣ：patch management component）は、第１のワークロード部分に関して、パッチの第１のサブセットのパッチの脆弱性スコアに基づいて、オフラインであるときに保守時間ウィンドウ内で第１のワークロード部分の一部に対して実行できるパッチの第１のサブセットの一部（例えば、第３のサブセット）を決定することができ、第２のワークロード部分に関して、オンラインであるときに実行できるパッチの第２のサブセットを決定することができる。ＰＭＣは、保守時間ウィンドウの間に適用するためのパッチの第１のサブセットの一部（例えば、第３のサブセット）、および第２のワークロード部分に適用するためのパッチの第２のサブセットを決定することを容易にするために、パッチの相対的な重要度に少なくとも部分的に基づいて、パッチの脆弱性スコアまたはパッチのグループ（例えば、パッチの異なるグループ化）のグループ脆弱性スコア（group vulnerability scores）を決定することができる。一部の実施形態では、パッチの第３のサブセットのパッチの少なくとも一部を、互いに同時にまたは並列に適用することができ、あるいはパッチの第２のサブセットのパッチの少なくとも一部を、互いに、またはパッチの第３のサブセットのパッチの少なくとも一部と、同時にまたは並列に適用することができる。

パッチ実行コンポーネントは、第１のワークロード部分がオフラインであるときに、保守時間ウィンドウ内で、第１のワークロード部分の一部に対してパッチの第３のサブセットを実行することができ、第２のワークロード部分に対してパッチの第２のサブセットを実行することができ、そのようなパッチが実行されている（例えば、適用されている）ときに、第２のワークロード部分はオンラインであることができる。ＰＭＣは、パッチおよび関連するワークロードが適切に機能していることを保証するために、まだ保守時間ウィンドウ内であるときに、適用されるパッチおよび関連するワークロードの妥当性を確認することができる。ＰＭＣが、パッチの妥当性が確認されない（例えば、パッチが適用された後に、そのようなパッチまたは関連するワークロードのアイテムが適切に機能していない）ということを決定した場合、ＰＭＣは、保守時間ウィンドウ内でこのパッチを取り消し、ワークロードのアイテムをパッチが適用される前の状態に戻すことができる。

ここで、開示される対象のこれらおよびその他の態様および実施形態が、図面に関して説明される。

図１は、開示される対象のさまざまな態様および実施形態に従って、コンピューティング・システム上でパッチを効率的に管理して適用することに利用され得る、例示的な非限定的システム１００のブロック図を示している。システム１００は、さまざまなコンポーネントを備えることができるコンピューティング・システム１０２を含むことができる。コンピューティング・システム１０２は、１つまたは複数のネットワーク（例えば、コンピューティング・ネットワークまたは通信ネットワーク）を備えることができる。一部の実施形態では、コンピューティング・システム１０２は、マルチディメンションであることができ、コンピューティング・システム１０２は、複数のディメンションにわたって広がることができ、コンピューティング・システム１０２の複数のディメンションにわたって広がることができるワークロード（例えば、ハイブリッド・ワークロード）を含むことができる。例えば、コンピューティング・システム１０２は、本明細書においてさらに詳細に説明されるように、複数のクラウドまたは複数のオペレーティング・システム・アーキテクチャを備えることができ、マルチディメンションのデプロイメント・モデル（例えば、従来のコンピューティング・インフラストラクチャ、プライベート・クラウドまたはパブリック・クラウド、オンプレミスおよびオフプレミス、専用または共有）を採用することができ、マルチディメンションのデプロイメント・モデルの複数の層または複数の部分にわたって広がることができるさまざまな種類のコンポーネントまたはデバイス（例えば、ベアメタル・マシン、ＶＭ、コンテナ、外部サービスなど）を採用することができ、コンピューティング・システム１０２の複数のディメンションにわたって広がることができるさまざまな種類のワークロード（例えば、バッチ・ワークロード、トランザクション・ワークロード、分析ワークロード、高性能のワークロード、データベース・ワークロードまたはＣＰＵ、ディスク負荷またはプロセッサ負荷の大きいワークロードなど）を伴うことができ、コンピューティング・システム１０２の複数のディメンションにわたって広がることができるＤｅｖＯｐｓプロセスまたはその他の特徴を備えることができる。

コンピューティング・システム１０２は、さまざまなコンテナ１０４、仮想マシン（ＶＭ）１０６、物理マシン（ＰＭ：physical machines）１０８、その他のリソース１１０、およびノード１１２を備えることができ、これらは互いに関連して配置されるか、または互いに関連付けられて、コンピューティング・システム１０２を形成すること、およびさまざまなサービス（例えば、コンピュータ関連のサービスおよびアプリケーション）を提供することができる。例えば、さまざまなコンテナ１０４、ＶＭ１０６、ＰＭ１０８、その他のリソース１１０、またはノード１１２は、本明細書においてさらに詳細に説明されるように、コンピューティング・システム１０２の複数のディメンションにわたって広がることができ、複数の層に配置され得る（例えば、コンテナ１０４は、第１の層に存在することができ、第２の層内の別のコンテナ１０４またはＶＭ１０６に関連付けることができ、第２の層内の他のコンテナ１０４またはＶＭ１０６は、第３の層内の別のＶＭ１０６またはＰＭ１０８に関連付けることができる、などである）。さまざまな実施形態に従って、コンテナ１０４、ＶＭ１０６、ＰＭ１０８、またはその他のリソース１１０は、ノード１１２であることができ、ノード１１２の一部であることができ、またはノード１１２に関連付けられ得る。

さまざまなときに、コンピュータ・プログラムまたは関連するデータにパッチを適用してコンピューティング・システム１０２を改良するのが、望ましいことがある。パッチは、コンピュータ・プログラムまたはコンピュータ・プログラムを支援するデータを更新するように設計されたか、またはコンピュータ・プログラムを修正もしくは改良するように設計された、１つのソフトウェアであることができる。パッチは、セキュリティの脆弱性またはその他のバグを修正すること、あるいはコンピュータ・プログラムのアップグレードに伴ってコンピュータ・プログラムの使い勝手または性能を改善することを、含むことができる。１つまたは複数の層に属することができるノードに対するパッチは、通常、オペレーティング・システム（例えば、第１の種類のオペレーティング・システム、第２の種類のオペレーティング・システム、第３の種類のオペレーティング・システムなど）に限定されず、ノードにインストールされているソフトウェア（例えば、アプリケーション、ミドルウェア、またはデータベース）にも適用され得る。

パッチの適用を容易にするために、システム１００は、定義されたパッチ管理基準および関連するパッチ管理アルゴリズムに従ってさまざまなコンテナ１０４、ＶＭ１０６、ＰＭ１０８、その他のリソース１１０、ノード１１２、アプリケーション、関連するデータなどへのパッチの適用を管理（例えば、制御）できる、パッチ管理コンポーネント（ＰＭＣ：patch management component）１１４（更新管理コンポーネントとも呼ばれる）を備えることができる。ＰＭＣ１１４は、（例えば、保守時間ウィンドウの間に）パッチを識別または決定して実行することができるパッチ識別コンポーネント１１６（更新識別コンポーネントとも呼ばれる）、およびさまざまなコンテナ１０４、ＶＭ１０６、ＰＭ１０８、その他のリソース１１０、ノード１１２、アプリケーション、または関連するデータなどに対してパッチ（例えば、選択されたパッチ）を実施または実行（例えば、適用）することができるパッチ実行コンポーネント１１８（更新実行コンポーネントとも呼ばれる）を、含むことができる。

一部のパッチは、システム１００の一部のコンポーネント（例えば、コンテナ１０４、ＶＭ１０６、ＰＭ１０８、またはその他のリソース１１０、あるいはノード１１２など）に対して、それらのコンポーネントがオンラインであるときに実行することができ、一方、特定のパッチは、システム１００の特定のコンポーネント（例えば、特定のコンテナ１０４、ＶＭ１０６、ＰＭ１０８、その他のリソース１１０、またはノード１１２など）に、それらの特定のコンポーネントがオフラインになるまで、適用することができない。通常は、パッチを適用するためにコンポーネントがオフラインになることができる、比較的短い時間（例えば、保守時間ウィンドウ）が存在することがある。さらに、さまざまなパッチが、さまざまなレベルの脆弱性、優先度、重要性、またはリスクに関連付けられることがある。したがって、保守時間ウィンドウが制限されていることがあるため、保守時間ウィンドウの間に、一部のパッチ（例えば、より高いレベルの脆弱性、優先度、重要性、またはリスクに関連付けられたパッチ）の適用を、他のパッチ（例えば、相対的に低いレベルの脆弱性、優先度、重要性、またはリスクに関連付けられたパッチ）よりも優先するのが、望ましいことがある。

さまざまな実施形態に従って、所定の保守時間ウィンドウの間に、ＰＭＣ１１４は、第１のワークロード部分がオフラインであるときにパッチが適用される第１のワークロード部分、および第２のワークロード部分がオンラインであるときにパッチが適用され得る第２のワークロード部分を含んでいるワークロードを識別することができ、本明細書においてさらに詳細に説明されるように、定義されたパッチ管理基準および関連するパッチ管理アルゴリズムに従って、パッチに関連付けられた脆弱性スコアに少なくとも部分的に基づいて、第１のワークロード部分がオフラインであるときに、保守時間ウィンドウの間に適用され得るパッチのサブセットを決定することができる。どのパッチを（例えば、保守時間ウィンドウの間に）実行するかを決定することにおいて、ＰＭＣ１１４は、コンテナ１０４、ＶＭ１０６、ＰＭ１０８、その他のリソース１１０、ノード１１２、アプリケーションなどへのパッチの適用に関連する特徴を含む、コンテナ１０４、ＶＭ１０６、ＰＭ１０８、その他のリソース１１０、ノード１１２、アプリケーションなどに関するさまざまな特徴を考慮することができる。

例えば、コンテナ・プラットフォーム（例えば、特定の種類のコンテナ・プラットフォーム）に関連付けられたコンテナ（例えば、コンテナ１０４）にパッチを適用することに関して、通常、実行中のコンテナにパッチは適用されない。代わりに、コンテナ（例えば、１０４）に関して、コンテナがまだ実行中である（例えば、オンラインである）ときに、コンテナによって使用されるイメージに（例えば、パッチ実行コンポーネント１１８によって）パッチを適用することができ、新しいパッチ適用済みのコンテナ・イメージを使用して、コンテナが再起動され得る。新しいコンテナ（例えば、新しいコンテナ・イメージ）が起動されるときに、コンテナ上で実行されているアプリケーションが（例えば、ＰＭＣ１１４によって）停止されることがあり、したがって、コンテナ・イメージのパッチ適用に関連して、アプリケーションに、停止時間および起動時間が生じることがある。

ＶＭ（例えば、ＶＭ１０６）にパッチを適用することに関しては、ＶＭにパッチを適用することによって、アプリケーションに停止時間および起動時間が生じることがあり、多くの場合、（例えば、ＰＭＣ１１４による）リブートが必要になる。さらに、アプリケーションが（例えば、ＰＭＣ１１４によって）停止された後に、パッチ実行コンポーネント１１８は、ＶＭ（例えば、ＶＭ１０６）のＶＭインスタンス（イメージではない）にパッチを適用することができ、したがって、ＰＭＣ１１４がアプリケーションを再起動する前に、ＶＭインスタンスに、ＶＭに適用可能なパッチの各々に関するパッチ適用時間が生じることがある。

示されたように、通常は、パッチ実行コンポーネント１１８によってオフラインのパッチ適用を実行できる制限されたウィンドウが存在することがある。例えば、クラスタ化されていないコンテナ１０４またはＶＭ１０６の場合、制限された保守時間ウィンドウ（例えば、保守ダウンタイム・ウィンドウ（maintenance downtime window））が存在することがあり、この保守時間ウィンドウ内で、パッチ適用プロセスによって、アプリケーションの停止時間および起動時間、ならびにコンテナ１０４およびＶＭ１０６のリブート時間および再起動時間が生じることがある。この制限された保守時間ウィンドウ内で、ＶＭ１０６にパッチ適用時間が生じることがある。保守時間ウィンドウの間に使用可能な制限された（例えば、相対的に短い）時間に起因して、通常、パッチ実行コンポーネント１１８は、保守時間ウィンドウの間に、パッチの部分的なサブセットのみを適用することができる。コンテナ１０４のパッチ適用に関しては、この保守時間ウィンドウの外側で（例えば、コンテナ１０４およびその他のリソースがオンラインであるときに）コンテナのイメージにパッチを適用することができるため、コンテナには、通常、このパッチ適用時間が生じない。したがって、コンテナ１０４の場合、パッチ実行コンポーネント１１８は、通常、（例えば、オンラインまたはオフラインであるときに）パッチをコンテナ１０４に適用することができる（例えば、すべてのパッチを適用することができる）。

オンラインのパッチ適用に関しては、例えば、コンテナ・プラットフォームの特定の種類（例えば、ローリング・アップデートをサポートできるコンテナ・プラットフォーム）に関して、（例えば、ＰＭＣ１１４によって管理される）パッチ実行コンポーネント１１８は、ローリング・アップデート（例えば、ローリング・パッチ適用）を実行することができ、望ましい（例えば、正しい）レプリカの数に達する（例えば、達成される）まで新しいコントローラおよび古いコントローラでのレプリカ数を増やすか、または減らすことができる複製コントローラが採用され得る。例えば、ポッドが１つまたは複数のコンテナを含んでいることがある。複製コントローラは、任意の時間に望ましい（例えば、指定された）数のポッドのレプリカ（ポッドのレプリカ数またはコピーとも呼ばれる）が実行中である（例えば、１つまたは複数のノード上で同時に実行中である）ことを保証することができる。複製コントローラは、複数のノードにわたって複数のポッドを管理する（例えば、監視する）ことができる。例えば、複製コントローラが、多すぎるポッドが存在するということを決定した場合、複製コントローラは余分なポッドを終了することができ、複製コントローラが、十分なポッドが存在しないということを決定した場合、複製コントローラは、追加のポッドを起動または作成することができる。サービス停止が発生せずにサービスを更新するために、パッチ実行コンポーネント１１８は、ポッドに対してローリング・アップデートを実行することができ、ローリング・アップデートは、サービス全体（例えば、サービスのすべてのポッド）を同時に受け取るのではなく、一度に１つのポッドを更新することができる。サービスに関連付けられたワークロード部分（およびしたがって、サービス）は、更新中のさまざまなときに、それでも機能し続けることができ、このワークロード部分に対して実行しているノードの一部（例えば、レプリカ数に属するノード）は、パッチ適用のために停止されることがある。一部の実施形態では、ＰＭＣ１１４が、ポッドに対するレプリカ数が１より大きいということを決定した場合、ＰＭＣ１１４は、ポッドにライブで（例えば、オンラインで）パッチを適用できるということを決定できる。このようにして、パッチ実行コンポーネント１１８が、要求されたバッチ・サイズを有する新しいインスタンスでポッドのインスタンスを増加的に更新することによって、ダウンタイムなしでデプロイメントの更新が発生することを可能にする。ＶＭ１０６またはコンテナ１０４上の高可用性アプリケーション（例えば、特定のアプリケーション・サーバ）は、パッチ実行コンポーネント１１８を含んでいるＰＭＣ１１４が自動アプリケーション・ロールアウト更新プロセス（automatic application rollout update process）を実行できるようにすることができ、自動アプリケーション・ロールアウト更新プロセスは、アプリケーションのダウンタイムなしで、更新が実行されるクラスタのメンバーをホストしている各アプリケーション・サーバを停止または一時停止することができる。高可用性障害復旧（ＨＡＤＲ：high availability disaster recovery）環境は、ソフトウェアまたはハードウェアをアップグレードするときに、ローリング・アップデート・プロセス全体を通じてデータベース・サービスを利用可能に保ちながら、処理が１つのデータベースから他のデータベースに切り替えられるときの瞬間的なサービスの中断のみを伴って、パッチ実行コンポーネント１１８を含んでいるＰＭＣ１１４が、データベース関連のソフトウェア（例えば、データベース製品ソフトウェア）を更新すること、またはデータベース構成パラメータを変更（例えば、修正、調整）することを可能にすることができる。

パッチ適用を管理することに関連して、ＰＭＣ１１４は、定義されたパッチ管理基準に従って、所定の期間（例えば、保守時間ウィンドウ）の間にどのパッチを実装するかを決定することを容易にするために、コンピューティング・システム１０２（例えば、ハイブリッド・クラウド・コンピューティング・システム）の他の特徴または要因を考慮することもできる。例えば、ハイブリッド・クラウドに関しては、ハイブリッド・クラウドは、異なるプロバイダまたはベンダーからのクラウドのプラットフォームおよびサービスを使用するために、プラグ・アンド・プレイ手法を実装することができる。これらのクラウドは、本明細書においてさらに詳細に説明されるように、プライベート・クラウドまたはパブリック・クラウドあるいはオフプレミスまたはオンプレミスのクラウドを含むことができ、コンテナ１０４、ＶＭ１０６、ＰＭ１０８などであること、またはこれらを備えることができる。

一部の実施形態では、コンピューティング・システム１０２は、さまざまな依存関係（例えば、層間の依存関係）を含むことがある多層アプリケーションを採用することができる。多層アプリケーションは、プレゼンテーション機能、アプリケーション処理機能、業務処理機能、およびデータ管理機能を物理的に分離可能にすることができる。層は、１つのレイヤが他のレイヤに依存することがあるため、通常、積み重なったレイヤになることができる。各レイヤは、上位のレイヤを伴わずに存在することができ、そのようなレイヤの下位のレイヤを利用して機能することができる。層（例えば、段階的レイヤ）間のデータ転送は、アーキテクチャの一部であることができる。ｎ層システムを通るデータ・フローのエンドツーエンドの追跡可能性は、システムの複雑さが増すときにより重要になる、困難な課題になることがある。各層自体は、クラスタとして実行することができる。

多層アプリケーション、依存関係、ならびにオフラインおよびオンラインのパッチ適用に関しては、オフラインの層とオンラインの層の間に、パッチ適用にとって重要な（例えば、重大な）依存関係が存在することがある。保守時間ウィンドウの間にオフラインのパッチ適用が実行される第１の層が存在し、次にその第１の層が、オンラインのパッチ適用を実行できる別の層に依存する場合、第１の層のためにオフラインで実行されているパッチが保守時間ウィンドウを満たすのが、望ましい（例えば、有用である）ことがある。オンラインのパッチ適用が実行される第１の層が存在し、次にその第１の層が、オフラインのパッチ適用が実行される別の層に依存する場合、オンラインのパッチ適用に関連付けられた第１の層は、基本的に、オフラインのパッチ適用に関連付けられた他の層の期間の間、（例えば、ＰＭＣ１１４によって）オフラインであると見なされ得る。これによって、オンラインでパッチを適用できる依存関係ツリーの分岐を識別することを可能にすることができ、オフラインのパッチ適用のための保守時間ウィンドウの間に、より多くのサービスにパッチを適用することを可能にすることができる。

特定の実施形態では、ＰＭＣ１１４は、定義されたパッチ管理基準に従って、さまざまなリソース（例えば、コンテナ１０４、ＶＭ１０６など）の同時の、または並列なパッチ適用を実行できることが望ましい。同じＰＭ１０８を使用できる複数のコンテナ１０４およびＶＭ１０６の同時のパッチ適用に関しては、マシン（例えば、ＶＭ１０６）が他のアプリケーションによっても使用されている場合、クラウド内でそれらのマシンに多すぎる負荷をかけないようにするのが望ましいことがある。したがって、ＰＭＣ１１４は、マシン（例えば、ＶＭ１０６）に同時に適用されるパッチの量を望ましく制限するように、パッチ適用を制御することができる。サービスが別のアプリケーションからのリソースを使用できないようなやり方で、コンピューティング・システム１０２のクラウドが共有されるということが仮定される場合、パッチ実行コンポーネント１１８を採用しているＰＭＣ１１４は、定義されたパッチ管理基準に従って、望ましいだけの数のサービスへのパッチ適用を開始できる可能性がある。

したがって、開示される対象に関して、ワークロードにパッチを適用する問題が、パッチのサブセットを検出することに帰着することができ、このサブセットの一部は、他のパッチが（例えば、アプリケーションを停止することによって）オフラインで適用される間に、オンラインで適用することができ、パッチを適用するための合計時間は、許容される保守時間ウィンドウを超えない。パッチを適用することに関しては、開示されるように、パッチを適用するための時間は、パッチを実行するための実際の実行時間に加えて、アプリケーションの停止時間および起動時間、ならびにＶＭまたはコンテナのリブート時間および再起動時間を含むことがある。ＰＭＣ１１４の目標は、優先順位を決めることであることができ、ＰＭＣ１１４は、優先度が低いか、またはあまり緊急でないアプリケーションのパッチよりも、リスクの高い脆弱性へのパッチ適用、およびより緊急性の高いアプリケーションのパッチを優先することができる。

ＰＭＣ１１４は、ハイブリッド・クラウド環境内のノードのグループにわたってデプロイされた複数のリソースを含んでいる多層ワークロードへのパッチ適用を管理することができ、ワークロードは、ノード（コンテナ１０４、ＶＭ１０６、ＰＭ１０８など）の混合にわたってデプロイされたリソースを含むことができる。ＰＭＣ１１４は、他の望ましいリソースにオフラインでパッチを適用しながら、かつ保守時間ウィンドウ内で、サービスおよびアプリケーション、ならびにコンピューティング・システム１０２の関連するコンポーネントがオフラインである間に、パッチ適用が望ましいサービスおよびアプリケーションにパッチを適用できることを保証しながら、（例えば、オンラインのパッチ適用を実行できるということが決定された場合に）リソースの一部にオンラインでパッチが適用されることを可能にすることもできる。例えば、ＰＭＣ１１４は、適用可能な保守時間ウィンドウ内で脆弱性のリスクのより高いパッチ（例えば、高い脆弱性または重要性のスコアまたはレベルを有するパッチ）を優先しながら、オフラインであるときに保守時間ウィンドウの間に特定のパッチが適用される第１のワークロード部分、およびオンラインであるときに他のパッチを適用できる第２のワークロード部分を含んでいるワークロードを、同時に、または実質的に同時に処理する（例えば、管理する）ことができる。

一部の実施形態では、ＰＭＣ１１４は、コンテナ１０４、ＶＭ１０６、ＰＭ１０８、その他のリソース１１０、またはノード１１２などの間のワークロードの依存関係を決定することを容易にするために、要求（例えば、リソース間の要求）に関してネットワーク（例えば、コンピューティング・システム１０２のネットワーク）を監視することができ、ワークロードの依存関係は、第１の種類のアイテム（例えば、コンテナ１０４）と別の種類のアイテム（例えば、ＰＭ１０８）の間に存在するか、または同じ種類のアイテム（例えば、第１のＶＭ１０６および第２のＶＭ１０６）間に存在することがある。リソース間の要求は、リソース間の関連性、または１つのリソースが他のリソースに依存しているかどうか、要求の種類、またはリソースの層もしくは相対的層を（例えば、ＰＭＣ１１４に）示すことがある（例えば、１つのリソースが１つの層（またはレイヤ）内に存在し、他のリソースが、この１つの層の下の別の層（またはレイヤ）内に存在する）。

ＰＭＣ１１４は、本明細書において説明されているように、要求に関してネットワークを監視することに少なくとも部分的に基づいて、またはそのようなワークロードの依存関係を決定する他の手段によって、コンテナ１０４、ＶＭ１０６、ＰＭ１０８、その他のリソース１１０、またはノード１１２などの間のワークロードの依存関係を決定することができる。一部の実施形態では、ＰＭＣ１１４は、要求を分析することに少なくとも部分的に基づいて、リソース間の依存関係を含んでいるネットワークのトポロジーを決定または識別することができる。また、要求を分析することに少なくとも部分的に基づいて、またはそのようなワークロードの依存関係を決定する他の手段によって、ＰＭＣ１１４は、リソース／ノード間の依存関係ツリーを決定または生成することができ、コンピューティング・システム１０２またはその一部の依存関係ツリーは、ＰＭＣ１１４が複数のサービスに同時にパッチを適用することを可能にする形状を有することができる。ＰＭＣ１１４は、依存関係ツリーを活用して、所定の保守時間ウィンドウ内でより多くのパッチを含めること、および実行することを可能にすることができる。

ＰＭＣ１１４は、リソース間のワークロードの依存関係に少なくとも部分的に基づいて、ワークロードを決定することができる。ワークロードは、保守時間ウィンドウ内で（例えば、ワークロードのアイテムのワークロードの依存関係に少なくとも部分的に起因して）オフラインであるときにパッチの第１のサブセットによってパッチが適用されるワークロードのアイテム（例えば、コンテナ１０４、ＶＭ１０６、ＰＭ１０８、リソース１１０、またはノード１１２など）であることができる第１のワークロード部分、およびオンラインであるときにパッチの第２のサブセットによってパッチが適用され得る第２のワークロード部分を含むことができる。パッチ識別コンポーネント１１６は、ワークロードに適用されるパッチ、あるいはパッチまたはパッチに関連する情報の相対的な重要度（例えば、脆弱性スコア）を識別または決定することができる。

所定の保守時間ウィンドウの間にどのパッチを実行するかを決定することを容易にするために、ＰＭＣ１１４は、少なくとも、保守時間ウィンドウの間にオフラインであるときにワークロードの第１のワークロード部分に対して実行されるのが望ましいパッチの第１のサブセットに対して、脆弱性スコアを決定することができる。一部の実施形態では、ＰＭＣ１１４は、オンラインであるときにワークロードの第２のワークロード部分に対して実行され得るパッチの第２のサブセットに対して、脆弱性スコアを決定することもできる。

保守時間ウィンドウの間に使用可能な制限された時間を前提として、保守時間ウィンドウの間に、第１のワークロード部分に対してパッチの第１のサブセット内のすべてのパッチを実行できないことが多い。ＰＭＣ１１４は、パッチの第１のサブセットまたはパッチの第２のサブセットのパッチの各々の重要性、優先度、脆弱性、またはリスク・レベルに少なくとも部分的に基づいて、パッチの第１のサブセットまたはパッチの第２のサブセットのパッチの脆弱性スコアを決定することができる。通常、パッチの第１のサブセット内の他のパッチよりも、実行することがより重要である一部のパッチが存在することがある。ＰＭＣ１１４は、保守時間ウィンドウの間に、実行することができるパッチの第１のサブセットのより重要なパッチを実行するように、パッチに優先順位を付けることによって、対処されるリスク（例えば、コンピューティング・システム１０２またはその一部（コンテナ１０４、ＶＭ１０６、ＰＭ１０８、その他のリソース１１０、ノード１１２、アプリケーション、またはデータなど）に対するリスク）を最大化することができ、保守時間ウィンドウの間に実行される（例えば、実行されるパッチの第３のサブセットに含まれる）より重要なパッチを選択することができる。

脆弱性スコアは、パッチの重要性における変動を示すことができる。例えば、ＰＭＣ１１４は、パッチの各々に関する各問題の重大さの程度について知らせることができる脆弱性評価尺度（vulnerability scoring scale）（例えば、点尺度）を採用することができ、ＰＭＣ１１４は、この尺度を使用して、パッチごとに問題の重大度を判定または決定し、最も重要なパッチを決定することができる。脆弱性評価尺度は、正確な欠陥および欠陥の種類（または現在の脅威レベル、ただし、現在の脅威レベルはそのような分析から省略されることがある）の技術的分析に基づいて、可能性のあるリスクを考慮することができる。共通脆弱性評価システム（ＣＶＳＳ：Common vulnerability scoring system）ベースのスコアは、脆弱性に関する追加の指針を提供することができ、脆弱性の一定の態様（例えば、アクセス・ベクトル、アクセスの複雑さ、認証、機密性、完全性、および可用性）を採点することによって、詳細な重大度の評価を行う。一部の実施形態では、ＰＭＣ１１４は、１～３の脆弱性評価尺度を採用することができ、１が最も重要なパッチ適用を表し、３が重要性が最も低いパッチ適用を表す。例えば、１の値またはスコアは、パッチに関連付けられた脆弱性のレベルが高く、そのようなパッチの優先度が高いことを示すことができ、２の値またはスコアは、パッチに関連付けられた脆弱性のレベルが中程度であり、そのようなパッチの優先度が相対的に中程度であることを示すことができ、３の値またはスコアは、パッチに関連付けられた脆弱性のレベルが低く、そのようなパッチの優先度が相対的に低いことを示すことができる。さまざまなその他の実施形態では、ＰＭＣ１１４が、例えば、５（または１０または１００）が最も重要なパッチ適用を表し、１が重要性が最も低いパッチ適用を表すか、またはその逆を表す、１～５（または１０または１００）の尺度などの、その他の脆弱性、重要性、またはリスクの評価尺度を採用することができるということが、認識され、理解されるべきである。

特定の実施形態では、ＰＭＣ１１４は、本明細書においてさらに詳細に説明されるように、望ましいパッチ管理アルゴリズムを使用して、（パッチのグループごとの）個別のパッチの個別の脆弱性スコアに少なくとも部分的に基づいて、パッチのグループに対して、グループ脆弱性スコアを決定するか、または割り当てることができる。例えば、適用され得る１つのパッチ管理アルゴリズムに従って、ＰＭＣ１１４は、本明細書においてさらに詳細に説明されるように、等比級数の合計に基づく式を個別の脆弱性スコアに適用することによって、（パッチのグループごとの）個別のパッチの個別の脆弱性スコアに少なくとも部分的に基づいて、第１のワークロード部分または第２のワークロード部分に関連付けられたパッチのグループ（例えば、パッチの異なるグループ化）のグループ脆弱性スコアを決定する（例えば、計算する）ことができる。ＰＭＣ１１４は、より高い脆弱性スコアを有しているパッチにより高い優先度を与えるために、そのような式を使用して、低い脆弱性スコアを有している多数のパッチが、高い脆弱性スコアを有している相対的に少数のパッチよりも高いグループ脆弱性スコアを有することにならないようにすることを、容易にすることができる。

パッチの脆弱性スコアを評価した後に、ＰＭＣ１１４は、パッチの第１のサブセットまたはパッチの第２のサブセットのパッチの脆弱性スコア、および保守時間ウィンドウに少なくとも部分的に基づいて、第１のワークロード部分の一部（例えば、コンテナ１０４、ＶＭ１０６、ＰＭ１０８、リソース１１０、またはノード１１２などのサブセット）に適用され得るパッチの第３のサブセットを、第１のワークロード部分に関連付けられたパッチの第１のサブセットから決定することができる。例えば、ＰＭＣ１１４は、望ましいパッチ管理アルゴリズムに従って（例えば、式またはその他の望ましいパッチ管理アルゴリズムを使用して）、第１のワークロード部分または第２のワークロード部分に関連付けられたパッチの他のグループのグループ脆弱性スコアと比較して最も高いグループ脆弱性スコアを有している第１のワークロード部分または第２のワークロード部分に関連付けられたパッチのグループを、決定することができる。ＰＭＣ１１４は、パッチ適用に関して最も高いグループ脆弱性スコアを有しているパッチのグループを選択することができ、このパッチのグループは、保守時間ウィンドウの間にオフラインであるときに第１のワークロード部分の一部に適用され得るパッチの第３のサブセット、またはオンラインであるときに第２のワークロード部分に適用され得るパッチの第２のサブセットを含むことができる。

パッチ実行コンポーネント１１８は、保守時間ウィンドウの間に、第１のワークロード部分の一部に対して、パッチの第３のサブセットを実行する（例えば、適用する）ことができる。一部の実施形態では、パッチ実行コンポーネント１１８は、ＰＭＣ１１４によって決定されたネットワークのトポロジーに従って、トポロジー的順序で、パッチの第３のサブセットのパッチを実行することができる。特定の実施形態では、パッチ実行コンポーネント１１８は、使用可能な保守時間ウィンドウ内で、第１のワークロード部分の一部の、依存関係を有するワークロードのアイテムを含む複数のワークロードのアイテム（例えば、コンテナ１０４、ＶＭ１０６、ＰＭ１０８、その他のリソース１１０、ノード１１２、アプリケーション、またはデータなど）に対して、パッチの第３のサブセットのパッチを同時に（例えば、並列に）実行することができる。

パッチ実行コンポーネント１１８を含んでいるＰＭＣ１１４は、パッチの第３のサブセットの実行を容易にするためのパッチ適用プロセスを実行することができ、このパッチ適用プロセスは、本明細書においてさらに詳細に説明されるように、第１のワークロード部分の一部に関連付けられたリソースを停止することおよび再起動すること、ならびにパッチの第３のサブセットに関連付けられたノードをリブートすることを含むことができる。パッチが適用されるコンテナ１０４に関しては、変更不可能なコンテナ・インスタンスに通常はパッチが適用されないため、パッチ実行コンポーネント１１８は、コンテナ１０４のコンテナ・イメージにパッチを適用することができる。ＶＭ１０６およびＰＭ１０８に関しては、パッチ実行コンポーネント１１８は、必ずしもＶＭ１０６またはＰＭ１０８のＶＭまたはＰＭのイメージではなく、通常、ＶＭ１０６またはＰＭ１０８のＶＭまたはＰＭのインスタンスにパッチを適用することができる。

パッチ実行コンポーネント１１８は、第２のワークロード部分に対してパッチの第２のサブセットを実行することもでき、パッチの第２のサブセットは、第２のワークロード部分（または、コンピューティング・システム１０２の他の部分）がオンラインであるときに実行することができ、あるいは保守時間ウィンドウの外側で、または保守時間ウィンドウの間に実行することができる。特定の実施形態では、パッチ実行コンポーネント１１８は、パッチの第２のサブセットのパッチのすべて、または少なくとも一部を、第２のワークロード部分に対して同時（例えば、並列に）に実行することができ、保守時間ウィンドウの間に、パッチの第３のサブセットのパッチの一部が第１のワークロード部分の一部に対して実行される。

一部の実施形態では、パッチ実行コンポーネント１１８を含んでいるＰＭＣ１１４は、次のようにパッチ（例えば、パッチの第２および第３のサブセット）を適用することができる。パッチ実行コンポーネント１１８は、ライブのパッチ適用を（例えば、バックグラウンドで）開始し、第２のワークロード部分（例えば、コンテナ１０４（例えば、ポッド）、ＶＭ１０６、ＰＭ１０８、その他のリソース１１０、ノードなど）に関して、例えば、パッチがライブで（例えば、オンラインで）適用され得る関連するサービスのために、パッチを適用することができる。ポッドのサブセット、および第１のワークロード部分の一部のＶＭ１０６ごとのパッチのサブセットに関する、オフラインで実行されている第１のワークロード部分の一部に関連付けられたパッチ適用に関しては、パッチ実行コンポーネント１１８は、依存関係を有していないポッド（例えば、コンテナ１０４）およびＶＭ１０６に対するパッチ適用を開始することができ、そのようなポッドおよびＶＭに並列にパッチを適用する（例えば、更新する）ことができる。ポッドまたはＶＭにパッチが適用されるたびに、ＰＭＣ１１４は、パッチが適用され得るポッドおよびＶＭのリストを更新することができ、ポッドおよびＶＭのリスト上のポッドおよびＶＭに対してパッチ適用を開始することができる。パッチ実行コンポーネント１１８を含んでいるＰＭＣ１１４は、望ましい（例えば、選択された）サービスのすべてにパッチが適用されるまで、この開示されたプロセスを継続することができる。

パッチの実行後に、ＰＭＣ１１４は、パッチが適切に適用されたことを保証し、そのようなパッチが適用された後に、パッチ、ならびに第１のワークロード部分または第２のワークロード部分の一部の各アイテム、およびコンピューティング・システム全体が適切に機能していることを保証するのを容易にするために、保守時間ウィンドウ内で第１のワークロード部分または第２のワークロード部分の一部のパッチ適用の妥当性を確認することができる。例えば、１つまたは複数のパッチが適用された後に、ＰＣＭ１１４は、パッチのうちの１つまたは複数に関連付けられたか、またはパッチのうちの１つまたは複数による影響を受けたアプリケーション、ノード、またはリソースなどを分析するか、または調べて、アプリケーション、ノード、またはリソースなどが、アプリケーション、ノード、またはリソースなどが定義された正常な動作状態または使用可能な動作状態にある（例えば、アプリケーション、ノード、またはリソースなどが、正しく、適切に、容認できる状態で、または最適に動作しているか、あるいは少なくとも、定義された最小限の動作基準を満たすか、または超えるように十分良好に動作している）ことを示す定義されたパッチ管理基準を満たしているかどうかを決定することができる。１つまたは複数のパッチが適用された後に、ＰＭＣ１１４が、アプリケーション、ノード、またはリソースなどがそのような定義されたパッチ管理基準を満たしているということを決定した場合、ＰＭＣ１１４は、１つまたは複数のパッチの妥当性が確認されたということを決定できる。ＰＭＣ１１４が、特定のパッチの妥当性が確認されたということを決定した場合、ＰＭＣ１１４は、この特定のパッチを維持することができる。しかし、特定のパッチおよび関連するワークロードのアイテムの妥当性を確認できないということの決定に応答して、ＰＭＣ１１４は、保守時間ウィンドウ内で、ワークロードのアイテムに関連付けられた特定のパッチを取り消し、ワークロードのアイテムを特定のパッチが適用される前の状態に戻すことができる。

保守時間ウィンドウの間にＰＭＣ１１４によって実行対象として選択されなかったパッチの第１のサブセットの他のパッチ（例えば、適用されていないパッチ）に関しては、ＰＭＣ１１４は、定義されたパッチ管理基準に従って、そのような他のパッチを第１のワークロード部分の他の一部に対して実行することを、次の、または将来の保守時間ウィンドウに延期することができる。ＰＭＣ１１４は、パッチ実行コンポーネント１１８がパッチの第１のサブセットの他のパッチ（または、もしあれば、その後使用可能になることができるか、もしくは検出され得る他のパッチ）を適用できる次の保守時間ウィンドウを、決定または計算することができる。

ここで図２を（図１と共に）参照すると、図２は、開示される対象のさまざまな態様および実施形態に従って、複数のディメンションにわたることができるワークロードを含んでいる例示的な非限定的コンピューティング・システム２００の図を示している。コンピューティング・システム２００（例えば、ハイブリッド・クラウドベースのコンピューティング・プラットフォーム）は、従来のＩＴプラットフォーム２０２、プライベート・クラウド・コンピューティング・プラットフォーム２０４、およびパブリック・クラウド・コンピューティング・プラットフォーム２０６を備えることができ、それによって、コンピューティング・プラットフォームに関して、複数のディメンションに広がることができる。従来のＩＴプラットフォーム２０２は、例えば、アプリケーション２０８および２１０を含むアプリケーション（ａｐｐ：applications）、アプリケーション・サーバ２１２および２１４を含むアプリケーション・サーバ（ａｐｐ ｓｅｒ：application servers）、ならびにデータベース２１６および２１８を含むデータベース（ＤＢ：databases）を備えることができる。プライベート・クラウド・コンピューティング・プラットフォーム２０４は、例えば、アプリケーション２２０および２２２を含むアプリケーション、アプリケーション・サーバ２２４および２２６を含むアプリケーション・サーバ、ならびにデータベース２２８および２３０を含むデータベースを備えることができる。パブリック・クラウド・コンピューティング・プラットフォーム２０６は、例えば、アプリケーション２３２および２３４を含むアプリケーション、アプリケーション・サーバ２３６および２３８を含むアプリケーション・サーバ、ならびにデータベース２４０および２４２を含むデータベースを備えることができる。

一部の実施形態では、コンピューティング・クラウド（例えば、２０４、２０６）は、異なるベンダー（例えば、第１のベンダー、第２のベンダー、または第３のベンダーなど）に関連付けることができ、したがって、ベンダーおよびベンダーの種類（例えば、ベンダーによって提供されるサービスの種類）に関して、複数のディメンションにわたって広がることができる。コンピューティング・システム２００は、例えば、さまざまなコンピューティング・サービスを提供することができるベアメタル・ハイパーバイザ技術、カーネルベースのＶＭ（ＫＶＭ：kernel-based VM）（例えば、カーネルベースのハイパーバイザ技術）、マイクロカーネルベースのハイパーバイザ技術、コンテナ、またはユニカーネルなどの複数のハイパーバイザ技術を採用することもでき、したがってハイパーバイザ技術の種類に関して複数のディメンションにわたって広がることができる。

ワークロードは、例えばコンピューティング・プラットフォーム（例えば、従来のＩＴプラットフォーム２０２、プライベート・クラウド・コンピューティング・プラットフォーム２０４、またはパブリック・クラウド・コンピューティング・プラットフォーム２０６）、コンピューティングまたはクラウド・サービス・ベンダー、ハイパーバイザ技術、リソースの種類（例えば、ＶＭ、コンテナ、ＰＭ、ノード、またはその他のリソース）に関して、複数のディメンションにわたって広がることができ、各ワークロードは、ワークロードのリソース間のそれ自身の依存関係（例えば、ワークロードの複数の層のノード間の依存関係）を有している（または依存関係を有していない）ことがある。例えば、例示的なコンピューティング・システムは、第１のワークロード２４４、第２のワークロード２４６、および第３のワークロード２４８を含むことができる。第１のワークロード２４４は、従来のＩＴプラットフォーム２０２およびプライベート・クラウド・コンピューティング・プラットフォーム２０４にわたって広がることができるＶＭ（例えば、ＶＭのみ）を含むことができ、第１のワークロード２４４のＶＭは、従来のＩＴプラットフォーム２０２のデータベース２１６、ならびにプライベート・クラウド・コンピューティング・プラットフォーム２０４のアプリケーション２２０およびアプリケーション・サーバ２２４によって実装されるか、またはデータベース２１６、アプリケーション２２０、およびアプリケーション・サーバ２２４に関連付けられることができ、データベース２１６、アプリケーション２２０、およびアプリケーション・サーバ２２４は、ＶＭとして、またはＶＭの形態で実装され得る。

第２のワークロード２４６は、ＶＭ、ＰＭ、およびコンテナを含むことができ、プライベート・クラウド・コンピューティング・プラットフォーム２０４およびパブリック・クラウド・コンピューティング・プラットフォーム２０６にわたって広がることができる。例えば、第２のワークロード２４６のＶＭは、パブリック・クラウド・コンピューティング・プラットフォーム２０６の（例えば、ＶＭとして実装された）アプリケーション・サーバ２３６、プライベート・クラウド・コンピューティング・プラットフォーム２０４の（例えば、ＰＭとして実装された）データベース２２８、およびパブリック・クラウド・コンピューティング・プラットフォーム２０６の（例えば、コンテナ（Ｃｏｎ：container）として実装された）アプリケーション２３４によって実装されるか、またはアプリケーション・サーバ２３６、データベース２２８、およびアプリケーション２３４に関連付けられることができる。

第３のワークロード２４８は、コンテナ（例えば、コンテナのみ）を含むことができ、プライベート・クラウド・コンピューティング・プラットフォーム２０４およびパブリック・クラウド・コンピューティング・プラットフォーム２０６にわたって広がることができる。例えば、第３のワークロード２４８のコンテナは、プライベート・クラウド・コンピューティング・プラットフォーム２０４のデータベース２３０、ならびにパブリック・クラウド・コンピューティング・プラットフォーム２０６のアプリケーション２３４およびアプリケーション・サーバ２３８によって実装されるか、またはデータベース２３０、アプリケーション２３４、およびアプリケーション・サーバ２３８に関連付けられることができ、データベース２３０、アプリケーション２３４、およびアプリケーション・サーバ２３８は、コンテナとして、またはコンテナの形態で実装され得る。これらのワークロード（例えば、２４４、２４６、２４８）は、単に例示的なワークロードであり、さまざまな実施形態に従って、開示される対象は、これらの例示的なワークロードおよび本明細書に記載された他のワークロードに加えて、または代替として、さまざまな異なる種類のワークロードを含むか、さまざまな異なる種類のワークロードに関連するか、またはさまざまな異なる種類のワークロードを伴うことができるということが、認識され理解されるべきである。

第１のワークロード２４４、第２のワークロード２４６、および第３のワークロード２４８は、（例えば、ＰＭＣ１１４およびパッチ実行コンポーネント１１８による）オフラインのパッチ適用に関して、リソース間の依存関係の例を提供することができ、リソースは、図２に示されているように（および、別の方法で図面に示されているか、または本明細書に記載されているように）、１つまたは複数のノードにわたって分散され得る。ＰＭＣ１１４は、本明細書においてさらに詳細に説明されるように、ワークロード（例えば、２４４、２４６、２４８など）に関連付けられたワークロードのリソース間の依存関係（例えば、ワークロードの複数の層のノード間の依存関係）を決定または識別し、定義されたパッチ管理基準（および、例えば関連するパッチ管理アルゴリズム）に従って、特定のワークロードを中断することも妨げることもなく、どのリソースを停止して起動することができるかを決定することを含む、特定の保守時間ウィンドウの間にどのパッチが特定のワークロードに対して実行されるか（例えば、特定の保守時間ウィンドウに関して、どのパッチが他のパッチよりも優先されて実行されるか）を決定することを、容易にすることができる。

図３を（図１と共に）参照すると、図３は、開示される対象のさまざまな態様および実施形態に従って、パッチに関連付けられたワークロードがオフラインであるときに、保守時間ウィンドウの間にパッチを適用するための例示的なパッチ・シーケンス３００のブロック図を示している。例示的なパッチ適用シーケンス３００は、例示的なワークロードに関連することができる。ただし、例示的なパッチ適用シーケンス３００が、例示的なワークロードに関連することができる１つの例示的なパッチ適用シーケンスであり、本明細書において説明されているように、さまざまな実施形態によれば、定義されたパッチ管理基準および関連するパッチ管理アルゴリズムに従って、他のワークロードに関して他のパッチ適用シーケンスが（例えば、ＰＭＣによって）実行され得るということが、認識され理解されるべきである。

保守時間ウィンドウの間にパッチ適用シーケンス３００に関連付けられた例示的なワークロードに対してパッチを実行するときに、例示的なパッチ適用シーケンス３００は、パッチ適用シーケンス３００の参照番号３０２によって示されているように、保守時間ウィンドウの間に、パッチが実行されるワークロードに関連付けられたＷｅｂサーバを停止する（例えば、Ｗｅｂサーバの動作を停止または一時停止する）ことを含むことができる。例えば、ＰＭＣ１１４は、保守時間ウィンドウの間、Ｗｅｂサーバを停止することができる。パッチ適用シーケンス３００の参照番号３０４で、ＰＭＣ１１４は、ワークロードに関連付けられたアプリケーション・サーバを停止する（例えば、アプリケーション・サーバの動作を停止または一時停止する）ことができる。参照番号３０６で、ＰＭＣ１１４は、ワークロードに関連付けられたデータベースのデータベース・バックアップの妥当性を確認することができる（例えば、データベースに格納されているデータを保護するために、データベースがバックアップされたことの妥当性を確認すること、または検証することができる）。例えば、データベースに格納されているデータのバックアップを容易にするために、データベースに格納されているデータを、１つまたは複数のデータ・ストアに格納することができる。参照番号３０８で、ＰＭＣ１１４がデータベースを停止することができる。

パッチ適用シーケンス３００の参照番号３１０で、パッチ実行コンポーネント１１８がパッチをワークロードに適用することができ、これらのパッチは、ワークロードに関連付けられたオペレーティング・システム、ミドルウェア、またはアプリケーションに対するものであることができる。参照番号３１２で、ＰＭＣ１１４が、ワークロードに関連付けられたノード（例えば、パッチが適用されるノード）を再起動する（例えば、ノードの動作をリブートまたは再開する）ことができる。参照番号３１４で、ＰＭＣ１１４がデータベースを起動することができる。参照番号３１６で、ＰＭＣ１１４がアプリケーション・サーバを起動する（例えば、アプリケーション・サーバの動作を再開する）ことができる。参照番号３１８で、ＰＭＣ１１４がＷｅｂサーバを起動することができる。

パッチ適用シーケンス３００の参照番号３２０で、ＰＭＣ１１４は、ワークロードの妥当性を確認することができる。例えば、保守時間ウィンドウの間に、ワークロードに関連付けられたリソースがオフラインであるときに、ＰＭＣ１１４は、ワークロードおよびワークロードに対して実行された関連するパッチの妥当性を確認し、パッチが実行された後に、ワークロードに関連付けられたリソースおよび関連するパッチが適切に機能している（例えば、Ｗｅｂサーバが適切に機能している、アプリケーション・サーバが適切に機能している、データがデータベースに復元されていることを含めて、データベースが適切に機能している、およびノードが適切に機能している）ことの妥当性を確認すること、または検証することができる。妥当性確認プロセスの間に、ＰＭＣ１１４が、パッチが実行された後に、特定のパッチまたは関連するワークロードのアイテムもしくはリソース（例えば、ノード、Ｗｅｂサーバ、アプリケーション・サーバ、データベースなど）が適切に、または容認できる状態で機能していないことを決定した場合、ＰＭＣ１１４は、本明細書においてさらに詳細に説明されるように、保守時間ウィンドウの間にパッチを取り消し（例えば、元に戻し）、ワークロードのアイテムもしくはリソースをパッチが実行される前の状態に戻すことができる。妥当性を確認できないパッチは、将来のある時点で、例えば、定義されたパッチ管理基準および関連するパッチ管理アルゴリズムに従って、望ましい（例えば、許容できる、適切な、改善された、または最適な）方式で機能するようにパッチが修正された後に、再実行することができる。

図４を（図１と共に）参照すると、図４は、開示される対象のさまざまな態様および実施形態に従って、ワークロードのリソース間の依存関係の決定およびパッチ管理に関連して例示的なアプリケーション・トポロジー４００の図を示している。クラウド・コンピューティング・システム４０２は、望ましいように互いに関連して配置されるか、または互いに関連付けられてクラウド・コンピューティング・システム４０２を形成し、さまざまな望ましいサービスおよびアプリケーションを提供することができる、さまざまなリソースおよびノードを備えることができる。

クラウド・コンピューティング・システム４０２では、例示的なアプリケーション・トポロジー４００が、トレーダー・アプリケーションに関連付けられ得るトレーダー・コンテナ４０４、ソーシャル・ネットワーキング・アプリケーションに関連付けられ得るソーシャル・ネットワーキング・サービス（ｓｏｃ ｎｗ ｓｖｃ：social networking service）コンテナのレプリカ４０６、消費者ロイヤルティ・サービス・アプリケーションに関連付けられ得る消費者ロイヤルティ・サービス（ｌｏｙａｌｔｙ ｓｖｃ：loyalty service）コンテナのレプリカ４０８、および通信サービス・アプリケーションに関連付けられ得る通信サービス（ｃｏｍｍ ｓｖｃ：communication service）コンテナ４１０を備えることができる。

トレーダー・コンテナ４０４は、例えば、ユーザ・インターフェイス（ＵＩ：user interface）であることができるか、またはユーザ・インターフェイスを備えることができ、アプリケーション・トポロジー４００の第１の層（例えば、最上層または最高の層）に位置することができる。トレーダー・コンテナ４０４は、アプリケーション・トポロジー４００の第２の層に位置することができるポートフォリオ・コンテナ４１２に関連付ける（例えば、通信によって、または動作可能なように、ポートフォリオ・コンテナ４１２に接続される）ことができ、ポートフォリオ・コンテナ４１２は、サーバであることができ、またはサーバを備えることができる。ポートフォリオ・コンテナ４１２は、アプリケーション・トポロジー４００内のポートフォリオ・コンテナ４１２およびトレーダー・コンテナ４０４の下の、アプリケーション・トポロジー４００の第３の層に位置することができるデータベースＶＭ４１４に関連付けることができ、データベースＶＭ４１４は、データベースまたはデータベース・アプリケーションもしくはデータベース・サービスであることができ、あるいはデータベースまたはデータベース・アプリケーションもしくはデータベース・サービスを備えることができる。ポートフォリオ・コンテナ４１２は、アプリケーション・トポロジー４００内のポートフォリオ・コンテナ４１２およびトレーダー・コンテナ４０４の下の、アプリケーション・トポロジー４００の第３の層に位置することができる株式コンテナ４１６に関連付けることもでき、株式コンテナ４１６は、サービス（例えば、株式取引などの、株式に関連するサービス）であることができ、またはサービスを備えることができる。

ＰＭＣ１１４は、ネットワーク、リソース、またはノード、あるいはリソース間の要求を分析することができ、この分析に少なくとも部分的に基づいて、コンテナ１０４、ＶＭ１０６、ＰＭ１０８、その他のリソース１１０、またはノード１１２などの間の依存関係を識別または決定することができる。例えば、ＰＭＣ１１４は、要求に関してネットワークを監視することができ、そのような要求を分析することができ、この分析の結果に少なくとも部分的に基づいて、コンテナ１０４、ＶＭ１０６、ＰＭ１０８、その他のリソース１１０、またはノード１１２などの間の依存関係を決定または推定することができる。例えば、例示的なアプリケーション・トポロジー４００に関して、ＰＭＣ１１４は、互いに関連して、トレーダー・コンテナ４０４が第１の層内にあり、ポートフォリオ・コンテナ４１２が第２の層内にあり、データベースＶＭ４１４および株式コンテナ４１６が第３の層内にあるということの決定を含めて、トレーダー・コンテナ４０４、ポートフォリオ・コンテナ４１２、データベースＶＭ４１４、および株式コンテナ４１６の間の依存関係を決定することができる。

図５を（図１と共に）参照すると、図５は、開示される対象のさまざまな態様および実施形態に従って、ワークロードのリソース間の依存関係およびパッチ管理に関連して、コンピューティング・システムに関連付けられた例示的なワークロードに関して例示的なパッチ選択５００の図を示している。例示的なパッチ選択５００に関して、ＰＭＣ１１４は、本明細書においてさらに詳細に説明されるように、定義されたパッチ管理基準および関連するパッチ管理アルゴリズムに従って、ワークロードのリソース間の依存関係（例えば、ワークロードの複数の層のノード間の依存関係）、ワークロードのアイテムおよび実行される関連するパッチの相対的な重要性、優先度、または脆弱性、あるいはその他の要因を考慮して、ワークロードの第１のワークロード部分に関連付けられたリソース、ノードなどがオフラインであるときに、保守時間ウィンドウ内で（例えば、パッチ実行コンポーネント１１８によって）適用されるワークロードの第１のワークロード部分に関連付けられ得るパッチのサブセットを含んでいる、実行対象として選択されるパッチを決定することができる。ＰＭＣ１１４は、第２のワークロード部分に関連付けられたリソース、ノードなどがオンライン（例えば、ライブ）であるときに（例えば、パッチ実行コンポーネント１１８によって）適用され得るワークロードの第２のワークロード部分に関連付けられたパッチの別のサブセットを決定することもでき、第２のワークロード部分に関連付けられた、パッチの他のサブセットまたはパッチの他のサブセットの少なくとも一部が、保守時間ウィンドウ内で（例えば、第１のワークロード部分に関連付けられたパッチを実行することと同時に、または並列に）適用され得る。

ＰＭＣ１１４は、本明細書においてさらに詳細に説明されるように、定義されたパッチ管理基準および関連するパッチ管理アルゴリズムに従って、所定の保守時間ウィンドウ内でより脆弱性の高いパッチ（例えば、より緊急性の高いアプリケーションのパッチ）を適用することを優先することができる。例えば、ＰＭＣ１１４は、所定の保守時間ウィンドウ内で脆弱性のより高いパッチ（例えば、高い脆弱性または重要性のスコアまたはレベルを有するパッチ）を優先するために、オフラインであるときに保守時間ウィンドウの間に特定のパッチが適用される第１のワークロード部分の少なくとも一部、およびオンラインであるときに他のパッチを適用できる第２のワークロード部分を含んでいるワークロードのパッチ適用を、（例えば、同時に、または実質的に同時に）処理する（例えば、管理する）ことができる。

例示的なパッチ選択５００に関して、ワークロード（例えば、アプリケーションまたは関連するリソース、ノードなど）の第１のワークロード部分がオフラインであり、第２のワークロード部分がオンラインであるときに、保守時間ウィンドウ（例えば、適用可能なダウンタイム・ウィンドウ）内でパッチを実行することが望ましいさまざまなアプリケーションに関連付けられたワークロードが存在することができる。これらのアプリケーションは、例えば、通信サービス（ｃｏｍｍ ｓｖｃ）アプリケーション５０２、消費者ロイヤルティ・サービス（ｌｏｙａｌｔｙ ｓｖｃ）アプリケーション５０４、トレーダー・アプリケーション５０６、ポートフォリオ・アプリケーション５０８、データベース・アプリケーション５１０、ソーシャル・ネットワーキング・サービス（ｓｏｃ ｎｗ ｓｖｃ）アプリケーション５１２、および株価アプリケーション５１４を含むことができる。

アプリケーション（例えば、５０２、５０４、５０６、５０８、５１０、５１２、５１４）に関して、アプリケーションに関連付けられたリソース間の依存関係およびワークロードに関連付けられたパッチの分析の結果に少なくとも部分的に基づいて、ＰＭＣ１１４は、実行される（例えば、適用される）ことが望ましいさまざまなパッチを決定または識別することができ、第１のワークロード部分がオフラインであるときに、保守時間ウィンドウ内で、それらのパッチのうちのどのパッチが、第１のワークロード部分に関連付けられたリソース（例えば、コンテナ１０４、ＶＭ１０６、ＰＭ１０８、その他のリソース１１０）、ノード（例えば、ノード１１２）などに適用されるかを決定することができ、第２のワークロード部分がオンラインであるときに、それらのパッチのうちのどのパッチが、リソース、ノードなどに適用され得るかを決定することができる。第１のワークロード部分に関連付けられ、第１のワークロード部分に関連付けられたリソース、ノードなどがオフラインであるときに保守時間ウィンドウの間に実行されるパッチの一部に関して、ＰＭＣ１１４は、保守時間ウィンドウ内で実行されることが望ましいパッチの相対的な（例えば、異なる）重要性、優先度、または脆弱性（例えば、高レベル、中レベル、または低レベル）を決定することができる。しかし、多くの場合に当てはまるように、保守時間ウィンドウ内で適用できるパッチの数よりも多い適用対象のパッチが存在することがある。例えば、ＰＭＣ１１４は、通信サービス・アプリケーション５０２に関して実行されるパッチ５１６および５１８を決定または識別することができ、パッチ５１６および５１８が低レベルのパッチである（例えば、パッチ５１６および５１８が、相対的に低いレベルの重要性、優先度、または脆弱性を有していることを示す脆弱性スコアをそれぞれ有している）ということを、さらに決定することができる。ＰＭＣ１１４は、消費者ロイヤルティ・サービス・アプリケーション５０４に関して実行されるパッチ５２０、５２２、および５２４を決定または識別することもでき、パッチ５２０が高レベルのパッチであり（例えば、パッチ５２０が、高レベルの重要性、優先度、または脆弱性を有していることを示す脆弱性スコアを有しており）、パッチ５２２が中レベルのパッチであり（例えば、パッチ５２２が、中レベルの重要性、優先度、または脆弱性を有していることを示す脆弱性スコアを有しており）、パッチ５２４が低レベルのパッチである（例えば、パッチ５２４が、相対的に低いレベルの重要性、優先度、または脆弱性を有していることを示す脆弱性スコアを有している）ということを、さらに決定することができる。

ＰＭＣ１１４は、トレーダー・アプリケーション５０６に関して実行されるパッチ５２６、５２８、および５３０をさらに決定または識別することができ、パッチ５２６および５２８が高レベルのパッチであり、パッチ５３０が低レベルのパッチであるということを、さらに決定することができる。さらに、ＰＭＣ１１４は、ポートフォリオ・アプリケーション５０８に関して実行されるパッチ５３２および５３４を決定または識別することができ、パッチ５３２および５３４が中レベルのパッチであるということを、さらに決定することができる。ＰＭＣ１１４は、データベース・アプリケーション５１０に関して実行されるパッチ５３６、５３８、および５４０を決定または識別することもでき、パッチ５３６が中レベルのパッチであり、パッチ５３８および５４０が低レベルのパッチであるということを、さらに決定することができる。

ＰＭＣ１１４は、ソーシャル・ネットワーキング・サービス・アプリケーション５１２に関して実行されるパッチ５４２および５４４をさらに決定または識別することができ、パッチ５４２が中レベルのパッチであり、パッチ５４４が低レベルのパッチであるということを決定することもできる。ＰＭＣ１１４は、株価アプリケーション５１４に関して実行されるパッチ５４６、５４８、および５５０をさらに決定または識別することができ、パッチ５４６が中レベルのパッチであり、パッチ５４８および５５０が低レベルのパッチであるということを決定することもできる。

ＰＭＣ１１４は、定義されたパッチ管理基準および関連するパッチ管理アルゴリズムに従って、パッチ（例えば、パッチ５１６～５５０）を分析し、ワークロードに関連付けられたリソース間の依存関係を決定および分析し、第１のワークロード部分がオフラインであるときに実行されるパッチ（例えば、パッチのサブセット）を決定し、第２のワークロード部分がオンラインであるときに実行され得るパッチ（例えば、パッチの他のサブセット）を決定し、パッチの脆弱性スコアまたはパッチのさまざまなグループ（例えば、グループ化）のグループ脆弱性スコアを決定し、保守時間ウィンドウ内で実行され得る、パッチの他のサブセットの他の全体的脆弱性スコアよりも高い（例えば、最高の）全体的脆弱性スコアを有するパッチの望ましい（例えば、最適な、適切な、または許容できる）サブセットを決定することができる。パッチのそのような望ましいサブセットは、最高の全体的脆弱性スコアを有する（例えば、脆弱性スコアを最大化する）ことによって、コンピューティング・システムの脆弱性を最小限に抑えるか、または少なくとも大幅に低減することができる。

例示的なパッチ選択５００では、分析結果に少なくとも部分的に基づいて、ＰＭＣ１１４は、例えば、通信サービス・アプリケーション５０２に関連付けられた低レベルのパッチであることができるパッチ５１６および５１８、ならびにソーシャル・ネットワーキング・サービス・アプリケーション５１２に関連付けられた、それぞれ中レベルのパッチおよび低レベルのパッチであることができるパッチ５４２および５４４が、第２のワークロード部分に関連付けることができ、第２のワークロード部分がオンラインであるときに適用され得る（例えば、保守時間ウィンドウ内または保守時間ウィンドウ外で適用され得る）ということを、決定することができる。また、分析結果に少なくとも部分的に基づいて、ＰＭＣ１１４は、（例えば、最高の全体的脆弱性スコアを有し、保守時間ウィンドウ内で実行することができる）パッチの望ましいサブセットが、パッチ５２０、５２２、５２４、５２６、５２８、５３０、５３２、５３４、および５３６を含むことができるが、パッチ５３８、５４０、５４６、５４８、および５５０を含まないということを、決定することができる。パッチ実行コンポーネント１１８は、本明細書においてさらに詳細に説明されるように、第１のワークロード部分がオフラインであるときに、保守時間ウィンドウ内で、第１のワークロード部分に関連付けられたパッチのサブセット（例えば、パッチ５２０～５３６）を適用することができ、第２のワークロード部分がオンラインであるときに、保守時間ウィンドウ内で、第２のワークロード部分に関連付けられたパッチの他のサブセット（例えば、パッチ５１６、５１８、５４２、および５４４）を適用することができる。

さらに図１に関して、保守時間ウィンドウの間に実行されるパッチを決定するためにＰＭＣ１１４が利用または適用できる、複数のパッチ管理アルゴリズムが存在する。１つのパッチ管理アルゴリズムに従って、ＰＭＣ１１４は、ＶＭの各パッチを単一のエントリとして扱うことができ、例えば、保守時間ウィンドウの間にすべてのパッチを適用できない場合に、高い脆弱性スコアを有するパッチを優先することができ、コンテナ（例えば、ポッド）ごとのすべてのパッチを単一のエントリとして扱うことができ、オフラインでコンテナ・イメージにパッチが適用されるため、そのようなパッチを適用するための時間ならびにポッド内のすべてのリソースの起動時間および停止時間が一緒に組み合わされ得る。

ＶＭ（例えば、ＶＭ１０６）上の特定のアプリケーション・サーバにパッチを適用するためにリソースを停止して起動するための時間の例として、アプリケーション・サーバを停止するのに約２分かかり、パッチを適用するのに約１分かかり、パッチの適用後にアプリケーション・サーバを起動するのに約４分かかることがある。アプリケーション・サーバのリソースのための複数のパッチが存在する場合、ＰＭＣ１１４は、これらのパッチを適用するためにアプリケーション・サーバを複数回停止して再起動する必要がないように、これらのパッチを単一のエントリに一緒に組み合わせることができる。アプリケーション・サーバのパッチが別々に考慮された場合、複数回の再起動を含めることによって、時間が過剰になる可能性がある（例えば、保守時間ウィンドウ内で使用可能な時間を超える可能性がある）。そのＶＭの再起動時間を、パッチを実行するための時間が０である別のエントリとして含めることができるということに注意する。

そのようなパッチ管理アルゴリズムに従って、各パッチは、コンテナ１０４、ＶＭ１０６、ＰＭ１０８、またはその他のリソース１１０を停止するための時間、コンテナ１０４、ＶＭ１０６、ＰＭ１０８、またはその他のリソース１１０を再起動するための時間、パッチを適用するために時間（コンテナ１０４の場合は、０であることができる）、パッチの重要性スコア（例えば、重要性または脆弱性スコア）、パッチに関連付けられたレプリカ数、およびパッチの種類、という属性を含むことができる。一部の実施形態では、パッチの重要性または脆弱性スコアを決定する（例えば、計算する）ときに、ＰＭＣ１１４は、等比級数の和をコンテナに使用して重要性または脆弱性スコアを計算することができる。

等比級数の和に基づく式を使用してポッドの重要性スコアを決定する（例えば、計算する）例示的な非限定的例は、次のようなものであることができる。更新の各種類に関して、ポッドの更新の重要性または脆弱性スコア（例えば、高い重要性、中程度の重要性、または低い重要性）を決定する（例えば、計算する）ことを容易にするために、ＰＭＣ１１４は、次の例示的な方程式を使用して更新のその種類の重要性または脆弱性スコア（例えば、個別の重要性または脆弱性スコア）を決定することができる。

ここで、ｘは重要性値（２＝高、３＝中、４＝低）を有する更新の種類であることができ、ｎｘはポッドに適用される特定の種類の更新の数であることができる。ＰＭＣ１１４は、ポッドの異なる種類の更新に対して決定された個別の重要性または脆弱性スコアを合計することによって、ポッドのすべての更新に対して重要性または脆弱性スコアの合計（例えば、全体またはグループ）を決定することができる。例えば、ポッドには、ｘ＝２という高い重要性を有する２つの更新（例えば、パッチ）、およびｘ＝３という中程度の重要性を有する４つの更新が存在することがある。ＰＭＣ１１４は、高い重要性を有する更新の重要性または脆弱性スコアを［（１／２）^２＋（１／２）^３］として決定することができ、中程度の重要性を有する更新の重要性または脆弱性スコアを［（１／３）^２＋（１／３）^３＋（１／３）^４＋（１／３）^５］として決定することができ、ポッドの更新の重要性または脆弱性スコアの合計を［（１／２）^２＋（１／２）^３］＋［（１／３）^２＋（１／３）^３＋（１／３）^４＋（１／３）^５］として決定することができる。コンテナまたはポッドのスコア、およびスコアの決定方法を決定するときに、多すぎるより低い重要性を有する更新（例えば、脆弱性のより低い更新またはパッチ）の合計が、高い重要性を有する更新の合計を圧倒しないようにするのが望ましいことがある。このパッチ管理アルゴリズム（および本明細書で開示されたその他のパッチ管理アルゴリズム）は、高い重要性を有する更新（例えば、高い重要性を有する更新の合計）が、より低い重要性を有する更新（例えば、相対的に多いより低い重要性を有する更新の合計）によって圧倒されないようにすることができる。

一部の実施形態では、ＰＭＣ１１４は、定義されたパッチ管理基準に従って保守時間ウィンドウ内でワークロードに対して実行するためのパッチの望ましい（例えば、適切な、最適な、または少なくとも事実上最適な）サブセットを決定することを容易にするために、別のパッチ管理アルゴリズムを適用することができる。そのようなパッチ管理アルゴリズムは、適用するパッチの望ましいサブセット決定するために、動的プログラミング解決策を提供することができ、例えば次のように表され得る。

ＰＭＣ１１４は、空の２次元配列Ｋ［（Ｎ＋１）］［（Ｗ＋１）］を作成することができ、Ｎは、更新（例えば、パッチ）の総数であることができ、Ｗは、サービスがリブートされ得るウィンドウ（例えば、保守時間ウィンドウ）のサイズであることができる。ＰＭＣ１１４は、この配列を初期化することができ、位置ごとに、この配列のＫ［ｉ］［ｊ］は、ｉ個の更新およびウィンドウ・サイズｊを前提として、更新［１：ｉ］のサブセット、およびウィンドウ・サイズｊの最大累積スコアを与えることができる更新の推定完了時間を含むことができるマップと、ウィンドウ・サイズｊ内で達成可能な最大累積スコアと、この最大累積スコアを達成するための複数のスレッドにわたる更新の分布を含むことができるスレッド・マップと、というエントリを保持することができ、スレッド・マップは、（例えば、オンラインで実行され得る更新のための）「ライブ」と呼ばれる特殊なスレッドも含むことができる。解は、Ｋ［（Ｎ＋１）］［（Ｗ＋１）］の位置のエントリであることができる。

Ｋを埋めること、および配列の各Ｋ［ｉ］［ｊ］でＫ［（Ｎ＋１）］［（Ｗ＋１）］を決定することに関して、ＰＭＣ１１４は、初期最大スコアをＫ［ｉ－１］［ｊ］のスコアに割り当てることができ、ポッドの最良のサブセットがＫ［ｉ－１］［ｊ］でのサブセットに等しくなるように、かつスレッド・マップがＫ［ｉ－１］［ｊ］のスレッド・マップに等しくなるように、初期化することができ、更新ｉを、Ｋ［ｉ－１］［ｌ］に位置する更新のサブセットに追加できるかどうかをチェックすることができ、ここでｌは、ウィンドウ・サイズｊを超えない０～ｊであり、更新ｉを更新のサブセットに追加できる場合、追加された新しいポッド／コンテナのすべてのスコアをＫ［ｉ－１］［ｌ］に加算し、その値を前の最大スコアと比較することができ、新しいポッド／コンテナのすべてのスコアをＫ［ｉ－１］［ｌ］に加算することから取得されたスコアが、前の最大スコアより大きい場合、３つのエントリを更新することができ、ＰＭＣ１１４がすべてのｌ：０～ｊを試みるまで、上記の動作の実行を継続することができる。ＰＭＣ１１４は、最大スコア（例えば、最大または最高の脆弱性スコア）に関連付けられたパッチのサブセットを識別または決定することができる。

さらに、更新ｉを更新のサブセットに追加できるかどうかをチェックして決定することに関して、ＰＭＣ１１４は、現在のポッド／コンテナの依存関係（例えば、ワークロードの複数の層のノード間の依存関係）のすべてのリストを取得または決定することができる。ＰＭＣ１１４は、現在のポッド／コンテナのすべての依存関係にライブで（例えば、オンラインで）パッチを適用できるかどうかをチェック（例えば、分析、評価）して決定することができる。現在のポッド／コンテナのすべての依存関係にライブでパッチを適用できる場合、ＰＭＣ１１４は、それらの依存関係をライブ・スレッドに追加し、スコア（例えば、脆弱性スコア）を更新することができる。現在のポッド／コンテナにライブでパッチを適用できないが、依存関係の一部にライブでパッチを適用できる場合、ＰＭＣ１１４は、それらの依存関係をライブ・スレッドから除去し、そのような依存関係を、ライブでパッチを適用できない新しい依存関係として扱うことができる。各依存関係に関して、前の依存関係が終了した時間がスレッド内に存在しない場合、ＰＭＣ１１４は、前の依存関係が終了した時間をスレッドに追加することができ、これによって、（例えば、欲張りスケジューリングに従って）前の依存関係が終了した後の最も早い依存関係を完了し、完了時間がｊを超えていないかどうかチェックし、現在の依存関係のスコアを合計スコアに加算することができる。

特定の実施形態では、ＰＭＣ１１４は、定義されたパッチ管理基準に従って、パッチのすべての可能なサブセットを列挙し、このリストから実行可能なサブセットをフィルタリングし、最高の累積スコアを有するパッチの実行可能なサブセットを決定することによって、パッチの望ましい（例えば、最も重要な）サブセットを決定することができる。保留中のパッチの総数がｍである場合、サブセットの数は２^ｍになることができる。

特定の実施形態では、ＰＭＣ１１４は、定義されたパッチ管理基準に従って保守時間ウィンドウ内でワークロードに対して実行するためのパッチの望ましい（例えば、適切な、または最適な）サブセットを決定することを容易にするために、パッチ管理アルゴリズム（例えば、本明細書で開示されているようなアルゴリズム１（ｇｅｔＯｐｔｉｍａｌＳｕｂｓｅｔ））を適用することができる。このパッチ管理アルゴリズム（例えば、アルゴリズム１）において使用される変数および関数の定義は、次を含むことができる：Ｗは、オフライン・ウィンドウのサイズであることができ、［ｐ１，ｐ２，ｐ３，．．．ｐｍ］は、保留中のパッチのリストであることができ、保留中のパッチの総数はｍであり、［（ｄｅｐｓＤｉｃｔ）］は、アプリケーションの依存関係ツリー（隣接リスト）であることができ、Ｋは、部分問題に対する解を保持できる２次元配列であることができ、ｓｃｈｅｄｕｌｅＣｒｉｔは、最長クリティカル・パスを最初にスケジューリングすることによって、パッチの所定のリストをスケジューリングすることができ、ｓｃｈｅｄｕｌｅＧｒｅｅｄｙは、欲張った先着順の方法でパッチの所定のリストをスケジューリングすることができ、ｓｃｈｅｄＰｏｌｉｃｙは、欲張りまたはクリティカルのいずれかであることができる、スケジューリング・ポリシーであることができる。

パッチ管理アルゴリズムは、次のように表され得る。

このパッチ管理アルゴリズム（例えば、アルゴリズム１（ｇｅｔＯｐｔｉｍａｌＳｕｂｓｅｔ））は、パッチを適用するための時間をパッチの重みと見なすことができ、パッチのスコアがパッチの値であることができ、合計オフライン・ウィンドウ・サイズを、ナップザックのサイズとして扱うことができるようなやり方で、パッチ選択をナップザックとしてモデル化することができる。このパッチ管理アルゴリズム（例えば、ＰＭＣ１１４によって実装されるようなパッチ管理アルゴリズム）は、Ｗ分内で最も重要なパッチのパッチ適用を保証する、パッチのサブセットを決定することができる。このパッチ管理アルゴリズム（例えば、ＰＭＣ１１４によって実装されるようなパッチ管理アルゴリズム）は、累積スコアを最大化するパッチの実行可能なサブセットを決定することを目的として、各パッチに重要性スコアを割り当てることができる。パッチ管理アルゴリズムは、同時のパッチの数に対する制限が存在する場合の事例に対処することができる。このパッチ管理アルゴリズム（例えば、ＰＭＣ１１４によって実装されるようなパッチ管理アルゴリズム）は、依存制約に違反しないようなやり方で、許可された数のスレッドにわたってパッチをスケジューリングすることができ、例えば、サービスを停止してパッチを適用する前に、アプリケーションのサービスの依存関係をオフにすることができる。パッチの最適なスケジュールへの近接を検出するために、パッチ管理アルゴリズム（例えば、ＰＭＣ１１４によって実装されるようなパッチ管理アルゴリズム）は、例えば、欲張りおよびクリティカル・パスなどの、複数の技術のうちの１つを使用することができる。欲張り法（ｓｃｈｅｄｕｌｅＧｒｅｅｄｙ）は、パッチ管理アルゴリズムの時間複雑さを低減することができ、現在のパッチを、すでに選択されたパッチのうちのパッチのスケジュールに単に適合させようとする。クリティカル・パス・スケジューリング（ｓｃｈｅｄｕｌｅＣｒｉｔ）に関しては、すべての部分問題Ｋ「ｉ」「ｊ」に対して、クリティカル・パス・スケジューリング（例えば、ＰＭＣ１１４によって実装されるクリティカル・パス・スケジューリング）は、常に最初にクリティカル・パスをスケジューリングし、その後、そのクリティカル・パスを保留中のパッチから除去することができる。クリティカル・パス・スケジューリング・プロセスは、スケジューリングするパッチが残っていない状態になるまで、またはすべてのスレッドが時間Ｗに関して占有されるまで、再帰的に繰り返され得る。

パッチ管理アルゴリズム（例えば、ＰＭＣ１１４によって実装されるようなパッチ管理アルゴリズム）は、空の２次元配列Ｋ［（ｍ＋１）］［（Ｗ＋１）］を作成することができ、ｍは、更新（例えば、パッチ）の総数であることができ、Ｗは、サービスがリブートされ得るウィンドウ（例えば、保守時間ウィンドウ）のサイズであることができる。ＰＭＣ１１４は、この配列を０に初期化することができ、位置ごとに、この配列のＫ［ｉ］［ｊ］は、ｉ個の更新およびウィンドウ・サイズｊを前提として、更新［１：ｉ］のサブセット、およびウィンドウ・サイズｊの最大累積スコアを与えることができる更新の推定完了時間を含むことができるマップと、ウィンドウ・サイズｊ内で達成可能な最大累積スコアと、この最大累積スコアを達成するための複数のスレッドにわたる更新の分布を含むことができるスレッド・マップと、というエントリを保持することができる。解は、Ｋ［（ｍ＋１）］［（Ｗ＋１）］の位置のエントリであることができる。

Ｋを埋めること、および配列の各Ｋ［ｉ］［ｊ］でＫ［（ｍ＋１）］［（Ｗ＋１）］を決定することに関して、ＰＭＣ１１４は、初期最大スコアをＫ［ｉ－１］［ｐｗ］のスコアに割り当てることができ、ポッドの最良のサブセットがＫ［ｉ－１］［ｊ］でのサブセットに等しくなるように、かつスレッド・マップがＫ［ｉ－１］［ｊ］のスレッド・マップに等しくなるように、初期化することができ、更新ｉを、Ｋ［ｉ－１］［ｐｗ］に位置する更新のサブセットに追加できるかどうかをチェックすることができ、ここでｐｗは、ウィンドウ・サイズｊを超えない０～ｊである。この、更新ｉを追加できるかどうかをチェックすることは、欲張りアルゴリズムまたはクリティカル・パス・ファースト・アルゴリズム（critical path first algorithm）を使用して実行され得る。更新ｉを更新のサブセットに追加できる場合、ＰＭＣ１１４は、追加された新しいポッド／コンテナのすべてのスコアをＫ［ｉ－１］［ｐｗ］に加算し、この値を前の最大スコアと比較することができ、新しいポッド／コンテナのすべてのスコアをＫ［ｉ－１］［ｌ］に加算することから取得されたスコアが前の最大スコアよりも大きい場合、ＰＭＣ１１４は３つのエントリを更新することができ、ＰＭＣ１１４は、ＰＭＣ１１４がすべてのｐｗ：０～ｊを試みるまで、上記の動作の実行を継続することができる。ＰＭＣ１１４は、最大スコア（例えば、最大または最高の脆弱性スコア）に関連付けられたパッチのサブセットを識別または決定することができる。

各依存関係に関して、前の依存関係が終了した時間がスレッド内に存在しない場合、ＰＭＣ１１４は、前の依存関係が終了した時間をスレッドに追加することができ、これによって、（例えば、欲張りスケジューリングまたはクリティカル・パス・スケジューリングに従って）前の依存関係が終了した後の最も早い依存関係を完了し、完了時間がｊを超えていないかどうかチェックし、現在の依存関係のスコアを合計スコアに加算することができる。

特定の実施形態では、同時のパッチ（スレッド）に対する制限がない場合、ＰＭＣ１１４は、さらに別のパッチ管理アルゴリズムを適用することができる。この場合、ジョブのスケジューリングおよび分割の問題を解決する必要がない。コンテナにデプロイされるサービスごとに、ＰＭＣ１１４は、コンテナに対するオフラインのパッチ適用の合計時間が、適用されるパッチに依存しないため、所定の保守時間ウィンドウ内で、依存関係と共にサービスを再起動できるかどうかを単にチェックすることができる。コンテナに対してパッチを適用し、このコンテナに依存しているものを再起動するための時間が、ウィンドウ・サイズＷよりも小さい場合、保守時間ウィンドウ（例えば、オフライン・ウィンドウ）の間に、このコンテナにパッチを適用することができる。ＶＭの場合、オフラインのパッチ適用時間は、適用されるパッチに依存することがある。このことが同時のパッチに対する制限にならないため、ＶＭごとに、ＰＭＣ１１４は、別々のナップザック・アルゴリズムを実行または実装し、所定の時間内に適用され得るパッチの最適なサブセットを決定して選択することができる。ＶＭのこの別々のナップザック問題ごとに、ＰＭＣ１１４は、本明細書で開示されているように、依存しているものを再起動するための時間を考慮することもできる。

図６は、開示される対象のさまざまな態様および実施形態に従って、例示的なＰＭＣ６００のブロック図を示している。ＰＭＣ６００は、本明細書においてさらに詳細に説明されるように、各コンポーネント（例えば、それぞれ名前が付けられたコンポーネント）とそれぞれ同じもしくは類似することができるか、または各コンポーネントと同じもしくは類似する機能を含むことができる、パッチ識別コンポーネント６０２およびパッチ実行コンポーネント６０４を備えることができる。

ＰＭＣ６００は、ＰＭＣ６００に関連付けられた動作を制御する（例えば、管理する）ことができる動作管理コンポーネント６０６を含むことができる。例えば、動作管理コンポーネント６０６は、定義されたパッチ管理基準、定義されたパッチ管理アルゴリズム（例えば、本明細書に記載された方法、システム、および技術によって本明細書において開示されたか、定義されたか、列挙されたか、具現化されたか、または示されたパッチ管理アルゴリズム）に従って、ＰＭＣ６００のコンポーネントに動作を実行させるための命令を生成することを容易にすることができ、命令に少なくとも部分的に基づいてＰＭＣ６００のコンポーネントによる動作の実行を容易にするために、命令をＰＭＣ６００のコンポーネント（例えば、パッチ識別コンポーネント６０２、パッチ実行コンポーネント６０４など、プロセッサ・コンポーネント６１８、データ・ストア６２０など）に通信することができる。動作管理コンポーネント６０６は、ＰＭＣ６００のコンポーネント間のデータ・フローを制御すること、およびＰＭＣ６００と、ＰＭＣ６００に関連付けられた（例えば、接続された）別のコンポーネントまたはデバイス（例えば、コンピュータ、ラップトップ・コンピュータ、またはその他の種類のコンピューティング・デバイスもしくは通信デバイス）との間のデータ・フローを制御することを、容易にすることもできる。

ＰＭＣ６００は、例えば、トポロジー識別コンポーネント６０８、スコア決定コンポーネント６１０、パッチ選択コンポーネント６１２、妥当性確認コンポーネント６１４、および復元コンポーネント６１６を備えることもできる。トポロジー識別コンポーネント６０８は、コンピューティング・システムに関連付けられたワークロード（例えば、ハイブリッド・クラウドベースのコンピューティング・システムに関連付けられたハイブリッド・ワークロード）のトポロジーを決定または識別することができる。ワークロードのトポロジーを決定することの一部として、トポロジー識別コンポーネント６０８は、ワークロードの依存関係ツリーを決定することを容易にするため、および保守時間ウィンドウの間にどのパッチを適用するかを効率的に決定し、パッチが適用される（例えば、オフラインでパッチが第１のワークロード部分に対して実行される）順序を決定し、保守時間ウィンドウの間にワークロードの少なくとも望ましい一部にパッチを適用することを容易にするために、ワークロードに関連付けられたノードまたはリソース間の依存関係を決定または識別することができる。

スコア決定コンポーネント６１０は、定義されたパッチ管理基準および関連する適用可能なパッチ管理アルゴリズムに従って、パッチの脆弱性および重要性のレベル（例えば、高レベル、中レベル、または低レベルの脆弱性）の分析の結果に少なくとも部分的に基づいて、ワークロードに関連付けられたパッチの、パッチ関連のスコア（例えば、ワークロードに関連付けられたパッチの脆弱性、重要性、またはリスクのスコア、あるいはワークロードに関連付けられたパッチのサブセットの全体的な、累積した、またはグループの脆弱性、重要性、またはリスクのスコア）を決定することができる。例えば、スコア決定コンポーネント６１０は、例えば本明細書に記載されたパッチ管理アルゴリズムなどの、望ましいパッチ管理アルゴリズムを利用して、ワークロードに関連付けられた、パッチの脆弱性スコアまたはパッチのサブセット（例えば、異なるグループ）のグループ脆弱性スコアを決定することを容易にすることができる。

パッチ選択コンポーネント６１２は、定義されたパッチ管理基準に従って、ワークロードに関連付けられたパッチに対して決定されたパッチ関連のスコア、あるいはワークロードに関連付けられたパッチのサブセットの全体的な、または累積したパッチ関連のスコアに少なくとも部分的に基づいて、保守時間ウィンドウの間に実行するために、ワークロードに関連付けられたパッチのセットから、パッチのサブセットを選択または決定することができ、ワークロードの第１のワークロード部分がオフラインであるときに、パッチのサブセットの少なくとも一部が適用され、ワークロードの第２のワークロード部分がオンラインであるときに、パッチのサブセットの別の一部が適用され得る。例えば、パッチ選択コンポーネント６１２は、適用可能なパッチ管理アルゴリズムに従って、ワークロードに関連付けられたパッチのサブセットが、ワークロードに関連付けられたパッチの他のサブセットの他のグループの、全体的な、または累積したパッチ関連のスコアと比較して最高のグループの、全体的な、または累積したパッチ関連のスコアを有しているということの決定に少なくとも部分的に基づいて、保守時間ウィンドウの間に実行するために、ワークロードに関連付けられたパッチのセットから、パッチのサブセットを選択または決定することができる。

妥当性確認コンポーネント６１４は、第１のワークロード部分に関連付けられたリソース、ノード、またはアプリケーションなどがオフラインであるときに、保守時間ウィンドウの間に、第１のワークロード部分または第２のワークロード部分に適用されたパッチを分析するか、あるいは第１のワークロード部分または第２のワークロード部分に関連付けられたリソース、ノード、アプリケーション、またはデータなどを分析し、パッチが適用された後に、第１のワークロード部分または第２のワークロード部分に関連付けられたパッチ、あるいはリソース、ノード、アプリケーション、またはデータなどが適切に機能している（例えば、Ｗｅｂサーバが適切に機能している、アプリケーション・サーバが適切に機能している、データベースが、データベースに復元されたデータを含めて適切に機能している、およびノードが適切に機能している）かどうかを決定すること、および妥当性を確認する（例えば、検証する）ことができる。妥当性確認コンポーネント６１４が、パッチの妥当性が確認されない（例えば、パッチまたは関連するリソース、ノード、アプリケーションなどが、定義されたパッチ管理基準に従って適切に機能していない）ということを決定した場合、妥当性確認コンポーネント６１４は、そのようなパッチの妥当性が確認されないということを示すことができる指標（例えば、妥当性未確認指標）を生成し、提示することができる。

復元コンポーネント６１６は、パッチの妥当性が確認されないということの決定に応答して、保守時間ウィンドウの間にパッチを取り消し（例えば、元に戻し）、ワークロードのアイテム（例えば、リソース、ノード、アプリケーション、またはデータなど）をパッチが実行される前の状態に戻すことができる。例えば、保守時間ウィンドウの間に、復元コンポーネント６１６は、パッチの妥当性が確認されないということを示すことができる、パッチに関連する無効指標を受信することができる。無効指標を受信したことに応答して、復元コンポーネント６１６は、保守時間ウィンドウ内でパッチを取り消し、ワークロードのアイテム（例えば、リソース、ノード、アプリケーション、またはデータなど）を、パッチがワークロードのアイテムに適用される前のワークロードのアイテムの状態に戻すことができる。

プロセッサ・コンポーネント６１８は、他のコンポーネント（例えば、パッチ識別コンポーネント６０２、パッチ実行コンポーネント６０４、動作管理コンポーネント６０６など、またはデータ・ストア６２０など）と連動して機能し、ＰＭＣ６００のさまざまな機能の実行を容易にすることができる。プロセッサ・コンポーネント６１８は、本明細書でさらに詳細に開示されているようなＰＭＣ６００の動作を容易にし、ＰＭＣ６００と、ＰＭＣ６００に関連付けられた（例えば、接続された）他のコンポーネント（例えば、コンピュータ、ラップトップ・コンピュータ、またはその他のコンピューティング・デバイスもしくは通信デバイス）の間のデータ・フローを制御するために、ワークロード、アプリケーション、オペレーティング・システム、ミドルウェア、ＶＭ、ＰＭ、コンテナ、リソース、ノード、定義されたパッチ管理基準、定義されたパッチ管理アルゴリズム、トラフィック・フロー、ポリシー、プロトコル、インターフェイス、ツール、またはその他の情報に関連付けられた、パッチ、ワークロード、クラウドコンピューティング環境、脆弱性スコア、ノード間の依存関係、リソースなどに関連する情報などのデータを処理できる、１つまたは複数のプロセッサ、マイクロプロセッサ、またはコントローラを採用することができる。

データ・ストア６２０は、ＰＭＣ６００に関連付けられた動作の制御を容易にするために、データ構造（例えば、ユーザ・データ、メタデータ）、コード構造（例えば、モジュール、オブジェクト、ハッシュ、クラス、プロシージャ）、または命令、ワークロード、アプリケーション、オペレーティング・システム、ミドルウェア、ＶＭ、ＰＭ、コンテナ、リソース、ノード、定義されたパッチ管理基準、定義されたパッチ管理アルゴリズム、トラフィック・フロー、ポリシー、プロトコル、インターフェイス、ツール、またはその他の情報に関連付けられた、パッチ、ワークロード、クラウドコンピューティング環境、脆弱性スコア、ノード間の依存関係、リソースなどに関連する情報を格納することができる。１つの態様では、プロセッサ・コンポーネント６２２は、動作することが望まれる情報を格納して取り出すため、あるいは少なくとも部分的に機能をパッチ識別コンポーネント６０２、パッチ実行コンポーネント６０４、動作管理コンポーネント６０６、もしくはデータ・ストア６２０など、またはＰＭＣ６００の実質的に任意のその他の動作可能な態様に提供するために、（例えば、メモリ・バスを介して）データ・ストア６２４に機能的に結合され得る。

システムまたはデバイスは、本明細書では複数のコンポーネント間の相互作用に関して説明された（または説明される）。そのようなシステムおよびコンポーネントが、それらのコンポーネントもしくはそれらの内部で指定されたサブコンポーネント、指定されたコンポーネントもしくはサブコンポーネントの一部、または追加のコンポーネントを含むことができるということが、認識されるべきである。サブコンポーネントは、親コンポーネント内に含まれるのではなく、他のコンポーネントに通信によって結合されたコンポーネントとして実装することもできる。さらに、１つまたは複数のコンポーネントまたはサブコンポーネントは、集合的機能を提供する単一のコンポーネントに組み合わされてよい。コンポーネントは、簡潔にするために本明細書では具体的に説明されないが、当業者によって知られている１つまたは複数の他のコンポーネントと、相互作用してもよい。

図７は、開示される対象のさまざまな態様および実施形態に従って、コンピューティング・プラットフォームに関連付けられたパッチを管理するための例示的な非限定的方法７００のフロー図を示している。方法７００は、例えば、パッチ識別コンポーネント、ＰＭＣ、パッチ実行コンポーネント、またはプロセッサ・コンポーネントを備えるか、あるいはこれらのコンポーネントに動作可能なように結合されたシステムによって、実行され得る。本明細書に記載された他の実施形態で採用されている類似する要素の説明の繰り返しは、簡潔にするために省略されているか、または省略されてよい。

７０２で、コンピューティング・プラットフォームに関連付けられたワークロードを決定することができ、このワークロードは、パッチの第１のサブセットが実行され得る第１のワークロード部分を含むことができる。パッチ識別コンポーネントまたはＰＭＣは、ワークロード（例えば、ハイブリッド・ワークロード）を識別または決定することができ、保守時間ウィンドウの間に、コンピューティング・プラットフォーム（例えば、ハイブリッド・クラウド・コンピューティング環境）の第１のワークロード部分がオフラインであるときにパッチの第１のサブセットを実行できる第１のワークロード部分（例えば、適用可能なリソース、ノード、またはアプリケーションなど）を識別することができ、第２のワークロード部分がオンラインであるときにパッチの第２のサブセットを実行できる第２のワークロード部分を識別または決定することもできる。

７０４で、第１のワークロード部分に関連付けられたパッチの第１のサブセットのパッチの脆弱性スコアに少なくとも部分的に基づいて、保守時間ウィンドウ内で第１のワークロード部分の一部に適用するためのパッチの第３のサブセットを決定することができ、パッチの第１のサブセットはパッチの第３のサブセットを含むことができる。ＰＭＣは、第１のワークロード部分に関連付けられたパッチの第１のサブセットのパッチの脆弱性スコアに少なくとも部分的に基づいて、コンピューティング・プラットフォームまたはコンピューティング・プラットフォームの適用可能な一部がオフラインであるときに、保守時間ウィンドウ内で第１のワークロード部分の一部（例えば、パーツ）に適用するためのパッチの第３のサブセットを決定することができる。例えば、ＰＭＣは、保守時間ウィンドウの間に第１のワークロード部分内のパッチのすべてを実行するための十分な時間が、保守時間ウィンドウの間に存在しないということを、決定することができる。ＰＭＣは、第１のワークロード部分に関連付けられたパッチの第１のサブセットのパッチの脆弱性スコアを少なくとも決定することができる。パッチの脆弱性スコアに少なくとも部分的に基づいて、ＰＭＣは、保守時間ウィンドウ内で第１のワークロード部分の一部に適用するためのパッチの第３のサブセットを、パッチの第１のサブセットから決定することができる。パッチの第３のサブセット内のパッチの少なくとも一部は、パッチの第３のサブセットに含めるようにＰＭＣによって選択されなかったパッチの第１のサブセットの他のパッチよりも相対的に高い脆弱性スコアを有することができる。

図８は、開示される対象のさまざまな態様および実施形態に従って、コンピューティング・プラットフォームに関連付けられたパッチを管理するための別の例示的な非限定的方法８００のフロー図を示している。方法８００は、例えば、パッチ識別コンポーネント、ＰＭＣ、パッチ実行コンポーネント、またはプロセッサ・コンポーネントを備えるか、あるいはこれらのコンポーネントに動作可能なように結合されたシステムによって、実行され得る。本明細書に記載された他の実施形態で採用されている類似する要素の説明の繰り返しは、簡潔にするために省略されているか、または省略されてよい。

８０２で、リソース間のワークロードの依存関係を決定することを容易にするために、リソースに関連付けられた要求に関してネットワークを監視することができる。ＰＭＣは、リソース間のワークロードの依存関係を決定することを容易にするために、リソース（例えば、コンテナ、ＶＭ、ＰＭ、その他のリソース、またはノード）に関連付けられた要求に関してネットワーク（例えば、コンピューティング・ネットワークまたは通信ネットワーク）を監視することができ、ワークロードの依存関係は、第１の種類のアイテム（例えば、ノード）と別の種類のアイテム（例えば、ＶＭまたはＰＭ）の間に存在することがあり、または同じ種類のアイテム（例えば、第１のＶＭおよび第２のＶＭ）間に存在することがある。

８０４で、要求に関するネットワークの監視に少なくとも部分的に基づいて、リソース間のワークロードの依存関係を決定できる。ＰＭＣは、本明細書において説明されているように、要求に関してネットワークを監視することに少なくとも部分的に基づいて、またはそのようなワークロードの依存関係を決定する他の手段によって、リソース間のワークロードの依存関係を決定することができる。一部の実施形態では、ＰＭＣは、本明細書において説明されているように、要求に関してネットワークを監視することに少なくとも部分的に基づいて、ネットワークのトポロジーまたは依存関係ツリーを決定または識別することができる。

８０６で、ワークロードの依存関係に少なくとも部分的に基づいて、オフラインである間にパッチの第１のサブセットによってパッチを適用するための第１のワークロード部分、およびオンラインである間にパッチの第２のサブセットによってパッチを適用するための第２のワークロード部分を含んでいるワークロードを決定することができる。ＰＭＣは、ワークロードに関連付けられた依存関係に少なくとも部分的に基づいて、ワークロードを決定することができる。ワークロードは、（例えば、ワークロードのアイテムのワークロードの依存関係に少なくとも部分的に起因して）オフラインであるときにパッチの第１のサブセットによってパッチが適用されるワークロードのアイテムまたはリソース（例えば、コンテナ、ＶＭ、ＰＭ、その他のリソース、ノードなど）であることができる第１のワークロード部分、およびオンラインであるときにパッチの第２のサブセットによってパッチが適用され得る第２のワークロード部分を含むことができる。

８０８で、少なくとも、第１のワークロード部分に関連付けられたパッチの第１のサブセットのパッチの脆弱性スコアを決定することができる。ＰＭＣは、少なくとも、ワークロードの第１のワークロード部分に対して実行されるパッチの第１のサブセットのパッチの脆弱性スコアを決定する（例えば、計算する）ことができる。一部の実施形態では、ＰＭＣは、パッチの第２のサブセットのパッチの脆弱性スコアを決定することもできる。

８１０で、定義されたパッチ管理基準および関連するパッチ管理アルゴリズムに従って、パッチの脆弱性スコアおよび保守時間ウィンドウに少なくとも部分的に基づいて、第１のワークロード部分に関連付けられたパッチの第１のサブセットから、第１のワークロード部分の一部に対するパッチの第３のサブセットを決定することができる。ＰＭＣは、本明細書においてさらに詳細に説明されるように、定義されたパッチ管理基準および関連するパッチ管理アルゴリズムに従って、パッチの脆弱性スコアおよび保守時間ウィンドウに少なくとも部分的に基づいて、第１のワークロード部分に関連付けられたパッチの第１のサブセットから、第１のワークロード部分の一部（例えば、コンテナ、ＶＭ、ＰＭ、その他のリソース、またはノードなどのサブセット）に適用され得るパッチの第３のサブセットを決定することができる。

８１２で、第１のワークロード部分の一部に関連付けられたリソース、ノードなどがオフラインであるときに、保守時間ウィンドウの間に第１のワークロード部分の一部に対してパッチの第３のサブセットを実行することができる。パッチ実行コンポーネントは、第１のワークロード部分の一部の、または第１のワークロード部分の一部に関連付けられた、リソース、ノード、アプリケーションなどがオフラインであるときに、保守時間ウィンドウの間に第１のワークロード部分の一部に対してパッチの第３のサブセットを実行する（例えば、適用する）ことができる。一部の実施形態では、ＰＭＣは、ネットワークのトポロジーに従って、トポロジー的順序でパッチの第３のサブセットのパッチを実行することができる。特定の実施形態では、パッチ実行コンポーネントは、使用可能な保守時間ウィンドウ内で、第１のワークロード部分の一部の、依存関係を有するアイテムを含む複数のアイテム（例えば、コンテナ、ＶＭ、ＰＭ、その他のリソース、またはノードなど）に対して、パッチの第３のサブセットのパッチを同時に（例えば、並列に）実行することができる。ＰＭＣおよびパッチ実行コンポーネントは、パッチの第３のサブセットの実行を容易にするためのパッチ適用プロセスを実行することができ、このパッチ適用プロセスは、本明細書においてさらに詳細に説明されるように、第１のワークロード部分の一部に関連付けられたリソースを停止することおよび再起動すること、ならびにパッチの第３のサブセットに関連付けられたノードをリブートすることを含むことができる。

８１４で、保守時間ウィンドウの間に第１のワークロード部分の一部のパッチ適用の妥当性を確認することができる。ＰＭＣは、パッチが適切に適用されたことを保証し、そのようなパッチが適用された後に、パッチ、ならびに第１のワークロード部分の一部の各アイテム、およびコンピューティング・システム全体が適切に機能していることを保証するのを容易にするために、保守時間ウィンドウ内で第１のワークロード部分の一部のパッチ適用の妥当性を確認することができる。

８１６で、第１のワークロード部分の一部のワークロードのアイテムに対するパッチの妥当性を確認できないということが決定された場合、保守時間ウィンドウ内でこのワークロードのアイテムに対するパッチを取り消し、ワークロードのアイテムをパッチ適用前の状態に戻すことができる。ＰＭＣは、ワークロードのアイテム（例えば、コンテナ、ＶＭ、ＰＭ、その他のリソース、またはノードなど）に対するパッチの妥当性が確認されたかどうかを決定することができる。ワークロードのアイテムに対するパッチの妥当性を確認できないということの決定に応答して、ＰＭＣまたはパッチ実行コンポーネントは、保守時間ウィンドウ内でワークロードのアイテムに対するパッチを取り消し、ワークロードのアイテムをパッチ適用前の状態に戻すことができる。

８１８で、第２のワークロード部分に対してパッチの第２のサブセットを実行することができる。パッチ実行コンポーネントは、第２のワークロード部分に対してパッチの第２のサブセットを実行することができ、パッチの第２のサブセットは、少なくとも第２のワークロード部分がオンラインであるときに実行することができ、あるいは保守時間ウィンドウの間に、または保守時間ウィンドウの外側で実行することができる。特定の実施形態では、パッチ実行コンポーネントは、パッチの第２のサブセットのパッチの少なくとも一部を、第２のワークロード部分に対して同時に（例えば、並列に）実行することができ、保守時間ウィンドウの間に、パッチの第３のサブセットのパッチの一部が第１のワークロード部分の一部に対して実行される。

ＰＭＣは、パッチが適切に適用されたことを保証し、そのようなパッチが適用された後に、パッチ、ならびに第２のワークロード部分の一部の各アイテム、およびコンピューティング・システム全体が適切に機能していることを保証するのを容易にするために、第２のワークロード部分に対して実行されたパッチの妥当性を確認することもできる。ＰＭＣは、ワークロードのアイテムに対する特定のパッチの妥当性が確認されたかどうかを決定することができる。ワークロードのアイテムに対する特定のパッチの妥当性を確認できないということの決定に応答して、ＰＭＣまたはパッチ実行コンポーネントは、ワークロードのアイテムに対するパッチを取り消し、ワークロードのアイテムをパッチ適用前の状態に戻すことができる。

説明を簡単にするために、一連の動作として方法またはコンピュータ実装方法が示され、説明される。開示される対象が、示された動作によって、または動作の順序によって制限されず、例えば動作が、本明細書において提示されておらず、説明されていない他の動作と共に、さまざまな順序で、または同時に発生できるということが、理解され認識されるべきである。さらに、開示される対象に従ってコンピュータ実装方法を実装するために、示されているすべての動作が必要でなくてもよい。加えて、当業者は、コンピュータ実装方法が、代替として、状態図を介して相互に関連する一連の状態またはイベントとして表され得るということを理解し認識するであろう。そのようなコンピュータ実装方法をコンピュータに輸送または転送するのを容易にするために、以下および本明細書全体を通じて開示されたコンピュータ実装方法を製品に格納できるということが、さらに認識されるべきである。製品という用語は、本明細書において使用されるとき、任意のコンピュータ可読デバイスまたはコンピュータ可読ストレージ媒体からアクセスできるコンピュータ・プログラムを包含するよう意図されている。

開示される対象のさまざまな態様の背景を提供するために、図９および以下の説明は、開示される対象のさまざまな態様が実装され得る適切な環境の概要を示すよう意図されている。図９は、本明細書に記載された１つまたは複数の実施形態を容易にすることができる例示的な非限定的動作環境のブロック図を示している。本明細書に記載された他の実施形態で採用されている類似する要素の説明の繰り返しは、簡潔にするために省略されているか、または省略されてよい。図９を参照すると、本開示のさまざまな態様を実装するための適切な動作環境９００は、コンピュータ９１２を含むこともできる。コンピュータ９１２は、処理ユニット９１４、システム・メモリ９１６、およびシステム・バス９１８を含むこともできる。システム・バス９１８は、システム・メモリ９１６を含むが、これに限定されないシステム・コンポーネントを、処理ユニット９１４に結合する。処理ユニット９１４は、さまざまな使用可能なプロセッサのいずれかであることができる。デュアル・マイクロプロセッサおよびその他のマルチプロセッサ・アーキテクチャが、処理ユニット９１４として採用されてもよい。システム・バス９１８は、ＩＳＡ（Industry Standard Architecture）、ＭＣＡ（Micro Channel Architecture）、ＥＩＳＡ（Extended ISA）、ＩＤＥ（Intelligent Drive Electronics）、ＶＥＳＡローカル・バス（ＶＬＢ：VESA Local Bus）、ＰＣＩ（Peripheral Component Interconnects）、カード・バス、ユニバーサル・シリアル・バス（ＵＳＢ：Universal Serial Bus）、ＡＧＰ（Advanced Graphics Port）、ＦｉｒｅＷｉｒｅ（ＩＥＥＥ １３９４）、および小型コンピュータ・システム・インターフェイス（ＳＣＳＩ：Small Computer Systems Interface）を含むが、これらに限定されない、任意のさまざまな使用可能なバス・アーキテクチャを使用する、メモリ・バスもしくはメモリ・コントローラ、ペリフェラル・バスもしくは外部バス、またはローカル・バスを含む、複数の種類のバス構造のいずれかであることができる。システム・メモリ９１６は、揮発性メモリ９２０および不揮発性メモリ９２２を含むこともできる。起動中などにコンピュータ９１２内の要素間で情報を転送するための基本ルーチンを含んでいる基本入出力システム（ＢＩＯＳ：basic input/output system）が、不揮発性メモリ９２２に格納される。不揮発性メモリ９２２の例としては、読み取り専用メモリ（ＲＯＭ：read only memory）、プログラマブルＲＯＭ（ＰＲＯＭ：programmable ROM）、電気的プログラマブルＲＯＭ（ＥＰＲＯＭ：electrically programmable ROM）、電気的消去可能プログラマブルＲＯＭ（ＥＥＰＲＯＭ（登録商標）：electrically erasable programmable ROM）、フラッシュ・メモリ、または不揮発性ランダム・アクセス・メモリ（ＲＡＭ：random access memory）（例えば、強誘電体ＲＡＭ（ＦｅＲＡＭ：ferroelectric RAM））が挙げられるが、これらに限定されない。揮発性メモリ９２０は、外部キャッシュ・メモリとして機能するランダム・アクセス・メモリ（ＲＡＭ）を含むこともできる。例えばＲＡＭは、スタティックＲＡＭ（ＳＲＡＭ：static RAM）、ダイナミックＲＡＭ（ＤＲＡＭ：dynamic RAM）、シンクロナスＤＲＡＭ（ＳＤＲＡＭ：synchronous DRAM）、ダブル・データ・レートＳＤＲＡＭ（ＤＤＲ ＳＤＲＡＭ：double data rate SDRAM）、拡張ＳＤＲＡＭ（ＥＳＤＲＡＭ：enhanced SDRAM）、シンクリンクＤＲＡＭ（ＳＬＤＲＡＭ：Synchlink DRAM）、ダイレクト・ラムバスＲＡＭ（ＤＲＲＡＭ：direct Rambus RAM）、ダイレクト・ラムバス・ダイナミックＲＡＭ（ＤＲＤＲＡＭ：direct Rambus dynamic RAM）、およびラムバス・ダイナミックＲＡＭ（ＲＤＲＡＭ：Rambus dynamic RAM）などの、ただしこれらに限定されない、多くの形態で利用可能である。

コンピュータ９１２は、取り外し可能／取り外し不可能な揮発性／不揮発性のコンピュータ・ストレージ媒体を含むこともできる。例えば図９は、ディスク・ストレージ９２４を示している。ディスク・ストレージ９２４は、磁気ディスク・ドライブ、フロッピー（登録商標）・ディスク・ドライブ、テープ・ドライブ、Ｊａｚドライブ、Ｚｉｐドライブ、ＬＳ－１００ドライブ、フラッシュ・メモリ・カード、またはメモリ・スティック（登録商標）などの、ただしこれらに限定されない、デバイスを含むこともできる。ディスク・ストレージ９２４は、コンパクト・ディスクＲＯＭデバイス（ＣＤ－ＲＯＭ：compact disk ROM device）、記録可能ＣＤドライブ（ＣＤ－Ｒドライブ：CD recordable drive）、再書き込み可能ＣＤドライブ（ＣＤ－ＲＷドライブ：CD rewritable drive）、またはデジタル多用途ディスクＲＯＭドライブ（ＤＶＤ－ＲＯＭ：digital versatile disk ROM drive）などの光ディスク・ドライブを含むが、これらに限定されないストレージ媒体を、別々に、または他のストレージ媒体と組み合わせて、含むこともできる。システム・バス９１８へのディスク・ストレージ９２４の接続を容易にするために、インターフェイス９２６などの、取り外し可能または取り外し不可能なインターフェイスが通常は使用される。図９は、ユーザと、適切な動作環境９００において説明された基本的なコンピュータ・リソースとの間の仲介として機能するソフトウェアも示している。そのようなソフトウェアは、例えば、オペレーティング・システム９２８を含むこともできる。ディスク・ストレージ９２４に格納できるオペレーティング・システム９２８は、コンピュータ９１２のリソースを制御し、割り当てるように動作する。システムのアプリケーション９３０は、例えばシステム・メモリ９１６またはディスク・ストレージ９２４のいずれかに格納されたプログラム・モジュール９３２およびプログラム・データ９３４を介して、オペレーティング・システム９２８によるリソースの管理を利用する。さまざまなオペレーティング・システムまたはオペレーティング・システムの組み合わせを使用して本開示が実装され得るということが、認識されるべきである。ユーザは、入力デバイス９３６を介して、コマンドまたは情報をコンピュータ９１２に入力する。入力デバイス９３６は、マウス、トラックボール、スタイラス、タッチ・パッド、キーボード、マイクロホン、ジョイスティック、ゲーム・パッド、衛星放送受信アンテナ、スキャナ、ＴＶチューナー・カード、デジタル・カメラ、デジタル・ビデオ・カメラ、Ｗｅｂカメラなどのポインティング・デバイスを含むが、これらに限定されない。これらおよびその他の入力デバイスは、インターフェイス・ポート９３８を介してシステム・バス９１８を通り、処理ユニット９１４に接続する。インターフェイス・ポート９３８は、例えば、シリアル・ポート、パラレル・ポート、ゲーム・ポート、およびユニバーサル・シリアル・バス（ＵＳＢ）を含む。出力デバイス９４０は、入力デバイス９３６と同じ種類のポートの一部を使用する。このようにして、例えば、ＵＳＢポートを使用して、入力をコンピュータ９１２に提供し、コンピュータ９１２から出力デバイス９４０に情報を出力できる。出力アダプタ９４２は、特殊なアダプタを必要とする出力デバイス９４０の中でも特に、モニタ、スピーカ、およびプリンタのような何らかの出力デバイス９４０が存在することを示すために提供される。出力アダプタ９４２の例としては、出力デバイス９４０とシステム・バス９１８の間の接続の方法を提供するビデオ・カードおよびサウンド・カードが挙げられるが、これらに限定されない。リモート・コンピュータ９４４などの、その他のデバイスまたはデバイスのシステムが、入力機能および出力機能の両方を提供するということに、注意するべきである。

コンピュータ９１２は、リモート・コンピュータ９４４などの１つまたは複数のリモート・コンピュータへの論理接続を使用して、ネットワーク環境内で動作できる。リモート・コンピュータ９４４は、コンピュータ、サーバ、ルータ、ネットワークＰＣ、ワークステーション、マイクロプロセッサベースの機器、ピア・デバイス、またはその他の一般的なネットワーク・ノードなどであることができ、通常は、コンピュータ９１２に関連して説明された要素の多くまたはすべてを含むこともできる。簡潔にするために、メモリ・ストレージ・デバイス９４６のみが、リモート・コンピュータ９４４と共に示されている。リモート・コンピュータ９４４は、ネットワーク・インターフェイス９４８を介してコンピュータ９１２に論理的に接続されてから、通信接続９５０を介して物理的に接続される。ネットワーク・インターフェイス９４８は、ローカル・エリア・ネットワーク（ＬＡＮ：local-area network）、広域ネットワーク（ＷＡＮ：wide-area network）、セルラー・ネットワークなどの、有線通信ネットワークまたは無線通信ネットワークを包含する。ＬＡＮ技術は、光ファイバ分散データ・インターフェイス（ＦＤＤＩ：Fiber Distributed Data Interface）、銅線分散データ・インターフェイス（ＣＤＤＩ：Copper Distributed Data Interface）、イーサネット（登録商標）、トークン・リングなどを含む。ＷＡＮ技術は、ポイントツーポイント・リンク、総合デジタル通信網（ＩＳＤＮ：Integrated Services Digital Network）およびその変形などの回路交換網、パケット交換網、およびデジタル加入者回線（ＤＳＬ：Digital Subscriber Line）を含むが、これらに限定されない。通信接続９５０は、ネットワーク・インターフェイス９４８をシステム・バス９１８に接続するために採用されたハードウェア／ソフトウェアのことを指す。通信接続９５０は、説明を明確にするために、コンピュータ９１２内に示されているが、コンピュータ９１２の外部に存在することもできる。ネットワーク・インターフェイス９４８に接続するためのハードウェア／ソフトウェアは、単に例示の目的で、通常の電話の等級のモデム、ケーブル・モデム、およびＤＳＬモデムを含むモデム、ＩＳＤＮアダプタ、ならびにイーサネット（登録商標）・カードなどの、内部および外部の技術を含むこともできる。

Claims (25)

1. コンピュータ実行可能コンポーネントを格納するメモリと、
   前記メモリに動作可能なように結合され、コンピュータ実行可能コンポーネントを実行するプロセッサとを備えているシステムであって、前記コンピュータ実行可能コンポーネントが、
   コンピューティング・プラットフォームに関連付けられたワークロードを識別するパッチ識別コンポーネントであって、前記ワークロードが、パッチの第１のサブセットが実行される第１のワークロード部分を含む、前記パッチ識別コンポーネントと、
   前記パッチの第１のサブセットのパッチの脆弱性スコアに基づいて保守時間ウィンドウ内で前記第１のワークロード部分の一部に対して実行するためのパッチの第２のサブセットを決定するパッチ管理コンポーネントであって、前記パッチの第１のサブセットが、前記パッチの第２のサブセットを含む、前記パッチ管理コンポーネントとを含む、システム。
2. 前記パッチ識別コンポーネントが、パッチのセットに関連付けられた前記ワークロードを識別し、前記ワークロードが前記第１のワークロード部分および第２のワークロード部分を含み、前記パッチのセットが、前記パッチの第２のサブセットを含んでいる前記パッチの第１のサブセットを含み、かつパッチの第３のサブセットを含み、前記パッチ管理コンポーネントが、前記第２のワークロード部分に対して実行するための前記パッチの第３のサブセットを決定する、請求項１に記載のシステム。
3. 前記コンピューティング・プラットフォームがクラウドベースのコンピューティング・プラットフォームであり、前記コンピュータ実行可能コンポーネントが、前記クラウドベースのコンピューティング・プラットフォームの前記第１のワークロード部分がオフラインであるときに、前記保守時間ウィンドウ内で前記第１のワークロード部分の前記一部に対して前記パッチの第２のサブセットを実行し、前記クラウドベースのコンピューティング・プラットフォームの前記第２のワークロード部分がオンラインであるときに、前記第２のワークロード部分に対して前記パッチの第３のサブセットを実行する、パッチ実行コンポーネントを含む、請求項２に記載のシステム。
4. 前記パッチ実行コンポーネントが、前記パッチの前記第２のサブセットの前記パッチの少なくとも一部を同時に実行し、前記クラウドベースのコンピューティング・プラットフォームがノードおよびリソースを備え、前記ノードが、前記第１のワークロード部分の第１の層に関連付けられた第１のノードおよび前記第１のワークロード部分の第２の層に関連付けられた第２のノードを含み、前記第２のノードが前記第１のノードに依存する、請求項３に記載のシステム。
5. 前記クラウドベースのコンピューティング・プラットフォームがノードおよびリソースを備え、前記パッチ管理コンポーネントが、前記クラウドベースのコンピューティング・プラットフォームの前記ノードにわたる依存関係の決定を含めて、前記ワークロードのトポロジーを決定し、前記トポロジーに基づいて、前記第１のワークロード部分に対する前記パッチの前記第２のサブセットの実行のトポロジー的順序を決定し、前記パッチ実行コンポーネントが、前記トポロジー的順序に従って前記パッチの前記第２のサブセットの前記パッチを実行する、請求項３に記載のシステム。
6. 前記パッチ実行コンポーネントが、少なくとも前記パッチの第３のサブセットの別のパッチと同時に、少なくとも前記パッチの第２のサブセットのパッチを実行する、請求項３に記載のシステム。
7. 前記保守時間ウィンドウが、前記コンピューティング・プラットフォームの、前記第１のワークロード部分に関連付けられたノードおよびリソースがオフラインである期間である、請求項１に記載のシステム。
8. 前記パッチ管理コンポーネントが、前記パッチの重要性の定義されたレベルに基づいて前記第１のワークロード部分に関連付けられた前記パッチの第１のサブセットの前記パッチの前記脆弱性スコアを決定し、前記パッチの第２のサブセットがパッチの他のサブセットの他の全体的脆弱性スコアよりも高い全体的脆弱性スコアを有するということの決定に基づいて、前記パッチの第２のサブセットを決定する、請求項１に記載のシステム。
9. 前記コンピューティング・プラットフォームがノードおよびリソースを備え、前記ノードのうちのノードが、仮想マシン、物理マシン、およびコンテナから成るノードのグループから選択され、前記パッチのうちの第１のパッチが前記仮想マシンの仮想マシン・インスタンスに対して実行され、前記パッチのうちの第２のパッチが前記物理マシンの物理マシン・インスタンスに対して実行され、前記パッチのうちの第３のパッチが前記コンテナのコンテナ・イメージに対して実行される、請求項１に記載のシステム。
10. 前記パッチ管理コンポーネントが、前記パッチの第２のサブセットに関連付けられたノードおよびリソースの動作を一時停止し、前記コンピュータ実行可能コンポーネントが、前記動作の前記一時停止に応答して前記ノードおよび前記リソースに対して前記パッチの第２のサブセットを実行するパッチ実行コンポーネントを含み、前記パッチ管理コンポーネントが、前記パッチの第２のサブセットが正常に実行されたことの妥当性を確認し、前記パッチの第２のサブセットが正常に実行されたことの前記妥当性確認に応答して、前記ノードおよび前記リソースの前記動作を再開する、請求項１に記載のシステム。
11. 前記パッチ管理コンポーネントが、前記パッチの第２のサブセットのパッチがアプリケーションに対して実行されたことに応答して、前記アプリケーションが定義された正常な動作状態にあるかどうかをテストし、前記アプリケーションが前記定義された正常な動作状態にないということの決定に応答して、前記パッチ管理コンポーネントが、前記保守時間ウィンドウ内で前記アプリケーションに対する前記パッチの実施を取り消し、前記アプリケーションを、前記アプリケーションに対する前記パッチの前記実行前に存在した前の状態に戻す、請求項１に記載のシステム。
12. 前記コンピューティング・プラットフォームがハイブリッド・クラウドベースのコンピューティング・プラットフォームであり、前記ワークロードが、複数のディメンションに広がり、クラウドベースのコンピューティング・サブプラットフォームの数、オペレーティング・システムの数、クラウド・デプロイメント・モデルの種類、リソースのデプロイメントの種類、ワークロードの種類、ワークロードの実行の頻度、ならびに開発および運用プロセスから成る前記ハイブリッド・クラウドベースのコンピューティング・プラットフォームの特性のグループから選択された特性に関連するハイブリッド・ワークロードである、請求項１に記載のシステム。
13. 前記パッチ管理コンポーネントが、前記保守時間ウィンドウの間に実行されなかった適用されていないパッチを識別し、前記適用されていないパッチの少なくとも一部を実行するための次の保守時間ウィンドウを決定する、請求項１に記載のシステム。
14. プロセッサに動作可能なように結合されたシステムによって、コンピューティング・プラットフォームに関連付けられたワークロードを決定することであって、前記ワークロードが、パッチの第１のサブセットが実行される第１のワークロード部分を含む、前記決定することと、
    前記システムによって、前記パッチの第１のサブセットのパッチの脆弱性スコアに基づいて保守時間ウィンドウ内で前記第１のワークロード部分の一部に適用するためのパッチの第２のサブセットを決定することであって、前記パッチの第１のサブセットが前記パッチの第２のサブセットを含む、前記決定することとを含む、コンピュータ実装方法。
15. 前記ワークロードが前記第１のワークロード部分および第２のワークロード部分を含み、前記ワークロードを前記決定することが、パッチのセットに関連付けられた前記ワークロードを決定することを含み、前記パッチのセットが、前記パッチの第２のサブセットを含んでいる前記パッチの第１のサブセットを含み、かつパッチの第３のサブセットを含み、前記方法が、前記システムによって、前記第２のワークロード部分に適用するための前記パッチの第３のサブセットを決定することをさらに含む、請求項１４に記載のコンピュータ実装方法。
16. 前記コンピューティング・プラットフォームがクラウドベースのコンピューティング・プラットフォームであり、前記方法が、
    前記システムによって、前記クラウドベースのコンピューティング・プラットフォームの前記第１のワークロード部分の少なくとも一部がオフラインであるときに、前記保守時間ウィンドウ内で前記パッチの第２のサブセットを前記第１のワークロード部分の前記一部に適用することであって、前記第２のサブセットのパッチのうちの第１のパッチおよび第２のパッチが並列に適用され、前記保守時間ウィンドウが、前記クラウドベースのコンピューティング・プラットフォームの、前記第１のワークロード部分に関連付けられたノードおよびリソースがオフラインである期間である、前記適用することと、
    前記システムによって、前記クラウドベースのコンピューティング・プラットフォームの前記第２のワークロード部分がオンラインであるときに、前記パッチの第３のサブセットを前記第２のワークロード部分に適用することであって、前記パッチの第３のサブセットの第３のパッチおよび前記第１のパッチが並列に適用される、前記適用することとをさらに含む、請求項１５に記載のコンピュータ実装方法。
17. 前記システムによって、前記パッチの脆弱性の定義されたレベルに基づいて前記第１のワークロード部分に関連付けられた前記パッチの第１のサブセットの前記パッチの前記脆弱性スコアを決定することと、
    前記システムによって、前記パッチの第２のサブセットが、パッチの他のサブセットの他の合計脆弱性スコアよりも高い合計脆弱性スコアを有するということを決定することであって、前記保守時間ウィンドウ内で前記第１のワークロード部分の前記一部に適用するための前記パッチの第２のサブセットを前記決定することが、前記パッチの第２のサブセットが前記より高い合計脆弱性スコアを有するということの前記決定に基づいて前記パッチの第２のサブセットを決定することを含む、前記決定することとをさらに含む、請求項１４に記載のコンピュータ実装方法。
18. 前記システムによって、前記パッチの第２のサブセットに関連付けられたノードおよびリソースの動作を一時停止することと、
    前記システムによって、前記動作の前記一時停止に応答して前記パッチの第２のサブセットを前記ノードおよび前記リソースに適用することと、
    前記システムによって、前記パッチの第２のサブセットが前記ノードおよび前記リソースに正常に適用されたことを検証することと、
    前記パッチの第２のサブセットが前記ノードおよび前記リソースに正常に適用されたことの前記検証に応答して、前記システムによって前記ノードおよび前記リソースの前記動作を再開することとをさらに含む、請求項１４に記載のコンピュータ実装方法。
19. 前記パッチの第２のサブセットのパッチがアプリケーションに対して適用されたことに応答して、前記システムによって、前記アプリケーションが定義された使用可能な動作状態にあるかどうかを決定するためのテストを実行することと、
    前記アプリケーションが前記定義された使用可能な動作状態にないということの決定に応答して、前記保守時間ウィンドウ内で、前記システムによって、前記アプリケーションに対する前記パッチの実施を取り消し、前記アプリケーションを、前記アプリケーションに対して前記パッチを前記適用する前に存在した前の状態に戻すこととをさらに含む、請求項１４に記載のコンピュータ実装方法。
20. コンピューティング・プラットフォームに対するパッチ適用を管理することを容易にするコンピュータ・プログラム製品であって、前記コンピュータ・プログラム製品が、プログラム命令が具現化されているコンピュータ可読ストレージ媒体を備え、前記プログラム命令が、プロセッサに、
    前記コンピューティング・プラットフォームに関連付けられたワークロードを決定することであって、前記ワークロードが、パッチの第１のサブセットが実行される第１のワークロード部分を含む、前記決定することと、
    前記パッチの第１のサブセットのパッチの脆弱性スコアに基づいてダウンタイム・ウィンドウ内で前記第１のワークロード部分の一部に適用するためのパッチの第２のサブセットを決定することであって、前記パッチの第１のサブセットが前記パッチの第２のサブセットを含む、前記決定することとを実行させるように、前記プロセッサによって実行可能である、コンピュータ・プログラム製品。
21. 前記ワークロードが前記第１のワークロード部分および第２のワークロード部分を含み、前記ワークロードを前記決定することが、パッチのセットに関連付けられた前記ワークロードを決定することを含み、前記パッチのセットが、前記パッチの第２のサブセットを含んでいる前記パッチの第１のサブセットを含み、かつパッチの第３のサブセットを含み、前記コンピューティング・プラットフォームがクラウドベースのコンピューティング・プラットフォームであり、前記プログラム命令が、前記プロセッサに、
    前記第２のワークロード部分に適用するための前記パッチの第３のサブセットを決定することと、
    前記クラウドベースのコンピューティング・プラットフォームの前記第１のワークロード部分の少なくとも一部がオフラインであるときに、前記ダウンタイム・ウィンドウ内で前記パッチの第２のサブセットを前記第１のワークロード部分の前記一部に適用することであって、前記第２のサブセットのパッチのうちの第１のパッチおよび第２のパッチが同時に適用され、前記ダウンタイム・ウィンドウが、前記クラウドベースのコンピューティング・プラットフォームの、前記第１のワークロード部分に関連付けられたノードおよびリソースがオフラインである期間である、前記適用することと、
    前記クラウドベースのコンピューティング・プラットフォームの前記第２のワークロード部分がオンラインであるときに、前記パッチの第３のサブセットを前記第２のワークロード部分に適用することであって、前記パッチの第３のサブセットの第３のパッチおよび前記第１のパッチが同時に適用される、前記適用することとを実行させるように、前記プロセッサによって実行可能である、請求項２０に記載のコンピュータ・プログラム製品。
22. コンピュータ実行可能コンポーネントを格納するメモリと、
    前記メモリに動作可能なように結合され、コンピュータ実行可能コンポーネントを実行するプロセッサとを備えているシステムであって、前記コンピュータ実行可能コンポーネントが、
    コンピューティング・プラットフォームに関連付けられたワークロードを識別する更新識別コンポーネントであって、前記ワークロードが、更新の第１のサブセットが実行される第１のワークロード部分および更新の第２のサブセットが実行される第２のワークロード部分を含む、前記更新識別コンポーネントと、
    前記第１のワークロード部分に関連付けられた前記更新の第１のサブセットの更新の脆弱性スコアに基づいて保守期間内に前記第１のワークロード部分の一部に適用するための更新の第３のサブセットを決定する更新管理コンポーネントであって、前記更新の第１のサブセットが前記更新の第３のサブセットを含む、前記更新管理コンポーネントとを含む、システム。
23. 前記更新識別コンポーネントが更新のセットに関連付けられた前記ワークロードを識別し、前記更新のセットが、前記更新の第３のサブセットを含んでいる前記更新の第１のサブセットを含み、かつ前記更新の第２のサブセットを含み、前記コンピューティング・プラットフォームがハイブリッド・クラウドベースのコンピューティング・プラットフォームであり、前記コンピュータ実行可能コンポーネントが、前記ハイブリッド・クラウドベースのコンピューティング・プラットフォームの前記第１のワークロード部分の少なくとも一部がオフラインであるときに前記保守期間内で前記更新の第３のサブセットを前記第１のワークロード部分に適用し、前記ハイブリッド・クラウドベースのコンピューティング・プラットフォームの前記第２のワークロード部分がオンラインであるときに前記更新の第２のサブセットを前記第２のワークロード部分に適用する、更新実行コンポーネントを含む、請求項２２に記載のシステム。
24. コンピューティング・プラットフォームの更新を管理することを容易にするコンピュータ・プログラム製品であって、前記コンピュータ・プログラム製品が、プログラム命令が具現化されているコンピュータ可読ストレージ媒体を備え、前記プログラム命令が、プロセッサに、
    コンピューティング・プラットフォームに関連付けられたワークロードを識別することであって、前記ワークロードが、更新の第１のサブセットが実行される第１のワークロード部分および更新の第２のサブセットが実行される第２のワークロード部分を含む、前記識別することと、
    前記第１のワークロード部分に関連付けられた前記更新の第１のサブセットの更新の脆弱性スコアに基づいてオフラインの保守期間内に前記第１のワークロード部分の一部に適用するための更新の第３のサブセットを決定することであって、前記更新の第１のサブセットが前記更新の第３のサブセットを含む、前記決定することとを実行させるように、前記プロセッサによって実行可能である、コンピュータ・プログラム製品。
25. 前記コンピューティング・プラットフォームがハイブリッド・クラウドベースのコンピューティング・プラットフォームであり、前記ワークロードを前記識別することが、更新のセットに関連付けられた前記ワークロードを識別することを含み、前記更新のセットが、前記更新の第３のサブセットを含んでいる前記更新の第１のサブセットを含み、かつ前記更新の第２のサブセットを含み、前記プログラム命令が、前記プロセッサに、
    前記ハイブリッド・クラウドベースのコンピューティング・プラットフォームの前記第１のワークロード部分の少なくとも一部がオフラインであるときに、前記オフラインの保守期間内に前記更新の第３のサブセットを前記第１のワークロード部分に適用することと、
    前記ハイブリッド・クラウドベースのコンピューティング・プラットフォームの前記第２のワークロード部分がオンラインであるときに、前記更新の第２のサブセットを前記オンラインのワークロードに適用することとを実行させるように、前記プロセッサによって実行可能である、請求項２４に記載のコンピュータ・プログラム製品。
    

Images