翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
OPS02-BP05 追加、変更、例外をリクエストするメカニズムが存在する
プロセス、手順、およびリソースの所有者にリクエストを送信できます。リクエストには、追加、変更、除外などがあります。このようなリクエストは変更管理プロセスを通ります。メリットとリスクを評価した後、実行可能かつ適切であると判断したリクエストを、十分な情報に基づいて承認します。
期待される成果:
-
割り当てられた所有権に基づいて、プロセス、手順、リソースの変更をリクエストできます。
-
変更は、メリットとリスクを検討し、熟考のうえで行われます。
一般的なアンチパターン:
-
アプリケーションをデプロイする方法を更新しなければならないが、オペレーションチームからデプロイプロセスの変更をリクエストする方法がない。
-
ディザスタリカバリ計画を更新しなければならないが、変更のリクエスト先になる特定できる所有者がいない。
このベストプラクティスを活用するメリット:
-
プロセス、手順、リソースを、要件の変更に合わせて進化させることができます。
-
所有者は、十分な情報に基づいて変更時期を決定できます。
-
変更は熟考のうえで行われます。
このベストプラクティスを活用しない場合のリスクレベル: 中
実装のガイダンス
このベストプラクティスを実装するには、プロセス、手順、リソースに対する変更のリクエストが可能である必要があります。変更管理プロセスは簡単なもので構いません。変更管理プロセスを文書化します。
お客様事例
AnyCompany 小売は責任割り当て (RACI) マトリックスを使用して、プロセス、手順、リソースの変更の所有者を特定します。文書化された変更管理プロセスは、簡単で従いやすいものです。RACI マトリックスとプロセスを使用すると、誰でも変更リクエストを送信できます。
実装手順
-
ワークロードのプロセス、手順、リソースと、それぞれの所有者を特定します。ナレッジマネジメントシステムにそれらを記録します。
-
OPS02-BP01 リソースが所有者を特定しました、OPS02-BP02 プロセスと手順で所有者が特定されている または OPS02-BP03 オペレーションアクティビティで、パフォーマンスに責任がある所有者を特定しました を実装していない場合は、まずそれらから始めます。
-
-
組織の関係者と協力して、変更管理プロセスを策定します。このプロセスは、リソース、プロセス、手順の追加、変更、除外を対象とします。
-
AWS Systems Manager Change Manager は、ワークロードリソースの変更管理プラットフォームとして使用できます。
-
-
ナレッジマネジメントシステムに、変更管理プロセスを記録します。
実装計画に必要な工数レベル: 中 変更管理プロセスの策定では、組織全体の複数の関係者と協調する必要があります。
リソース
関連するベストプラクティス:
-
OPS02-BP01 リソースが所有者を特定しました - 変更管理プロセスを構築する前に、リソースに特定された所有者が必要です。
-
OPS02-BP02 プロセスと手順で所有者が特定されている - 変更管理プロセスを構築する前に、プロセスに特定された所有者が必要です。
-
OPS02-BP03 オペレーションアクティビティで、パフォーマンスに責任がある所有者を特定しました - 変更管理プロセスを構築する前に、オペレーションアクティビティに特定された所有者が必要です。
関連ドキュメント:
関連サービス:
