## 概要 [[Wataru Tsuda]]（[[Luup]] SRE、gr1m0h）が SRE NEXT 2023（2023-09-29、Track C）で発表したスライド。電動マイクロモビリティのシェアサービス LUUP を運営する Luup において、SRE チームが開発組織全体へ SLI/SLO を普及・導入する「Enabling SLO」の実践を報告する。transcript なし（35 スライド全ページを画像で確認）。 ## 主要メッセージ - **伝えたいこと**（p.3）: SLO を開発者・PdM に伝導・導入するための方法と考慮点、および IoT 分野で SRE・SLO を実践していくための方法。 - **Enabling SRE の絞り込み**: "Enabling SRE" はスコープが広いため、Enabling "SLO" として SLO の導入をメインに進める（p.16）。 - **Enabling SLO は段階的に広げる**: Enabling SRE は少しずつ行い、関係するチームを増やしながら開発組織全体に拡大する（p.33）。 - **スタートアップの現実**: Embedded SRE はリソース的に困難。Developer Lead との直接コミュニケーションが現実的な代替手段（p.27、p.33）。 - **IoT 固有の課題**: IoT デバイスでは CUJ の代わりに CMC（Critical Machine Communication）という概念を使い、「マシンが期待通りに動作できる状態であるか」を SLI 化する（p.10）。 ## SLO の基礎定義（p.8-10） - **SLI**（Service Level Indicator）: 提供しているサービスの動作を直接測定した指標。レート・アベレージ・パーセンタイルなどのメトリクスで測定する。「ユーザーがサービスを期待通りに使えているか」が反映された指標であるべき。 - **SLO**（Service Level Objective）: SLI に対する具体的な目標値。e.g. 過去 30 日間で 99.9% 成功していること。信頼性に関してデータドリブンな意思決定を促す。 - **CUJ**（Critical User Journey）: SLO の主眼は顧客体験の改善。SLO はユーザーを中心に置くアクションについて書かれるべき（サイトリライアビリティワークブックより）。 - **CMC**（Critical Machine Communication）: Luup 独自の概念。IoT における SLI で計測すべきなのは「マシンが期待通りに動作できる状態であるか」。e.g. バッテリーが切れていないか、サーバーと接続されているか。プロトコルは MQTT、LwM2M など。ハードウェア異常は影響のあるユーザーは少ないが、顧客体験への影響がソフトウェアの異常よりも大きくなる懸念がある（p.10）。 ## 視覚的に重要な図表 **p.12 Luup 開発組織構成** ![[_attachments/20230929_SRENEXT2023/page-012.png]] 開発組織 10 人＋α、SRE チーム 2 人＋9 人＝11 人。Data・CTO・SRE・Android・iOS・Server・IoT の 7 チーム構成。SRE がハブ（ピンク色）として中心に位置する。 **p.13 他チームとの連携** ![[_attachments/20230929_SRENEXT2023/page-013.png]] PdM（Android/iOS/Server チームとコミュニケーション）と Hardware（IoT チームとコミュニケーション）が外部と連携する構造。Android/iOS/Server チームは点線で囲まれ PdM と双方向矢印。 **p.17 Enabling SRE の変化（これまでとこれから）** ![[_attachments/20230929_SRENEXT2023/page-017.png]] 左図（Before）: SRE を中心とした小さな緑の円に IoT・Server・PdM が包まれ、iOS・Android・Ops・Data・Server(OpsApp) が円外に存在。右図（After）: SRE・IoT・PdM が大きなピンクの円に入り、さらに全チームを包む大きな緑の円へ拡大。Enabling の広がり方を同心円構造で示す。 **p.27 Embedded SRE の代替手段** ![[_attachments/20230929_SRENEXT2023/page-027.png]] 左: Embedded SRE モデル（SRE チームから開発チームへ SRE を派遣）。右: Luup が採用したモデル（SRE チームが開発チームの Lead と直接コミュニケーション）。SRE 正社員 2 人・フルタイム 3 人という制約からの選択。 **p.31 CMC based SLI の設計（策定中）** ![[_attachments/20230929_SRENEXT2023/page-031.png]] 横軸に時間、縦軸に「count in service（上）/ count out of service（下）」。SLO を赤い水平線で示し、Server 側でエラーが発生すると count out of service（communication fault／hardware error fault／other fault の 3 種別）が増加し SLO Violation になる概念図。 ## Enabling SLO の実践内容 ### 開発組織全体への導入（p.21-24） 1. **SLO 習熟度調査の実施**（p.23） - 組織全体や個人の今現在の習熟度を知るために実施 - エンジニアだけでなく PdM も調査対象 - SLO に関する問題が全 14 問 - 将来的に再度実施して Enabling 度合いを計測、オンボーディング時に実施し個別フォローアップを計画 2. **SLO 勉強会の実施**（p.24） - エンジニアみんなで議論できるように素地を作るために実施 - 習熟度調査の結果をフィードバックして構成検討 - 3 部構成：「背景（なぜ SLI・SLO の知識が Luup 開発組織で必要か）」「SLI・SLO の基本」「Luup SRE チームの現在の SLO 運用状況（今どんな SLO を運用しているか、既知の問題とその対応状況）」 ### IoT チームへの導入（p.28-31） IoT デバイスの信頼性を担保するために以下の活動を実施: 1. **車両の施錠解錠のエラー率の低減: 自動サービスアウト**（2 種類） - **定期通信途絶によるサービスアウト**（p.29）: 一定時間、定期通信がないときに自動でサービスアウトする機能。車両の利用状況に関わらず一定時間ごとに定期通信をしており、定期通信の応答時間を DB に保存。一定時間応答なければサービスアウト、定期通信が発生したタイミングでサービスイン。 - **ハードウェアエラーによるサービスアウト**（p.30）: ハードウェアエラーを検知したときに自動でサービスアウトする機能。エラー毎にしきい値を決め、一定時間でしきい値を超えたら Slack 通知＋サービスアウト。ハードウェア起因の故障なので自動でサービスインはせず、フィールドで確認後に修理かサービスインかを判断。 2. **CMC based SLI の設計（策定中）**（p.31）: サービスインしている車両の割合を SLI として検討中。 ## まとめ（p.33） - **Enabling SRE は少しずつ行う**: 関係するチームを少しずつ増やしていき、開発組織全体に拡大する。 - **スモール組織では Lead との直接コミュニケーション**: 開発組織全体で人数が少ない状態（≒スタートアップ）では Embedded SRE はリソース的に難しい。Lead には将来的に各チームで SRE 伝道師を担ってもらうことを期待。 - **IoT 領域の SLI 設計には CMC を使用する**: 定期通信途絶とハードウェアエラーによる自動サービスアウトは現実世界で移動する IoT デバイスであるという LUUP 特有の機能。 ## 概念・実体への接続 - 登壇者・組織: [[Wataru Tsuda]]、[[Luup]] - 概念: [[サービスレベル目標]]、[[SRE組織変革]] - 参照先: SLOconf Tokyo 2023「LuupにおけるSLOの物語」(2023-05-16) も参照 ## 限界・不確実点 - transcript なし（口頭での補足、質疑内容は不明） - SLO 習熟度調査の 14 問の具体的内容は画像では読み取れなかった（スクリーンショット内の小文字） - CMC based SLI の具体的な目標値（何% をターゲットにするか）はスライド時点で「策定中」 - 会社全体（ビジネスサイド含む）への Enabling SLO の取り組みは「またどこかの機会で」として本スライドでは省略 - Android/iOS/Server チームへの SLO 導入詳細も「またどこかの機会で」として省略