OPS02-BP06 追加、変更、例外をリクエストするメカニズムが存在する - AWS Well-Architected Framework
実装のガイダンスリソース

OPS02-BP06 追加、変更、例外をリクエストするメカニズムが存在する

プロセス、手順、およびリソースの所有者にリクエストを送信できます。リクエストには、追加、変更、除外などがあります。このようなリクエストは変更管理プロセスを通ります。利点とリスクを評価した後、実行可能で適切であると判断されたリクエストを、十分な情報に基づいて承認します。

期待される成果:

  • 割り当てられた所有権に基づいて、プロセス、手順、リソースの変更をリクエストできます。

  • 変更は、メリットとリスクを検討して、熟考の上で行われます。

一般的なアンチパターン:

  • アプリケーションをデプロイする方法を更新しなければならないが、オペレーションチームからデプロイプロセスの変更をリクエストする方法がない。

  • ディザスタリカバリ計画を更新しなければならないが、変更のリクエスト先になる特定できる所有者がいない。

このベストプラクティスを活用するメリット:

  • プロセス、手順、リソースを、要件の変更に合わせて進化させることができます。

  • 所有者は十分な情報に基づいて変更時期を決定できます。

  • 変更は熟考の上で行われます。

このベストプラクティスが確立されていない場合のリスクレベル: 中

実装のガイダンス

このベストプラクティスを実装するには、プロセス、手順、リソースに対する変更のリクエストが可能である必要があります。変更管理プロセスは簡単なものでかまいません。変更管理プロセスを文書化します。

お客様事例

AnyCompany Retail は責任割り当て (RACI) マトリックスを使用して、プロセス、手順、リソースの変更を所有しているのが誰かを特定しています。文書化された変更管理プロセスは、簡単で従いやすいものです。RACI マトリックスとこのプロセスを使用して、誰でも変更リクエストを送信できます。

実装手順

  1. ワークロードのプロセス、手順、リソースと、それぞれの所有者を特定します。ナレッジマネジメントシステムにそれらを記録します。

    1. OPS02-BP01 リソースには特定の所有者が存在する、OPS02-BP02 プロセスと手順には特定の所有者が存在する、または OPS02-BP03 パフォーマンスに責任を持つ所有者が運用アクティビティに存在する を実装していない場合は、先に実装します。

  2. 組織の関係者と協力して、変更管理プロセスを作成します。このプロセスは、リソース、プロセス、手順の追加、変更、除外を対象とします。

    1. AWS Systems Manager Change Manager を、ワークロードリソースの変更管理プラットフォームとして使用できます。

  3. ナレッジマネジメントシステムに、変更管理プロセスを記録します。

実装計画に必要な工数レベル: 中。変更管理プロセスの作成では、組織全体の複数の関係者と協調する必要があります。

リソース

関連するベストプラクティス:

関連するドキュメント:

関連サービス: