How to measure "Site Reliability Engineering"

Slide 1

Slide 1 text

#sapurimeetup How to measure "Site Reliability Engineering" How to measure “Site Reliability Engineering” @chaspy / Takeshi Kondo スタディサプリ / Quipper オンラインミートアップ #3 (SRE)

Slide 2

Slide 2 text

#sapurimeetup How to measure "Site Reliability Engineering" #sapurimeetup (QA は zoom にお願いします)

Slide 3

Slide 3 text

#sapurimeetup How to measure "Site Reliability Engineering" Takeshi Kondo Lead Software Engineer, K12 SRE Team @chaspy_ @chaspy

Slide 4

Slide 4 text

#sapurimeetup How to measure "Site Reliability Engineering" Agenda | 01 02 03 04 SRE Team の紹介 Site Reliability Engineering とはなにかどのように Site Reliability Engineering を計測するのかまとめと今後

Slide 5

Slide 5 text

#sapurimeetup How to measure "Site Reliability Engineering" 今日お話しすることどのように Site Reliability Engineering を計測するのか Service Level だけでなく、SRE の関心である Developer Productivity と Production Reliability、そしてそれらを支える Platform Development の4つの領域に関連する指標を定め、分析・改善のサイクルを回すことを試みました。本発表ではこの課題に取り組んだ軌跡と学びを紹介します。意思決定を「なんとなく」行なってしまっている、以前の僕たちのような方にヒントを持ち帰ってもらえたら幸いです。

Slide 6

Slide 6 text

#sapurimeetup How to measure "Site Reliability Engineering" SRE Team の紹介 01

Slide 7

Slide 7 text

#sapurimeetup How to measure "Site Reliability Engineering" 2 Products 100+ Developers 7 SREs Hiring😉 70+ 30+

Slide 8

Slide 8 text

#sapurimeetup How to measure "Site Reliability Engineering"

Slide 9

Slide 9 text

#sapurimeetup How to measure "Site Reliability Engineering" Vision ● 最高の学習プロダクトを作り続けられる開発組織の実現 Mission ● 自己完結チームがプロダクトを素早く安全に届け続けるためのプラットフォームと文化を作る

Slide 10

Slide 10 text

#sapurimeetup How to measure "Site Reliability Engineering" Values ● Fail smart ○ 失敗を非難せず、学習の糧とする。また、影響範囲をコントロールし、最小のリスクから最大のリターンを得られるよう、プロセスに失敗を織り込む。 ● Learning ○ 未知の課題を発見・解決するために、あらゆる物事を学習の機会と捉え、必要な変化をし続ける。 ● Borderless ○ 組織の垣根なくコミュニケーションし、協力しあうことでより大きな成果を目指す。 ● Metrics-driven ○ あらゆる課題・物事を指標化し、問題を点ではなく線で捉え、柔軟かつ自動的な解決を目指す。

Slide 11

Slide 11 text

#sapurimeetup How to measure "Site Reliability Engineering" Concerns Developer Productivity Production Reliability Platform Development Security Cost Management

Slide 12

Slide 12 text

Slide 13

Slide 13 text

#sapurimeetup How to measure "Site Reliability Engineering" Concerns Developer Productivity Production Reliability Platform Development Security Cost Management 素早く開発できる ● Monorepo CI/CD ● Preview Environment ● Infrastructure Management ● Microservice setup script

Slide 14

Slide 14 text

#sapurimeetup How to measure "Site Reliability Engineering" Concerns Developer Productivity Production Reliability Platform Development Security Cost Management 安全に運用できる ● Incident Response ● Auto Scaling(HPA/CA) ● Worker Node Management ● Monitoring

Slide 15

Slide 15 text

#sapurimeetup How to measure "Site Reliability Engineering" Concerns Developer Productivity Production Reliability Platform Development Security Cost Management 両方を支える Platform ● Application Platform (Kubernetes Cluster) ● Monorepo CI/CD ● Terraform CI/CD ⬆Empowerment⬆

Slide 16

Slide 16 text

#sapurimeetup How to measure "Site Reliability Engineering" Site Reliability Engineering とはなにか 02

Slide 17

Slide 17 text

#sapurimeetup How to measure "Site Reliability Engineering" Deﬁnition our Site Reliability Engineering teams focus on hiring software engineers to run our products and to create systems to accomplish the work that would otherwise be performed, often manually, by sysadmins - Site Reliability Engineering / Chapter1 Introduction: Google’s Approach to Service Management: Site Reliability Engineering

Slide 18

Slide 18 text

#sapurimeetup How to measure "Site Reliability Engineering" Core Concepts: SLI/SLO Product development and SRE teams can enjoy a productive working relationship by eliminating the structural conflict in their respective goals. The structural conflict is between pace of innovation and product stability, and as described earlier, this conflict often is expressed indirectly. In SRE we bring this conflict to the fore, and then resolve it with the introduction of an error budget. - Site Reliability Engineering / Chapter1 Introduction: Pursuing Maximum Change Velocity Without Violating a Service’s SLO

Slide 19

Slide 19 text

#sapurimeetup How to measure "Site Reliability Engineering" Concerns Developer Productivity Production Reliability Platform Development Security Cost Management Service Level 目標を満たしているうちは Productivity に（ガンガンリリース）目標を下回ったら Reliability に投資する数値という fact を用いて開発チームが自律的に意思決定できるようにする

Slide 20

Slide 20 text

#sapurimeetup How to measure "Site Reliability Engineering" SLI/SLO 運用の現状と課題 ● ✅ ほぼ全てのチームでサービスの SLI/SLO を設定し、定期的に確認している ● ✅ SLO 違反時のアラートも設定できている ● 🤔 エラーバジェットポリシーを設定できていないチームが多い ● 🤔 SLI/SLO/エラーバジェットポリシーを定期的に見直すカルチャーが定着していない ● 🤔 SLI/SLO をビジネスチームを含めて合意できていない ○ これができないと、リリースより信頼性、という意思決定をができない

Slide 21

Slide 21 text

#sapurimeetup How to measure "Site Reliability Engineering" SLI/SLO だけが SRE の仕事か 🤔

Slide 22

Slide 22 text

#sapurimeetup How to measure "Site Reliability Engineering" SLI/SLO 運用の現状と課題 ● SLI/SLO の運用は大事だが Production Reliability を示す指標に過ぎない ● 真に目指したいのは Reliability を保ちながら Productivity を最大化すること ● そしてそれを事業全体で同じ目線を持つこと ● SLI/SLO だけでなく、Productivity や Platform という自分達がやっている仕事が事業にどのように関連するのかを再定義し、それを数値にしていくことが必要ではないか

Slide 23

Slide 23 text

#sapurimeetup How to measure "Site Reliability Engineering" どのように Site Reliability Engineering を計測するのか 03

Slide 24

Slide 24 text

#sapurimeetup How to measure "Site Reliability Engineering" SRE Team が提供する価値をどう計測すれば良いか

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

#sapurimeetup How to measure "Site Reliability Engineering" 事業にとって ”Developer Productivity” はどう関係するのか

Slide 28

Slide 28 text

#sapurimeetup How to measure "Site Reliability Engineering" スタディサプリという事業はどのように成り立っているのか

Slide 29

Slide 29 text

#sapurimeetup How to measure "Site Reliability Engineering"

Slide 30

Slide 30 text

#sapurimeetup How to measure "Site Reliability Engineering"

Slide 31

Slide 31 text

#sapurimeetup How to measure "Site Reliability Engineering" スタディサプリ大学受験講座の場合大学受験生というユーザに対して、プロ講師の神授業の視聴、理解度確認のテスト、コーチの伴走という価値を提供するプロダクト

Slide 32

Slide 32 text

#sapurimeetup How to measure "Site Reliability Engineering" スタディサプリ大学受験講座の場合大学受験生というユーザに対して、プロ講師の神授業の視聴、理解度確認のテスト、コーチの伴走という価値を提供するプロダクト受験合格というアウトカムを目指して、価値を事業KPIと学習KPIで計測し、それを向上させるための仮説検証を繰り返す

Slide 33

Slide 33 text

#sapurimeetup How to measure "Site Reliability Engineering" 仮説検証を繰り返すための ”Developer Productivity”

Slide 34

Slide 34 text

#sapurimeetup How to measure "Site Reliability Engineering" それを示す指標は？

Slide 35

Slide 35 text

#sapurimeetup How to measure "Site Reliability Engineering" （本番環境への）デプロイ頻度🚀

Slide 36

Slide 36 text

#sapurimeetup How to measure "Site Reliability Engineering" デプロイ頻度リードタイム MTTR 変更失敗率 Lean と DevOps の科学より - 4 Keys

Slide 37

Slide 37 text

#sapurimeetup How to measure "Site Reliability Engineering" なぜデプロイ頻度が適当か🤔

Slide 38

Slide 38 text

#sapurimeetup How to measure "Site Reliability Engineering" 初回課金率学習KPI デプロイ頻度継続率事業KPIとの関連性事業KPI 課金額だけでなく、ユーザに使ってもらうことを重視してKPI を設定

Slide 39

Slide 39 text

#sapurimeetup How to measure "Site Reliability Engineering" 初回課金率学習KPI デプロイ頻度継続率事業KPIとの関連性事業KPI 開発チームは学習KPI改善の How として機能開発や修正を行う開発した機能が学習KPIを改善するかどうかはリリースしてみないと分からない（目的不確実性）仮説検証を繰り返し、本番環境からフィードバックを得る必要がある

Slide 40

Slide 40 text

#sapurimeetup How to measure "Site Reliability Engineering" 初回課金率学習KPI デプロイ頻度継続率事業KPIとの関連性事業KPI 速く、安全に、多く機能を届け続ければ学習KPIが改善する可能性が高い

Slide 41

Slide 41 text

#sapurimeetup How to measure "Site Reliability Engineering" なぜデプロイ頻度が指標として適切か ● 前提としてプロダクト開発ではリリースしてみないとKPIを改善するかどうかわからない（目的不確実性）がある ● 仮説検証をできるだけ多く繰り返すためにはデプロイ頻度を高める必要がある

Slide 42

Slide 42 text

#sapurimeetup How to measure "Site Reliability Engineering" デプロイ頻度だけ追えば良いか🤔

Slide 43

Slide 43 text

#sapurimeetup How to measure "Site Reliability Engineering" デプロイ頻度リードタイム MTTR 変更失敗率 4 Keys の関係性デプロイ頻度があがると変更失敗率はさがる？リードタイムが短くなるとデプロイ頻度があがるリードタイムが短くなると MTTR も短くなる

Slide 44

Slide 44 text

#sapurimeetup How to measure "Site Reliability Engineering" 開発環境デプロイ頻度リードタイム MTTR 変更失敗率 Sub KPIs 開発ブランチへのデプロイ頻度 PR 平均生存時間 Preview 環境が準備できるまでの時間開発環境稼働率コードメトリクス（量・循環複雑度）本番環境

Slide 45

Slide 45 text

#sapurimeetup How to measure "Site Reliability Engineering" デプロイ頻度だけ追えばいいか ● No ● さまざまな指標がシステム的に複雑に影響しあう ● デプロイ頻度を main KPI と置きつつ、他の指標も観察する必要がある ● 指標間には様々な関係性がある ○ 先行指標 ↔ 遅行指標 ○ 比例 / 反比例 ○ 包含関係

Slide 46

Slide 46 text

#sapurimeetup How to measure "Site Reliability Engineering" 結局、どこからどうやってはじめたらいい？

Slide 47

Slide 47 text

#sapurimeetup How to measure "Site Reliability Engineering" “プロダクト的”に考える 💡

Slide 48

Slide 48 text

Slide 49

Slide 49 text

#sapurimeetup How to measure "Site Reliability Engineering" Vision ● 最高の学習プロダクトを作り続けられる開発組織の実現 Mission ● 自己完結チームがプロダクトを素早く安全に届け続けるためのプラットフォームと文化を作るユーザ価値プロダクト提供する価値を”デプロイ頻度”という指標で計測し、それを向上させるために仮説検証を繰り返す

Slide 50

Slide 50 text

#sapurimeetup How to measure "Site Reliability Engineering" “プロダクト的”に Platform を進化させる ● ユーザを観察し ● 価値を提供し ● その価値を示す指標を定めて ● 指標改善のための仮説検証を繰り返す

Slide 51

Slide 51 text

#sapurimeetup How to measure "Site Reliability Engineering" なぜ”プロダクト的”に考えると良いのか ● “プロダクト的”に考えないとどうなるか ○ 開発・改善した効果が分からない ○ 効果がわからないとどの施策をやるべきか優先順位がつけられない ● Business との関連性 ○ 当たり前だが、SRE / Platform もスタディサプリ/Quipper 事業のために存在している ○ “Developer Productivity” / “Service Level” / “Production Reliability” を事業全体で共有したいなら、ツリー的につながる数値目標(KPI)を持つべき

Slide 52

Slide 52 text

#sapurimeetup How to measure "Site Reliability Engineering" 指標を検討するためにやってきたこと ● 顧客・提供価値の言語化 ● 開発チームの Value Stream Mapping ● 目指す姿をツリーで書き出し

Slide 53

Slide 53 text

#sapurimeetup How to measure "Site Reliability Engineering" 顧客・提供価値の言語化 ● 興味あるひといればあとで画面共有します

Slide 54

Slide 54 text

#sapurimeetup How to measure "Site Reliability Engineering" 開発チームの Value Stream Mapping ● 実際にリリースする様子を見学・観察した

Slide 55

Slide 55 text

#sapurimeetup How to measure "Site Reliability Engineering" 目指す姿をツリーで書き出し ● ちょっと巨大なのでこれも興味あるひとあれば画面共有します

Slide 56

Slide 56 text

#sapurimeetup How to measure "Site Reliability Engineering" 今やっている取り組み ● 指標の Monitoring 強化 ● Autify による E2E テスト自動化 ● Release 体験改善

Slide 57

Slide 57 text

#sapurimeetup How to measure "Site Reliability Engineering" 指標の Monitoring 強化 ● coverband gem によるプロダクションコードカバレッジ取得 ● リードタイムで支配的なビルド時間の短縮検討 ● 開発ブランチのデプロイ数の継続的取得 ○ gh pr list で spot で取得したのみなので metric として取れるとなお良い

Slide 58

Slide 58 text

#sapurimeetup How to measure "Site Reliability Engineering" Autify による E2E テスト自動化 ● 検証中 ● あるサービスでは既存の手動テストがほぼカバーできることが分かった ● ノウハウを他サービスに展開中

Slide 59

Slide 59 text

#sapurimeetup How to measure "Site Reliability Engineering" Release 体験改善 ● Release PR 作成 Script 実行時間高速化 ● Master branch へ Hotﬁx した際の backport PR 作成自動化 ● デプロイ完了後、Pod が Ready になった際の通知

Slide 60

Slide 60 text

#sapurimeetup How to measure "Site Reliability Engineering" まとめと今後 04

Slide 61

Slide 61 text

#sapurimeetup How to measure "Site Reliability Engineering" まとめ ● Platform を”プロダクト的”に考えよう ○ ユーザは誰か ○ 提供する価値は何か ○ 価値を計測する指標は何か ● 指標はデプロイ数からはじめよう ○ 計測が簡単 ○ これを main KPI とおけば他の指標は従属指標になる ● 事業活動との関係を意識しよう ○ Site Reliabiliy Engineering は「組織への実装」が必要 ○ 開発組織だけに閉じない

Slide 62

Slide 62 text

#sapurimeetup How to measure "Site Reliability Engineering" 今後 ● Business Team と一緒に Platform KPI を追いかけていく ● ユーザの観察と指標改善のためのアクションを打って、仮説検証を繰り返していく ● Platform Development 以外の領域にも同じ考え方を適用する ○ Security: 脅威と頻度等から数値化できないか？ ○ Cost Management: User 規模と売り上げ・利益率から目標値を定めて適切なアクションを打っていくべき

Slide 63

Slide 63 text

#sapurimeetup How to measure "Site Reliability Engineering" 2 Products 100+ Developers 7 SREs 70+ 30+ We are hiring 😉 🔍【Quipper SRE】

Slide 64

Slide 64 text

#sapurimeetup How to measure "Site Reliability Engineering" カジュアル面談しましょう！

Slide 65

Slide 65 text

#sapurimeetup How to measure "Site Reliability Engineering" Takeshi Kondo Lead Software Engineer, K12 SRE Team @chaspy_ @chaspy

Slide 66

Slide 66 text

#sapurimeetup How to measure "Site Reliability Engineering" Thank you!

Slide 67

Slide 67 text

#sapurimeetup How to measure "Site Reliability Engineering" FAQ Q. SLI/SLOとエラーバジェットの運用について、SREだけでなくプロダクト開発組織全体を巻き込んだ運用を行うためにはどうすればいいでしょうか (どうしてもSRE 本位になりがちで悩んでいます) A. 以下がコツになりそう。 - 推奨(Default) SLI/SLO を提供する - Terraform 等で定義・作成を自動化、generator で簡易化する - 開発者と対話する・共同作業する - プロセスに組み込む - 新規サービス開始時の Design Doc / Production readiness Checklist の項目にしています - 可能な限りシンプルにする - よくある Web Service ならまずは Availability(Success Rate) と Latency だけでいい

Slide 68

Slide 68 text

#sapurimeetup How to measure "Site Reliability Engineering" FAQ Q. 開発チームとSREチームの境界線 (SLI/SLOに対して各チームがどこから/どこまで主体性を持って取り組んでいるか。インフラの選定やアップデートなども同様) A. 基本境界はない、Boaderless、はみ出し歓迎スタンスを前提に ● Web Application, Kubernetes manifest, CI は Developer ● Kubernetes Cluster, CD, Infrastructure CI/CD, IAM 等は SRE ● アーキテクチャレビューは SRE がやるが、基本開発チーム主導 ● SLI/SLO 運用は開発チーム任せ、metrics 取得や考え方のサポートを SRE がする

Slide 69

Slide 69 text

#sapurimeetup How to measure "Site Reliability Engineering" FAQ Q. 変更失敗率はどうやって計測しているか A. 現状は計測していない ● 変更失敗率は非常に重要。main KPI であるデプロイ頻度が高くても、変更失敗率も同時に高ければ意味がない ● 変更失敗した場合、必ず Revert するため Revert PR の数でいいか？と考えたが、失敗してなくても Revert することはある ● 能動的に Label をつけるなどプロセスに組み込む必要性を感じている ● QA Team と協力してモニタリングする予定

Slide 70

Slide 70 text

#sapurimeetup How to measure "Site Reliability Engineering" FAQ Q. MTTR はどうやって計測しているか A. 現状は計測していない ● 一度過去のインシデントから棚卸しして手作業で計測したことはある ● 障害自体の発生数はそう多くないため、手作業での計測でも問題ない ● また、MTTR の数値は頻度が低いことから十分なデータ量が得られず、少数の大障害が大きな影響を与えてしまう ● 一方で、障害対応の Value Stream Mapping を考えた場合、共通でこれらを遅くする要因は取り除くべき ● 重要な指標ではあるが、自動計測は難しく、また統計値としては役に立ちづらいため優先度を下げている。