セルフサービス型オブザーバビリティ：セルフサービスを通じてオブザーバビリティツールの活用を促進する方法

この記事の対象読者は、組織内でオブザーバビリティツールの活用を推進する立場にある方です。プラットフォームエンジニアリングチームやオブザーバビリティCoEのメンバー、あるいは組織内でオブザーバビリティの推進者と見なされている方が対象となります。

強力なオブザーバビリティツールセットを導入したものの、利用が定着せず、リクエストが山積し、定型作業に追われるばかりで、高度なオブザーバビリティプラクティスの構築に取り組む余裕がない。また、ツールの導入が期待したほど広がらず、プラットフォームの価値が十分に発揮されていない。

このような状況を打開するのがセルフサービス型オブザーバビリティです。

このブログ記事では、セルフサービス型オブザーバビリティを取り入れることが今や必須である理由、取り入れなかった場合のデメリット、サポートチームの負担を増やすことなくオブザーバビリティツールの活用を組織全体に広げていくための主な考慮事項をご紹介します。

セルフサービス型オブザーバビリティとは

セルフサービス型オブザーバビリティとは、組織内の各チームが独自にオブザーバビリティ資産を構築、管理、改善できるようにするためのサービス提供モデルです。リクエスト型のプロセスのみに依存した方法から脱却し、特定のチームや担当者に負担が集中するのを避けることができます。オブザーバビリティ資産には以下のものがあります。

• ダッシュボード
• ディテクター
• サービスレベル目標/指標(SLO/SLI)
• ログパイプライン
• テレメトリ設定

セルフサービス型オブザーバビリティは、自己管理形式のオブザーバビリティを実践するためのフレームワークであり、システムの構築と運用に最も深く関わるチームがシステムの完全な所有権を持ちます。これにより、各チームには以下のようなメリットがもたらされます。

• サービスの動作を理解する
• パフォーマンスの低下を早期に検出する
• スタックの変化に合わせて可視性を継続的に向上させる

セルフサービス化は、ルールを取り払って、各チームにツールを制約なしに使ってもらうということではありません。その目的は、有意義で持続可能なオブザーバビリティを構築するために必要な手段、スキル、パターンをエンジニアに提供することです。

セルフサービス型オブザーバビリティのメリット

セルフサービス型への移行で重要なのは、オブザーバビリティツールの活用を促し、その投資による 真の価値の実現 を推進するという点です。各チームがツールを有効活用することで、組織全体で以下のメリットが得られます。

• カバー範囲の拡大
• インシデント対応の迅速化
• ROIの向上

また、オブザーバビリティチームとプラットフォームエンジニアリングチームの負担を軽減して、技術に詳しくないユーザーの支援、統合の強化、タグ付けやテレメトリ収集の基準の改善、パイプラインやAPIを使ったオブザーバビリティの自動化など、より重要な業務に集中してもらうことができます。

セルフサービス型は、秩序をなくすのではなく、ユーザーの能力を活かすことで秩序あるシステムを拡張していくためのフレームワークです。

従来の監視モデルの問題点

私はSplunk社員として、あらゆる形態や規模の組織と仕事をしています。その中には、オブザーバビリティプラクティスを精力的に拡張している組織もあれば、従来の監視サービスモデル、具体的にはフルサービス提供モデルに沿ったオブザーバビリティプラクティスから脱却できていない組織もあります。

フルサービスモデルがどのようなものかを簡単な例でご説明しましょう。あるチームが次のようなリクエストを出します。

• 「このサービスのログを追加できますか？」
• 「新しいAPIの状況を表示するダッシュボードを作ってください」

そして対応を待ちます。それは数日かもしれませんし、数週間かもしれません。ときにはリクエストが放置されることもあるでしょう。

リクエストはすべて、ごく簡単なものであっても、中央の順番待ちのキューを経由する必要があります。これはリクエストする側とされる側の両者にデメリットをもたらします。リクエストする側は、順番を待たなければなりません。リクエストされる側は、付加価値の低い反復的な作業に追われます。プラットフォームの統合、自動化、パターン開発といったオブザーバビリティの戦略的イニシアチブに取り組めず、リクエスト処理がボトルネックになってしまいます。

その結果、組織全体で効率が低下します。

このモデルでは、組織の成長に合わせてオブザーバビリティを拡張していくことができません。イノベーションのペースに合わせてオブザーバビリティを拡張するには、基準とパターンを明確にし、支援体制を整えることで、各チームが自律的にオブザーバビリティを推進できるようにする必要があります。

影響：機会、コンテキスト、価値の喪失

オブザーバビリティをフルサービスモデルでのみ導入する場合、その影響は運用や組織全体にまで及びます。業務の効率が低下し、可視化の盲点が生まれ、オブザーバビリティ投資のビジネス価値を最大限に引き出せません。その結果、以下の問題が生じます。

• 一貫性のない計装：一部のサービスは詳細な情報まで収集でき、一部のサービスはほとんど可視化できない状態に陥ります。そのため、環境全体で一貫したベースラインを確立できなくなります。
• 重要なアラートの見落とし：各システムに最も深く関わるチームに可視化の権限がないため、重要なシグナルが大量のノイズに埋もれたり、アラート自体が設定されなかったりといった事態に陥ります。
• オンボーディングの遅れ：ダッシュボード、ディテクター、インテグレーションの設定待ちで新規のサービスやプロジェクトの進捗が妨げられます。
• 利用率の低下：ツールがあっても、あまり使われない状況になります。フルサービスのみのモデルでは拡張が制限されます。
• 所有権のサイロ化：オブザーバビリティは自分の仕事ではないという意識が広まると、インシデント対応時に責任の所在が曖昧になります。
• オブザーバビリティの負債化：オブザーバビリティが検出、調査、解決を加速させるどころか、そのプロセスを妨げ、負担を増やすことになります。

その結果、可視性が低下し、MTTRが長引き、ツールがあまり使われなくなって、カスタマーエクスペリエンスを保護するために必要なインサイトをエンジニアリングチームが得られなくなります。

フルサービス型のオブザーバビリティが有効な場面

念のために付け加えておきますが、フルサービス型のオブザーバビリティが決して悪いわけではありません。実際、多くの組織にとって不可欠なものです。ITチームの人数が少ない場合やエンジニアリング支援が直接受けられない事業部門の場合、あるいは高度なユースケース(経営幹部向けダッシュボードや領域横断的なイベント収集など)が必要な場合は、通常、専任のチームに一任する必要があります。

ただし、フルサービスモデルを既定路線とするのは避けるべきです。

セルフサービス：責任共有型のオブザーバビリティ

SREに着想を得た「開発者は運用にも責任を持つ」という考え方が組織内に浸透すると、オブザーバビリティの所有権もセルフサービスフレームワークを通じて共有責任になっていきます。これには以下のメリットがあります。

• 重要なテレメトリを確実に設定できる
• 実用的なアラートを生成できる
• サービスの進化に合わせて可視性を拡大できる

重要な考慮事項：オブザーバビリティプラットフォームのセルフサービス対応状況

セルフサービス型オブザーバビリティに移行する前に、次の点を確認する必要があります。

現在使用しているオブザーバビリティプラットフォームはセルフサービスに対応できるか

各チームが所有権を持つのではなく専任チームが一元管理することを想定したレガシーツールでは、オブザーバビリティの導入を拡大するのは困難です。こうしたプラットフォームは、運用だけでも、極めて専門的な知識、厳格なUIパス、深い暗黙知が必要になることが珍しくありません。そのため、今日の組織で求められるスピード、拡張性、チームベースの提供モデルには対応できません。

オブザーバビリティツールの活用を促進し、価値を実現するとともに、オブザーバビリティチームとプラットフォームエンジニアリングチームの負担を軽減して、より重要な業務に集中してもらうには、セルフサービスに対応したオブザーバビリティプラットフォームが不可欠です。

セルフサービス対応のオブザーバビリティプラットフォームが提供する機能

セルフサービスに対応したオブザーバビリティプラットフォームは以下の機能を備えています。

• プログラムによる設定と自動化：API、SDK、Terraformプロバイダーを通じて、ディテクター、ダッシュボード、アクセスポリシー、アラートルールをコードとして作成および管理します。この機能は「Observability as Code」と呼ばれます。

• マルチテナントと可視化範囲の設定：チーム、サービス、事業部門ごとにオブザーバビリティデータを論理的に分離します。これにより、各グループがそれぞれにとって重要なデータに集中できます。

• 再利用可能なテンプレートとすぐに使えるコンテンツ：整備されたダッシュボード、分析ワークスペース、ディープダイブナビゲーター、最適な設定などを提供して、早期の価値実現を支援します。

• 埋め込み式のマニュアルとAI支援によるワークフロー：外部の情報を参照しなくても、製品に組み込まれたガイドを使いながら機能を覚え、カバー範囲を検証し、トラブルシューティングを行うことができます。

• OpenTelemetryとOTLPのサポート：これらをネイティブでサポートしていれば、ベンダーロックインの回避、テレメトリ収集の標準化、データの取り込みの簡素化が実現し、データ活用に集中できます。

• わかりやすいユーザーエクスペリエンスでのインサイト提供：コンテキストに沿って関連コンテンツを自動的に提示し、機能をまたいでメトリクス、トレース、ログ、アラートをリンクできれば、シグナルをすばやく相関付けることができます。

• エンタープライズレベルのObservability-as-a-Service：以下の機能をサポートします。

  • オブザーバビリティパイプライン管理：テレメトリを集約、フィルタリング、補強し、バックエンド間で転送します。
  • トークン管理：大規模環境でのアクセスの委任や取り込みの管理を安全に行えます。
  • 使用量に関するメトリクスとコストの可視化：使用量に基づくチャージバック、最適化、ビジネスの透明性確保が可能になります。

プラットフォームにこれらの基本機能がない場合、セルフサービス型への移行は難しいというよりも不可能です。

セルフサービス型のオブザーバビリティの構築方法：基盤となる6項目

お使いのオブザーバビリティプラットフォームがセルフサービスに対応していることを確認したら、次に進みましょう。次の課題は、その基盤の構築とオブザーバビリティの拡大です。

このセクションの内容は特に、オブザーバビリティプラットフォームのオーナー、管理者、CoEメンバー、組織全体でのオブザーバビリティツールの活用を推進する担当者に役立ちます。ここでは、各チームがオブザーバビリティツールを自ら活用してボトルネックを解消できるようにし、サポート担当チームの負担を軽減するための基本事項を簡単にご説明します。

ツールへのアクセスを開放するだけでは、セルフサービス型オブザーバビリティは実現できません。適切な仕組み、方針、サポート体制を整備することで、利用率と成熟度を高めて、ビジネス価値を促進することも必要になります。

セルフサービスの基盤

成果を生み出すには強固な基盤が不可欠です。まずは、先入観を捨てて準備に着手し、必要な知識をユーザーに提供します。

• 手軽に利用できる基礎トレーニングを提供する：オブザーバビリティの基礎知識を身に付けてもらい、組織の環境に合わせたツールのウォークスルーを実施します。トレーニングでは以下のような内容を取り上げます。

  • コードのインストルメンテーション(計装)の方法
  • オブザーバビリティプラットフォームへのログイン方法
  • ツールを使用すべき状況とその理由

• 実践に進むための前提条件を明確にする：トレーニングの完了、アクセストークンやログイン資格情報の取得などの条件を決めます。

• フルサービス型オブザーバビリティのサポートによって、ユーザーをセルフサービス型へと導く：この「魚を与えるのではなく、釣り方を教えよ」のアプローチは、セルフサービスの利用を加速させ、自動化の必要な箇所を特定するために役立ちます。

フレームワーク、パターン、導入支援

正しい活用方法を簡単に実行できるよう支援します。

• 初心者向けテンプレートを用意する：一般的なサービスやユースケースのベストプラクティスとなる「ゴールデンパス」を提供します。
• 技術ガイダンスを共有する：テレメトリ設定、アラート設定、タグ付け規則、KPI設計などに関するガイダンスを提供します。オブザーバビリティエージェントを標準イメージや「as-Code」モジュール/設定ファイルに含めることも検討しましょう。
• 実例を示す：Terraform、APIの使用法(実際のcURLの例など)、トークン管理を実例で示します。

エンジニアリングへのオブザーバビリティの組み込み

オブザーバビリティは後付けではなく構築時点から組み込むのが最も効果的です。

• オブザーバビリティの設定をCI/CDパイプラインに直接組み込む：これにより、CI/CDパイプラインからのデプロイ時に、ダッシュボードやディテクターなどのオブザーバビリティ設定が常に含められるようになります。
• オブザーバビリティを開発プロセスに統合する：内部開発者プラットフォーム(IDP：Internal Developer Platform)ツールや開発者ワークフローに統合します。
• タグ付けとテレメトリ収集のプラクティスを標準化する：環境全体で共通のプラクティスを確立します。
• 他のチームの取り組みを紹介する：先行して取り組んでいるチームの事例を共有します。

大規模導入への対応

専任チームに大きな負担がかからないやり方で各チームへのサポートを強化します。

• オブザーバビリティのチャンピオンを育成する：各領域やチーム内で導入に積極的なメンバーに知識を共有します。
• 手軽で使いやすいサポートチャネルを用意する：Office Hours、専用のSlackチャネル、オンボーディングガイドなどを提供します。
• 製品に組み込まれたAIアシスタントやドキュメントを活用する：これにより、よくある質問やユースケースで一般的な問題をユーザーが自ら解決できます。

(参考：Splunk Observability CloudのAI機能)

インサイトに基づく改善

オブザーバビリティプラットフォームを活用してツールの定着を支援します。

• オブザーバビリティツールの利用状況を追跡する：SSOログイン、資産の作成、アラートの量、チームのアクティビティなどを監視します。
• チームごとの運用状況を評価する：支援が必要なチーム(利用率が低い、効率的に利用できていないなど)や、成果をあげているチームを特定します。
• 利用状況データを活用する：イネーブルメントやサポートモデルの強化に活用します。

文化、成長、評価

オブザーバビリティを単なるインシデント対応にとどまらない、重要な取り組みとして位置づけます。そうすることで、各チームはオブザーバビリティの仕組みをより深く理解し、自信を持って取り組めるようになります。

• チームの成果を発表する：効果的なダッシュボードを作成したチームや、シグナルの品質を向上させたチームを表彰します。
• 優れた事例を組織全体で共有する：デモ、ニュースレター、ショーケースなどで紹介します。
• オブザーバビリティへの積極的な取り組みを評価する：各人の取り組みをキャリアアップや人事評価と連携させます。

セルフサービス型への移行によるオブザーバビリティの拡大

チケットを増やし、管理者を増やし、プロセスを増やしても、オブザーバビリティを拡大することはできません。そうするためには、ボトルネックを解消し、チームが自主的にオブザーバビリティに取り組めるようにすることが必要です。

セルフサービス型オブザーバビリティは、単なるサービス提供モデルではなく、オブザーバビリティツールの価値を何倍にも高めるための実践手段でもあります。適切なプラットフォーム、構成、イネーブルメントを確立すれば、すべてのチームが、レジリエンス、スピード、インサイトを強化するための武器としてオブザーバビリティを活用できるようになります。

オブザーバビリティプラクティスの成熟度を向上：実践方法

このブログ記事のようなオブザーバビリティコンテンツにご興味をお持ちであれば、このシリーズの他のブログをぜひご覧ください。

• 階層型オブザーバビリティ：オブザーバビリティ機能を優先度に沿って成熟させる方法

実際にお試しになりたい場合は、Splunk Observability Cloudの無料トライアル版で、セルフサービス型のオブザーバビリティに対応した機能を体験していただけます。