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