sre-key-metrics.md

SREチーム/Platform開発の目標とする指標を語るNight誰かしません？クローズドでオンラインで。やってること、やりたいこと、やった方が良さそうなことなどフェーズ問いません。興味あるひとリプかDMください。一応僕の方でいくつか考えてて計測してるのもあればまだのもあるって感じで今期やっていき

https://twitter.com/chaspy_/status/1388036457705574400

背景

• @chaspy が所属する SRE Team では以下の領域に関する仕事をしている。
  • Cost Management
  • Security
  • Developer Experience / Developer Productivity
  • Site Relibaility
  • Application Platform / Kubernetes
• SRE Team として、何らかの指標を観察し、その改善を目指して仕事を進める・優先度づけをするアプローチの必要性を感じている
  • やることが多すぎる中、優先度をつけることが難しい
  • 何らかの改善を行ったとして、それがどれぐらいよくなったのか定量的に判断ができない

候補となる Key Metrics

Cost Management

3つの指標をあげた。

• Production Cost / Number of Monthly Active User ユーザ数に比例してインフラコストは増えるはず|
• Production Cost / 売り上げ or 営業利益 ビジネス観点で、売り上げがないのにインフラコストを使うのはよくないので|
• Staging Cost / Number of Developers 開発にかかるコストは開発者に比例するはず|

Staging か Production かは大きく区別したい。その上で、何らかで正規化しないといけないのでそれぞれ関連するもので割っている。まずはタグなどを使ってこれらを分類、可視化をし、その後何が効くかを考えて計画を立てて実行していく。

Security

指標は持たない。追いかけうる指標はあるが、基本的にやれと言われたことをやらないといけないので、それを他の領域とバランスを考えながら確実にプロジェクトマネジメントをして進めていく。

Developer Productivity

3つあげた。Staging と Production 両方見ていく。

• Number of deploys
• Time to deploy
• CI Stability

Site Reliability

SRE Team であるからには、サービスの安定稼働は第一のミッションであり、いかに他の指標を満たそうともサービスの信頼性を落としては意味がない。ミッションにある"安全に"の部分を担保するために、この観点は必須だろう。

だからといって SRE Team がサービス全体の SLO 99.99% だとか決めるのはナンセンスだ。サービスレベルはビジネス要求によって変わるし、それは信頼性と機能開発のバランスをとるためのツールでしかないので、この数値自体を目標値にするのは本質的ではない。

指標としては1つあげた。

• MTTR / Mean time to recovery とはいえ安定して稼働している時間をできるだけ長くとることは大事だし、障害を局所化したり、すぐに復旧できるようにする必要がある。

結局 SLO と似たようなものを見ていくようになるかもしれないが、障害と判定されてそれが復旧するまでの時間をできるだけ短くなるようにトラックしたい。これが長くなってしまった場合、それを短くなるような仕組みであったり基盤の改善、あるいはプロセスの整備を SRE Team だけでなく Product 開発チーム全体で目指していきたい。

余談ながら、MTTR に Number of the affected user を入れるかどうかちょっと悩む。

Team Health

いったん普段受けるアラートの数を追いかける。認知負荷を奪うので。

• Number of alerts

まとめ

領域	指標	理由
Cost	Production Cost / Number of Monthly Active User	ユーザ数に比例してインフラコストは増えるはず
Cost	Production Cost / 売り上げ or 営業利益	ビジネス観点で、売り上げがないのにインフラコストを使うのはよくないので
Cost	Staging Cost / Number of Developers	開発にかかるコストは開発者に比例するはず
Developer Productivity	Time to Deploy	PR Merge からサービスが Deploy されるまでの時間。障害発生時の MTTR にも影響する
Developer Productivity	Number of Deploy	Productione / Develop への Deploy の数。Accelerate にも書いてあったやつ
Developer Productivity	CI Stability	Develop CI の成功率
Reliability	MTTR
Team	Number of alerts we receive

話したいこと

• ここであげている指標が有効そうか、そうでなさそうか意見があれば聞きたい
• ここであげていない指標で有効そうなものがあれば意見が聞きたい
• こういった指標をトラッキングするための技術的な解決策があれば聞きたい
  • 容易に取れるものもあれば、難しいものもある。
  • Developer の数とか、MTTR とか悩んでる。
  • インフラコストも契約を全部割らない限りは Production / Staging 綺麗に分けられるものではない、とか
• こういった指標を決め、おそらくきっと Indicator を途中で変えたり、経過を定期的に観察したりというアプローチを組織ですでにやっているのであれば事例が聞きたい
  • 運用フェーズにはまだまだ至っていないので

参考資料

DevOps Criteria

https://github.com/suwa-sh/devops-criteria

これはこれで定期的にアセスメントはしたほうがいいが、範囲が広いのと、yes / no での診断なので指標とはちょっと違う。

DX Criteria

https://dxcriteria.cto-a.org/

NewsPicksにCTOとして入社して1年でDX Criteriaを大幅改善した話

https://tech.uzabase.com/entry/2021/01/28/190209

Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations

https://www.amazon.com/Accelerate-Software-Performing-Technology-Organizations/dp/1942788339
Lean と DevOps の科学

補足: 所属する SRE Team の Vision / Mission / Value

Vision

最高の学習プロダクトを作り続けられる開発組織の実現

Mission

自己完結チームがプロダクトを素早く安全に届け続けるためのプラットフォームと文化を作る

Values

Fail smart

失敗を非難せず、学習の糧とする。また、影響範囲をコントロールし、最小のリスクから最大のリターンを得られるよう、プロセスに失敗を織り込む。

Learning

未知の課題を発見・解決するために、あらゆる物事を学習の機会と捉え、必要な変化をし続ける。

Borderless

組織の垣根なくコミュニケーションし、協力しあうことでより大きな成果を目指す。

Metrics-driven

あらゆる課題・物事を指標化し、問題を点ではなく線で捉え、柔軟かつ自動的な解決を目指す。

どうやって取得するか

Cost

まず、インフラコストを Staging と Production で分離する必要がある。基本的に AWS とかであればタグで分離しつつ、最終的にはアカウント分離したほうがいい。他のサービスも同様。

Production Cost / Number of Monthly Active User

これはデータソースがどこかにあって redash で見れると思うんだけど、ちゃんと調べる必要がある。

Production Cost / 売り上げ or 営業利益

これは頻繁に更新されるもんでもないので半年に1度とかで手作業のスプレッドシートで十分。

Staging Cost / Number of Developers

これは毎月 Spreadsheet が更新されている。google spreadsheet って api あるんだっけ？そこからとってきてdatadog に export するやつ書きたい。

Developer Productivity

Number of deploys

CircleCI および GitHub Actions で metrics をすでに取得できている。
branch ごとに計算すれば良い

Time to deploy

これは一手間必要。

• Deploy 時に deployment の annotation に PR number を入れる
• time-to-deploy-exporter(仮) が deployment の変更を検知する
• deployment が ready になった時間と、Github api を使って PR が merge された時間を取得する
• その差分を計算し、統計情報を metric として export する

Metric として単一イベントを持つと結構取扱いが難しくて、できれば内部で Average, Median, P95 などを計算して、直近 n 日間の値を metric として出す形が望ましい。

CI Stability

CircleCI および GitHub Actions で metrics をすでに取得できている。
ただし、悪化したとしてどこからどう手をつけていくのか、インセンティブ設計および分析の方法をもう一歩推し進める必要がある。

Site Reliability

MTTR / Mean time to recovery

自動の取得は基本的に難しい。また、障害自体めったに起きないので、インシデント報告フローに障害発生時間と復旧時間を記録して、まずはスプレッドシートからなんとかするのが第一歩として良いか

Team Health

Number of alerts

datadog-monitor-prometheus-exporter を作りたい。https://github.com/chaspy/datadog-monitor-prometheus-exporter

ちなみに monitor summary は csv で取得できる https://docs.datadoghq.com/monitors/faq/how-can-i-export-alert-history/ し、summary はwewekly で配信されているが、ラベルでフィルタしたいし、etric として扱いたいので自作したい。