運用上のオブザーバビリティ

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

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

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

DevOps と並行して運用が果たす役割は見過ごされがちですが、多くの組織では、中央運用チームが依然として通常の営業時間外に重要な初対応を行っています。(このモデルの詳細については、「オペレーショナルエクセレンスのホワイトペーパー」を参照してください。) ワークロードを所有する DevOps チームとは異なり、通常、これらのチームは同じ知識を持ちません。そのため、タグがダッシュボードやアラート内に提供するコンテキストによって、問題に適したランブックにタグを誘導したり、自動ランブックを開始したりできます (ブログ記事「Automating Amazon CloudWatch Alarms with AWS Systems Manager」を参照）。