ナビゲーション全体を読み込み中です。

Elevate 2026へのカウントダウンが始まりました。 今すぐ登録 シカゴ、ロンドン、またはシドニーで私たちと一緒に過ごしませんか。

Partners

ドキュメント

LMアカデミー

LMコミュニティ

価格

Platform
解決策
業種
職種
結果はありません。
無料トライアル

14日間フルアクセス LogicMonitor プラットフォーム

ロジックモニターブログ

1万ドルの教訓：SLAを通じて品質文化を構築する

1万ドルのSLA違反による罰金という一つの教訓は、顧客が感じるサービスの質を測るべきだということだ。ここでは、収益を守り、長く有効に機能するSLAを構築する方法を紹介する。

10〜16分
メディ・ダウディ

ニュースレター

最新情報のメール配信を登録

最新のブログ、ホワイトペーパー、電子ガイドなどを直接受信ボックスにお届けします。

シェア

クイックダウンロード:

顧客の視点から測定できないことは、決して約束してはいけない。

  • 稼働率100％という約束一つが、その約束を測定・管理するシステムがなかったために、1万ドルの罰金につながった。

  • SLA（サービスレベル契約）は、顧客の視点から、インターネット経路上の多くの視点から測定することで、より誠実なものとなる。

  • 外部への約束と内部目標を一致させることで、法務、営業、財務、エンジニアリング、運用部門は共通のサービス言語と共通の評価指標を持つことができた。

  • 顧客体験に基づいて自社のSLAプログラムを評価することで、リスクを事前に察知し、約束が破られる前に対応できるようになります。

DoubleClickの創業初期、SaaSがまだアプリケーションサービスプロバイダー（ASP）と呼ばれていた頃、私はQoS（サービス品質）チームの立ち上げを任されました。当初の主な任務は監視システムの構築でしたが、すぐにサービスレベル契約（SLA）の管理に携わることになり、その後、多額の支払いを済ませた後、この業務は極めて重要なものとなりました。 1万ドルの罰金 単一顧客に対するSLA違反について。原因は単純明快だった。誰かが契約書に署名し、 100％稼働時間それは不可能な約束だ。

そのペナルティから学んだ教訓は、それ以来私が携わってきたすべてのサービスに活かされています。それは、顧客の視点から測定できないことは決して約束してはならないということです。優れたSLAは、ユーザーが体験するサービスを様々な視点から測定し、制御可能なものと制御不可能なものを関連付けることにかかっています。この原則は、LogicMonitorが現在自律型ITに取り組む際の中心的な考え方であり、クラウドやSaaSサービスを運営するすべての人にとって、DoubleClickの事例をケーススタディとして改めて取り上げる価値がある理由でもあります。

これは、私たちがどのようにしてSLAを管理し、財政的な損失を食い止め、法務、営業、財務、エンジニアリング、運用といった各部門間で共通のサービス言語を構築したかという物語です。現在SLAを管理している方も、SLAの仕組みに興味がある方も、この記事では私たちが直面した課題、構築した解決策、そしてそれぞれの教訓が現代の業務にどのように活かせるかを解説します。

SLAとは何ですか？

An SLA（サービスレベルアグリーメント） これは、ベンダーと顧客の間で交わされる契約であり、期待されるサービスレベルを概説するものです。この法的枠組みの下で、あなたは サービスレベル目標（SLO）これらは、稼働時間、速度、1秒あたりのトランザクション数などの具体的な指標を定義します。

DoubleClickでは、以下の原則を念頭に置いてSLAを定義しました。

  • 達成可能： 目標は現実的なものでなければならない。
  • 繰り返し可能: 指標は一貫して測定可能であるべきである。
  • 測定可能： パフォーマンスは定量化可能であるべきだ。
  • 意味がある： これらの指標はビジネスにとって重要であるべきだ。
  • 相互に受け入れ可能： 両当事者は条件について合意する必要がある。

SLAは顧客とベンダーの両方にメリットをもたらします。顧客にとっては、 客観的な評価基準 そして、劣悪なサービスからの保護も提供する。ベンダーにとっては、明確な期待値を設定し、品質改善を促すインセンティブとなる。

グラウンド・ゼロ、ディスカバリー

SLAの問題に初めて取り組んだとき、私たちは危機的な状況にありました。最初のステップは、すべての契約を一覧化し、SLAとSLOを抽出し、関連するペナルティを文書化することでした。この情報をデータベースに保存し、ビジネスリーダー、法務チーム、経営幹部を含む関係者に対し、SLAの重要性について啓発活動を開始しました。

当初から私たちは エンドユーザー体験に基づくSLAつまり、パフォーマンスをサーバー側だけでなくユーザー側からも測定する必要があるということです。この点が、今日でも多くのSLAプログラムが失敗している原因となっています。社内ダッシュボードは、サーバーの状態、CPU、社内サービスの稼働時間など、チームが管理できる範囲を測定する傾向がありますが、これは必ずしも顧客がインターネット経由で実際に体験する状態とは一致しません。サーバーは正常と報告していても、ユーザーにはタイムアウト、ページの読み込みの遅さ、トランザクションの失敗などが見られることがあります。顧客の視点から、つまり外部から測定することで、SLAプログラムの信頼性が保たれるのです。

普遍的な課題

長年にわたり、多くの企業が同様の問題に直面しているのを見てきました。SREや開発チームの中には、組織が顧客と締結しているSLAを十分に理解していないところがあります。彼らは社内SLOに重点を置きすぎて、それらの指標が契約上の義務とどのように直接結びついているかを見落としていることがよくあります。例えば、多額の罰金を科せられた後、次のような企業は Slack 社内目標と顧客への約束をより整合させるため、SLA（サービスレベル契約）の条項を改訂した。

SLAアプリケーションのパフォーマンス

SLAを確立するということは、契約書に数行の文章を盛り込むだけではありません。私たちが100万ドルを支払った理由は、SLA管理システムが全く導入されていなかったからです。そこで私たちは、管理、監視、報告、コンプライアンス（AMRC）という4つの柱に基づいたサービスレベル管理（SLM）の実践を構築することから始めました。

SLMプロセス

私たちは、ビジネスパートナー、顧客、法務チーム、財務チームと協議し、将来的に高額な損失につながるミスを防ぐためのプロセスを構築しました。このプロセスは「SLAライフサイクル」と名付けられ、有効性を維持し、ビジネス目標との整合性を確保するために四半期ごとに見直されました。

  1. データサイエンスを用いたリスクシミュレーション： 当社のSLMプロセスにおいて最も重要なステップの一つは、社内のデータサイエンティストによるシミュレーションの実施でした。これらのシミュレーションでは、監視ツールから得られた過去のデータを分析し、SLA違反のリスクを評価しました。目標は、顧客の期待に応えつつ、毎日違反するような事態にはならない現実的なSLAを設定することでした。
  2. 「もしも​​」のシナリオ： また、可用性と収益の関係を理解するために、複数の「もしも」シナリオを実行しました。これらのシナリオは、時間帯や曜日によってダウンタイムが収益に与える影響を評価するのに役立ちました。例えば、トラフィックがピークとなる時間帯に10分間システム障害が発生した場合と、ピーク時以外に同じ時間だけシステム障害が発生した場合とで、収益への影響を比較することができました。
  3. SLAデスク： プロセスを効率化するため、2001年にオンラインツール、いわば「SLAデスク」を開発しました。これにより、営業チームは顧客向けにSLAポートフォリオをリクエストできるようになりました。これらのリクエストはQoSチームによって審査・承認され、すべてのSLAが現実的で測定可能であり、当社の能力に見合ったものであることが保証されました。

外部SLAと内部SLAの整合性

私たちが直面した最大の課題の一つは、外部SLA（顧客に約束した内容）と内部SLA（社内で測定した内容）の不一致でした。例えば、顧客は広告配信の稼働時間を要求する一方で、当社の技術チームはサーバーの可用性を測定していました。

この問題を解決するために、外部SLOと内部SLOを整合させ、内部目標（ターゲット）を非常に高い水準に設定しました。これは大きな成果であり、SLAリスク状況を把握し、運用上の卓越性を推進するために、単一の指標に頼ることができるようになりました。当社の技術グループ（運用、エンジニアリングなど）も、ビジネスSLAの概念をより意識するようになり、SLA違反をしないよう細心の注意を払うようになりました。現代のクラウドおよびSaaSの用語で言えば、これは内部SLOとエラーバジェットを契約における顧客向けコミットメントに直接結び付けることで、オンコールエンジニアとアカウントチームの両方に単一のシグナルを提供するという手法です。

モニタリングはSLA成功の鍵

可用性とパフォーマンスの確保のため、当社は3つの合成監視製品を活用しました。社内では、当時としては初期の合成監視およびインフラストラクチャ監視ツールであったSitescopeを17のデータセンターで運用し、さらに2つの外部合成監視製品を使用しました。可能な限り多くのツールから、可能な限り多くのデータポイントを取得したいと考えていました。複数のツールに投資しないわけにはいかないほど、リスクが高かったのです。このSLMプロジェクト全体は、導入と年間運用コストが高額でしたが、適切な方法で実施しない場合のコストも十分に理解していました。

監視のためには、できるだけ多くの視点から、できるだけ頻繁にテストを行う必要があることが明らかになった。

  • チェック頻度が低いと、状況を正しく把握できません。SLOエンドポイントのテストを1時間に1回しか行わない場合、59分間の間隔内で発生した短時間の障害は完全に見逃される可能性があり、長時間の障害の場合はその継続時間が不正確に測定される可能性があります。そうなると、顧客と話し合う際に報告される数値に対する信頼性が損なわれます。
  • 統計的有意性を確保するには、多くのデータポイントが必要です。データセットが小さいと精度と検出力が低下しますが、大きいデータセットは偽陽性や偽陰性を抑制するのに役立ちます。

今日では、その直感は具体的な基準へと昇華されています。すなわち、グローバルな監視ポイントから測定を行い、短時間の障害を検知できる十分な頻度でテストを実施し、契約がかかっている場合でも統計的に信頼できる数値が得られるよう十分なサンプルを収集することです。LMインターネットパフォーマンスモニタリングは、グローバルな監視ポイントネットワークからのデータに基づいてパフォーマンスを測定することで、単一の内部チェックでは見落とされがちな盲点を解消します。

差分パフォーマンス測定（DPM）を入力する

最大の課題の一つは、広告配信速度を効果的に測定し、それをSLAに反映させる方法を見つけることでした。クライアントは自社サイトのパフォーマンスを確認し、急激なパフォーマンス低下に気づいて、それを弊社のシステムに原因があると判断していましたが、弊社のパフォーマンステレメトリでは問題は検出されませんでした。2つのグラフを関連付けることができなかったため、問題が弊社にあるのか、他社にあるのかについて意見が一致しませんでした。

これに対処するために、私たちは次のような方法論を開発しました。 性能差測定 (DPM) 私たちの目標は、DoubleClickのパフォーマンスと可用性を正確に測定し、それが顧客のページにどのような影響を与えるかを把握することでした。また、自分たちが管理できる範囲については責任を負い、責任のなすりつけ合いを避けることも目的としていました。

この手法は、測定結果に文脈を与えるものでした。DPMは明確さと比較可能性をもたらし、SLAから絶対的なパフォーマンス数値を排除しました。振り返ってみると、DPMは現代のオブザーバビリティでは当然のこととされている原則の初期バージョンでした。つまり、自分が責任を負うパフォーマンスを周囲の外部ノイズから切り離すことで、自分の役割に責任を持ち、それを正確に測定できるようにするという原則です。

差別化されたパフォーマンス測定のレシピ（広告を例に）

  1. 広告なしのページと、広告呼び出しが1つだけ掲載されたページの2つを用意してください。
  • ページA＝広告なし
  • ページB＝広告1件
  1. ページ内に他のサードパーティの参照（CDNなど）が含まれていないことを確認してください。
  2. ページサイズ（KB単位）が同じであることを確認してください。
  3. 「ベイク」：両方のページの応答時間を測定すると、次の指標が得られます。
  • 異なる反応 （DR）は（ページBの応答時間）マイナス（ページAの応答時間）となります。
  • 応答率の差 (DRP) = DR / A。（例えば、ページAが2秒、ページBが2.1秒の場合、DRは0.1秒となり、DRPは0.1/2 = 0.05、つまり5%となります。）

このアプローチは、以下の原因によるノイズの除去に役立ちました。

  1. 当社では制御できないインターネット関連の問題（例えば、光ファイバーケーブルの切断など）。
  2. エージェントの不整合を監視する（監視ツールを監視する必要性が高まる）。
  3. その他のサードパーティ製依存関係。

差分パフォーマンス測定（DPM）の影響を視覚化するために、以下のグラフでは2つのシナリオにおける応答時間を比較しています。

シナリオ1： 広告配信会社でパフォーマンスの問題が発生し、顧客のサイトに悪影響が出ました。ベンダーは、時間4から時間8の間でSLAのしきい値を超過しました。

シナリオ2： ウェブサイト自体にパフォーマンス上の問題が発生したが、これは広告配信会社とは無関係である。

報告、透明性、説明責任

1万ドルの罰金処分後、SLA管理は最優先事項となり、CEOに至るまで状況を把握する体制が整いました。当時使用していたサービスレベルレポートツールであるDigitalFuelなどを活用し、コンプライアンス遵守状況と違反状況を毎月報告することで、問題をリアルタイムで検出しました。

2001年末までに、当社は100件を超える運用レベル契約（OLA）を追跡し、DoubleClick社内に品質重視の文化が根付きました。最大の変化はツールではなく、人によってもたらされました。エンジニア、経営陣、営業、法務、財務といったあらゆる部門が同じサービス用語を使い、同じビジネス指標に基づいて自己評価を行うようになり、誰もSLA違反の原因になりたくなくなりました。この共通言語こそが、社内全体で数値の意味を明確にしたのです。

学んだ教訓と今後の展望

DoubleClickで包括的なSLMプロセスを導入したことで、以下のことが可能になりました。

  • 数百件の契約を管理する それぞれ最大5つのSLOを設定可能。
  • 拡張可能なSLAを提供する 新製品にも適応できるもの。
  • 財務リスクを軽減 高額な罰金を回避することによって。
  • 評判を維持する 正確かつ有意義なSLAを提供することによって。
  • リアルタイムで侵害を検知するこれにより、我々は先手を打つことができる。

最大の利点の1つは、SLA違反のリスクを事前に把握できることでした。例えば、ダウンタイムが4分増えると12件の契約違反となり、Xドルの違約金が発生すると予測できました。こうした先見性によって、運用上の意思決定が大きく変わりました。運用チームは、契約違反が収益損失や顧客からの信頼失墜につながる前に、リリースを一時停止したり、変更を保留したり、トラフィックを迂回させたりすることができたのです。

2001年当時、難しかったのは、これらの信号がそれぞれ異なる場所に存在していたことでした。SLAリスクは1つのデータベースに、インフラストラクチャの状態は監視ツールに、インターネットの状態は合成製品に、顧客体験はクライアントが報告するあらゆる情報にそれぞれ存在していました。それらを統合するには、人員と時間が必要でした。それらを1つのシステムで相関させることは、 LogicMonitor 今日もそうです。

LMエンビジョン ハイブリッドインフラストラクチャ、クラウド、アプリケーション全体にわたるテレメトリ基盤を提供します。 LogicMonitorによる合成データおよびインターネットパフォーマンス監視 ユーザーがインターネット経路全体でどのような体験をするかを示し、 エドウィン AI これらのシグナル全体にわたって、ビジネスへの影響に基づいて優先順位を付け、相関関係を統制された優先順位付けされた行動へと転換する理由。

つまり、これらを総合すると、チームはSLAリスク、そのリスクを引き起こしているインフラストラクチャ、その周辺のインターネット依存関係、そしてその背後にあるユーザーへの影響を一つの画面で把握し、約束が破られる前に対応することができるようになるということです。

100万ドルの教訓以来、これを正しく行うことのビジネス上のメリットは変わっていません。SLA違反は、収益リスク、顧客からの信頼の失墜、そして法的・商業的な約束の不履行という、すべてを同時に招きます。顧客の視点からサービスを評価することで、チームはこれら3つすべてを同時に守ることができるのです。

SLA（サービスレベル契約）を軽視する人もいますが、多くの場合、その懐疑的な見方はもっともです。非現実的な保証、実質的な罰則の欠如、あるいは曖昧な測定基準など、質の低いSLAは信頼を損ないます。パケット損失率0%を謳うSLAをよく見かけますが、その測定方法を尋ねると、すぐに意味のないものだと気づきます。こうしたSLAは、SLAという概念全体の評判を落としてしまうのです。

適切に運用されたSLAは不可欠です。顧客とベンダーの認識を一致させ、摩擦を軽減し、責任のなすりつけ合いをなくします。顧客は、紙の上で聞こえの良いだけのSLAではなく、実際に機能する実用的なSLAを求めるべきです。その目的は、ベンダーに責任を負わせ、サービス提供に失敗した場合には、その影響を実感させることです。

すべてのSLAおよびSLOプログラムが今日測定すべきこと

もし私が今QoS（サービス品質）の運用体制を構築するとしたら、すべてのSLA（サービスレベル契約）およびSLO（サービスレベル目標）プログラムに以下の項目を課すでしょう。

  • 可用性と稼働時間： 測定は、サーバーのそばだけでなく、顧客が座っている場所から行う。
  • レイテンシ： ユーザーにとって重要なやり取りにおける応答時間。
  • 取引成功: エンドポイントが応答するかどうかだけでなく、実際のユーザー操作が完了したかどうかも重要です。
  • サードパーティの依存関係: あなたが依存しているものの、制御できないCDN、API、およびサービス。
  • インターネット経路の健全性: お客様のサービスと顧客間のネットワーク状況。
  • ユーザーへの影響を示すシグナル： 誰が、どこで、どの程度影響を受けているかを把握することで、技術的な健全性とビジネスリスクを結びつけることができます。

SLAプログラムの構築または改善をお考えですか？まずは基本と最新のベストプラクティスから始めましょう。

SLAの進化

2001年当時、SLA管理が重要であることは認識していましたが、今日のクラウド主導の世界において、それがこれほど不可欠なものになると予測できた人はほとんどいなかったでしょう。SLAは、単純な稼働時間保証から、レイテンシからデータ所在地まであらゆるものを網羅する複雑な契約へと進化しました。現在では、XLO（Experience Level Objectives：顧客体験レベル目標）という指標が主流となり、サーバーのパフォーマンスだけでなく、顧客体験に焦点を当てるようになっています。この、内部指標から顧客成果への転換こそ、20年以上前に100万ドルの罰金によって痛感させられた教訓なのです。

今日のサービスを運営するあらゆるチームにとって重要な教訓は、優れたSLAは、顧客が感じる感覚に基づいてそれを測定できる能力があってこそ真価を発揮するということです。サービスコミットメントを遵守するには、SLAリスク、インフラストラクチャの状態、インターネットへの依存度、ユーザーエクスペリエンスを1か所で関連付け、違反が発生する前にその状況に基づいて対策を講じる必要があります。現在SLAプログラムを構築または改善している場合は、まず基本原則と、それに関する最新の実践方法から始めましょう。

契約違反が発生する前に、顧客の視点からSLAリスクを評価しましょう。

LogicMonitorは、SLAリスク、そのリスクを引き起こすインフラストラクチャ、インターネット依存関係、およびユーザーへの影響を単一のビューに統合することで、チームがまだ時間があるうちにコミットメントを守るための対策を講じることを可能にします。

よくあるご質問

稼働率100%のSLAが問題となるのはなぜですか？

稼働率100%保証は、実際のインターネット環境において、いかなるサービスも測定・維持できない約束です。DoubleClick社では、このたった一つの約束が1万ドル以上の罰金につながりました。優れたSLA（サービスレベル契約）は、達成可能で、再現性があり、測定可能で、意義があり、かつ双方にとって受け入れ可能な目標を設定するものです。

顧客の視点からSLAを測定するとはどういう意味でしょうか？

これは、サーバー側だけでなく、ユーザーが体験するサービスの状態も測定することを意味します。サーバー側では正常と報告されていても、顧客はタイムアウト、ページの読み込み遅延、トランザクションの失敗などを経験する可能性があります。グローバルな視点から、短時間の障害も見逃さないよう頻繁に外部からの測定を行うことで、契約がかかっている場合でも報告される数値の信頼性を維持できます。

LogicMonitorは、今日のチームにおけるSLAリスク管理にどのように役立つのでしょうか？

LM Envisionは、ハイブリッドインフラストラクチャ、クラウド、アプリケーション全体にわたるテレメトリ基盤を提供します。LogicMonitor Syntheticsとインターネットパフォーマンスモニタリングは、インターネット経路全体でユーザーが体験する状況を示します。Edwin AIはこれらのシグナルを分析し、ビジネスへの影響に基づいて優先順位付けを行います。これにより、チームはSLAリスク、インフラストラクチャ、インターネット依存関係、ユーザーへの影響を1つのビューで確認し、侵害が発生する前に対応することができます。

メフディ・ダウディ著

キャッチポイント ゼネラルマネージャー

Mehdi DaoudiはLogicMonitorのCatchpoint担当GMであり、以前はCatchpointの共同創業者兼CEOを務めていました。IT分野での経験が、ユーザーとして思い描いたデジタルエクスペリエンス・プラットフォームの構築へと彼を導きました。GoogleとDoubleClickで10年以上勤務し、サービス品質、社内外の監視ソリューションの調達、構築、導入、運用を担当し、1日数十億件のトランザクションを処理するDARTインフラストラクチャの監視に携わりました。

免責事項: このブログで述べられている見解は著者の見解であり、LogicMonitor またはその関連会社の見解を必ずしも反映するものではありません。

© LogicMonitor 2026 | 無断複写・転載を禁じます。 | ここで言及されているすべての商標、商号、サービス マーク、およびロゴは、それぞれの会社に帰属します。

関連ブログ

AWS Kinesis 上で OpenTelemetry トレースヘッダーを伝播する方法: パート 3
Blog 可観測性

AWS Kinesis 上で OpenTelemetry トレースヘッダーを伝播する方法: パート 3

Kinesis PartitionKey と ExplicitHashKey を組み合わせることで、OpenTelemetry トレース コンテキストを伝播させつつ、レコードを元のシャードに保持し、順序を維持することができます。
2026 年 10 月 5 日
さらに詳しく
統合クラウド監視がハイブリッドITの盲点を解消する方法
Blog クラウド

統合クラウド監視がハイブリッドITの盲点を解消する方法

現代のITは、パブリッククラウド、データセンター、コンテナ、SaaS、ネットワーク、AIサービスなど、複数の環境にまたがって運用されています。これらの環境が同じ可観測性コンテキストを共有することで、クラウド監視はより大きな価値を発揮します。これにより、チームはサービスの問題をより明確にトラブルシューティングし、クラウド支出を管理し、AIを活用した運用をサポートできるようになります。
2026 年 9 月 30 日
さらに詳しく
WebMCP監視：AIエージェントにとってウェブサイトの稼働時間だけでは不十分な理由
Blog WebMCPモニタリング

WebMCP監視：AIエージェントにとってウェブサイトの稼働時間だけでは不十分な理由

ウェブサイトが正常に見えていても、AIエージェントが誤動作する可能性があります。WebMCPのモニタリングでは、ツール検出からバックエンド応答まで、エージェントの動作全体を検証するために合成テストがどのように使用されるかをご覧ください。
2026 年 9 月 18 日
さらに詳しく