Upgrade to Pro — share decks privately, control downloads, hide ads and more …

How to measure "Site Reliability Engineering"

How to measure "Site Reliability Engineering"

Takeshi Kondo

August 25, 2021
Tweet

More Decks by Takeshi Kondo

Other Decks in Technology

Transcript

  1. #sapurimeetup How to measure "Site Reliability Engineering" How to measure

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

    02 03 04 SRE Team の紹介 Site Reliability Engineering とはなにか どのように Site Reliability Engineering を計測するのか まとめと今後
  3. #sapurimeetup How to measure "Site Reliability Engineering" 今日お話しすること どのように Site

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

    Mission • 自己完結チームがプロダクトを素早く安全に届け続けるためのプラットフォー ムと文化を作る
  5. #sapurimeetup How to measure "Site Reliability Engineering" Values • Fail

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

    Production Reliability Platform Development Security Cost Management
  7. #sapurimeetup How to measure "Site Reliability Engineering" Vision • 最高の学習プロダクトを作り続けられる開発組織の実現

    Mission • 自己完結チームがプロダクトを素早く安全に届け続けるためのプラット フォームと文化を作る
  8. #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
  9. #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
  10. #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⬆
  11. #sapurimeetup How to measure "Site Reliability Engineering" Definition 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
  12. #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
  13. #sapurimeetup How to measure "Site Reliability Engineering" Concerns Developer Productivity

    Production Reliability Platform Development Security Cost Management Service Level 目標を満たしているうちは Productivity に(ガンガンリリース) 目標を下回ったら Reliability に投資する 数値という fact を用いて開発チームが自律的に意思決定できるように する
  14. #sapurimeetup How to measure "Site Reliability Engineering" SLI/SLO 運用の現状と課題 •

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

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

    Production Reliability Platform Development Security Cost Management Service Level 最大化したい 安定させたい 信頼性を示すような指 標を選びたい
  17. #sapurimeetup How to measure "Site Reliability Engineering" Concerns Developer Productivity

    Production Reliability Platform Development Security Cost Management Service Level 最大化したい 安定化させたい 信頼性を示すような指 標を選びたい
  18. #sapurimeetup How to measure "Site Reliability Engineering" スタディサプリ大学受験講座の場合 大学受験生というユーザに対して、 プロ講師の神授業の視聴、理解度確認

    のテスト、コーチの伴走という価値を提供 するプロダクト 受験合格というアウトカ ムを目指して、価値を事 業KPIと学習KPIで計測 し、それを向上させるた めの仮説検証を繰り返 す
  19. #sapurimeetup How to measure "Site Reliability Engineering" 初回課金率 学習KPI デプロイ頻度

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

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

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

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

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

    • さまざまな指標がシステム的に複雑に影響しあう • デプロイ頻度を main KPI と置きつつ、他の指標も観察する必要がある • 指標間には様々な関係性がある ◦ 先行指標 ↔ 遅行指標 ◦ 比例 / 反比例 ◦ 包含関係
  25. #sapurimeetup How to measure "Site Reliability Engineering" スタディサプリ大学受験講座の場合 大学受験生というユーザに対して、 プロ講師の神授業の視聴、理解度確認

    のテスト、コーチの伴走という価値を提供 するプロダクト 受験合格というアウトカ ムを目指して、価値を事 業KPIと学習KPIで計測 し、それを向上させるた めの仮説検証を繰り返 す
  26. #sapurimeetup How to measure "Site Reliability Engineering" Vision • 最高の学習プロダクトを作り続けられる開発組織の実現

    Mission • 自己完結チームがプロダクトを素早く安全に届け続けるためのプラットフォー ムと文化を作る ユーザ 価値 プロダクト 提供する価値を”デプロイ頻度”という指標で計 測し、それを向上させるために仮説検証を繰り 返す
  27. #sapurimeetup How to measure "Site Reliability Engineering" “プロダクト的”に Platform を進化させる

    • ユーザを観察し • 価値を提供し • その価値を示す指標を定めて • 指標改善のための仮説検証を繰り返す
  28. #sapurimeetup How to measure "Site Reliability Engineering" なぜ”プロダクト的”に考えると良いのか • “プロダクト的”に考えないとどうなるか

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

    Mapping • 実際にリリースする様子を見学・観察した
  30. #sapurimeetup How to measure "Site Reliability Engineering" 今やっている取り組み • 指標の

    Monitoring 強化 • Autify による E2E テスト自動化 • Release 体験改善
  31. #sapurimeetup How to measure "Site Reliability Engineering" 指標の Monitoring 強化

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

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

    Release PR 作成 Script 実行時間高速化 • Master branch へ Hotfix した際の backport PR 作成自動化 • デプロイ完了後、Pod が Ready になった際の通知
  34. #sapurimeetup How to measure "Site Reliability Engineering" まとめ • Platform

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

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

    Developers 7 SREs 70+ 30+ We are hiring 😉 🔍【Quipper SRE】
  37. #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 だけでいい
  38. #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 がする
  39. #sapurimeetup How to measure "Site Reliability Engineering" FAQ Q. 変更失敗率はどうやって計測しているか

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

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