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

# ステージ 1: North Star を定義する
<a name="define-north-star"></a>

オブザーバビリティの実装を成功させるのは、運用とツールだけでなく、所有権、継続的な改善、積極的な問題解決の文化を育むことです。成功した戦略と同様に、オブザーバビリティ戦略では、人材、プロセス、テクノロジーの 3 つの柱を包括的に考慮する必要があります。

オブザーバビリティ体制を確立または改善する場合は、まず重要なものを定義し、ビジネス成果から戻り、ビジネス、チーム、製品の進化に合わせて戦略を継続的に見直し、調整、再調整することをお勧めします。

この最初の段階では、North *Star を定義して確立します。North* Star は、組織にとって何が良いかについて合意され、よく理解された定義です。この段階の一部またはすべてのアクティビティは、ビジネスの進化、新しい製品、アプリケーション、サービスの開始、またはアーキテクチャの大幅な変更を設計するときに、オブザーバビリティプラットフォームと組織のニーズを再評価するために再検討することをお勧めします。

## 開発ライフサイクルの早い段階でオブザーバビリティを統合する (シフト左アプローチ)
<a name="shift-left"></a>

オブザーバビリティをエンジニアリング、運用、製品チームのメンバー全員の責任とし、ユニットテストやセキュリティと同様に、主要な機能要件として扱います。これにより、運用チームから開発チームに責任が移ることはありませんが、複数のチームに必要なコラボレーションが強調されます。開発ライフサイクルの早い段階で、チームがコラボレーションで次のアクティビティを実行すると便利です。これらは、チケットごと、機能ごと、または製品ごとに実行できます。
+ **ステークホルダーを特定します。**関係者は誰で、この機能や製品が期待どおりに機能しない場合、関係者にとって何が重要ですか? 利害関係者を特定するときは、機能、可用性、セキュリティ、コスト、売上、製品の使用状況などの側面を考慮してください。ステークホルダーには、チーム、製品の顧客、社内のビジネスステークホルダー、プラットフォーム運用チームのメンバー、アプリケーション開発者が含まれます。シナリオによっては、セキュリティチームと財務チームも利害関係者になる可能性があります。
+ **主要な成果を特定します。**主要な成果と、それがビジネスと各ステークホルダーに与える影響を決定します。各成果とステークホルダーの成功と失敗を特定します。結果は通常、サービスレベル目標 (SLOs) として定義され、定量化可能である必要があります。SLO は、各結果の尺度です。優れた SLO には、目標として目指す、または維持すべき目標値があります。SLO はユーザー満足度の尺度になります。サービスレベルインジケータ (SLI) は、SLO を満たしているかどうかを判断するために使用される実際の測定値またはメトリクスです。これは、目標に対して追跡する定量化可能なデータポイントです。例としては、MTTR を 60% 削減したり、アプリケーションの可用性を 99.99% に維持したり、開発者の生産性を 30% 向上させたりすることが挙げられます。

  アプリケーションの可用性を 99.99% に維持し、成功の測定と検証に必要な SLO、SLI、メトリクスを定義しましょう。この例では、RESTful アプリケーションを考慮し、アプリケーションの可用性をすべての受信リクエストが正常に完了したものとして定義します。そのためには、アプリケーションへのリクエストの合計数と各リクエストの完了ステータスを測定する必要があります。これらを SLO および SLI に変換する場合、受信リクエストをキャプチャするメトリクスと、リクエストのステータスをキャプチャする別のメトリクスが必要です。すべてのリクエストが正常に完了すると、アプリケーションは使用可能と見なされます。1 つ以上のリクエストでエラーが発生した場合、アプリケーションは使用できないと見なされます。したがって、SLI は、エラーになっているリクエスト完了の合計を 5 分間隔で受信リクエストの合計で割ったものになります。つまり、*エラー率*です。この SLI に目標を追加して SLO にすることができます。例えば、エラー率が 3 つの連続した 5 分間隔で 0.1% 未満になるようにします。
+ **主要な成果に優先順位を付けます。 **各結果に設定した優先度に基づいて、すべてを同時に実行するのではなく、最も影響の大きい結果に最初に焦点を合わせることができます。小規模から始めて反復し、オブザーバビリティの姿勢を少しずつ改善します。オブザーバビリティは、成熟度と利点を高めるために継続的なレビュー、監査、機能強化、改善を必要とするプロセスです。優先順位付けは、特定された成果に向けて段階的なマイルストーンを定義する機会にもなります。
+ **必要な計測を特定します。**前のステップで特定したように、重要な結果に影響を与えるアーキテクチャまたは実装のコンポーネントおよび関連機能は何ですか? 例えば、Amazon Elastic Compute Cloud (Amazon EC2) インスタンスでアプリケーションを実行すると、コア数と使用可能な RAM 数がアプリケーションの応答性とスループットに影響する可能性があります。この段階では、使用するツールまたはライブラリがすでにこの計測の一部を提供しているかどうかを判断するのにも役立つ場合があります。チケット[の準備完了 (DoR) の定義](https://scrum-master.org/en/definition-of-ready-dor-an-essential-tool-for-improving-software-development-quality/)に一連の事前レビューを行ったり、次のような質問を追加したりすると、このアクティビティを標準プロセスの一部にすることができます。
  + このオペレーションが失敗した場合、失敗に対処するために何を知る必要がありますか? 一般的なオペレーションや問題のあるオペレーションは、関連するコンポーネントにどのように影響しますか? このオペレーションは、ログ、メトリクス、トレースなど、どのような種類のシグナルを送信する必要がありますか? この計測のコストは、その値と比較してどれくらいですか? SLOs に違反することなく、どのような集約が許容されますか?
  + このオペレーションで障害を引き起こす可能性のあるコンポーネントと依存関係は何ですか? 障害の原因となったコンポーネントまたは依存関係をどのように特定しますか? これらのコンポーネントと依存関係のさまざまな設定レバーと、それぞれがオペレーションにどのように影響しますか?
  + SLI と SLO を正確に測定するために必要なメトリクスの詳細度とサンプリングレートは何ですか?
+ **成功基準を定義します。**優先順位付けされた成果ごとに、目標を達成したかどうかの影響に合わせたしきい値を定義します。成功基準は、チームがアラートに応答するときに追加のコンテキストを提供します。また、必要な可視性のために計測のコストを予測してトレードオフすることもできます。

## 効果的な組織とチーム構造を設定する
<a name="team-structure"></a>

ビジネスのアーキテクチャの複雑さとサイズに基づいて、オブザーバビリティに重点を置いた専用チームをセットアップする必要がある場合があります。このチームは、オブザーバビリティツールの設定と、他のチームのオブザーバビリティプラットフォームの設定を担当します。また、標準の OpenTelemetry 実装を選択した場合は、専用チームを設定することをお勧めします。小規模な組織では、すべてのチームメンバーに追加の責任としてオブザーバビリティを割り当て、チーム全体でベストプラクティスを推進して適用するオブザーバビリティチャンピオンを任命することもできます。これらのチャンピオンは、1 日の一部をボランティアで行い、プロセスを定義し、組織の標準を設定します。これらは自律型チームとして機能するか、専用のオブザーバビリティスペシャリストが主導できます。次の図は、投資が組織のアプローチをどのように決定できるかを示しています。

![投資に基づいてオブザーバビリティの責任を判断する方法。](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/strategy-accelerate-observability-outcomes/images/complexity.png)


チャンピオンは、チーム内に完全に埋め込まれたり (次の図のチーム 2 を参照）、チーム全体でローテーションしてベストプラクティスを確立して推進するチームの一部になることができます (図のチーム 1)。

![チームを有効にするか、オブザーバビリティチャンピオンを埋め込むためのセットアップ。](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/strategy-accelerate-observability-outcomes/images/team-structure-for-observability.png)


## コスト配分を追跡する
<a name="cost-allocation"></a>

組織は、リソースの使用状況とコストに関するチーム固有の説明責任を確立しながら、メトリクス、ログ、トレース全体で包括的なコスト追跡と可視性を実装する必要があります。財務オペレーション (FinOps) プラクティスの統合を成功させるには、体系的なデータ保持と収集の最適化と組み合わせた予算アラートを備えた自動モニタリングシステムが必要です。エンジニアリングチームと財務チームは、共有ダッシュボードと定期的なレビューを通じて目標を調整する必要があります。組織は、所有権と説明責任を推進するために、明確なチャージバックモデルとコスト配分戦略を実装することでメリットを得られます。

## 標準を定義する
<a name="standards"></a>

アラートやダッシュボード戦略など、アプリケーションに必要な基本シグナルとテレメトリを特定して定義します。アプリケーションごとにチェックリストまたは正式なレビュープロセスを作成します。[AWS オブザーバビリティのベストプラクティス](https://aws-observability.github.io/observability-best-practices/)ウェブサイトでは、適切なアラートしきい値の設定、アラート疲労の最小化、各ペルソナに十分なコンテキストを持つダッシュボードの作成など、アラートとダッシュボードの作成に関するガイドラインを提供しています。接続およびキュレートされたオブザーバビリティエクスペリエンスについては、Amazon CloudWatch ドキュメントの[「アプリケーションシグナル](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Application-Monitoring-Sections.html)」を参照してください。

## エスカレーションプロセスを確立する
<a name="escalation"></a>

エスカレーションメカニズム、アラートの所有権、対応手順を確立して適用することが重要です。エスカレーションが重視されない文化を促進することをお勧めします。

## トレーニングによるスキルの向上
<a name="skills"></a>

既存および新規のチームメンバーをスキルアップし、オブザーバビリティの重要性を強化し、継続的な改善の文化を育む最善の方法を特定します。組織のニーズに応じて、オブザーバビリティのチャンピオンまたはスペシャリストが提供する、録画済みのオンデマンドトレーニングまたはクラスルームトレーニングを選択できます。 AWS アカウント チームは、[One Observability Workshop](https://catalog.workshops.aws/observability/en-US) や [GameDays](https://aws.amazon.com/gameday/) などの詳細な実践的なトレーニングセッションを提供して、オブザーバビリティのスキルとベストプラクティスを指導し、向上させることができます。さらに、ベストプラクティスを強化し、組織が定義した標準を推進するためのメカニズムを組み込む必要があります。