盲点と推測を排除し、監視ツールの切り替えの手間を省きましょう。Splunk Observability CloudとAI Assistantを使えば、1つのソリューションですべてのメトリクス、ログ、トレースを自動的に相関付けることができます。
                オブザーバビリティツールの活用を促進するには、ボトルネックを解消する必要があります。セルフサービス型のアプローチは、少数の限られたチームだけでなくすべてのチームがオブザーバビリティツールを簡単に活用、導入、拡張できるようにするための、唯一の持続可能なモデルです。ただし、このモデルに移行するには、単にユーザーがツールにアクセスできるようにするだけでなく、設計から見直す必要があります。
この記事の対象読者は、組織内でオブザーバビリティツールの活用を推進する立場にある方です。プラットフォームエンジニアリングチームやオブザーバビリティCoEのメンバー、あるいは組織内でオブザーバビリティの推進者と見なされている方が対象となります。
強力なオブザーバビリティツールセットを導入したものの、利用が定着せず、リクエストが山積し、定型作業に追われるばかりで、高度なオブザーバビリティプラクティスの構築に取り組む余裕がない。また、ツールの導入が期待したほど広がらず、プラットフォームの価値が十分に発揮されていない。
このような状況を打開するのがセルフサービス型オブザーバビリティです。
このブログ記事では、セルフサービス型オブザーバビリティを取り入れることが今や必須である理由、取り入れなかった場合のデメリット、サポートチームの負担を増やすことなくオブザーバビリティツールの活用を組織全体に広げていくための主な考慮事項をご紹介します。
セルフサービス型オブザーバビリティとは、組織内の各チームが独自にオブザーバビリティ資産を構築、管理、改善できるようにするためのサービス提供モデルです。リクエスト型のプロセスのみに依存した方法から脱却し、特定のチームや担当者に負担が集中するのを避けることができます。オブザーバビリティ資産には以下のものがあります。
セルフサービス型オブザーバビリティは、自己管理形式のオブザーバビリティを実践するためのフレームワークであり、システムの構築と運用に最も深く関わるチームがシステムの完全な所有権を持ちます。これにより、各チームには以下のようなメリットがもたらされます。
セルフサービス化は、ルールを取り払って、各チームにツールを制約なしに使ってもらうということではありません。その目的は、有意義で持続可能なオブザーバビリティを構築するために必要な手段、スキル、パターンをエンジニアに提供することです。
セルフサービス型への移行で重要なのは、オブザーバビリティツールの活用を促し、その投資による真の価値の実現を推進するという点です。各チームがツールを有効活用することで、組織全体で以下のメリットが得られます。
また、オブザーバビリティチームとプラットフォームエンジニアリングチームの負担を軽減して、技術に詳しくないユーザーの支援、統合の強化、タグ付けやテレメトリ収集の基準の改善、パイプラインやAPIを使ったオブザーバビリティの自動化など、より重要な業務に集中してもらうことができます。
セルフサービス型は、秩序をなくすのではなく、ユーザーの能力を活かすことで秩序あるシステムを拡張していくためのフレームワークです。
私はSplunk社員として、あらゆる形態や規模の組織と仕事をしています。その中には、オブザーバビリティプラクティスを精力的に拡張している組織もあれば、従来の監視サービスモデル、具体的にはフルサービス提供モデルに沿ったオブザーバビリティプラクティスから脱却できていない組織もあります。
フルサービスモデルがどのようなものかを簡単な例でご説明しましょう。あるチームが次のようなリクエストを出します。
そして対応を待ちます。それは数日かもしれませんし、数週間かもしれません。ときにはリクエストが放置されることもあるでしょう。
リクエストはすべて、ごく簡単なものであっても、中央の順番待ちのキューを経由する必要があります。これはリクエストする側とされる側の両者にデメリットをもたらします。リクエストする側は、順番を待たなければなりません。リクエストされる側は、付加価値の低い反復的な作業に追われます。プラットフォームの統合、自動化、パターン開発といったオブザーバビリティの戦略的イニシアチブに取り組めず、リクエスト処理がボトルネックになってしまいます。
その結果、組織全体で効率が低下します。
このモデルでは、組織の成長に合わせてオブザーバビリティを拡張していくことができません。イノベーションのペースに合わせてオブザーバビリティを拡張するには、基準とパターンを明確にし、支援体制を整えることで、各チームが自律的にオブザーバビリティを推進できるようにする必要があります。
オブザーバビリティをフルサービスモデルでのみ導入する場合、その影響は運用や組織全体にまで及びます。業務の効率が低下し、可視化の盲点が生まれ、オブザーバビリティ投資のビジネス価値を最大限に引き出せません。その結果、以下の問題が生じます。
その結果、可視性が低下し、MTTRが長引き、ツールがあまり使われなくなって、カスタマーエクスペリエンスを保護するために必要なインサイトをエンジニアリングチームが得られなくなります。
念のために付け加えておきますが、フルサービス型のオブザーバビリティが決して悪いわけではありません。実際、多くの組織にとって不可欠なものです。ITチームの人数が少ない場合やエンジニアリング支援が直接受けられない事業部門の場合、あるいは高度なユースケース(経営幹部向けダッシュボードや領域横断的なイベント収集など)が必要な場合は、通常、専任のチームに一任する必要があります。
ただし、フルサービスモデルを既定路線とするのは避けるべきです。
SREに着想を得た「開発者は運用にも責任を持つ」という考え方が組織内に浸透すると、オブザーバビリティの所有権もセルフサービスフレームワークを通じて共有責任になっていきます。これには以下のメリットがあります。
セルフサービス型オブザーバビリティに移行する前に、次の点を確認する必要があります。
現在使用しているオブザーバビリティプラットフォームはセルフサービスに対応できるか
各チームが所有権を持つのではなく専任チームが一元管理することを想定したレガシーツールでは、オブザーバビリティの導入を拡大するのは困難です。こうしたプラットフォームは、運用だけでも、極めて専門的な知識、厳格なUIパス、深い暗黙知が必要になることが珍しくありません。そのため、今日の組織で求められるスピード、拡張性、チームベースの提供モデルには対応できません。
オブザーバビリティツールの活用を促進し、価値を実現するとともに、オブザーバビリティチームとプラットフォームエンジニアリングチームの負担を軽減して、より重要な業務に集中してもらうには、セルフサービスに対応したオブザーバビリティプラットフォームが不可欠です。
セルフサービスに対応したオブザーバビリティプラットフォームは以下の機能を備えています。
プラットフォームにこれらの基本機能がない場合、セルフサービス型への移行は難しいというよりも不可能です。
これらの必須機能を提供できるプラットフォームをお探しですか?Splunk Observability Cloudは、エンドツーエンドの可視化と組織レベルのセルフサービス型オブザーバビリティを実現する、先進的なオブザーバビリティプラットフォームです。
お使いのオブザーバビリティプラットフォームがセルフサービスに対応していることを確認したら、次に進みましょう。次の課題は、その基盤の構築とオブザーバビリティの拡大です。
このセクションの内容は特に、オブザーバビリティプラットフォームのオーナー、管理者、CoEメンバー、組織全体でのオブザーバビリティツールの活用を推進する担当者に役立ちます。ここでは、各チームがオブザーバビリティツールを自ら活用してボトルネックを解消できるようにし、サポート担当チームの負担を軽減するための基本事項を簡単にご説明します。
ツールへのアクセスを開放するだけでは、セルフサービス型オブザーバビリティは実現できません。適切な仕組み、方針、サポート体制を整備することで、利用率と成熟度を高めて、ビジネス価値を促進することも必要になります。

成果を生み出すには強固な基盤が不可欠です。まずは、先入観を捨てて準備に着手し、必要な知識をユーザーに提供します。
正しい活用方法を簡単に実行できるよう支援します。
オブザーバビリティは後付けではなく構築時点から組み込むのが最も効果的です。
専任チームに大きな負担がかからないやり方で各チームへのサポートを強化します。
(参考:Splunk Observability CloudのAI機能)
オブザーバビリティプラットフォームを活用してツールの定着を支援します。
オブザーバビリティを単なるインシデント対応にとどまらない、重要な取り組みとして位置づけます。そうすることで、各チームはオブザーバビリティの仕組みをより深く理解し、自信を持って取り組めるようになります。
チケットを増やし、管理者を増やし、プロセスを増やしても、オブザーバビリティを拡大することはできません。そうするためには、ボトルネックを解消し、チームが自主的にオブザーバビリティに取り組めるようにすることが必要です。
セルフサービス型オブザーバビリティは、単なるサービス提供モデルではなく、オブザーバビリティツールの価値を何倍にも高めるための実践手段でもあります。適切なプラットフォーム、構成、イネーブルメントを確立すれば、すべてのチームが、レジリエンス、スピード、インサイトを強化するための武器としてオブザーバビリティを活用できるようになります。
このブログ記事のようなオブザーバビリティコンテンツにご興味をお持ちであれば、このシリーズの他のブログをぜひご覧ください。
実際にお試しになりたい場合は、Splunk Observability Cloudの無料トライアル版で、セルフサービス型のオブザーバビリティに対応した機能を体験していただけます。
Splunkプラットフォームは、データを行動へとつなげる際に立ちはだかる障壁を取り除いて、オブザーバビリティチーム、IT運用チーム、セキュリティチームの能力を引き出し、組織のセキュリティ、レジリエンス(回復力)、イノベーションを強化します。
Splunkは、2003年に設立され、世界の21の地域で事業を展開し、7,500人以上の従業員が働くグローバル企業です。取得した特許数は1,020を超え、あらゆる環境間でデータを共有できるオープンで拡張性の高いプラットフォームを提供しています。Splunkプラットフォームを使用すれば、組織内のすべてのサービス間通信やビジネスプロセスをエンドツーエンドで可視化し、コンテキストに基づいて状況を把握できます。Splunkなら、強力なデータ基盤の構築が可能です。