今回の記事は年末スペシャルです。
僕が SRE をしながらやってきた取り組みについては、今年も会社のテックブログに色々書かせてもらいました（職場の理解のおかげです。いつも感謝してます）。
ただ、それぞれのブログ記事の間を埋めるストーリーというか、その背景にあることについてはなかなか書く機会がありませんでした。なので、今回はそれらの記事を引っ張りながら、今年 SRE をしながら考えていたことをつらつらと書いていこうと思います。
この1年で考えが大きく変わったこと
SRE のあるべき組織体制について、1年前はこう考えていました。
- 複数の開発チームをまたぐ形で SRE をマトリックス的に配置して、SRE はアプリの開発状況を細かく把握しながら監視・運用すべき
ただ、この1年で考えが変わり、いまはこう考えています。
- SRE をマトリックス的に配置するのは、確かに、開発速度を一時的に上げるのには効果的
- ただ、そんなスキルがある SRE をたくさん集めるのは難しいし、集められたとしてもそんな働き方をさせたらすぐ疲弊して退職しかねない
- 持続性を優先するなら、アプリの監視・運用の責任は開発チームが持ち、SRE はそれを支えるシステム作りに労力を割くべき
こう書くと、なんか、結局当たり前の結論に帰ってきてしまった感じがしますね……。SRE って元々そういうものだろ、と言われそうな気もします。ただまあ、どういう過程を経てそういう考えに落ち着いたのかを振り返ってみます。
1年前（2018年末）に考えていたこと
去年の年末の時点で、僕個人はこういう状況でした。
- SRE は複数の開発チームをまたぐ形でマトリックス的に配置されていた
- 僕個人は、Play 化プロジェクトに関わる開発チームに参加して、監視・運用全般を担当していた
2018年前半から、「SRE をマトリックス的に配置したほうがうまくいくだろう」という議論があり、それまで1つの SRE チームだったものを複数の開発チームにまたがる形にしました。Dev と Ops が分離してしまっていた当時の状況では、それが最適なチーム構成だろう、と僕も強く同意していました。
このあたりの話に興味のある方は、SRE チームの黎明期を知るメンバに繰り返しインタビューして書いた発表資料やブログ記事がありますので、そちらをぜひどうぞ。
で、この人員配置の中で、僕は2018年4月から今年の7月まで「Play 化プロジェクト」というリプレイスプロジェクトに参加してました。もちろん、SRE 同士の横の連携はありましたが、このプロジェクトの状況を熟知して動いていた SRE は1人だけという状況でした。
開発チームに SRE が入り、インフラとアプリの両方に目配せすることで、いろいろな問題を未然に防げたという手応えはありました。その一方で、このプロジェクトで SRE として1人頑張り続けることのつらさも強く感じていました。2018年末はそんな状況でした。
2019 年に考えていたこととやったこと
そこから1年経って、2019年末（現時点）の状況はこう変わりました。
- SRE は開発チームから出て SRE チームに所属する。SRE チームは開発チームを支援するかたわら、SRE 主導での改善プロジェクトも進める
- アプリの監視は、開発チームに徐々に移行しつつある
- 僕個人は、改善プロジェクトの1つを進めている（※この内容も、いずれテックブログに書きます）
SRE と開発チームの分離は、2019年の年始に、SRE が改善活動を主導できる体制作りを目的に行われました。実は、僕は当初この分離には反対していました。
しかし、リプレイスプロジェクトでの経験を経て、SRE を特定の開発チームに割り当てるのは、短期的には有効だけど、長期的には持続可能じゃないという考えに変わりました。
考えが変わった理由の第一は、開発速度が早い開発チームに SRE として張り付け続けるつらさを実体験したからです。リリースが少ない安定したサービスならともなく、リリースが日々活発に行われるサービスでは、張り付けられた SRE の負荷が大きすぎる。これでは SRE はすぐ疲弊して、退職されてしまうだろうと……。どれくらい大変かの具体的な話は、リプレイスプロジェクトが終わったときのブログ記事に書いたので、よかったらこちらをどうぞ。
考えが変わったもう一つの理由は、SRE Lounge などの勉強会で、いろいろな他社事例に触れたことです。特にメルカリの Microservices Platform Team の事例では、開発チームへの監視・運用の移行がここまで現実に可能なのかと驚かされました。例えば、いろいろな勉強会で触れられている microservices-starter-kit について以下のイベントで初めて知り、懇親会でメルカリのエンジニアに詳しい話を聞いて感銘を受けました。
それまでは、マイクロサービスは自分の現場に合うのかどうかがずっと疑問でしたが、「SRE とアプリ開発者の責任分界点を明確にするため」という目的さえブレなければ、マイクロサービス化を推し進めていいのではないかと考え始めました。
メルカリの事例に強く影響を受けて、その後、自分の現場でも、アプリ開発者に監視業務を移行するためのアラート通知システムを整備しました。マイクロサービス化まではまだ進んでいませんが、責任分界点を明確にするためには、これからマイクロサービス化を段階的に進めていく必要があると思っています。
ちなみに、開発チームに1年以上いたおかげで、アプリ監視の業務設計ができて、結果的にこのアラート通知システムも作れました。その点は、1年以上悪戦苦闘したのも無駄な努力ではなかったのかな、と。
来年1発目のイベントは SRE NEXT
上記でメルカリの事例について軽く触れましたが、SRE の業務について考えるにあたって、他社の事例を聞くのはとても参考になると実感した1年でもありました。
僕は去年から SRE Lounge というコミュニティのスタッフとして参加しているのですが、同じコミュニティ主催の大規模イベント SRE NEXT がとうとう来年1/25(土)に開催されます。いまのところ、僕は Room A の司会としてスタッフ参加している予定です。
すでにチケットは売り切れてしまっています（すみません！）が、発表スライドは後ほどいろいろな登壇者が公開してくれると思います。僕もイベント当日は見てる余裕がなさそうなので、あとから発表スライドやレポートブログなどをゆっくり読ませてもらうつもりです。
来年末も、今とはまたいろいろ考えが変わってるのかなあ。どうなんだろう……。
