OPS02-BP03 パフォーマンスに責任を持つ所有者が運用アクティビティに存在する
定義されたワークロードに対して特定のアクティビティを実行する責任を持つ者と、その責任が存在する理由を理解します。運用アクティビティを実行することに責任を負うのが誰かを理解すると、アクティビティを実行する人物、結果を検証する人物、アクティビティの所有者にフィードバックを提供する人物を把握できます。
期待される成果:
組織において、定義されたワークロードで特定のアクティビティを実行し、そのワークロードによって生成されたイベントに対応する責任が明確に定義されています。組織は、プロセスの所有権と履行を文書化し、この情報を検出可能にしています。組織で変更があった場合は責任を見直して更新し、チームは欠点や非効率を特定するアクティビティのパフォーマンスを追跡して測定します。フィードバックメカニズムを実装して、欠点や改善を追跡し、反復的な改善をサポートします。
一般的なアンチパターン:
-
責任を文書化しない。
-
断片化されたスクリプトが、隔離されたオペレータワークステーションに分散している。一部の個人だけがスクリプトの使用方法を知っている、またはチーム内の知識として非公式に参照している。
-
レガシープロセスの更新が必要であるのに、プロセスの所有者が誰かを誰も把握しておらず、当初の作成者が既に組織を離れている。
-
プロセスとスクリプトが検出可能になっていないため、必要なとき (インシデントへの対応時など) にすぐに利用できない。
このベストプラクティスを活用するメリット:
-
アクティビティを実行する責任を持つのは誰か、アクションが必要なときに誰に通知すべきか、アクションを実行し、結果を検証してアクティビティの所有者にフィードバックを提供するのは誰かを理解できます。
-
プロセスと手順が整備されていると、ワークロードの運用努力の効果が上がります。
-
新しいチームメンバーがより早く成果を出せるようになります。
-
インシデントを軽減するための時間を短縮できます。
-
さまざまなチームが同じプロセスと手順を使用して、一貫した方法でタスクを実行できます。
-
繰り返し使用可能なプロセスを持つことで、チームがプロセスをスケールすることができます。
-
プロセスと手順が標準化されているため、チーム間でワークロードの責任を移転することによる影響を軽減できます。
このベストプラクティスを活用しない場合のリスクレベル: 高
実装のガイダンス
責任の定義を始めるには、まず責任マトリックス、プロセスと手順、ロールと責任、ツールとオートメーションなどの既存のドキュメントから始めます。文書化されたプロセスについて責任をレビューし、ディスカッションを設けます。複数のチームとレビューして、文書化されている責任とプロセスの間の不一致を特定します。提供されるサービスについてそのチームの内部顧客と話し合い、チーム間での期待事項のギャップを特定します。
相違点を分析して対処します。改善の機会を特定し、頻繁にリクエストされ、リソースを大量に消費するアクティビティを探します。こうしたアクティビティは、一般的に有力な改善候補と考えられます。改善を簡素化し標準化するためのベストプラクティス、パターン、規範ガイダンスを調べます。改善の機会を記録し、改善が完了するまで追跡します。
経時的に、これらの手順をコードとして実行できるよう変換し、人的介入の必要性を減らします。例えば、AWS Lambda 関数、AWS CloudFormation テンプレート、または AWS Systems Manager Automation ドキュメントとして手順を開始できます。これらの手順が適切なリポジトリでバージョン管理されていることを確認し、チームが所有者とドキュメントを簡単に特定できるように適切なリソースタグを付けます。アクティビティの実行責任を文書化し、オートメーションの正常な起動と稼働、期待される成果のパフォーマンスをモニタリングします。
お客様事例
AnyCompany Retail では、所有権を 1 つまたは (共通のアーキテクチャプラクティスとテクノロジーを共有する) 複数のアプリケーションのプロセスを所有するチームまたは個人と定義しています。同社は、最初にプロセスと手順をステップバイステップガイドとしてドキュメント管理システムに文書化しています。アプリケーションをホストする AWS アカウントと、アカウント内の特定のリソースグループのタグを使用して手順を検出可能にし、AWS Organizations を使用して AWS アカウントを管理しています。時間の経過に伴って、AnyCompany Retail はこれらのプロセスをコードに変換し、Infrastructure as Code を使用して (CloudFormation または AWS Cloud Development Kit (AWS CDK) テンプレートなどのサービスを通じて) リソースを定義します。運用プロセスは AWS Systems Manager または AWS Lambda 関数でオートメーションドキュメントとなります。これらの関数は、スケジュールされたタスクとして、Amazon CloudWatch アラームや Amazon EventBridge イベントなどのイベントへの応答として、または IT サービス管理 (ITSM) プラットフォーム内のリクエストによって起動できます。すべてのプロセスには、所有者を識別するタグが付いています。チームは、プロセスのコードリポジトリによって生成された Wiki ページ内で、オートメーションとプロセスのドキュメントを管理しています。
実装手順
-
既存のプロセスと手順を文書化します。
-
レビューを行い、最新の状態であることを確認します。
-
各プロセスまたは手順に所有者がいることを確認します。
-
手順をバージョン管理下に置きます。
-
可能な場合は、アーキテクチャ設計を共有するワークロードや環境全体でプロセスと手順を共有します。
-
-
フィードバックと改善のためのメカニズムを確立します。
-
プロセスをレビューする頻度に関するポリシーを定義します。
-
レビュー担当者と承認者用のプロセスを定義します。
-
フィードバックを提供して追跡するための問題やチケットキューを実装します。
-
プロセスと手順は、可能な限り、変更承認委員会 (CAB) による事前承認とリスク分類を受けます。
-
-
プロセスと手順を実行する必要がある人が、これにアクセスでき、検出できるようにします。
-
タグを使用して、ワークロードのプロセスと手順にアクセスできる場所を示します。
-
有意義なエラーやイベントのメッセージを活用して、問題に対処するための適切なプロセスや手順を示します。
-
Wiki またはドキュメント管理を使用して、プロセスと手順を組織全体で一貫して検索できるようにします。
-
-
適切である場合は自動化します。
-
サービスやテクノロジーが API を提供している場合は、オートメーションを開発します。
-
プロセスが十分に理解されていることを確認し、これらのプロセスを自動化するためのユーザーストーリーと要件を作成します。
-
プロセスと手順の適切な使用を評価し、問題を追跡して反復的な改善に役立てます。
-
実装計画に必要な工数レベル: 中
リソース
関連するベストプラクティス:
関連ドキュメント:
関連動画:
関連する例:
