## 概要 [[渡辺 起]]（[[Hatena]]、[[Mackerel]] プロデューサー、2022 年まで PO）が SRE NEXT 2023（2023-09-29）で発表したスライド（39 枚）。エンジニア向け監視 SaaS「Mackerel」チームが、信頼性より開発速度が課題だった状況から SLO を導入し、2022 年頃に DORA フロー段階・後期段階まで到達した実践を語る。PO の視点から「判断と改善をチームで回したい」という動機を中心に、SLO 導入のステップ・活用シーン・開発速度との関係を具体的に示す。 ## 主要メッセージ - **SLO の動機は「チームで判断を回す」こと**(p.20, p.37): 信頼性に関わる技術判断を PO が個人で行う代わりに、SLO という数値基準でチームが自律的に判断できるようにする。判断が減ることが PO にとっての嬉しいポイント。 - **信頼性の定義はユーザー主語**(p.18): O'Reilly SLO 本を引き「ユーザーの期待に沿っているか」を採用。レイテンシ・エラー率ではなくユーザー体験から逆算して SLI を選ぶ。 - **まず仮値で始めて見直しフローを作る**(p.27-29): SREが叩き台を作り、仮値を設定して運用開始。完璧な値を追い求めず、見直しサイクルを回すことを重視。 - **Error Budget Policy は緩く始める**(p.33-34): 「調査をするか判断する」という最低限のアクションから。徐々に強化していく設計。 - **SLO の活用シーン**(p.35): P99 が悪化してもSLO を割らなければ「無視する」と判断できる。大きな仕組み変更でエラーが出たときは「リリーススケジュールを調整する」と意思決定できる。 - **開発速度との関係**(p.38): 速度は上がったがデプロイ仕組みの変更が主因。SLO は直接的効果より「下支え」として機能。 ## 視覚的に重要な図表 **p.15 DORA 2022 クラスタ比較表・Mackerel の位置づけ** ![[_attachments/2023__SRENext2023__PO-to-SLO-Mackerel/page-015.png]] DORA 4 クラスタ（初期段階・フロー段階・後期段階・終了段階）の指標比較表。2022 年時点の Mackerel チームがフロー段階/後期段階に位置することを示す。以前は「停止メンテ時間が長い・デプロイ週 2 回・リリース頻度低い」という状態から改善が進んでいた。 **p.30 GitHub SLO ドキュメント + Mackerel sample SLI/SLO ダッシュボード** ![[_attachments/2023__SRENext2023__PO-to-SLO-Mackerel/page-030.png]] Google SRE Workbook の SLO ドキュメントテンプレートと、Mackerel の実際の SLI/SLO ダッシュボード。可用性 SLO 99.8% → 実測 99.98%、レイテンシ SLO 99.8% → 実測 99.88% という具体的な数値を示す。 ## 概念・実体への接続 - **[[渡辺 起]]**: 登壇者。はてな Mackerel プロデューサー（2022 年まで PO）。 - **[[Mackerel]]**: エンジニア向け SaaS 型監視サービス。2014 年リリース、10 人前後のチーム（うち SRE 1〜3 名）。 - **[[サービスレベル目標]]**: SLI/SLO の定義方法、ユーザー主語の信頼性定義、仮値スタートの実践を追記。 - **[[エラーバジェット]]**: Error Budget Policy の「緩く始める」パターンを追記。 - **[[SLI-SLO段階的導入]]**: まず SRE が叩き台を作り仮値で動かすアプローチが例として合致する。 - 外部: DORA（2022 State of DevOps Report）、O'Reilly 『Implementing Service Level Objectives』 ## 限界・不確実点 - transcript なし。口頭説明（SLO 設定の経緯詳細、チーム内議論の経緯）は不明。 - SLI ダッシュボードの具体的な計装方法（Mackerel 自身の指標をどう計測しているか）はスライドでは非開示。 - 「開発速度向上の主因はデプロイ仕組みの変更」とあるが、その仕組みの詳細は本資料のスコープ外。 - 発表当時（2023-09-29）の DORA クラスタ評価は 2022 年データに基づく自己評価。