翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# 運用上のオブザーバビリティ
<a name="operational-observability"></a>

 環境パフォーマンスに対して実行可能な見通しを立て、問題の検出と調査に役立てるには、オブザーバビリティが必要です。また、重要業績評価指標 (KPI) や稼働時間などのサービスレベル目標 (SLO) を定義して測定できるという副次的な目的もあります。ほとんどの組織にとっては、インシデント発生時の平均検出時間 (MTTD) とインシデントからの平均回復時間 (MTTR) が重要な運用 KPI です。

オブザーバビリティでは、データが収集されてから関連するタグが収集されるため、コンテキストが重要です。対象になるサービス、アプリケーション、またはアプリケーション層に関係なく、その特定のデータセットを絞り込んで分析できます。CloudWatch Alarms へのオンボーディングをタグで自動化できるため、特定のメトリクスのしきい値を超えた場合に適切なチームがアラートを受け取ることができます。例えば、タグキー `example-inc:ops:alarm-tag` とその値が CloudWatch アラームの作成を示している可能性があります。これを示すソリューションについては、「[Amazon EC2 インスタ―スに対する Amazon CloudWatch アラームの作成と維持のためにタグを使用する](https://aws.amazon.com/blogs/mt/use-tags-to-create-and-maintain-amazon-cloudwatch-alarms-for-amazon-ec2-instances-part-1/)」を参照してください。

 設定したアラームの数が多すぎると、オペレーターが個々のアラームを手動で重要度を判定して優先順位付けをしている間に、大量のアラームや通知でオペレーターに負担がかかり、全体的な効果を低下して、アラートストームが発生しやすくなります。アラームの追加コンテキストはタグの形で提供でき、Amazon EventBridge 内でルールを定義できるため、ダウンストリームの依存関係ではなくアップストリームの問題に的を絞ることができます。

 DevOps と並行して運用が果たす役割は見過ごされがちですが、多くの組織では、中央運用チームが依然として通常の営業時間外に重要な初対応を行っています。(このモデルの詳細については、「[オペレーショナルエクセレンスのホワイトペーパー](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/separated-aeo-ieo-with-cent-gov-and-partner.html)」を参照してください。) ワークロードを所有する DevOps チームとは異なり、通常、それらには同じ知識の深さがないため、タグがダッシュボードやアラート内に提供するコンテキストは、問題の正しいランブックにタグを誘導したり、自動ランブックを開始したりできます (ブログ記事[「Automating Amazon CloudWatch Alarms with AWS Systems Manager](https://aws.amazon.com/blogs/mt/automating-amazon-cloudwatch-alarms-with-aws-systems-manager/)」を参照）。