本投稿はSRE Advent Calendar 2023の19日目の記事になります。
こんにちは。SREチームの矢野(@yymm)です。
今年の4月からCADDi DRAWERのサービス信頼性向上のためSREチームが活動を始めています。チーム立ち上げから3Q経過して方向性も見えてきたため改めて立ち上がりから今までのことを紹介します。
CADDi DRAWERについて
図面データ活用クラウドのCADDi DRAWERは、2022年6月に正式にローンチされました。
ローンチから1年半経過し取り扱うデータ数のオーダーやユーザー数が拡大してきており、機能面の拡充はもちろんのことですが、非機能要件の重要性も高まってきています。
私は2021年12月のDRAWER立ち上げ期から開発に関わるSWEだったのですが、私も含め当時関わっていたメンバーがアプリケーション開発メインだったこともありインフラ周りや非機能要件周りに課題があるのを感じていました。
課題があるなら解決やったるぞということでSREへの社内ジョブチェンジを打診してチームの立ち上げをしました。1エンジニアのチャレンジを認めてもらえたことに感謝をしているのと、会社としての懐の広さを感じています。
SREチーム立ち上げから今までの道のり
ローンチから9ヶ月してCADDi DRAWER開発チームの拡大に伴い、Team Topologyをベースにしたチーム構成が採用されました。SREチームは、横断的な活動をするEnablingチームのサブチームとして位置づけられています。
キャディでは3ヶ月を1クォーター（Q）として、その都度目標を設定しています。立ち上げから3Q経過したので、それぞれのQでの活動を振り返っていきます。
立ち上げ初期(2023-04~): SRE未経験からのスタート
SREチームの初期メンバーは2人で実は2人ともSRE未経験、当時MLOps領域を担当していたメンバーと共に始まりました。モチベーションはあるもののどうしようか...というところからのスタートでした。
とはいえ目先の課題はあったので、Engineering Managerと一緒に課題を整理して目標を設定しました。 経験もなくSREチームとしても人数少ないですが、 Platformチームに協力を仰ぎ適宜支援いただきながら 以下のようなトピックに取り組みました。
- インフラコストの削減と可視化
- セキュリティ向上のためのIAMやサービスアカウント周り整備
- IaCの整備
- GKEの保守運用（クラスタアップグレードなど）
もう一つ大事なことは、我々はそもそもSREとは何かを学ぶ必要があったので、輪読会を開催してSRE本やSRE Workbookを読みSREへの理解を深めていきました。
安心安定の定番書籍SRE本です、SRE未経験の私にとってはSREの役割や考え方を学ぶにはとても良い本でした。今でも作業の傍らにおいて読み返したりすることも多くバイブルと化しています。
自律的な目標設定(2023-07~): プロダクトロードマップとの連携
前の四半期ではSREとは何かをよく分からず取り組みましたが、今後はSREらしいチーム目標を立てて自律的に活動していきたいと考えていました。
自分もSREという言葉を知っていましたが具体的なSite Reliability Engneeringというエンジニアリングアプローチを知らない方も一定いると思い、そもそもSREについての組織全体の理解度を上げることも大事と思い、Slackの雑談チャンネルなどでの布教活動もしていました。
これからSREチームの取り組みを効果的に発揮していくためには、開発チームに閉じないでPdMなどのプロダクトの意思決定ができるステークホルダーと一緒に取り組むのが大事と思い、そのレイヤーの方々を巻き込んでの目標設定に取り組みました。
今まで取り組んできたトピックでもPdMやTPM(Technical Product Manager)などのプロダクトサイドとの接点があったことや前述の布教活動が功を奏してSREの認知が広まっていたこともありスムーズに議論は進み、最終的にプロダクトロードマップの1項目としてReliabilityを設定することになりました。
これはプロダクトロードマップの説明スライドの1枚なのですが、大枠はGoogleが提唱しているSREのベストプラクティスに則る形で策定しています。
プロダクトサイドとの連携は今後も重要になってくるため、このアプローチを活かしてSREチームはSREらしく活動することができ、その活動がビジネスの目標と連携していき組織的な成長を促進していけるように取り組んで行こうと思っています。
本格活動開始(2023-10~): Enablingチーム拡大でSREにフォーカスできるように
順調に方向性も定まりやっていくぞという雰囲気なのですが1つ問題がありました。
横断的なチームという特性と、私が落ちがちなボールを見つけると拾う習性があったため、一般的にはSREチームでは扱わないようなトピックも扱うようになっておりSREのフォーカスに集中しきれないという課題がありました。
2023-10のタイミングでちょうど全社的な組織変更がありEnablingチームメンバーの拡充され、以下のようなチーム体制への変化がありました。
エンジニア向け会社紹介資料から抜粋
紫色のEnablingチームは元々SRE/QA/アーキテクチャチームで構成されていたのですが、データマネジメントチームが組成され各チームの人員も増えました。
この組織変更と人事異動が功を奏して関わっていたSRE以外のトピックを、適切なチームに責務とタスクを委譲することができました。担当の余力が少なく、SREで巻き取っていたデータマネジメント関連のタスクを委譲できたのは個人的にインパクトが大きかったです。
Enablingチームの人数が増えたことでチームに活気も生まれ、連携強化のためにサブチーム全員で1つのスクラムを回してみたり、スクラムのトレーニングが実施されるなどチームの強度が上がってきているのを感じています。
実際の活動についてはPdMとTPMと協力して定めたプロダクトロードマップに沿って進めており、以下のような内容に取り組んでいます。
- Metrics & Monitoring
- PdM, TPMと相談してクリティカルユーザージャーニーの再設定、SLIの計測に向けた基盤構築
- Emergency Response
- インシデント対応フロー、On-call体制の整備
- Capacity Planning
- キャパシティ評価の基盤構築
- Change Management
- QAチームとArchチームでアーキテクチャやリリースフローの整理
- PlatformチームでFour Keys測定の基盤構築
プロダクトロードマップの大部分はSREチームがOnwerとして取り組んでいますが、Change Managementの部分は状況的にSREチーム以外のチームに協力してもらいつつ連携を取りながら進めています。横断チーム間で連携しつつプロダクトロードマップにアラインした活動を行うことができており、今後も適宜コラボレーションモードを切り替えながら効果的に施策を進めていきたいと思っています。
今後の展望
定めたロードマップを推進して、信頼性の高いサービス提供ができるように組織全体のSRE力を上げていきます。今回の記事では具体的な取り組み内容に関しては言及できてないので、今後はSREチームの成果も発信していきたいと思っています。
SREというロールは初めてまだ1年満たないので馬力不足なところもありますが、一人前のSREを名のれるようにどんどん成長していく所存です。
昨今はSREに関連する書籍も結構増えてきているので、輪読会も継続していきます。輪読会はSREチーム以外の方も自由参加でわいわいやっています。
実はPlatformチームからインフラに強いメンバーのジョインもあり現在3人チームになりました。とはいえまだまだやらないといけないことがたくさんあり、SREポジションを絶賛募集中です。
製造業のポテンシャルを解放する成長中のSaaSを支えるSREに興味のある方は、カジュアル面談も行っていますのでぜひお気軽にお声掛けください。最後まで読んでいただきありがとうございました。
