対象読者
この連載では以下の読者を想定しています。
- オブザーバビリティやOpenTelemetryに興味がある人
- SREやDevOps、Platform Engineeringに取り組んでいるエンジニア
- バックエンド開発者、クラウドエンジニア、インフラエンジニア
OpenTelemetryの導入。どこから、何から始めよう？
前回までの連載で以下のようなテーマを扱ってきました。
- 第1回：オブザーバビリティとは何か、OpenTelemetryとは何か
- 第2回：オブザーバビリティを支えるテレメトリーデータとは何か、どう活用するか
- 第3回：OpenTelemetry Collectorによって、どのようにデータを扱うか
- 第4回：実践！OpenTelemetryでの計装
- 第5回：OpenTelemetryのトラブルシュートをする
まだご覧になっていない方は、是非ご一読ください。
第6回となる今回は、実際に組織へ展開する方法を議論します。
“OpenTelemetryを使いたい！” と思われたとき、ではどこから始めましょうか。
第一歩は、もちろんあなたのプロジェクトです。
いきなり組織全体に展開しようとしても、例えば計装するメリットが分からない、性能への影響が心配、開発工数が増大するのではなどの反対意見が出てくるケースが多いです。
そのため、ある程度戦略的に進めていく必要があります。
そのうえで、いくつか参考になるかもしれないヒントはこちらです。
導入を考えたとき、最初に陥りがちな罠
なぜOpenTelemetryを導入するか目的を明確にする
OpenTelemetryを導入することを目的としてはいけません。
この連載のタイトルにもある通り、オブザーバビリティの向上・実践のためにOpenTelemetryを導入するのです。
これは組織やチームが抱えている現状の開発・運用に関する課題や、「もっとこうなったらいいのに」という思いに基づいて考えていく必要があります。多くの場合、以下のような課題・理想を持つ方が多いと思います。例えば、「トラブルシューティングを迅速化したい」、「インシデント調査の迷宮入りを減らしたい」、「ユーザーからのクレームトリガーのインシデント対応はやめたい」、「プロアクティブにリソースコントロールしたい」といった目の前の課題や、最終的な目標として「開発効率性・リソーススピードを高めたい」、「インシデントを防止したい」などです。
最初から厳格なROIを考えない
「オブザーバビリティ」はこれから実践と理解が進んでいく分野です。
まずはやってみましょう。
どのような効果が得られるか綿密に検討しなければ導入できないシステムであれば、恐らくターゲットではありません。後回しにしましょう。
一方で、データを入れ始めると「こんなケースにも使えるかもしれない」と想像が膨らむかもしれません。
