メリークリスマス！maruです。この記事はSRE アドベントカレンダー2023の12月25日分です。最後のアドベントカレンダーがポエム記事で恐縮ですが、振り返りつつ思っていることを書きなぐります。
私は2020年12月にLINEに転職し、SREチームに配属（当時専任SREは私1人）、なんとかかんとか3年ほどチームとして続いてきました。チームメンバーも専任SREは最大4名（現在は3名）となり、順調に拡大しているところです。
2023年の私の外部登壇や記事は下記のようなものがありました。
Postmortem as a textbook at みんなで学ぶポストモーテムLT
ツール・プラクティスの導入と浸透における課題と対策 at TechFeed Experts night SRE
障害を前提に準備する at SRE大集合LT大会
予期せぬアクセス急増、その謎に迫る at ゆるSRE1
LINEスタンプの事例集: 大きなスパイクアクセスを捌くためのSREing at SRE NEXT 2023
失敗？それとも学び？ at ゆるSRE2
LINEの「あけおめLINE」過負荷対策 at Gihyo.jp SREの現場から
さて、そんななんやかんや3年ほどSREチームをリードしてきて、ようやくSREチームにおける私のリード＆マネジメントスタイルを自覚してきました。今日はそれをなるべく他人にも伝わるように言語化を試みたいと思います。
自然体なまま、良い状態になりたい
「水が低きに流れるように、人は易きに流れる」という言葉を聞いたことはあるでしょうか。これは「安易な道に行くな」という戒めのために使われることもあるようですが、原典においては「自然体こそが最上の善」であり、自然体を体現している水はとても素晴らしく、そして「人もまた易きに流れることは自然（で善いことである）」というお話だそうです。
そして私の思想としては、各個人、エンジニアだけでなく他の職種も、さらにはエンドユーザーも、各々が自然体で良い状態に落ち着くのが理想と考えています。
つまり何が言いたいかというと、「誰かが意識してるから、なんとかそうなってる」みたいな状況がとても嫌いです。例えば「誰かがポストモーテムを推進してるからポストモーテムを書いている」みたいな状態は嫌いです。「誰も意識してないからこそ自然とそうなる」、その結果として良い状態になっていることが理想です。
「インフラの変更であってもリリースする際には、プルリクエストでレビューされる」が当たり前であって欲しいし、「変更がリリースされる際は、その変更を加えた人がサービスのレイテンシなどのメトリクスに意識を割く」のが当たり前であって欲しいし、「ユーザーにプッシュ通知を送る際に同時にアクションするユーザー数を企画者が意識する」のも当たり前であって欲しいわけです。
そして、それらはSREという専門ロールの人が「Infra as Code！！」とか「SLO！Observability！」とか「Launch Coordination Engineering！」とかを口うるさく言うからではなく、自然体でそうなっている状態が理想です。
低きに流れた結果狙った場所に留まれるように
つまり私にとって、今のSREチームというのは、水が低きに流れて”狙った場所に”留まれるように、「地面を掘って整地する係」です。
そしてその「地面を掘って整地する係」でいるには、「強さ」や「巨大さ」や「盤石さ」というものは邪魔だと考えています。
有り体にいえば、コンウェイの法則を意識しているわけですが、SWE視点では「なんでもやってくれる強いSREチームが存在すると、そのSREチームを頼るのが自然体になる」わけです。
さらに悪いこととして、SRE視点では「何かを進めるのにSRE内で十分議論できて、SRE内で完結して進めるのが手っ取り早く自然」なことが挙げられます。
こうなるとチームごとのただの分業で、私の理想とするSREチームの役割ではなくなってしまいます。
たった一人のSRE、そしてプラットフォームはやらない
ただの分業を防ぐために実際に行っていることはこの2点です。
1つのプロダクトに埋め込まれるSREは一人だけ
プラットフォームは持たないけど、作るのは手伝う
SWEの協力なくして、大したこと出来ないSREになる
各プロダクトにSREが一人しかいなければ、IaCのツール選定も含めて、すべてそのプロダクトのSREとSWEの議論によって決定しなければいけません。他のSREメンバーは有識者として、terraformやk8s manifestのコードレビューには参加しますが、テクニカルディシジョンには参加しません。そのプロダクト内では、SWEの協力なくしてSREは大したことは出来なくなります。
SREの顧客は常にエンドユーザー
そして「プラットフォームを持たない」については、「私たちSREの顧客は常にエンドユーザーである」と言い換えることも出来ます。つまり開発者を顧客としたプラットフォームを持たないようにしています。開発者体験の改善などを行う場合も、常に自分たち自身が受益者になるような改善に留めており、SWEのためだけの改善はしません。
これが出来るのは、プラットフォームエンジニアリングの専門チームがいるからこそではあるのですが、プラットフォームエンジニアリングのチームは私たちのためだけに開発しているわけではないため、しばしば私たちにとって重要な機能の優先度が低いことがあります。そういった場合は、プラットフォームを持ちたい欲に強く駆られるわけですが、そこを踏ん張って、プラットフォームチームのコードベースにコントリビュートしたりしています。
つまり、プラットフォームは持たないけど、プラットフォームへのフィードバックは行うし、なんならプラットフォームにプルリクエストを投げる形で作ることには貢献しています。
フットワークの軽いEmbedded SRE
このような形でEmbedded SREチームを運営していくと、どのプロダクトに対しても影響力や依存を控えることが出来るため、比較的フットワーク軽めに様々なプロダクトで様々な角度から信頼性向上を目的とした改善を行うことが出来ていると思います。
まとめ
長文となりましたが、頑張って考えていることを言語化してみました。このような弱くて小さなSREチームが大きなこと（当社比）を成し遂げていられるのは、各プロダクトのSWEの超絶なるサポートがあるからです。またプラットフォームを持たずに、それでいて機能開発もしないエンジニアが成果を出せているのは、プラットフォームを持ってくれているチームがあるおかげです。そして、これを今言語化しようと試みた理由は、私自身が「常にプラットフォームエンジニアリングへの引力を感じている」からです。自然体に身を任せるべきならば、私は今すぐに欲しいプラットフォーム作りに専念したいですが、そうすると今の強みである「SREスペシャリストたちのフットワークが軽い」が失われると思っています。さて、この引力をどうにかするには、次は何が必要かな。
では、良いお年を。