本セッションの登壇者
セッション動画
「ツール・プラクティスの導入と浸透における課題と対策」という題でお話をさせていただきます。
ここまで5人のベテランエンジニアの方が登壇されて、SREが芽吹いていないところに新しく導入する、すでに開発者がSREをやっていたけれどSRE専任のエンジニアとしてジョインする、オブザーバービリティをどうやって始めるのかといった、0から1にする部分の悩みを持っている方向けの話だったかなと思うんですけども、今回、私の方で話したいのはその先、1から10にする話です。
今回話す内容をざっくり言うと、成長し始めたSRE組織での課題、どうやって解決したのかという部分で、私たちの具体的な事例をお話しして、最後に軽くまとめて終わりにしたいと思います。
少人数のチームと多人数のチームでトレードオフがある
まず、私たちはLINEの主にスタンプのチームにフォーカスするSREチームです。チームトポロジーではストリームアラインドチームと呼ばれています。このSREチームは2019年にはありませんでした。2020年あたりから１人、2人と毎年人が増えていって、担当のプロダクトもLINEスタンプだけだったのが横にどんどん広がっています。0人の時はSREでリライアビリティの改善を誰もやってなかったのかというとそうではなくて、開発者が自ずとSREを実践していました。1人増えたところで開発者とSREエンジニアが一緒にやり始めて、2人、3人と増えていくにつれて、SREの人がどんどんリードするようになってきています。
SRE専任のエンジニアが増えると何が起こったのかという話をします。SREが1人のときでも設計とかコードレビューは当然複数人でやるので、常に開発者（SWE）と一緒にやっていました。これは非常にいいループがあって、本当に必要な改善を現場を見ながらできていました。一方で、担当できるプロダクトの数には限りがありました。SREチームが成長していくと、コードのレビューや新しいツールの調査もどんどんSREチームの中で議論して深められるようになります。また、あるチームに導入したプロダクトを横展開して、知見の共有が進むのは非常に大きな特徴かなと思います。
両方とも、利点をひっくり返すと改善点というか課題点になります。たとえば0～1人の時には破壊的な大きな変更が後回しになりがちです。これはマンパワーの問題だったり、そもそも変更することに抵抗感があったりするからです。また、横展開する余裕がないので、当然サイロ化しがちです。
では3人、4人、5人と大きくなればいいのかというとそうではなくて、検討段階で開発者の声が拾いきれないので、本当に開発者が欲しかった機能、たとえばDevOpsのツールとか、本当にユーザが必要だったリライアビリティまで拾いきれないとか、そういったところが不足しがちだったりします。
もちろん人数が増えて、チームに閉じた議論ができると効率がいいので変化が早いんですよね。Kubernetesに移行しました、DBを移行しましたといった変更が劇的過ぎて、開発者たちが変化のキャッチアップで疲弊していくということもあるかなと思います。つまり大きなSREチーム、小さなSREチームともトレードオフの関係があって、SREが少なければ、サイロ化しがちだけど個別に最適化できている、逆に多いと作って作ってで終わりになってしまうビルドトラップみたいなことがあり得るかなと思います。
じゃあどうやって解決するかですが、いろいろな解決方法が過去にもいろいろ提案されてきたのですが、「そうだ、人の進化の歴史を思い出そう！」ということで、ウルトラCな解決策をちょっと考えてみました。
ヒトの進化の歴史にヒントが！？
ヒトはさまざまな淘汰圧に対して適応しながら発展してきたわけですね。進化仮説というのは、他の霊長類とかと比較してヒトは何が差別化要因となってこんなに発展してるのか、みたいなのを研究する分野です。じゃあそれをどうやって活かせるのか。SREの改善に適用すると、どうやって適応しながら変化していくのかというところに解決方法のヒントがあるかもしれません。
ちょっと調べてみました。ざっくり言うと4つぐらいメジャーな仮説があるようです。
1つ目がハイブリッド化仮説です。これは遺伝子的な交雑による多様性で、異なる能力や特性を持つ個体が混ざりあって1つの集団になるもの。2つ目の社会的脳仮説というのは、大きな集団の中で役割分担、協力とか競争とか対立とかを行ないながら、脳を発達させながら役割分担をしていくもの。3つ目の持久走仮説というのは、僕は「へぇ」と思ったんですが、人間って霊長類の中でも長距離を走行することに特化しているらしくて、動く獲物を追い詰めて狩ることができるらしいんですね。それで、木の実だったり葉っぱを食べる草食から肉食化して、高たんぱくとか高エネルギーなものを摂取できるようになって、エネルギーの総量が上がって脳が発達したというもの。最後に料理仮説。これもすごくおもしろくて、実は日本語の書籍が出ていて僕も読んでいるんですけど、牛って草を食べるように体が最適化されていて、人はそういう意味でいうと料理したものを食べるように最適化してるという仮説です。たとえば顎の大きさがチンパンジーの半分だったり、胃の大きさが半分だったりして、消化吸収の効率がいいものを食べることを前提に発達していて、それで脳が発達して行動範囲が広がって、という仮説があるそうです。
ここからどんなヒントが得られるかなんですけど、ハイブリッド化仮説からは異なる能力、特性を持つ個体でチームを組織するというのが導けます。何かヒントっぽいですよね。社会的脳仮説からは役割分担して効率的にみたいなのがキーワードですね。持久走仮説からは、これはこじつけに近いんですけど、導入や改善の総量を増やすことです。たとえば草食から肉食に代わってカロリーが増えるみたいなイメージで、導入や改善の総量自体を増やすこと。そして、料理仮説というのは消化効率を上げること。導入や改善をちゃんと自分の血肉にする効率を上げる。この4つがある意味ヒントなのかなと考えています。
では、ちょっと戻ってみましょう。0から1人のときと、2、3人以上のチームのときがそれぞれどう分類できるのかと考えると、4つの仮説をきれいに分割できています。まず0から1人の小さなチームは、結果的に異なる能力や特性で協力していますよね（ハイブリッド化仮説）。リライアビリティにとにかくフォーカスする人と、フィーチャーの開発とかにフォーカスしたりする人が混じり合ってやるので導入の消化効率が良い（料理仮説）。その逆が3人以上のチームで、役割分担して効率的（社会的脳仮説）だし、導入の総量が多い（持久走仮説）。じゃあどうやってそれを両立しましょうかというので、ここからが私達の事例です。
関係性を変えてSREを埋め込む、開発者視点のアナウンス
まず関係性を変えるというのをやりました。私達はLINEのスタンプとか、ホームタブというプロダクトのSREを担当しているんですけども、それぞれのプロダクトに明確なSREメンバーを埋め込む（embedded）ということを行っていて、実際のタスクとかは開発者と一緒にやるので、異なる能力、特性で協力し合っています。それぞれのプロダクトの課題とかを集約して、1つにまとめることで総量を増やすことができ、横展開がしやすくなります。また、開発者との役割分担はそのままにして、オーナーシップを取りやすくしています。まずこういった、いわゆるEmbedded SREという形を明確に取るようにしました。これが中長期的な改善です。
もう1つ、導入のアナウンス方法を変えるという短期的な改善も行ないました。今までは、新しく何かを変更しました、たとえば「Fluentdの設定を変更してKubernetesのEventログをKibanaで検索できるようにしました！」といったアナウンスを、週次ミーティングやSlackで行っていたんですけど、これはSRE視点のアナウンスなんですよね。それを開発者視点のプレスリリース、改善記事として出すようにしています。たとえば、「今まではPodがKillされた原因を調べようとした時に、Kubernetesに接続する必要がありました。またそのログが1時間しか保存されなかったので調査が大変でした。なので私たちSREチームがそれをデータ分析基盤に送信するようにしましたよ。だからKibanaを使ってみなさん検索して調査できるようになりました。たとえばこういうのを調べたいときはこんなクエリを書いてください」みたいな、もう本当に1枚の記事として出すように変更しました。
ただ、これもどんどん流れていってしまうものなので、変更点をまとめて共有する会議を毎月開催しています。会議では、プレスリリースの紹介をしたり、発生した障害を紹介したり、進行中のタスクを共有したり、オープンディスカッションをやったりしています。
まとめ：独りよがりにならないことが重要
では、まとめです。開発者がSREをやること、またSRE専門のチームを組織してやることのそれぞれにメリットとデメリットがあると考えています。ただどちらにしても独りよがりにならないように工夫が重要ですねという話でした。人の進化仮説についてはちょっと寄り道をしたかっただけなので、トリビア程度に聞いていただければ大丈夫です。
