本セッションの登壇者
セッション動画
「なぜSREをはじめるのは難しいのか」について話していこうと思います。よろしくお願いします。
「これでいいんだっけ？」をなくすために
なぜ難しいのかを考えたときによくあるのが「これでよかったんだっけ?」となるケースじゃないかなと思います。たとえば、SREとは言ってもインフラエンジニアから名前を変えただけだったり、何でもできるエンジニアが担当した結果、何でも屋さんになってしまったり、他社事例をトレースしたんだけどうまくいかなかったり…などです。
最近はこういう話がすこし高い解像度で出てくるようになっています。もちろん必ずしも問題があるわけではありませんが、たとえば開発メンバーから一方的に依頼を受けているだけで「これでいいんだっけ?」となっているとか、一方的にSREプラクティスを導入したんだけどそれが運用できなかったとか、煙たがられてるんじゃないかとか、いろいろ考えることがあると思います。
このように、「これでいいんだっけ?」となりがちなのが最近のSREの難しいところなのかなと思っています。そこで今回は、「これでよかったんだっけ?」にならないようなTipsをご紹介したいと思いますので、皆さんにとってヒントになれば幸いです。
用語の前提ですが、「サービス」という表現は、今回の文脈上では「システム」という言葉に置き換えて大丈夫です。また、SREというものは組織によって役割がまったく異なることがあるので、そこは読み替えていただければ嬉しいです。
自己紹介ですが、マネーフォワードで人事労務SaaSのSREをしています。ひとりめのSREとして自部署に参画して、2022年のSRE NEXTで「一人から始めるプロダクトSRE」というお話をさせていただいたことがあります。現場の仕事や採用、チーム運営、広報などもやっていますのでいろいろ聞いてみてください。
こんな感じで給与計算とか勤怠管理とかサービスを担当しています。
SREを入れる目的によって打ち手は違う
さっそく本題ですが、個人的にいつも確認しておきたいと思っているのはこのあたりです。後で解説を入れていくので、まずは見ていこうと思います。
現代のSREは難しく、激しく多様化していると思っていて、同じ会社であってもチームが違えばSREが持つ使命も変わってくると思っています。なので、組織における目的というか、需要がどこから来たのかを確認すると良いと思っています。
次に、SREを理解している人がどこにどれくらいいるのか確認していました。自分しかいないのか、上長が理解しているのか、あるいはメンバーには知っている人がいるのか、などを確認すると良いと思っています。
もうひとつ、(SREチームが)どんな存在というか、どういう立ち振る舞いであるべきか、などもよく考えたりしています。たとえば、チームを組んだときに「すべて俺たちに任せてくれ!」と振る舞うのか、プロダクトやサービスを作っている人が自律的に運用できるように支援していくチームにするのか、あるいはサービス開発者も私たちにとってはSREのユーザーだから、そういう人たちに「ツールを作るから利用してほしい」と要望するのか、など、いろいろな形があると思います。
ここからいくつか具体例を見ていきます。
たとえば、「その需要はどこから来るのか」を確認したいのであれば、「サービスをもっと安定させたい」とか、「しょっちゅうアラートが鳴っててつらい」というところは、モニタリングの体験やパフォーマンスの話になると思いますし、「開発効率があまり良くない」ということであれば「プラットフォームの体験を良くしたい」につながると思います。
そういった需要から、サービス安定化とかアラートの問題なら、SLO/SLIなどGoogle SRE入門にあるような活動でやってもよさそうですし、逆にプラットフォームの体験みたいな部分が強く出ているなら、そこはいったん置いておいてサービス基盤の強化に時間を割いてもいいと思います。
SREは「土壌を育てる」ところから
次に組織の状況です。SREの概念という部分が組織内に存在している場合は、はじめるハードルがぐっと下がりますが、問題はそれがない場合です。SREを銀の弾丸だと思っている人や、すべてを任せても大丈夫だと思ってる人もいるかもしれませんが、土壌がないところではSRE活動はなかなか育たないので、いきなり導入しようとしても難しいケースが多いように思います。
そういう場合は、「SREっていったい何ですか」という部分を理解してもらうステップを入れることが重要です。先ほどの目的観から、SREの私たちが何をして、何をしないのかも明確にして取り組みを始めると良いかと思います。
もし組織の体制がDevチームとOpsチームを分断しているような状況だったら、SRE活動を進めるにはまずそこから変える必要があるかもしれません。現場によって判断が違うとは思いますが、こういう判断もあり得るとわかっていればスムーズに進む可能性が高くなります。
チームトポロジから「ありたい存在」の形を探る
最後の目的はその組織体制によって、SREの関わり方が形を変えることだと思ってます。技術でリードして、信頼性を高めるために何でもやるというチームもあれば、ファシリテートで支援するみたいなチームもあるだろうし、開発ツールを作ってそれで支援をするというチームもあるかと思います。この状態は固定ではなく、組織やサービスのフェーズによって変化していくこともあります。
この図式を「なんかどこかで見たことあるな」という人がいらっしゃるかもしれません。実は「チームトポロジー」(マシュー・スケルトン/マニュエル・パイス著 日本能率協会マネジメントセンター)という本に似たようなことが書いてあります。
チームトポロジには実際的な組織設計をする場合の役割が書かれています。このストリームアラインドチームという名前はあまり聞きなじみがないと思いますが、いわゆるGoogleのSRE本に書かれているSREがこの役割になっています。本番環境に責任を持つためにいろんなことをする人たちのことです。ここでチームトポロジの話をしすぎると時間がなくなってしまうので、気になった方はぜひ読んでみてください。
私のチームではストリームアラインドに近い状態で組んでいます。設計、アーキテクチャの設計、開発、モニタリングなどにも手を貸している状態です。必ずしもチームトポロジの定義に当てはめる必要はないのですが、型が欲しい場合には参考にしてもいいと思います。
最後にまとめです。SREも多様化しているので、目的が曖昧だとなかなか頭でっかちになってしまって、怖くなったり不安になったりすると思うので、ぜひこのあたりを確認してみてください。
私の発表は以上です。ありがとうございました。
