

# 進化
<a name="a-evolve"></a>

**Topics**
+ [OPS 11. 運用はどのように進化させるのですか?](ops-11.md)

# OPS 11. 運用はどのように進化させるのですか?
<a name="ops-11"></a>

 ほぼ継続的で漸進的な改善に時間とリソースを費やすことで、オペレーションの効果と効率を進化させることができます。

**Topics**
+ [OPS11-BP01 継続的改善のプロセスを用意する](ops_evolve_ops_process_cont_imp.md)
+ [OPS11-BP02 インシデント後の分析を実行する](ops_evolve_ops_perform_rca_process.md)
+ [OPS11-BP03 フィードバックループを実装する](ops_evolve_ops_feedback_loops.md)
+ [OPS11-BP04 ナレッジ管理を実施する](ops_evolve_ops_knowledge_management.md)
+ [OPS11-BP05 改善の推進要因を定義する](ops_evolve_ops_drivers_for_imp.md)
+ [OPS11-BP06 インサイトを検証する](ops_evolve_ops_validate_insights.md)
+ [OPS11-BP07 オペレーションメトリクスのレビューを実行する](ops_evolve_ops_metrics_review.md)
+ [OPS11-BP08 教訓を文書化して共有する](ops_evolve_ops_share_lessons_learned.md)
+ [OPS11-BP09 改善を行うための時間を割り当てる](ops_evolve_ops_allocate_time_for_imp.md)

# OPS11-BP01 継続的改善のプロセスを用意する
<a name="ops_evolve_ops_process_cont_imp"></a>

 ワークロードを社内外のアーキテクチャのベストプラクティスに対して評価します。頻繁かつ意図的なワークロードレビューを実施します。ソフトウェア開発サイクルの中で改善の機会を優先事項にします。

 **期待される成果:** 
+  アーキテクチャのベストプラクティスに対してワークロードを頻繁に分析します。
+  ソフトウェア開発プロセスにおいて、新機能の開発と改善の機会に同程度の優先順位を与えます。

 **一般的なアンチパターン:** 
+  ワークロードを数年前にデプロイして以来、アーキテクチャレビューを実施していない。
+  改善の機会の優先順位が低い。新機能と比較して、これらの機会は未処理のままである。
+  組織のベストプラクティスに対する変更の実装について基準がない。

 **このベストプラクティスを活用するメリット:** 
+  ワークロードがアーキテクチャのベストプラクティスに準拠した最新の状態に保たれます。
+  ワークロードを意図を持って進化させることができます。
+  組織のベストプラクティスを活用して、すべてのワークロードを改善できます。
+  わずかなメリットが累積的な影響をもたらし、効率性の向上につながります。

 **このベストプラクティスを活用しない場合のリスクレベル:** 高 

## 実装のガイダンス
<a name="implementation-guidance"></a>

 ワークロードの構造的レビューを頻繁に実施します。社内外のベストプラクティスを使用してワークロードを評価し、改善の機会を特定します。ソフトウェア開発サイクルの中で改善の機会を優先事項にします。

### 実装手順
<a name="implementation-steps"></a>

1.  合意された頻度で、本稼働ワークロードの定期的なアーキテクチャレビューを実施します。AWS 固有のベストプラクティスを含む文書化された構造基準を使用します。

   1.  これらのレビューには、社内で定義された基準を使用します。社内基準がない場合は、AWS Well-Architected フレームワークを使用します。

   1.  AWS Well-Architected Tool を使用して社内ベストプラクティスのカスタムレンズを作成し、アーキテクチャレビューを実施します。

   1.  AWS ソリューションアーキテクトまたはテクニカルアカウントマネージャーに連絡して、ワークロードのガイド付き Well-Architected Framework レビューを実施します。

1.  レビュー中に特定された改善機会を、ソフトウェア開発プロセスの中で優先事項に設定します。

 **実装計画に必要な工数レベル:** 低 AWS Well-Architected フレームワークを使用して年次のアーキテクチャレビューを実施できます。

## リソース
<a name="resources"></a>

 **関連するベストプラクティス:** 
+  [OPS11-BP02 インシデント後の分析を実行する](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_perform_rca_process.html) 
+  [OPS11-BP08 教訓を文書化して共有する](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_share_lessons_learned.html) 
+  [OPS04 オブザーバビリティを実装する](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_process_cont_imp.html) 

 **関連ドキュメント:** 
+  [AWS Well-Architected Tool - カスタムレンズ](https://docs.aws.amazon.com/wellarchitected/latest/userguide/lenses-custom.html) 
+  [AWS Well-Architected ホワイトペーパー - レビュープロセス](https://docs.aws.amazon.com/wellarchitected/latest/framework/the-review-process.html) 
+  [カスタムレンズと AWS Well-Architected Tool で Well-Architected レビューをカスタマイズする](https://aws.amazon.com/blogs/mt/customize-well-architected-reviews-using-custom-lenses-and-the-aws-well-architected-tool/) 
+  [AWS Well-Architected カスタムレンズライフサイクルを組織に実装する](https://aws.amazon.com/blogs/architecture/implementing-the-aws-well-architected-custom-lens-lifecycle-in-your-organization/) 

 **関連動画:** 
+  [AWS re:Invent 2023 - Scaling AWS Well-Architected best practices across your organization](https://youtu.be/UXtZCoE9qfQ?si=OPATCOY2YAwiF2TS) 

 **関連する例:** 
+  [AWS Well-Architected Tool](https://docs.aws.amazon.com/wellarchitected/latest/userguide/intro.html) 

# OPS11-BP02 インシデント後の分析を実行する
<a name="ops_evolve_ops_perform_rca_process"></a>

 顧客に影響を与えるイベントを確認し、寄与する要因と予防措置を特定します。この情報を使用して、再発を制限または回避するための緩和策を開発します。迅速で効果的な対応のための手順を開発します。対象者に合わせて調整された、寄与因子と是正措置を必要に応じて伝えます。

 **期待される成果:** 
+  インシデント後の分析を含むインシデント管理プロセスが確立されます。
+  イベントに関するデータを収集するためのオブザーバビリティ計画が整います。
+  このデータから、インシデント後の分析プロセスを支えるメトリクスを理解し、収集できます。
+  インシデントから学び、その後の成果の向上につなげることができます。

 **一般的なアンチパターン:** 
+  アプリケーションサーバーを管理しています。約 23 時間 55 分ごとに、すべてのアクティブなセッションが終了します。あなたは、アプリケーションサーバーで何が問題なのかを特定しようとしました。あなたは、これがネットワークの問題である可能性があることを疑っていますが、ネットワークチームが忙しすぎてサポートを提供できないため、当該チームから協力を得ることができません。あなたには、サポートを得て、何が起こっているかを判断するために必要な情報を収集するための事前定義されたプロセスがありません。
+  あなたは、ワークロード内でデータを失ってしまいました。このような問題が発生したのはこれが最初であり、原因は明らかではありません。あなたは、データを再作成できるため、これが重要ではないと判断しています。データ損失は、顧客に影響するほどの高い頻度で発生し始めます。また、これにより、失われたデータの復元に際して、追加の運用上の負担も発生します。

 **このベストプラクティスを活用するメリット:** 
+  インシデントの原因となったコンポーネント、条件、アクション、イベントを決定する事前定義されたプロセスを持つことで、改善の機会を把握できます。
+  インシデント後の分析のデータを改善に役立てます。

 **このベストプラクティスを活用しない場合のリスクレベル:** 高 

## 実装のガイダンス
<a name="implementation-guidance"></a>

 プロセスを使用して、寄与した要因を判断します。顧客に影響を与えるすべてのインシデントを確認します。インシデントに寄与した要因を特定してドキュメント化するためのプロセスを用意しておき、再発を抑制または防止する緩和策と、迅速で効果的な対応手順を展開できるようにしておきます。インシデントの根本原因を適宜伝達し、伝える相手に合わせて伝え方を調整します。教訓を組織内で広く共有します。

### 実装手順
<a name="implementation-steps"></a>

1.  デプロイの変更、構成変更、インシデントの開始時刻、アラーム時刻、エンゲージメント時間、緩和開始時刻、インシデント解決時刻などのメトリクスを収集します。

1.  タイムライン上で重要な時点を特定し、インシデントの該当時点のイベントを把握します。

1.  次の質問について検討します。

   1.  検出までの時間を短縮できますか?

   1.  インシデントを早く検出するメトリクスとアラームの更新はありますか。

   1.  診断までの時間を短縮できますか?

   1.  対応計画またはエスカレーション計画の更新があり、正しい応答者をより早くエンゲージすることはありますか。

   1.  緩和までの時間を短縮できますか?

   1.  ランブックやプレイブックに追加または改善できる手順はありますか?

   1.  今後のインシデントの発生を防止できますか?

1.  チェックリストとアクションを作成します。すべてのアクションを追跡し、実行します。

 **実装計画に必要な工数レベル:** 中 

## リソース
<a name="resources"></a>

 **関連するベストプラクティス:** 
+  [OPS11-BP01 継続的改善のプロセスを用意する](ops_evolve_ops_process_cont_imp.md) 
+ [OPS 4 - オブザーバビリティを実装する](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/implement-observability.html)

 **関連ドキュメント:** 
+  [Incident Manager でのインシデント後分析の実行](https://docs.aws.amazon.com/incident-manager/latest/userguide/analysis.html) 
+  [運用準備状況レビュー](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/iteration.html) 

# OPS11-BP03 フィードバックループを実装する
<a name="ops_evolve_ops_feedback_loops"></a>

フィードバックループは、意思決定を推進するための実行可能なインサイトを提供します。フィードバックループを手順やワークロードに組み込みます。そうすることで、問題および改善すべき領域を特定することができます。またフィードバックループは、改善への投資を検証することもできます。これらのフィードバックループは、ワークロードの継続的な改善の基盤となります。

 フィードバックループは、即時フィードバックと遡及分析の 2 つのカテゴリに分類されます。即時フィードバックは、オペレーションアクティビティのパフォーマンスと結果のレビューをとおして収集されます。このフィードバックは、チームメンバー、顧客、またはアクティビティの自動出力から得られます。即時フィードバックは A/B テストや新機能のリリースなどからも得ることができ、フェイルファストにおいて不可欠なものです。

 遡及分析は定期的に実行され、オペレーションの結果とメトリクスの長期間にわたるレビューからフィードバックを取得します。これらの遡及分析は、スプリント、サイクル、またはメジャーリリースやイベントの完了時に行われます。このタイプのフィードバックループは、オペレーションまたはワークロードへの投資を検証でき、成果と戦略の計測に役立ちます。

 **期待される成果:** 即時フィードバックと遡及分析を使用して、改善を推進します。ユーザーやチームメンバーからのフィードバックを取得する仕組みがあります。遡及分析を使用して、改善を推進する傾向を特定します。

 **一般的なアンチパターン:** 
+ 新しい機能をローンチしたが、顧客からのフィードバックを得る方法はない。
+ オペレーションの改善に投資した後、遡及分析を行って投資を検証していない。
+ 顧客からのフィードバックを収集しているが、定期的にレビューしていない。
+ フィードバックループに基づいて提案されたアクション項目があるが、それらはソフトウェア開発プロセスに含まれていない。
+  顧客からの改善提案に対するフィードバックを行っていない。

 **このベストプラクティスを活用するメリット:** 
+  顧客の視点から新しい機能を推進することができる。
+  組織の文化をより迅速に変化させることができる。
+  傾向をレビューすることで、改善の機会を特定できる。
+  遡及分析によって、ワークロードやオペレーションへの投資を検証できる。

 **このベストプラクティスを活用しない場合のリスクレベル:** 高 

## 実装のガイダンス
<a name="implementation-guidance"></a>

 このベストプラクティスを採用すると、即時フィードバックと遡及分析の両方を使用することになります。これらのフィードバックループによって改善を推進します。即時フィードバックには、調査、顧客へのアンケート、フィードバックフォーラムなど、さまざまな仕組みがあります。また組織は、遡及分析を使用して改善の機会を特定し、取り組みを検証できます。

 **お客様事例** 

 AnyCompany Retail は、顧客がフィードバックを投稿したり、問題を報告したりすることができるウェブフォーラムを作成しました。週次会議では、ソフトウェア開発チームがユーザーからのフィードバックを評価します。プラットフォームの改善方針の決定のために、フィードバックは定期的に使用されます。各スプリントの完了時に遡及分析を実施して、改善する項目を特定します。

## 実装手順
<a name="implementation-steps"></a>

1. 即時フィードバック
   +  顧客やチームメンバーからフィードバックを得るための仕組みが必要です。また、オペレーションアクティビティを構成して、自動的にフィードバックを受信することもできます。
   +  組織にはフィードバックをレビューし、改善点を決定して、改善のスケジュールを策定するプロセスが必要です。
   +  フィードバックはソフトウェア開発プロセスに追加する必要があります。
   +  改善を進めるとともに、改善の提案者にフォローアップのフィードバックを行います。
     +  [AWS Systems Manager OpsCenter](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter.html) を使用することで、これらの改善を [OpsItems](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-working-with-OpsItems.html) として作成し追跡することができます。

1.  遡及分析 
   +  開発サイクル、定められたサイクル、またはメジャーリリースの完了時に遡及分析を実施します。
   +  ワークロードの関係者を集めて、遡及分析会議を行います。
   +  ホワイトボードまたはスプレッドシートに、停止、開始、維持の 3 つの列を作成します。
     +  停止は、チームの活動を停止する項目を指します。
     +  開始は、アイデアへの取り組みを開始する項目を指します。
     +  維持は、取り組みを維持する項目を指します。
   +  会議室内の関係者からフィードバックを収集します。
   +  フィードバックに優先順位を付けます。アクションと関係者を開始項目または維持項目に割り当てます。
   +  アクションをソフトウェア開発プロセスに追加し、改善を進めながら更新されたステータスを関係者に通知します。

 **実装計画に必要な工数レベル:** 中 このベストプラクティスを採用するには、即時フィードバックを収集し分析するプロセスが必要です。また、遡及分析プロセスを確立する必要もあります。

## リソース
<a name="resources"></a>

 **関連するベストプラクティス:** 
+  [OPS01-BP01 外部顧客のニーズを評価する](ops_priorities_ext_cust_needs.md): フィードバックループは、外部顧客のニーズを収集する仕組みです。
+  [OPS01-BP02 内部顧客のニーズを評価する](ops_priorities_int_cust_needs.md): 内部関係者は、フィードバックループを使用して、ニーズや要件を伝えることができます。
+  [OPS11-BP02 インシデント後の分析を実行する](ops_evolve_ops_perform_rca_process.md): 事後分析は、インシデント後に実施される重要な遡及分析の 1 つです。
+  [OPS11-BP07 オペレーションメトリクスのレビューを実行する](ops_evolve_ops_metrics_review.md): オペレーションメトリクスレビューでは、傾向および改善の領域を特定します。

 **関連ドキュメント:** 
+  [CCOE を構築するときに避けるべき 7 つの落とし穴](https://aws.amazon.com/blogs/enterprise-strategy/7-pitfalls-to-avoid-when-building-a-ccoe/) 
+  [Atlassian Team Playbook - Retrospectives](https://www.atlassian.com/team-playbook/plays/retrospective) 
+  [E メール定義: フィードバックループ](https://aws.amazon.com/blogs/messaging-and-targeting/email-definitions-feedback-loops/) 
+  [AWS Well-Architected フレームワークレビューに基づいたフィードバックループの確立](https://aws.amazon.com/blogs/architecture/establishing-feedback-loops-based-on-the-aws-well-architected-framework-review/) 
+  [IBM Garage Methodology - Hold a retrospective](https://www.ibm.com/garage/method/practices/learn/practice_retrospective_analysis/) 
+  [Investopedia – The PDCS Cycle](https://www.investopedia.com/terms/p/pdca-cycle.asp) 
+  [Maximizing Developer Effectiveness by Tim Cochran](https://martinfowler.com/articles/developer-effectiveness.html) 
+  [運用準備状況レビュー (ORR) ホワイトペーパー - イテレーション](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/iteration.html) 
+  [ITIL CSI - Continual Service Improvement](https://wiki.en.it-processmaps.com/index.php/ITIL_CSI_-_Continual_Service_Improvement)
+  [When Toyota met e-commerce: Lean at Amazon](https://www.mckinsey.com/capabilities/operations/our-insights/when-toyota-met-e-commerce-lean-at-amazon) 

 **関連動画:** 
+  [Building Effective Customer Feedback Loops](https://www.youtube.com/watch?v=zz_VImJRZ3U) 

 **関連する例:** 
+  [Astuto - Open source customer feedback tool](https://github.com/riggraz/astuto) 
+  [AWS ソリューション - QnABot on AWS](https://aws.amazon.com/solutions/implementations/qnabot-on-aws/) 
+  [Fider - A platform to organize customer feedback](https://github.com/getfider/fider) 

 **関連サービス:** 
+  [AWS Systems Manager OpsCenter](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter.html) 

# OPS11-BP04 ナレッジ管理を実施する
<a name="ops_evolve_ops_knowledge_management"></a>

ナレッジ管理は、チームメンバーが業務を遂行するために情報を検索する際に役立ちます。従業員の学びが促進される組織では、個人を支援する情報が自由に共有されています。情報は探索したり検索したりできます。情報は正確かつ最新の内容です。新しい情報を作成し、既存の情報を更新し、古い情報をアーカイブするメカニズムが存在します。ナレッジ管理プラットフォームの最も一般的な例は、wiki などのコンテンツ管理システムです。

 **期待される成果:** 
+  チームメンバーはタイムリーで正確な情報にアクセスできます。
+  情報は検索できます。
+  情報を追加、更新、アーカイブするメカニズムが導入されています。

 **一般的なアンチパターン:** 
+ 一元化されたナレッジストレージがありません。チームメンバーは、個人のローカルマシンで自分用のメモを管理しています。
+  組織でホストする Wiki はあっても、情報を管理するメカニズムがないため、情報が古くなっています。
+  不足する情報が特定されても、チームの wiki にその情報の追加を要請するプロセスがありません。チームが独自に情報を追加しても、重要なステップを見逃してしまい、使用停止につながります。

 **このベストプラクティスを活用するメリット:** 
+  情報が自由に共有されるため、チームメンバーに支援が行き届きます。
+  ドキュメントは最新の内容で検索可能であるため、新しいチームメンバーのオンボーディングがより迅速になります。
+  情報はタイムリーな内容で正確かつ実用的です。

 **このベストプラクティスを活用しない場合のリスクレベル:** 高 

## 実装のガイダンス
<a name="implementation-guidance"></a>

 ナレッジ管理は、従業員の学びが促進される組織の重要な側面です。まず、ナレッジを保存する中央リポジトリが必要です (一般的な例には、自己ホスト型の wiki があります)。ナレッジを追加、更新、アーカイブするためのプロセスを開発する必要があります。文書化すべき対象の基準を策定して、全チームメンバーが貢献できるプロセスを導入します。

 **お客様事例** 

 AnyCompany Retail では、社内 Wiki をホストして、すべてのナレッジを保存しています。チームメンバーには、日常業務を遂行する際にナレッジベースに情報を追加することが推奨されています。四半期ごとに、部門横断的なチームが、更新が最も少ないページを評価し、アーカイブまたは更新する必要があるかを判断しています。

 **実装手順** 

1.  まず、ナレッジを保存するコンテンツ管理システムを特定します。組織全体にわたるステークホルダーからの賛同を得ます。

   1.  既存のコンテンツ管理システムがない場合は、自己ホスト型の wiki を導入するか、バージョン管理リポジトリの導入から始めるかを検討します。

1.  情報を追加、更新、アーカイブするためのランブックを作成します。チームにこのプロセスについての教育を提供します。

1.  コンテンツ管理システムに保存すべきナレッジを特定します。チームメンバーが実行する日常業務のアクティビティ (ランブックとプレイブック) から始めます。ステークホルダーと協力して、追加するナレッジに優先順位を付けます。

1.  ステークホルダーと協力し、定期的に古い情報を特定し、アーカイブするか、最新の状態に更新します。

 **実装計画に必要な工数レベル:** 中 既存のコンテンツ管理システムがない場合は、自己ホスト型の wiki またはバージョン管理されたドキュメントリポジトリを設定することができます。

## リソース
<a name="resources"></a>

 **関連するベストプラクティス:** 
+  [OPS11-BP08 教訓を文書化して共有する](ops_evolve_ops_share_lessons_learned.md) - ナレッジ管理を行うと、学んだ教訓の情報共有が容易になります。

 **関連ドキュメント:** 
+ [ Atlassian - Knowledge Management ](https://www.atlassian.com/itsm/knowledge-management)

 **関連する例:** 
+ [DokuWiki](https://www.dokuwiki.org/dokuwiki)
+ [gollum](https://github.com/gollum/gollum)
+ [MediaWiki](https://www.mediawiki.org/wiki/MediaWiki)
+ [Wiki.js](https://github.com/Requarks/wiki)

# OPS11-BP05 改善の推進要因を定義する
<a name="ops_evolve_ops_drivers_for_imp"></a>

 データとフィードバックループに基づいて機会を評価して優先順位を設定できるよう、改善の推進要因を特定します。システムやプロセスの改善機会を探り、適切な場合は自動化します。

 **期待される成果:** 
+  環境全体のデータを追跡します。
+  イベントやアクティビティをビジネスの成果に関連付けます。
+  環境とシステムを比較対照できます。
+  デプロイと結果の詳細なアクティビティ履歴を管理できます。
+  セキュリティ体制をサポートするためのデータを収集します。

 **一般的なアンチパターン:** 
+  環境全体からデータを収集していますが、イベントとアクティビティの関連付けは行っていません。
+  資産全体から詳細なデータを収集しているため、Amazon CloudWatch および AWS CloudTrail のアクティビティとコストの増加につながっています。ただし、このデータを有意義に使用することはできていません。
+  改善の推進要因を定義する際、ビジネス成果を考慮していません。
+  新機能の効果は測定していません。

 **このベストプラクティスを活用するメリット:** 
+  改善の基準を決定することで、イベントベースのモチベーションや感情的投資の影響を最小限に抑えることができます。
+  技術的なイベントだけでなく、ビジネスイベントにも対応できます。
+  環境を測定して、改善すべき領域を特定します。

 **このベストプラクティスを活用しない場合のリスクレベル:** 中 

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  改善の推進要因を理解する: システムに変更を加えるのは、望まれている成果がサポートされているときだけにしてください。
  +  望まれている機能: 改善の機会を評価する際は、望まれている機能を評価してください。
    +  [AWS の最新情報](https://aws.amazon.com/new/) 
  +  許容できない問題: 改善の機会を評価する際は、許容できない問題、バグ、脆弱性を評価してください。適切なサイジングオプションを追跡し、最適化の機会を探します。
    +  [AWS セキュリティ速報](https://aws.amazon.com/security/security-bulletins/) 
    +  [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/) 
    +  [クラウドインテリジェンスダッシュボード](https://www.wellarchitectedlabs.com/cloud-intelligence-dashboards/) 
  +  コンプライアンスの要件: 改善の機会を確認する際は、規制/ポリシー遵守の維持、またはサードパーティーによるサポートの維持に必要な更新と変更を評価します。
    +  [AWS コンプライアンス](https://aws.amazon.com/compliance/) 
    +  [AWS Compliance Programs](https://aws.amazon.com/compliance/programs/) 
    +  [AWS コンプライアンスの最新情報](https://aws.amazon.com/compliance/compliance-latest-news/) 

## リソース
<a name="resources"></a>

 **関連するベストプラクティス:** 
+  [OPS01 組織の優先順位](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/organization-priorities.html) 
+  [OPS02 関係性と所有権](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/relationships-and-ownership.html) 
+  [OPS04-BP01 主要業績評価指標を特定する](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_observability_identify_kpis.html) 
+  [OPS08 ワークロードのオブザーバビリティの活用](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/utilizing-workload-observability.html) 
+  [OPS09 運用状態の把握](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/understanding-operational-health.html) 
+  [OPS11-BP03 フィードバックループを実装する](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_feedback_loops.html) 

 **関連ドキュメント:** 
+  [ Amazon Athena](https://aws.amazon.com/athena/?whats-new-cards.sort-by=item.additionalFields.postDateTime&whats-new-cards.sort-order=desc) 
+  [Quick](https://aws.amazon.com/quicksight/) 
+  [AWS コンプライアンス](https://aws.amazon.com/compliance/) 
+  [AWS コンプライアンスの最新情報](https://aws.amazon.com/compliance/compliance-latest-news/) 
+  [AWS Compliance Programs](https://aws.amazon.com/compliance/programs/) 
+  [AWS Glue](https://aws.amazon.com/glue/?whats-new-cards.sort-by=item.additionalFields.postDateTime&whats-new-cards.sort-order=desc) 
+  [AWS セキュリティ速報](https://aws.amazon.com/security/security-bulletins/) 
+  [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/) 
+  [Export your log data to Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3Export.html) 
+  [AWS の最新情報](https://aws.amazon.com/new/) 
+  [顧客中心のイノベーションの必要性](https://aws.amazon.com/executive-insights/content/the-imperatives-of-customer-centric-innovation/) 
+  [デジタルトランスフォーメーション: 誇大広告? それとも戦略的必然?](https://aws.amazon.com/blogs/enterprise-strategy/digital-transformation-hype-or-a-strategic-necessity/)

 **関連動画** 
+  [AWS re:Invent 2023 - Improve operational efficiency and resilience with サポート (SUP310)](https://youtu.be/jaehZYBNG0Y?si=UNEaLZsXDrxcBgYo) 

# OPS11-BP06 インサイトを検証する
<a name="ops_evolve_ops_validate_insights"></a>

 分析結果を確認して部門横断的なチームやビジネスオーナーで応答します。これらのレビューに基づいて共通の理解を確立し、追加的な影響を特定するとともに、一連のアクションを決定します。必要に応じて対応を調整してください。

 **期待される成果:** 
+  ビジネスオーナーと定期的にインサイトを見直します。ビジネスオーナーは、新たに得たインサイトに追加のコンテキストを提供します。
+  インサイトを確認して技術者にフィードバックを求め、学んだことをチーム間で共有します。
+  他の技術チームやビジネスチームが確認できるようにデータやインサイトを公開します。学んだことを他の部署の新しい実践に取り入れます。
+  シニアリーダーと共に新しいインサイトをまとめ、レビューします。シニアリーダーは、新しいインサイトを活用して戦略を定義します。

 **一般的なアンチパターン:** 
+  新しい機能をリリースします。この機能により、顧客の行動の一部が変わります。オブザーバビリティではこうした変更が考慮に入れられておらず、こうした変更のメリットの定量化も行われていません。
+  新しいアップデートをプッシュしますが、CDN は更新されません。CDN キャッシュは最新リリースとの互換性がなくなります。エラーのあるリクエストの割合を測定します。バックエンドサーバーとの通信時に、すべてのユーザーが HTTP 400 エラーを報告します。クライアントのエラーを調査したところ、誤ったディメンションを測定したために時間を無駄にしていたことがわかりました。
+  サービスレベル契約では 99.9% のアップタイムが規定されており、目標復旧時間は 4 時間です。サービスオーナーは、システムのダウンタイムはゼロだと主張しています。高価で複雑なレプリケーションソリューションを実装すると、時間と費用が無駄になります。

 **このベストプラクティスを活用するメリット:** 
+  ビジネスオーナーや各分野のエキスパートとインサイトを検証することで、共通の理解を確立し、より効果的に改善につなげることができます。
+  隠れた問題を発見し、それを将来の意思決定に取り入れることができます。
+  技術的な成果からビジネスの成果にフォーカスを移します。

 **このベストプラクティスを活用しない場合のリスクレベル:** 中 

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  **インサイトを検証する:** ビジネスオーナーや各分野のエキスパートと協力して、収集したデータの意味について共通の理解と合意があることを確認します。追加の懸念事項や潜在的な影響を特定し、一連のアクションを判断します。

## リソース
<a name="resources"></a>

 **関連するベストプラクティス:** 
+  [OPS01-BP06 メリットとリスクを管理しながらトレードオフを評価する](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_priorities_eval_tradeoffs.html) 
+  [OPS02-BP06 チーム間の責任は事前定義済みまたは交渉済みである](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_neg_team_agreements.html) 
+  [OPS11-BP03 フィードバックループを実装する](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_feedback_loops.html) 

 **関連ドキュメント:** 
+  [Cloud Center of Excellence (CCOE) の設計](https://aws.amazon.com/blogs/enterprise-strategy/designing-a-cloud-center-of-excellence-ccoe/) 

 **関連動画:** 
+  [Building observability to increase resiliency](https://youtu.be/6bJkYtrMMPI?si=yu8tVMz4a6ax9f34&t=2695) 

# OPS11-BP07 オペレーションメトリクスのレビューを実行する
<a name="ops_evolve_ops_metrics_review"></a>

 ビジネスのさまざまな分野のチームメンバー間で運用メトリクスの遡及分析を定期的に実施します。これらのレビューに基づいて、改善の機会と取り得る一連のアクションを特定するとともに、教訓を共有します。すべての環境 (開発、テスト、本番など) で改善する機会を探します。

 **期待される成果:** 
+  ビジネスに影響するメトリクスを頻繁に確認する 
+  オブザーバビリティ機能を通じて異常を検出し確認する 
+  データをビジネスの成果と目標の裏付けに使用する 

 **一般的なアンチパターン:** 
+  大規模な販促活動によってメンテナンスウィンドウが中断されます。ビジネスに影響する他のイベントがある場合、標準メンテナンスウィンドウが延期される可能性があることが認識されていません。
+  組織で古いライブラリを頻繁に使用していたため、長い時間システムが停止しました。その後、サポートされているライブラリに移行しました。組織内の他のチームは、自身がリスクにさらされているかはわかっていません。
+  顧客の SLA の達成状況を定期的に確認していません。顧客の SLA に適合しない傾向があります。顧客の SLA に適合しない場合は、金銭的ペナルティが発生します。

 **このベストプラクティスを活用するメリット:** 
+  運用メトリクス、イベント、インシデントを定期的に確認することで、チーム間の共通理解を維持します。
+  チームは定期的にミーティングを行い、メトリクスやインシデントを確認します。これにより、リスクに対処し、顧客の SLA を確認できます。
+  学んだ教訓を共有することで、ビジネス成果の優先順位付けや目標とする改善のためのデータが得られます。

 **このベストプラクティスを活用しない場合のリスクレベル:** 中 

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  ビジネスのさまざまな分野のチームメンバー間で運用メトリクスの遡及分析を定期的に実施します。
+  ビジネス、開発、オペレーションチームを含むステークホルダーを参加させて、即時フィードバックと遡及分析から得られた結果を検証し、教訓を共有します。
+  それらのインサイトに基づいて、改善の機会と取り得る一連のアクションを特定します。

## リソース
<a name="resources"></a>

 **関連するベストプラクティス:** 
+  [OPS08-BP05 ダッシュボードを作成する](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_workload_observability_create_dashboards.html) 
+  [OPS09-BP03 運用メトリクスのレビューと改善の優先順位付け](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_operations_health_review_ops_metrics_prioritize_improvement.html) 
+  [OPS10-BP01 イベント、インシデント、問題管理のプロセスを使用する](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_event_response_event_incident_problem_process.html) 

 **関連ドキュメント:** 
+  [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) 
+  [CloudWatch メトリクスを発行する AWS のサービス](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html) 
+  [カスタムメトリクスをパブリッシュする](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) 
+  [Amazon CloudWatch メトリクスを使用する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) 
+  [CloudWatch を使用したダッシュボードとビジュアライゼーション](https://docs.aws.amazon.com/prescriptive-guidance/latest/implementing-logging-monitoring-cloudwatch/cloudwatch-dashboards-visualizations.html) 

# OPS11-BP08 教訓を文書化して共有する
<a name="ops_evolve_ops_share_lessons_learned"></a>

 運用アクティビティから学んだ教訓を文書化して共有し、社内とチーム全体で利用できるようにします。チームが学んだことを共有して、組織全体のメリットを増やす必要があります。情報とリソースを共有して、回避可能なエラーを防止し、開発作業を容易にして、期待される機能の提供にフォーカスします。

 AWS Identity and Access Management (IAM) を使用して、アカウント内またはアカウント間で共有するリソースへのコントロールされたアクセスを可能にするアクセス許可を定義します。

 **期待される成果:** 
+  バージョン管理されたリポジトリを使用して、アプリケーションライブラリ、スクリプト化された手順、手順のドキュメント、その他のシステムドキュメントを共有します。
+  インフラストラクチャ標準は、バージョン管理された AWS CloudFormation テンプレートとして共有します。
+  チーム全体で学んだ教訓を確認します。

 **一般的なアンチパターン:** 
+  組織でバグが含まれているライブラリを頻繁に使用していたため、長い時間システムが停止しました。その後、チームは信頼性の高いライブラリに移行しました。組織内の他のチームは、自身がリスクにさらされていることを知りません。このライブラリでの経験が文書化や共有されていないため、誰もリスクに気づいていません。
+  あるユーザーが、セッションがドロップする原因となる内部共有マイクロサービスのエッジケースを特定しました。そのユーザーは、このエッジケースを回避するために、サービスへの自分の呼び出しを更新しました。組織内の他のチームは、自身がリスクにさらされているかはわかっていません。
+  マイクロサービスの 1 つについて、CPU 使用率要件を大幅に削減する方法が見つかりました。他のチームがこの手法を利用できるかどうかはわかりません。

 **このベストプラクティスを活用するメリット:** 教訓を共有して、改善をサポートし、経験から得られる恩恵を最大化します。

 **このベストプラクティスを活用しない場合のリスクレベル:** 低 

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  **教訓を文書化して共有する:** 運用アクティビティと遡及分析の実行から学習した教訓を文書化する手順を決めて、ほかのチームが使用できるようにします。
+  **教訓を共有する:** 教訓と関連するアーティファクトをチーム全体で共有する手順を決めます。例えば、アクセス可能な Wiki を使用して手順の更新、ガイダンス、ガバナンス、ベストプラクティスを共有します。共通のリポジトリを使用してスクリプト、コード、ライブラリを共有します。
  +  [AWS re:Post Private](https://aws.amazon.com/repost-private/) as a knowledge サービスを活用して、組織内でのコラボレーションと知識共有を合理化します。

## リソース
<a name="resources"></a>

 **関連するベストプラクティス:** 
+  [OPS02-BP06 チーム間の責任は事前定義済みまたは交渉済みである](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_neg_team_agreements.html) 
+  [OPS05-BP01 バージョン管理を使用する](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_dev_integ_version_control.html) 
+  [OPS05-BP06 設計標準を共有する](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_dev_integ_share_design_stds.html) 
+  [OPS11-BP03 フィードバックループを実装する](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_feedback_loops.html) 
+  [OPS11-BP07 オペレーションメトリクスのレビューを実行する](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_metrics_review.html) 

 **関連ドキュメント:** 
+ [コラボレーションを強化し、クラウドに関する知識を AWS re:Post Private と安全に共有する](https://aws.amazon.com/blogs/aws/increase-collaboration-and-securely-share-cloud-knowledge-with-aws-repost-private/)
+ [ Reduce project delays with a docs-as-code solution ](https://aws.amazon.com/blogs/infrastructure-and-automation/reduce-project-delays-with-docs-as-code-solution/)

 **関連動画:** 
+ [AWS re:Invent 2023 - Collaborate within your company and with AWS using AWS re:Post Private ](https://www.youtube.com/watch?v=HNq_kU2QJLU)
+  [サポートs You \$1 Exploring the Incident Management Tabletop Exercise](https://www.youtube.com/watch?v=0m8sGDx-pRM) 

# OPS11-BP09 改善を行うための時間を割り当てる
<a name="ops_evolve_ops_allocate_time_for_imp"></a>

 漸進的な継続的改善を可能にする時間とリソースをプロセス内に設けます。

 **期待される成果:** 
+  一時的に重複する環境を作成することで、実験やテストのリスク、労力、コストを削減できます。
+  こうした重複する環境を使用して、分析、実験からの結論をテストし、計画した改善を開発してテストできます。
+  ゲームデーを実施し、Fault Injection Service (FIS) を使用して、チームが本番環境に似た環境で実験を行うために必要な制御とガードレールを提供します。

 **一般的なアンチパターン:** 
+  アプリケーションサーバーに既知のパフォーマンスの問題があります。当該問題は、すべての計画された機能実装の背後にあるバックログに追加されます。計画された機能が一定の割合で追加され続ければ、パフォーマンスの問題は解決しません。
+  継続的な改善をサポートするために、管理者と開発者が改善の選択と実装にすべての余分な時間を費やすことを承認します。改善は完了しません。
+  運用上の承認が完了した後は、運用プラクティスの再テストを行っていません。

 **このベストプラクティスを活用するメリット:** 時間とリソースをプロセス内に設けることで、漸進的な改善を継続的に行うことができます。

 **このベストプラクティスを活用しない場合のリスクレベル:** 低 

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  改善を行うための時間を割り当てる: 継続的な漸進的改善のために、プロセス内に時間とリソースを割り当てます。
+  改善のための変更を加えて結果を評価し、成功を判断します。
+  結果が目標に達しておらず、今後も改善が優先事項である場合は、アクションの代替案を検討します。
+  ゲームデーを通して本番環境のワークロードをシミュレートし、これらのシミュレーションから学んだことを改善に生かします。

## リソース
<a name="resources"></a>

 **関連するベストプラクティス:** 
+  [OPS05-BP08 複数の環境を使用する](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_dev_integ_multi_env.html) 

 **関連動画:** 
+  [AWS re:Invent 2023 - Improve application resilience with AWS Fault Injection Service](https://youtu.be/N0aZZVVZiUw?si=ivYa9ScBfHcj-IAq) 