LESSON 30分

ストーリー

田
田中VPoE
プラットフォームの設計ができた。次はそのプラットフォームの上で「何を測るか」を定義する。SLI/SLO体系の組織展開だ
あなた
SLI/SLOは各チームが個別に定義すればいいのでは？
あ
田
田中VPoE
チームごとにバラバラに定義すると、同じサービスティアなのにSLOの基準が異なったり、上流サービスのSLOが下流より緩くて意味をなさない、という状況が起きる。組織として統一された体系が必要だ
あなた
「組織レベル」のSLI/SLO戦略というのは、全社共通のフレームワークを作るということですか
あ
田
田中VPoE
その通りだ。個別のSLO値はチームが決める。だがSLIの選び方、SLOの基準水準、エラーバジェットのポリシー — これらの「枠組み」を組織として標準化する。これがSLI/SLO体系だ

SLI/SLOの基本概念の復習

SLI（Service Level Indicator）

概念説明
定義サービスの品質を定量的に測定する指標
特徴0-100%の範囲で表現される比率
計算式Good Events / Total Events × 100%

SLO（Service Level Objective）

概念説明
定義SLIの目標値
特徴「このSLIはX%以上であるべき」という目標
例「可用性SLIが99.9%以上」

SLA（Service Level Agreement）

概念説明
定義顧客との契約上の合意
特徴SLOを下回った場合のペナルティ（返金等）を含む
関係SLO > SLA（SLOは常にSLAより厳しく設定）
関係性:

  SLO（内部目標）: 99.95%  ← チームが目指す水準
  SLA（外部契約）: 99.9%   ← 顧客への約束

  バッファ: 0.05% = SLOとSLAの差
  → このバッファがあることで、SLO違反が即SLA違反にならない

組織レベルのSLI戦略

サービスタイプ別のSLI定義

サービスタイプ推奨SLI計算式
リクエスト/レスポンス型可用性成功レスポンス数 / 総リクエスト数
レイテンシ閾値以内のリクエスト数 / 総リクエスト数
データ処理型鮮度最新のデータが閾値時間以内に処理された割合
正確性正しく処理されたレコード数 / 総レコード数
ストレージ型耐久性データ損失なしの割合
可用性成功した読み書き操作数 / 総操作数

SLI設計の4原則

原則説明例
ユーザー視点内部メトリクスではなくユーザー体験を反映するCPU使用率ではなく応答時間
測定可能自動的に正確に測定できる手動測定ではなくメトリクスから算出
比率で表現0-100%の比率にする絶対値ではなく Good/Total
アクショナブルSLI低下時に対処行動が明確「改善のために何をすべきか」が分かる

サービスティア制度

ティア定義

組織内のサービスをビジネスインパクトに応じてティア分類し、ティアごとにSLOの基準水準を設定します。

ティア定義SLO基準水準例
Tier 1: クリティカルダウンすると売上・信頼に直接影響99.95%以上決済API、認証サービス
Tier 2: 重要ダウンすると主要機能に影響99.9%以上タスク管理API、通知サービス
Tier 3: 標準ダウンしても一部機能に限定的影響99.5%以上検索サービス、レポート生成
Tier 4: 低優先ダウンしてもビジネス影響が小さい99.0%以上バッチ処理、内部ツール

ティア判定基準

判定軸Tier 1Tier 2Tier 3Tier 4
売上への直接影響あり間接的なしなし
影響ユーザー数全ユーザー大多数一部社内のみ
代替手段なし限定的ありあり
ダウンタイム許容度分単位10分以内1時間以内日単位
依存サービス数多い中程度少ないなし
SLOとダウンタイムの対応:

SLO 99.95% → 月間ダウンタイム許容: 約22分
SLO 99.9%  → 月間ダウンタイム許容: 約44分
SLO 99.5%  → 月間ダウンタイム許容: 約3.6時間
SLO 99.0%  → 月間ダウンタイム許容: 約7.2時間

SLO設定のガイドライン

SLOは「100%」にしない理由

理由説明
不可能性100%の可用性は物理的に達成不可能（ハードウェア故障、ネットワーク障害）
コスト曲線99.9%→99.99%は99%→99.9%の10倍以上のコストがかかる
イノベーション阻害100%を目指すとデプロイが停止し、改善ができなくなる
エラーバジェット適切なSLOがあることでエラーバジェットが生まれ、リスクのある改善に投資できる

SLO設定の手順

1. 現状のSLI実績を30日間測定する
2. P50とP99を把握する
3. ユーザー体験から許容範囲を定義する
4. ティア基準と照合する
5. SLOを仮設定する（現状実績より少し厳しく）
6. 1-2四半期運用して妥当性を検証する
7. 実績に基づいてSLOを調整する

「SLOは”約束”であり”目標”だ。高すぎるSLOは開発速度を殺し、低すぎるSLOはユーザー体験を犠牲にする。データに基づいて”ちょうどいい”水準を見つけることが組織の成熟度を示す」 — 田中VPoE

まとめ

ポイント内容
SLI/SLO/SLASLIが指標、SLOが目標、SLAが契約。SLO > SLAで運用
SLI設計原則ユーザー視点、測定可能、比率表現、アクショナブル
ティア制度サービスをTier 1-4に分類し、ティア別にSLO基準水準を設定
SLO設定100%にしない、現状実績に基づき段階的に調整

チェックリスト

  • SLI/SLO/SLAの関係を理解した
  • サービスタイプ別のSLI定義方法を理解した
  • サービスティア制度の設計方法を理解した
  • SLO設定のガイドラインと手順を理解した

次のステップへ

次は「SLO階層設計」を学びます。組織全体のSLOをどのように階層的に設計し、サービス間の依存関係を考慮したSLO体系を構築するかを身につけましょう。

推定読了時間: 30分