TL;DR
- SLO Service Level Objective。SLI に対する “目標値” 。例: 28 日間で成功率 99.9% 以上。 /エラーバジェット SLO を満たしつつ “許される失敗の枠” 。意思決定の通貨。 は“止める/止めない”の絶対規則ではなく、現実的な意思決定のためのものさし。
- 導入は小さく（パイロット → 可視化 → 会話）から。いきなりバーンレート エラーバジェットの“消費速度”で鳴るアラート。上級運用向け。 等の上級運用に飛ばない。
- 認知負荷を下げる仕組みづくり（押すだけのダッシュボード/アラート/手順）が継続のカギ。
- 四半期〜年次で見直し。サポートチケットや NPS Net Promoter Score。推奨度ベースの満足度指標。 と併置して SLO の厳しさ/緩さを調整。
参加イベント
2025 年 11 月 27 日（木）に開催された連続講義『SRE の旅』の Road2「信頼性を定義して組織で運用する」をアーカイブ視聴しました。
視聴メモと、実務に転用できそうなポイントを残します。
── 『SREの知識地図』の著者を招いてお送りするSREの旅〜Road 2 信頼性を定義して組織で運用する 技術評論社から出版された『SREの知識地図』をテーマに、各章の執筆者と株式会社TopotalのCTOであるRyota Yoshikawaが対談形式で各章の内容について …
視聴した感想や、自身に置き換えて役に立てそうだと思ったことを書いていきたいと思います。
備考: Road1 は未参加ですが、公開資料（SpeakerDeck）を参考として本記事内に掲載しています。→ 第一回（Road1）の資料へ
印象に残ったこと
今回の対話で強調されていたのは、「SLO は現場の意思決定を助ける指標であって、現実を無視して何もかも止めるための“絶対規則”ではない」という姿勢でした。
目標を上回る/下回るの 2 軸と、「今は信頼性に投資する/機能開発を進める」の 2 軸で整理し、状況に応じた 4 通りの行動を選ぶ。
これにより、感情や声量ではなく、合意済みの“ものさし”で会話できるようになるのが価値だと腹落ち。
エラーバジェット運用も白黒ではなく段階的でした。「即・開発凍結」だけが解ではなく、例外承認や限定的リリースなど現実的な選択肢を用意し、事後レビューで恒常対策につなげる。
大切なのは “納得のある判断が再現できること” 。
導入の進め方は、組織規模に応じてトップダウン/ボトムアップを併用。大きな組織では合意形成の仕組みを上層で用意しつつ、現場ではまず 1 チームのパイロットで「目に見える成果（ダッシュボード/改善）」を作り、成功体験を水平展開するのが効く、という実感が共有されました。
もう一つのキーメッセージは “認知負荷を下げる” 。
SRE が「これ設定しておいてください」と丸投げするのではなく、SLI
Service Level Indicator。ユーザー価値に直結する“計測指標”。例: 成功率、p95 レイテンシ、データ鮮度。
設計・ダッシュボード・アラート・運用手順を“押すだけ”レベルまで用意し、開発者の追加作業を最小化する。
サービス理解を SRE 側が持ち、いっしょに決めに行く姿勢が継続運用のカギ。
最後に、やり過ぎ注意。最初からバーンレート・アラート等の高難度運用に飛ばず、まずは単純な評価窓（例: 2 週間/28 日）で SLO を見て運用のリズムを作る。
SLI の粒度はモノリス/複数機能/チーム境界に応じて“丸め過ぎ/細か過ぎ”のトレードオフを意識し、運用コストと検知感度のバランスを取る。SLO の見直しは四半期〜年次の儀式とし、サポートチケットや NPS と併置して“厳しすぎ/緩すぎ”を定期点検するのが良い。
第一回（Road1）の資料
以下は Road1 の公開資料です。
明日から試すこと（自分向け）
インフラ/SRE の日常運用に即して、まずは“認知負荷を下げる SLO 導入”から着手します。
- パイロット選定: 影響が大きく、メトリクスが既に揃っている 1 機能を対象にする。
- 可視化の先行: ダッシュボードに SLI（成功率/レイテンシ/鮮度）を載せ、「今の緑/赤」が誰にでも見える状態に。
- SLO は最大 3 件: 運用可能な数まで絞る。除外条件・評価窓を明記。
- アラートは“少数精鋭”: SLO 直結だけ Pager。他はダッシュボードで観察に退避。
- 例外ルールの雛形: 「いつ/誰が/どう承認するか」を 1 枚にまとめておく。
- レビューの儀式化: 月次で運用確認、四半期で SLO 見直し（サポート/NPS と併置）。
SLO 導入ミニテンプレ（コピペ可）
## 対象/目的
- 対象機能: <例: 注文 API>
- 目的: <例: 障害対応の判断を“SLO 基準”に揃える>
## SLI/SLO（初期案）
- 成功率: <HTTP 2xx 率 / 28 日 / 除外: デプロイ 10 分>
- レイテンシ: <p95 < 300ms / 28 日>
- 鮮度: <例: 同期遅延 < 60 秒>
## 可視化/アラート
- ダッシュボード: <URL or 名称>
- Pager 条件: <SLO 直結のみ>
- それ以外: 週次レビューで確認
## 例外運用（サンプル）
- 例外承認者: <PdM or EM>
- 期間/範囲: <例: 新機能 A の限定ロールアウトのみ>
- 事後対応: PIR で恒久対策まで記録
## レビュー
- 月次: 運用指標チェック（アラート量/MTTA/MTTR）
- 四半期: SLO の妥当性をサポート/NPS と照合
MTTA / MTTR
- 平均検知までの時間 / 平均復旧時間。運用の“反応と回復”の速さを表す。
まとめ（現時点の所感）
SRE は“定義 → 運用 → 学習”のリズムを組織で回す営みだと再確認しました。
まずは自チームの SLO を 3 件に絞り、アラートの棚卸しと PIR
Post-Incident Review。事後レビュー。非難なく、タイムライン/影響/恒久対策を言語化する振り返り。
のテンプレ整備から着手したいと思います。