翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# ステージ 3: 検査、適応、反復
オブザーバビリティシステムを実装したら、実装を継続的に確認、評価、学習、適応、改善することをお勧めします。[AWS オブザーバビリティ成熟度モデル](https://aws-observability.github.io/observability-best-practices/guides/observability-maturity-model/)をツールとして使用して、実装の成熟度を評価し、改善すべき分野を特定して優先順位を付けることができます。
## 定期的なレビューを実装する
オブザーバビリティは反復的なプロセスです。これには、既存のコンポーネントの定期的な監査と評価、および継続的な改善を推進するための変更と機能強化が必要です。SLOs、アラートしきい値、ダッシュボード、メトリクスの詳細度、保持ポリシー、サンプリング戦略などを定期的に見直して、これらがチームやビジネスにとって価値を高めていることを確認することをお勧めします。オブザーバビリティのコストを特定のチームやサービスに接続することで、カバレッジとリソース割り当てに関するデータ駆動型の意思決定を実現できます。
Amazon では、毎週[運用準備状況レビュー (ORRs) ](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html)を実施して、チームのプロセスとオブザーバビリティ体制をベストプラクティスに照らして監査します。これは、Amazon のサービスの数とリリースの頻度に沿ったノンブロッキングの演習です。
組織の規模によっては、通常どおりビジネス (BAU) 名簿を作成することもできます。ここでは、各チームの 1 人のメンバーが、異常や傾向の報告、未知の未知の発見、不要な計測やアラートの削除、ダッシュボードの改善、オブザーバビリティソリューションがチームにとって引き続き機能し、チームの目標と成功メトリクスに合致していることの確認を担当します。これは、より応答性が高く、プロアクティブで、ユーザーに近いアラート戦略を再評価する機会でもあります。これらのレビューの目的は、次の図に示すように好循環を作成し、オブザーバビリティ成熟度[AWS モデルで説明されているように、オブザーバビリティ体制の成熟度](https://aws-observability.github.io/observability-best-practices/guides/observability-maturity-model)を向上させることです。
最も頻繁にアクセスされるプレイブックを特定し、アプリケーションの改善や計測の追加を検討してください。最も頻繁に実行されるランブックを特定し、それらのランブックの自動化を検討します。
これらのレビューからの学習は、中央プログラムとオブザーバビリティプラットフォームの改善を強調するために、オブザーバビリティの分隊やスペシャリストとも共有されます。たとえば、デプロイによってトリガーされるイベントの頻度に応じて、他のコンポーネントよりもデプロイパイプラインの改善を優先できます。モニタリングギャップが原因で MTTR が高い場合は、オブザーバビリティプラットフォームとその設定の改善を優先できます。
## 成功を祝う
オブザーバビリティツールを使用するチームの成功事例を共有します。例えば、オブザーバビリティメトリクスを使用して、より効率的でレイテンシーやコストの削減につながる代替ソリューションを実装したチームの成功を強調します。この成功を伝えることで、オブザーバビリティの重要性が強調され、他のチームがオブザーバビリティ体制を改善し、同様の成功を目指します。
## インシデントから学ぶ
Amazon で[エラー修正 (COE)](https://aws.amazon.com/blogs/mt/why-you-should-develop-a-correction-of-error-coe/) プロセスと同様の無責任なインシデント後演習を行い、改善すべき分野を特定し、将来の問題を防止します。成功と同様に、この演習から学んだことを他のチームと共有して、オブザーバビリティとベストプラクティスの価値を高めることができます。