こんにちは。SRE の chaspy です。先日オンラインイベントで登壇しました。
本記事では、その時の発表を完全にブログ化するのではなく、話した内容をベースに、あらためて今我々 SRE Team および開発組織・事業が抱えている課題とその打ち手を説明します。また、当日出た質問への回答も記載します。
抱えていた課題
SLI/SLO を事業レベルで合意できていない
Quipper では1年半ほど前に SLI/SLO をプロダクト開発チームに導入し、全てのサービスに SLI/SLO が定義・運用されています。一方で、エラーバジェットポリシーの策定や、SLI/SLO そのものの定期的な見直しができていない点に加えて、Business Developer を含む事業レベルで合意できていないことから、SLO 違反を起こしたときに新規開発と止めて信頼性に投資するという意思決定が難しいという課題がありました。
この課題を解決するのは簡単でなく、そもそも現状の SLI が本当にカスタマージャーニーの重要な部分を示している指標になっていない点を改善していく必要があると思っています。また、Backend サービスの Latency SLO に関しても、エンドユーザの体験を表す Frontend での SLO を策定し、それを満たすための Backend Latency SLO という位置付けにしないと改善も難しいように感じます。
上記の点は今後も引き続き改善に向けて開発チームと連携していきたいと考えていますが、事業レベルで同じ目線を得るには、SLI/SLO だけでなく、そもそも SRE / Platform 開発の仕事の事業との位置付けを明らかにすることが必要だと感じました。
SRE Team 内の業務の優先順位付けが難しい
途方もない範囲の業務がある中で、どのように優先順位をつけるのか。現状は個人が（チームメンバーからのフィードバックを得ながら）意思決定しています。それ自体は裁量があって良いと思いますが、時に意思決定は難しく、負担にもなり得ます。また、チームも少しずつ拡大しており、全員でコンセンサスを取ることも、全員の知識レベルを平等にするのも現実的ではありません。
対策として誰か1人が優先度を決めることもできますが、それはその意思決定者がボトルネックになることを意味し、スケーラブルではありません。また、どんなに優秀な人だったとしても、業務範囲の広さと深さが求められている中、その1人が正しい意思決定ができるとも思えません。
そんな中できることは、意思決定を助ける何らかの方法を見出すことです。それはチーム内でタスク見積もりの技術を身につけたり、課題とソリューションを言語化し議論しコンセンサスを取る能力を得ることも必要ですが、それ以上に重要なことは比較可能な指標という Fact で判断することです。もちろんあらゆるものを指標化することはそれ自体がコストですし、難しいものもありますが、可能なところからやっていく必要があると思います。
解決策: Platform を"プロダクト的"に考える
上記の課題に対する解決策が「Platform を"プロダクト"として考える」ことです。SRE の業務を、開発者というユーザに、Developer Productivity、Production Reliability という「価値」を Platform という「プロダクト」として提供する、と解釈すると、これはプロダクトでの事業開発と同じ構図になります。
この考え方を適用することで、自分たちの仕事と事業との関連性を定義付け、またその指標があることで改善に対する策の優先順位も付けやすくなることが期待できます。
"プロダクト的"とは何か。少なくとも以下の考え方が当てはまりそうです。
- ユーザのことを考える
- ユーザに提供する価値を考える
- 提供した価値を表す指標を定義する
- 指標を改善するために仮説検証を繰り返す
ありがたいことに Product Management はここ数年で一気に体系化され、書籍やフレームワークも多く紹介されるようになりました。そのノウハウをそのまま使うことができる点もメリットとして大きいです。
適切な指標をどのように定めるか
「Lean と DevOps の科学」を参考にしながら、デプロイ頻度を main KPI として定めました。その妥当性は、事業 KPI, 学習KPI との関連性、そしてプロダクト開発のユーザに届けてみないと価値を届けられているかわからない目的不確実性があるという前提を考慮し、仮説検証を繰り返すことをキーに置くところから意味づけました。
このように考えてみれば当たり前のように思えますが、本当にこれが正しいかはわかりません。逆に、100% 正しい KPI は存在しません。KPI 設定自体も「正しいらしい」ものを目指し常に改善を繰り返す必要があります。これは SLI/SLO も同様ですね。
そして見るべき指標は1つではありません。main KPI を1つ定めながらも、システム的に複雑に関係・連動する他多数の指標もモニタリングする必要があります。
もちろん、計測する際には計測可能にするコストや、データ量、データ変更頻度など様々な特性があり、何から何まで全て取ればいいというわけでもなく、これはメンバーの実装力や Platform がこれをどうサポートするか、外部の SaaS / Tool をどう選定するか、などを考慮してバランスよく決めていく必要があります。
Site Reliability Engineering の最終目標は組織への実装
僕は近い将来 SREs という専門 Role / Team はなくなると考えています。SRE という横断組織とサービス開発チーム、どちらがサービスのことをよく知っているかというと言うまでもなく後者でしょう。従来システム管理者がしていた手作業は自動化され、Platform そのものの機能として実現されつつあります。その場合、残る「Site Reliability Engineering」に関することは、サービスチームがより正しいらしいユーザ価値を示す指標 = SLI を定め、それを改善し続けることです。SLI/SLO を中心にしながら、サービス開発をより安全に、高速にすることをサービス開発チーム自身でできるようになる必要があります。
スタディサプリ / Quipper でも直近はサービスそのものに特化した信頼性の問題が増えてきており、定期的な負荷試験の実施やドメインに特化した指標を用いての Scheduled Scaling など、サービスチームの協力なくしてはできない事例が増えてきています。
サービスのことに一番詳しいサービスチームが、自分たちの生産性と信頼性を、自分たちだけで改善し続けられる世界が最も合理的なのは言うまでもありません。その頃には横断組織としての SRE は不要になるでしょう。今はまだその道の途中です。しかし、かなり順調に進歩してきていると感じます。今後はこれまで同様、開発チームが信頼性を扱う方法をうまくインストールしながら、開発チームを顧客として価値を提供する Platform を"プロダクト的"に作っていきたいと考えています。
おわりに
Quipper では"最高の学習プロダクトを作り続けられる開発組織の実現"のために、"自己完結チームがプロダクトを素早く安全に届け続けるためのプラットフォームと文化を作る"仲間を募集しています。
QA
SREはスクラムの中ですか？外ですか？中の場合は掛け持ちですか？
横断チームなので外です。Embedded SRE 的に中に入った方が開発者の業務理解や、課題をより解像度高く理解できるとは考えています。
SREがSLI/SLOのふりかえりには普段入らず、気になったときに介入すると話にありあしたが、これはソフトウェアエンジニアがSREに参加して欲しいとリクエストするのか、SREが自分たちの判断でフォローに入るのとどちらでしょうか？また、どちらの場合もどのような判断理由で参加しているのでしょうか。
両方あります。SLI/SLO を Slack の highlight word に設定しているので気づいた時に声かけたり、かけなかったりしています。また、metric が取得できていないとか、設定方法がわからない場合、開発チームからメンションをもらうこともあります。
開発環境のSub KPIsはプロダクトによって影響関係が異なりますか？それともどのプロダクトもだいたい似たような影響関係になりますか？
影響関係はだいたい同じかもしれないんですが、どこを重視するかはプロダクト・ビジネス形態によって異なると感じています。BtoC プロダクトの場合、本番へのデプロイ数を重視するのはマッチするのですが、BtoB プロダクトの場合、提供先が学校なので、本番へのデプロイ数を多くするインセンティブはあまりなく、障害の時間を短くするとか、開発体験をよりよくするほうに意識が向くようです。このように同じ Platform (as Product) を提供するとしても、重視する指標はプロダクトごとに違うので、顧客（のビジネス）理解はとても重要だと感じています。
開発生産性についての意見や要望はどのように開発チームから吸い上げたり、すり合わせたりされていますか？メトリクスによる判断に加えて、定性的な声をどのように受け取り活用しているのか伺いたいです。
要望を受け付ける目安箱のような GitHub Issue からもらったり、Slack 上で問い合わせをもらったり、1on1 や、開発チームのペアワークなどを通して定性的な声をもらっています。今後は定期的な Survey やユーザインタビューも取り入れて行きたいと考えています。
開発チームのVSM整理などを行うにあたって、SREが開発・リリース手法を変更したりしましたか。それとも開発方法自体はソフトウェアエンジニアに任せていますか？ SREが開発チーム内(スクラムチーム内？)にいた方がやりやすいとか思うことはないですか？
SRE が開発・リリース手法を変更しておらず、お任せしています。直近では local 開発環境として Eclipse che https://www.eclipse.org/che/ を開発メンバーと SRE がペアで検証しており、実際に動くところまで行った例はあります。VSM 整理や、課題を理解する上で、Embedded SRE 的に開発チーム内にいるほうが便利な点は多くあると思います。また、負荷試験をやる際にも、ドメイン知識があると的確なチューニングが可能なので Embedded SRE のような存在があるとより効果的に試験を行うことができるでしょう。
スタディサプリとQuipperと複数のプロダクトのSREを担当しているとのことですが、指標は共通化しているのでしょうか？
いったんは同じ指標を見るでいいと思っていますが、やはりビジネスの特性は異なるので、顧客のことをよく観察し、この指標で良いのか？は問い続けることになると思います。
サービス開発を始めたばかりでインフラエンジニアがひとりのため、開発者の意向が強くなり、インフラで重視したいところがうまく意見が通らない場合は、どのように折り合いをつけていますか？
回答が難しいのでぜひ 1on1 しましょう！課題をちゃんと説明するとか、ペアでやるとか、そもそもインフラで重視したい考え方が組織で理解されてないので上長に相談するとか、いろんな方法があると思います。個人で解決するのはなかなか難しい状況に見えます。
SREのチーム/個人の目標設定はどのように設定していますか? うちでは横断であるがゆえに他チームからの相談など読めない割り込みが多くなって目標にチームや個人が進んでいくのが難しいことが多くなることが多く。。。 こういったことがもしあれば何か工夫していることはありますか?
他チームからの相談やインシデント対応、アラート対応など、割り込みのタスク以外の範囲で目標設定をしています。仮にこのような Reactive なタスクが多くて目標達成のための Proactive な業務ができない場合は、例えば当番制を導入するとか、チームメンションに対してランダムにアサインをしたりして負荷分散を試みています。実際、アラート対応はその日の Daily Standup のファシリテータが対応します。誰がやっても同じ依頼はランダムにアサインし、もし他の仕事でできなさそうなら都度担当者を相談して決めています。
SREの目標みたいなのはどのようなものがあるのでしょうか？SLOの達成度合いとかはどれくらい人事的な評価に影響があるのでしょうか？
目標は抽象度が高く、問題をより根本的に・構造的に解決するような種類のものが多いです。SLO の達成度合いは人事評価に影響は一切ありません。
主にSREが担当する領域において、当面の技術的課題はどのようなものがありますか？
Enginering Manager の @yuya-takeyama の回答を引用します。
月並みな言葉で言うとスケーラビリティとサステナビリティということになると思います。
ここでいうスケーラビリティはシステムのものそうですが、それ以上に組織としてのスケーラビリティです。 そのために重要なのが発表内、SRE チームのミッションの中でも出てきた「自己完結チーム」です。
現在マイクロサービス化を初めて3年ほど経っていますが、一番の理由はそこだと思っています。 各ビジネスチームが自分たちの中で解決すべきビジネス課題を定義し、そのための施策や開発を計画し、それを実現するための機能を開発したり、それを実現するためのアーキテクチャを構築できたりと、一連のライフサイクルを自己完結でできることが重要です。
現状でいうとリリース当初から存在するモノリスがまだまだ大きく、更なる分割や、分割したサービスの継続的な開発・改善のサイクルを効率よく回せるようにしていく必要があります。 アプリケーションの開発・デプロイのためのプラットフォームもそうですし、SLOやポストモーテムのような文化との両輪が重要だと考えています。
もうちょっと具体的な施策レベルの話でいうと以下のようなものが挙げられます。
- 自己完結チームのための次世代ジョブ基盤
- 現在、定期的に実行する決済ジョブ等は Jenkins で運用していますが、同じ Jenkins に複数のチームが乗っていることもあって、例えば高負荷で Jenkins に障害が起きた場合は複数のチームが影響を受けてしまいます
- また、深夜メンテナンスの際なども、停止しないといけないジョブについてあらゆるチームに聞いて回らないといけなかったり、ownership の所在もわかりにくくなっています
- これを AWS のマネージドなサービス等を利用して、各チームで自律的に運営しやすい基盤に移行したいと考えています。現在は StepFunctions をベースに、Kubernetes Job を実行する仕組みを、Terraform module を利用してコードとして定義できるようなものなどを検討しています
- AWS の複数アカウント化、Organization 化、SSO 対応
- 組織やプロダクトが大きくなっていく中で、セキュリティの重要性は上がり続けています。
- 現状は本番環境とそれ以外が VPC では分離されているものの、AWS アカウントは単一のものとなってしまっています
- セキュリティのため、それぞれの環境に対してアクセスできる人だったり、アクセスする方法について制約を加えて行っていますが、環境の isolation が不十分 (アカウントが単一) なので、セキュリティのためにアジリティが犠牲になるケースが増えています
- アカウント分割を正しく行うことで、例えば開発用の環境からは重要なリソース・データから完全に isolation できるため、強い権限を与えて好きに検証したり試行錯誤してもらえるような環境を用意することもできます
- 現在な組織にマッチしたクラウド環境を提供することで、セキュリティとアジリティを両立できるようにしたいと考えています
