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 として、何らかの指標を観察し、その改善を目指して仕事を進める・優先度づけをするアプローチの必要性を感じている
- やることが多すぎる中、優先度をつけることが難しい
- 何らかの改善を行ったとして、それがどれぐらいよくなったのか定量的に判断ができない
3つの指標をあげた。
- Production Cost / Number of Monthly Active User ユーザ数に比例してインフラコストは増えるはず|
- Production Cost / 売り上げ or 営業利益 ビジネス観点で、売り上げがないのにインフラコストを使うのはよくないので|
- Staging Cost / Number of Developers 開発にかかるコストは開発者に比例するはず|
Staging か Production かは大きく区別したい。その上で、何らかで正規化しないといけないのでそれぞれ関連するもので割っている。まずはタグなどを使ってこれらを分類、可視化をし、その後何が効くかを考えて計画を立てて実行していく。
指標は持たない。追いかけうる指標はあるが、基本的にやれと言われたことをやらないといけないので、それを他の領域とバランスを考えながら確実にプロジェクトマネジメントをして進めていく。
3つあげた。Staging と Production 両方見ていく。
- Number of deploys
- Time to deploy
- CI Stability
SRE Team であるからには、サービスの安定稼働は第一のミッションであり、いかに他の指標を満たそうともサービスの信頼性を落としては意味がない。ミッションにある"安全に"の部分を担保するために、この観点は必須だろう。
だからといって SRE Team がサービス全体の SLO 99.99% だとか決めるのはナンセンスだ。サービスレベルはビジネス要求によって変わるし、それは信頼性と機能開発のバランスをとるためのツールでしかないので、この数値自体を目標値にするのは本質的ではない。
指標としては1つあげた。
- MTTR / Mean time to recovery とはいえ安定して稼働している時間をできるだけ長くとることは大事だし、障害を局所化したり、すぐに復旧できるようにする必要がある。
結局 SLO と似たようなものを見ていくようになるかもしれないが、障害と判定されてそれが復旧するまでの時間をできるだけ短くなるようにトラックしたい。これが長くなってしまった場合、それを短くなるような仕組みであったり基盤の改善、あるいはプロセスの整備を SRE Team だけでなく Product 開発チーム全体で目指していきたい。
余談ながら、MTTR に Number of the affected user を入れるかどうかちょっと悩む。
いったん普段受けるアラートの数を追いかける。認知負荷を奪うので。
- 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 を途中で変えたり、経過を定期的に観察したりというアプローチを組織ですでにやっているのであれば事例が聞きたい
- 運用フェーズにはまだまだ至っていないので
補足: 所属する SRE Team の Vision / Mission / Value
Vision
最高の学習プロダクトを作り続けられる開発組織の実現
Mission
自己完結チームがプロダクトを素早く安全に届け続けるためのプラットフォームと文化を作る
Values
Fail smart
失敗を非難せず、学習の糧とする。また、影響範囲をコントロールし、最小のリスクから最大のリターンを得られるよう、プロセスに失敗を織り込む。
Learning
未知の課題を発見・解決するために、あらゆる物事を学習の機会と捉え、必要な変化をし続ける。
Borderless
組織の垣根なくコミュニケーションし、協力しあうことでより大きな成果を目指す。
Metrics-driven
あらゆる課題・物事を指標化し、問題を点ではなく線で捉え、柔軟かつ自動的な解決を目指す。