

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

**Topics**
+ [OPS 11 オペレーションをどのように進化させるのですか?](w2aac19b5c11b5.md)

# OPS 11 オペレーションをどのように進化させるのですか?
<a name="w2aac19b5c11b5"></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>

 最も大きな利益をもたらす取り組みに集中できるように、改善の機会を定期的に評価し、優先順位を設定します。 

 **一般的なアンチパターン:** 
+  これまでに、開発環境またはテスト環境の作成に必要な手順を文書化しました。あなたは、CloudFormation を使用してプロセスを自動化することもできますが、代わりにコンソールから手動で行います。 
+  テストでは、アプリケーション内の CPU 使用率の大部分が、非効率的な機能の小さな集まりの状態にあることが示されています。あなたは、改善とコスト削減に注力することもできますが、新しいユーザビリティ機能を作成するタスクが割り当てられています。 

 **このベストプラクティスを活用するメリット:** 継続的な改善は、改善の機会を定期的に評価し、機会に優先順位を付けて、最大のメリットを提供できる領域に注力するメカニズムを提供します。 

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

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  継続的改善のプロセスを定義する: 最も大きな利益をもたらす取り組みに集中できるように、改善の機会を定期的に評価し、優先順位を設定します。改善のための変更を加えて結果を評価し、成功を判断します。結果が目標に達しておらず、今後も改善が優先事項である場合は、代わりの一連のアクションを使用して繰り返します。オペレーションプロセスには、漸進的な継続的改善を可能にする時間とリソースを含める必要があります。 

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

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

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

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

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

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  プロセスを使用して寄与した要因を判断する: 顧客に影響を与えるすべてのインシデントを確認します。インシデントに寄与した要因を特定してドキュメント化するためのプロセスを用意しておき、再発を抑制または防止する緩和策と、迅速で効果的な対応手順を展開できるようにしておきます。必要に応じ、対象者に合わせて根本原因を通知します。 

# 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 チームプレイブック - 振り返り](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 ガレージメソドロジー - 振り返りの保留](https://www.ibm.com/garage/method/practices/learn/practice_retrospective_analysis/) 
+  [Investopedia - PDCS サイクル](https://www.investopedia.com/terms/p/pdca-cycle.asp) 
+  [開発者の有効性を最大化する (Tim Cochran 著)](https://martinfowler.com/articles/developer-effectiveness.html) 
+  [運用準備状況の確認 (ORR) に関するホワイトペーパー - イテレーション](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/iteration.html) 
+  [TIL CSI - 継続的なサービスの改善](https://wiki.en.it-processmaps.com/index.php/ITIL_CSI_-_Continual_Service_Improvement)
+  [トヨタでの e コマースの採用: Amazon での無駄のない管理](https://www.mckinsey.com/capabilities/operations/our-insights/when-toyota-met-e-commerce-lean-at-amazon) 

 **関連動画:** 
+  [効果的な顧客フィードバックループの構築](https://www.youtube.com/watch?v=zz_VImJRZ3U) 

 **関連サンプル: ** 
+  [Astuto - オープンソースの顧客フィードバックツール](https://github.com/riggraz/astuto) 
+  [AWS ソリューション - AWS の QnABot](https://aws.amazon.com/solutions/implementations/qnabot-on-aws/) 
+  [Fider - 顧客フィードバックの管理プラットフォーム](https://github.com/getfider/fider) 

 **関連サービス:** 
+  [これらの改善を ](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter.html) 

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

 チームメンバーが探している情報をタイムリーに検出し、アクセスして、最新かつ完全であることを確認するメカニズムが存在しています。必要なコンテンツ、更新が必要なコンテンツ、および今後参照されることのないようにアーカイブする必要があるコンテンツを特定するためのメカニズムが存在しています。 

 **一般的なアンチパターン:** 
+  不満のある顧客が、認識された問題への対応を求めて、新しい製品機能のリクエストのサポートケースをオープンします。これは、優先的な改善のリストに追加されます。 

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

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  ナレッジ管理を実施する: チームメンバーが、探している情報をタイムリーに入手し、アクセスして、最新かつ完全であることを識別するための仕組みを確立します。必要なコンテンツ、更新が必要なコンテンツ、および今後参照されることのないようにアーカイブする必要があるコンテンツを特定するためのメカニズムを維持します。 

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

 機会を評価して優先順位を設定できるよう、改善の推進要因を特定します。 

 AWS では、すべての運用アクティビティ、ワークロード、インフラストラクチャのログを集約して詳細なアクティビティ履歴を作成できます。AWS ツールを使用して長期的に運用とワークロードの状態を分析し (トレンドの特定、イベントやアクティビティの成果への関連付け、環境間やシステム全体の比較や対比など)、推進要因に基づいて改善の機会を見つけることができます。 

 CloudTrail を使用し、AWS マネジメントコンソール、CLI、SDK、API を介して API アクティビティを追跡し、アカウント全体で何が起きているかを把握する必要があります。CloudTrail および CloudWatch を使用して、AWS デベロッパーツールのデプロイアクティビティを追跡します。これにより、デプロイの詳細なアクティビティ履歴と結果が CloudWatch Logs Logs のログデータに追加されます。 

 [長期保管用の Amazon S3 にログデータを](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3Export.html) エクスポートします。分析のために、 [AWS Glue](https://aws.amazon.com/glue/?whats-new-cards.sort-by=item.additionalFields.postDateTime&whats-new-cards.sort-order=desc)を使用して、Amazon S3 のログデータを検出して準備します。AWS Glue とネイティブで統合された [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/) を使用して、データを可視化、調査、分析することができます。 

 **一般的なアンチパターン:** 
+  あるスクリプトは、機能はするものの、洗練されてはいません。あなたは、書き換えに時間を費やします。現在は素晴らしいスクリプトです。 
+  スタートアップは、ベンチャーキャピタリストから別の資金を調達しようとしています。そのスタートアップは、PCI DSS へのコンプライアンスを実証することをあなたに求めています。あなたは、ベンチャーキャピタリストを満足させたいと考え、コンプライアンスを文書化し、ある顧客の納期に遅れ、その顧客を失います。それをするのは間違ったことではありませんでしたが、今では正しいことだったのかどうかを疑問に思います。 

 **このベストプラクティスを活用するメリット:** 改善に使用する基準を決定することで、イベントベースのモチベーションや感情的投資の影響を最小限に抑えることができます。 

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

## 実装のガイダンス
<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/) 
  +  コンプライアンスの要件: 改善の機会を確認する際は、規制/ポリシー遵守の維持、またはサードパーティーによるサポートの維持に必要な更新と変更を評価します。 
    +  [AWS コンプライアンス](https://aws.amazon.com/compliance/) 
    +  [AWS コンプライアンスプログラム](https://aws.amazon.com/compliance/programs/) 
    +  [AWS コンプライアンスの最新情報](https://aws.amazon.com/compliance/compliance-latest-news/) 

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

 **関連するドキュメント:** 
+  [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 コンプライアンスプログラム](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/) 
+  [ログデータを Amazon S3 にエクスポートする](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3Export.html) 
+  [AWS の最新情報](https://aws.amazon.com/new/) 

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

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

 **一般的なアンチパターン:** 
+  あなたは、CPU 使用率がシステムで 95% であることを確認し、システムの負荷を軽減する方法を見つけることを優先します。あなたは、最適なアクションがスケールアップであると判断します。システムはトランスコーダーであり、いつでも 95% の CPU 使用率で実行するようにスケールされています。あなたがシステム所有者に連絡していれば、状況を説明してもらえたかもしれません。時間を無駄にしてしまいました。 
+  システム所有者は、システムがミッションクリティカルであると主張しています。システムは強固なセキュリティ環境に配置されていませんでした。セキュリティの向上のため、あなたは、ミッションクリティカルなシステムに要求される追加の発見的統制および予防統制を実装します。あなたは、作業が完了し、追加のリソースに対して課金される旨をシステム所有者に通知します。この通知の後の話し合いにおいて、システム所有者は、ミッションクリティカルという用語について正式な定義があり、自身のシステムがこれに適合していないことを知ります。 

 **このベストプラクティスを活用するメリット:** ビジネスオーナーや各分野のエキスパートとインサイトを検証することで、共通の理解を確立し、より効果的に改善につなげることができます。 

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

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

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

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

 すべての環境 (開発、テスト、生産など) で改善する機会を探します。 

 **一般的なアンチパターン:** 
+  大々的な販促活動が行われていましたが、メンテナンスウィンドウによって中断されました。ビジネスに影響する他のイベントがある場合、標準メンテナンスウィンドウが延期される可能性があることが認識されていません。 
+  あなたは、組織で一般的に使用されているバグのあるライブラリを使用しているため、停止時間が長くなり、困っていました。その後、あなたは、信頼性の高いライブラリに移行しました。組織内の他のチームは、自身がリスクにさらされているかはわかっていません。あなたが定期的にミーティングを行い、このインシデントを確認していれば、彼らはリスクを認識していたでしょう。 
+  トランスコーダーのパフォーマンスは着実に低下しており、メディアチームに影響を及ぼしています。まだひどい状態であるとまでは言えません。インシデントの原因となるほど悪くなるまで気付く機会はありません。メディアチームと一緒にオペレーションメトリクスを見直すことで、メトリクスの変化や彼らの経験を認識し、問題に対処する機会が生まれるはずです。 
+  あなたは、顧客の SLA の満足度を確認していません。あなたは、顧客の SLA に適合しない傾向があります。顧客の SLA に適合しない場合は、金銭的ペナルティが発生します。これらの SLA のメトリクスを確認するためのミーティングを定期的に開催していれば、問題を認識して対処する機会が得られたはずです。 

 **このベストプラクティスを確立するメリット:** 定期的にミーティングを行い、オペレーションメトリクス、イベント、インシデントを確認することで、チーム全体で共通の理解を維持し、学んだ教訓を共有し、改善を優先順位付けして目標を設定することができます。 

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

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  オペレーションメトリクスのレビュー: 定期的に、さまざまな分野のチームメンバーとともに、オペレーションメトリクスの遡及分析を行います。ビジネス、開発、オペレーションチームを含む関係者を参加させて、即時フィードバックと遡及分析から得られた結果を検証し、教訓を共有します。それらの洞察に基づいて、改善の機会と取り得る一連のアクションを特定します。 
  +  [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) 
  +  [Amazon CloudWatch メトリクスを使用する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) 
  +  [カスタムメトリクスをパブリッシュする](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) 
  +  [Amazon CloudWatch のメトリクスとディメンションのリファレンス](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html) 

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

 **関連するドキュメント:** 
+  [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) 
+  [Amazon CloudWatch のメトリクスとディメンションのリファレンス](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) 

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

 運用アクティビティから学んだ教訓を文書化して共有し、社内とチーム全体で利用できるようにします。 

 チームが学んだことを共有して、組織全体のメリットを増やす必要があります。情報とリソースを共有して、回避可能なエラーを防止し、開発作業を容易にする必要があります。これにより、望まれる機能の提供に集中できます。 

 AWS Identity and Access Management (IAM) を使用して、アカウント内またはアカウント間で共有するリソースへのコントロールされたアクセスを可能にするアクセス許可を定義します。その後、バージョン管理された AWS CodeCommit リポジトリを使用して、アプリケーションライブラリ、スクリプト化された手順、手順のドキュメント、その他のシステムドキュメントを共有する必要があります。AMI へのアクセスを共有し、Lambda 関数の使用をアカウント間で許可することで、コンピューティング標準を共有します。また、インフラストラクチャ標準を AWS CloudFormation のテンプレートとして共有する必要もあります。 

 AWS API と SDK を使用すると、外部ツールやサードパーティーのツールやリポジトリ (GitHub、BitBucket、SourceForge など) を統合できます。学んだことや開発したことを共有するときは、共有リポジトリの完全性を保証するためにアクセス許可を構造化することに注意してください。 

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

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

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

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  教訓を文書化して共有する: 運用アクティビティと遡及分析の実行から学習した教訓を文書化する手順を決めて、ほかのチームが使用できるようにします。 
  +  教訓を共有する: 教訓と関連するアーティファクトをチーム全体で共有する手順を決めます。たとえば、アクセス可能な Wiki を使用して手順の更新、ガイダンス、ガバナンス、ベストプラクティスを共有します。共通のリポジトリを使用してスクリプト、コード、ライブラリを共有します。 
    +  [AWS 環境へのアクセスの委任](https://www.youtube.com/watch?v=0zJuULHFS6A&t=849s) 
    +  [AWS CodeCommit リポジトリを共有する](https://docs.aws.amazon.com/codecommit/latest/userguide/how-to-share-repository.html) 
    +  [AWS Lambda 関数の簡単な承認](https://aws.amazon.com/blogs/compute/easy-authorization-of-aws-lambda-functions/) 
    +  [特定の AWS アカウントと AMI を共有する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharingamis-explicit.html) 
    +  [AWS CloudFormation デザイナー URL によるテンプレート共有の高速化](https://aws.amazon.com/blogs/devops/speed-template-sharing-with-an-aws-cloudformation-designer-url/) 
    +  [Amazon SNS での AWS Lambda の使用](https://docs.aws.amazon.com/lambda/latest/dg/with-sns-example.html) 

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

 **関連するドキュメント:** 
+  [AWS Lambda 関数の簡単な承認](https://aws.amazon.com/blogs/compute/easy-authorization-of-aws-lambda-functions/) 
+  [AWS CodeCommit リポジトリを共有する](https://docs.aws.amazon.com/codecommit/latest/userguide/how-to-share-repository.html) 
+  [特定の AWS アカウントと AMI を共有する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharingamis-explicit.html) 
+  [AWS CloudFormation デザイナー URL によるテンプレート共有の高速化](https://aws.amazon.com/blogs/devops/speed-template-sharing-with-an-aws-cloudformation-designer-url/) 
+  [Amazon SNS での AWS Lambda の使用](https://docs.aws.amazon.com/lambda/latest/dg/with-sns-example.html) 

 **関連動画:** 
+  [AWS 環境へのアクセスの委任](https://www.youtube.com/watch?v=0zJuULHFS6A&t=849s) 

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

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

 AWS では、一時的に重複する環境を作成することで、実験やテストのリスク、労力、コストを削減できます。こうした重複する環境を使用して、分析、実験からの結論をテストし、計画した改善を開発してテストできます。 

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

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

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

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  改善を行うための時間を割り当てる: 継続的な漸進的改善を可能にするために、プロセス内に時間とリソースを割り当てます。改善のための変更を加えて結果を評価し、成功を判断します。結果が目標に達しておらず、今後も改善が優先事項である場合は、アクションの代替案を追及してください。 