翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
ステージ 2: オブザーバビリティを実装する
この段階では、チームが徐々に北極星に向かうプロセスを開始します。
オブザーバビリティプラットフォームを選択する
最初のステップは、シグナルを取り込み、視覚化、分析し、アラートを送信する適切なツールを特定することです。ツールを選択するときは、その機能セット、ライセンスモデル、料金、スキル要件、メンテナンスを考慮してください。
機能セット
考慮すべき質問をいくつか紹介します。
-
設定可能性とカスタマイズ。調査エクスペリエンスを簡素化し、MTTR を減らすためにツールが提供する機能はどれですか？ このツールは、アラームの相関関係、メトリクスの数学、テレメトリの欠落や異常検出を処理する柔軟性を提供しますか？
-
粒度。テレメトリシグナルの取り込みと視覚化でサポートされている粒度は何ですか？
-
ペルソナ。このツールは、開発者、プラットフォームエンジニア、その他のペルソナに提供するエクスペリエンスをサポートしていますか？ 技術的ペルソナとビジネスペルソナの両方で機能しますか？
-
ウィジェット。ダッシュボードはどのような種類のウィジェットをサポートしていますか？ ツールではカスタムウィジェットを作成できますか？
-
構築済みのソリューション。価値創出までの時間を短縮するために、ツールにはどのような種類の事前構築されたオブザーバビリティソリューションが用意されていますか？
-
自動化と生成 AI。このツールには、ユーザーとチームの作業を自動化または軽減するのに役立つどのような機能がありますか？ 例えば、自動異常検出、予測分析、その他の生成 AI 機能は、仮定や未知のもの （つまり、認識も完全にも理解もしていないもの) のストレスを軽減するのに役立ちます。このツールは、大規模なデータの分析を強化するための生成 AI/ML モデルの使用をサポートしていますか？ AIOps を自動化して実装するオプションはありますか？
-
セキュリティ。 ツールがサポートする認証と認可の統合の種類 ユーザーエクスペリエンスとログインエクスペリエンスは組織のニーズを満たしていますか？
-
OpenTelemetry のサポート。ツールとエージェントは OpenTelemetry をサポートしていますか？ ほとんどのオブザーバビリティプラットフォームは OpenTelemetry 互換シグナルの取り込みをサポートしていますが、すべてのエージェントがこれらのシグナルをオブザーバビリティプラットフォームに転送するための設定オプションを提供するわけではありません。
-
統合。ツールにはどのような統合が用意されていますか？ アラートを Slack に送信する必要があるか、チームメンバーにページングする必要があるか、解決を自動化する必要があるかを検討してください。
-
スケーラビリティ。ツールのスケーラビリティとパフォーマンスはどの程度ですか？ オブザーバビリティソリューションは、需要と使用量の増加に応じてスケールする必要があるため、アプリケーションが使用できない場合でも診断を提供できます。
-
サポート。どのようなサポートモデルが提供されますか？ オブザーバビリティツールは、MTTR とアプリケーションの可用性の目標またはサービスレベルアグリーメント (SLAs) を満たすために、アプリケーションが失敗した場合でも使用できる必要があります。オープンソースソリューションは、限定的な正式なサポートを提供する場合があります。
ライセンスとデプロイモデル
ソリューションのライセンスモデル (オープンソースまたは商用) とデプロイモデル (セルフホストまたはクラウドベースの) を検討してください。多くの場合、オープンソースオプションは前払いコストが低くなりますが、価値を提供する前に、デプロイ、セットアップと設定、メンテナンス、チームのスキルアップにより多くの時間が必要になる場合があります。オープンソースオプションを検討している場合は、オブザーバビリティの専門家で構成される専任チームが必要になる場合があります。通常、商用ソフトウェアは、価値実現までの時間を短縮し、前払いコストも高くなります。また、専用のオブザーバビリティチームの必要性は、導入、複雑さ、成熟度の向上に伴って時間の経過とともに進化します。セルフホスト型ソリューションでは、クラウドベースのソリューションと比較して、デプロイ、セットアップと設定、メンテナンス、運用オーバーヘッドにより多くの時間が必要です。
料金ディメンション
ツールの料金モデルは、アプリケーションが新規ユーザー、アーキテクチャフットプリントの拡大、または新機能やアプリケーションを獲得すると、総所有コスト (TCO) にどのように影響しますか？ たとえば、一般的なライセンスモデルの中には、永続的なものもあれば、サブスクリプション、名前付きユーザー数、消費量、ボリュームに基づくものもあります。アプリケーションとオブザーバビリティツールがどのように使用量をスケールインするか、ライセンスモデルがツールのコストにどのように影響するかを検討してください。
チームスキル
現在のスキルセットとチームの成熟度に応じて、どの程度のスキル向上が必要かを決定する必要があります。ベンダーがチームのトレーニングのためにどのようなサポートを提供しているかを検討します。また、組織構造が選択したツールの設定と管理をサポートしているかどうかも検討してください。例えば、OpenTelemetry を選択した場合は、オブザーバビリティを専門とする別のチームを設定することを検討する必要があります。
オペレーションとメンテナンス
以下の質問を評価します。
-
オブザーバビリティエージェントまたはコレクターはどのようなデプロイオプションを提供しますか？ これらのオプションはアーキテクチャの要件を満たしていますか？ たとえば、オブザーバビリティツールにコンテナ化されたデプロイを使用する場合、デーモンセットまたはサイドカーをサポートしていますか？ セキュリティやその他のすべてのプロセスとの整合性を確保するために、運用チームが実行または使用する必要がある追加のステップやツールは何ですか？
-
ソリューションを維持するためにどのような労力が必要ですか？ エージェントまたはコレクターを更新するプロセスはどの程度シンプルまたは自動化されていますか？ フルマネージド型およびクラウドベースのオブザーバビリティインターフェイスは、通常、自己デプロイ型およびホスト型アプリケーションと比較して運用オーバーヘッドが低くなりますが、エージェントまたはコレクターの管理は変わりません。チーム構造を考慮し、選択したオプションを維持するための人的コストを考慮してください。
アプリケーションを計測する
前のセクションの質問に対する回答は、アプリケーションを計測するために必要な情報を提供します。つまり、テレメトリ信号をキャプチャし、動作を測定、監視、検証するコードを追加します。アプリケーションの言語に OpenTelemetry SDK SDKs などの SDK を使用して、アプリケーションを自動的に計測できます。ギャップを埋め、end-to-endの可視性を確保するために、手動計測コードを追加する必要がある場合があります。追加するテレメトリは意図的に行い、前のステージで確立した 1 つ以上の SLIs と SLOs に接続できることを確認してください。
テレメトリを収集する
ステージ 1 で優先順位を付けた結果に合わせて、関連するテレメトリシグナルを取り込むようにテレメトリコレクターまたはエージェントを設定します。
オブザーバビリティコンポーネントを実装する
テレメトリが流れ、オブザーバビリティプラットフォームに取り込まれたら、ダッシュボード、アラート、プレイブック、ランブックを作成します。
-
ダッシュボード： 優先順位付けされた結果に関連する現在および過去の傾向を視覚的に表現するなど、関連情報を含むダッシュボードを作成します。ステージ 1 で定義したステークホルダーがこれらのダッシュボードを利用できるようにします。詳細については、Amazon Builders' Library ウェブサイトの「Building dashboards for operational visibility
」を参照してください。 -
アラート： 結果にリスクがあるか、違反している場合にチームに通知するためのアラートを定義します。セキュリティとパフォーマンスの問題に関するアラートを追加することを検討してください。以下を採用することでアラートを最適化し、アラートの疲労とコストを削減します。
-
異常検出を使用して、頻繁な調整が必要なハードしきい値の設定を回避し、不明なものの発生を減らします。
-
各メトリクスに個別のアラートを設定する代わりに、複数の関連メトリクスを一緒に見るインテリジェントなアラートの組み合わせを使用します。たとえば、CPU、メモリ、応答時間に個別のアラートを設定する代わりに、これらのメトリクスがまとめて実際の問題を示している場合にのみトリガーする意味のあるアラートを 1 つ作成します。このアプローチはアラートノイズを大幅に削減し、分離されたメトリクスの急増に対応するのではなく、チームが実際のサービスに影響する問題に集中するのに役立ちます。
-
ユーザーエクスペリエンスまたは結果がリスクにさらされている場合にのみアラートを生成します。たとえば、アプリケーションにアクティブなユーザーがいない場合、自動アップグレードによって引き起こされる CPU スパイクに関するアラートが表示されないようにしてください。
-
-
プレイブック: プレイブックは、インシデントやアラートに応答するユーザーにメンタルモデルとコンテキストを提供し、根本原因をより迅速に特定するのに役立ちます。高度に結合された複雑なアプリケーションと、計測が不足しているがステージ 1 で特定して優先順位を付けた結果に直接影響するアプリケーション用のプレイブックを作成することを検討してください。
-
ランブック: ランブックを使用して、インシデントまたはアラートの解決に必要なステップを定義します。
オブザーバビリティシステムを検証する
ソフトウェア開発ライフサイクル (SDLC) を通じて、システムテスト中にダッシュボードが期待される動作と更新を提供することを検証します。カオスエンジニアリングを実装し、プレイブックとランブックに記載されているステップを検証して、それらが正確であり、目的を果たしていることを確認します。また、アラートの所有権とエスカレーションパスを検証する必要があります。
