2023年9月29日に九段会館で開催された SRE NEXT 2023 に参加してきました。また、弊社ウォンテッドリーはブロンズスポンサーとして SRE NEXT に協賛させていただきました。
https://www.wantedly.com/companies/wantedly/post_articles/546244

私は「SRE を実践するためのプラットフォームの作り方と技術マネジメント」というタイトルでお話しました。

ウォンテッドリーでは SRE チームというものは存在せず、フロントエンド、バックエンド、モバイル、インフラ、データサイエンスなどそれぞれの技術領域で信頼性に向き合っています。そもそも「SRE」というものに対して戦略的に取り組めているわけではありません。より現場での問題やサービスを良くするための具体の課題に向き合ってきた結果こうなっているという一例と、それを形作っている（と思われる）プラットフォームの存在、文化（雰囲気）を紹介させていただきました。

会場の雰囲気や他のセッション感想は参加した他の弊社メンバーのブログにまかせて、せっかくなのでこのブログではセッションでは言い切れなかったことや、個人的に CfP 出すに至った思いを書いてみようと思います。

なぜ SRE NEXT の CfP を出したのか

カンファレンステーマ、特に「Diversity」と「Empathy」に強く共感しました。

SRE は信頼性に対する思想やプラクティスであることから、かなり会社や個人の認識で取り組みや実情に差があります。自分も「SREっぽいことはやってるけど、これが正しいのかどうかは実際よくわからない」というのが正直なところです。しかしテーマ「Diversity」が指し示されていることで「信頼性への向き合い方はそれぞれ、その向き合い方を共有すると良さそう」と考えるようになりました。また上記ブログにおいて「Empathy」は

Diversityが「どんなSREでも受け入れること」であれば、Empathyは「SRE以外も含めて裾野を広げること」です。

とあります。ウォンテッドリーでは開発組織全体で信頼性向上のエンジニアリングを行っている（？）し、プラクティスとしてはポストモーテムの文化がビジネスチームや ISMS チームにも広がっているのでその辺共有できるといいなと思っていました。（結局セッションのテーマにはしませんでしたが）

これらのテーマから我々の事例を発表することで、誰かの勇気につながればいいなと思い CfP を出すに至りました。CfP にて提出した事前の発表内容も、成功事例とは少し遠い、「なんかそれっぽく SRE してるかも」くらいのテンションで書いています。

セッションおかわり

当日話しきれなかった部分を補足的に書いてみます。

なんで『みんなが SRE』と言ったのか

もともとインフラチームではずっと Kubernetes や AWS をベースにサービスの基盤を、開発者体験も考えて作り続けてきましたし、SRE とは言わずともサービスの安定性のために問題や課題に取り組んできたつもりです。また、インフラの安定性以外にも目を向ければそれぞれの技術領域で信頼性に取り組んできました。みんなが信頼性に対して取り組んでみんなで作り上げてきたサービスと基盤なので、インフラチームだけが「SREやってます！」なんで絶対言いたくないし、そういった意味を込めて「みんなが信頼性に向き合っている」と表現をしました。

なので発表を聞いてくれたみなさんも「自分の組織で SRE やる必要があるのでは？」となったら、「今自分の組織では信頼性に対してだれがどう向き合っているのだろう？」と観察してみてほしいなと思います。その組織だからやっている向き合い方、方法があると思いますし、それを知りたいなと思っています。

ちなみにセッション中に「実はセッションの裏で別のチームが画像配信サーバーのリアーキテクチャのリリース作業を予定しています」と話しましたが、その顛末も書いておきます。結果的には、最終 QA チェックで問題が発見されてリリース延期になりました。 しかし「ユーザー体験が落ちにくい工夫」「迅速なロールバックの準備」を行いつつ、最後まで品質を考えて問題を発見した、というのは本当に尊敬します。

プラットフォームと技術の話をもう少し

タイトルに「プラットフォームの作り方」「技術マネジメント」と入れつつあまり多くは話せなかったのでいくつか追加しておこうと思います。

発表では「全部 Kubnernetes でインフラは共通基盤になっていて〜」みたいな話しをしましたが、「共通基盤」自体の作り方を発表ではすっ飛ばしているので追加しておきます。いまでこそウォンテッドリーのマイクロサービスは Kubernetes に全部載っていますが、やっぱり最初は一部のマイクロサービスが稼働しているだけでした。また、基盤が2種類ある時代も長かったようです。小さく価値検証を始め、そこで得られた新しい基盤の価値が認識された上で、2種類あることで発生する認知負荷を下げたりプラットフォームとしての価値を最大化させるためにも、「全部 Kubernetes に載せよう！」という勢いが当時あったようです。やっぱり、自分たちが行った技術選定を正解にするためにも「信じて全部やりきる」というムーブメントが必要なのではないかと思います。 （もちろんプロジェクトとしての目標値や撤退ラインは必要ですが。）これは Kuberentes だろうが ECS だろうが、SRE のプラクティスだろうが何だって同じです。一回選んだら信じて全部やり切るというムーブメントを基盤を作る人・使う人含めて起こせないと共通基盤はうまく行かないというのが筆者の考えです。

また共通ライブラリである servicex の話しもしましたが、（servicex の設計思想はさておき）共通ライブラリというものはテクニカルにはよくあるプラクティスです。

もう少し考えてみると、必要だったのは「基盤の安定化や信頼性のためのエンジニアリングに対して実装・拡張するサービス共通の場所をいくつか設計しておくこと」なのかなと思っています。これは Kubernetes でも同じことが言えます。たとえば istio なんかだと、マイクロサービスの諸問題に対してサービスメッシュでいろいろプラクティスを注入し、それを基盤全体に配れたりします。Kubernetes はこういった拡張やエコシステムが充実してるという面では魅力的ですね。基盤を拡張していく技術や仕組みを積極的に導入していく、というのは一つ重要なポイントなのかなと思っています。

今後の話

セッションの最後で、『横断 SRE チームが必要になってきたかも？』ということをサラッと言いました。現状の課題認識としては以下のようなものがあります。

• 信頼性が「高い」「低い」「守るべきところ」が全体で認識が微妙に違うことでコミュニケーションコストがありアプローチも制限される感覚がある（もっと自由に、効率的に素早く動きたい）
• 障害の問題分析や本質的な対応を考えるための負荷が高い（能力・速度を上げたい）
• 各所で信頼性に対していい動きを、全体的な組織文化に昇華させたい（全員ができるようになりたい）

それに、それぞれで取り組んでいるので、全体的な信頼性に対する認識やコラボレーション、全体的なアーキテクチャ変更といった中長期で取り組むことは苦手です。それぞれがやっている良い取り組み・意識を文化にすることで、もっと大きなコラボレーションや信頼性に対する組織の能力を上げていきたいと思っています。そのためのチームや基盤のウォンテッドリーならではの在り方を模索していきます。

謝辞

SRE NEXT の資料を作っている最中、SRE が何がなんだかわからなくなったりしながらも1つ考えを形にすることができました。またその考えを共有しあい、フィードバックを相互にできる貴重な場所・機会を与えてくれたオーガナイザー・運営スタッフの皆様、発表者、参加者の皆様、本当にありがとうございました！