クラシルリワードの裏側：システム運用とチーム体制の変遷

こんにちは、joooee0000です。クラシルリワードのEnablingSREチームに所属しています。

クラシルリワードは、リリースからわずか2〜3年でクラシルリワード関連APPのユーザー数(MAU)が200万人規模にまで成長しました。この急速な拡大を支える裏側では、システムの信頼性や安定した運用体制をいかにして担保するか、常に試行錯誤を続けてきました。

そして2025年2月、チームやシステム規模の拡大とそれに伴う運用課題から、EnablingSREチームを立ち上げることになりました。

このブログでは、クラシルリワードをリリースしてからEnablingSREチームを立ち上げるまでの間に、どのような運用体制をとってきたのか、また各フェーズで直面した課題について振り返ります。同じようなフェーズをたどるプロダクトやチームの参考になれば幸いです。

[フェーズ1] インフラ1人、サーバーサイド開発3人 (2022/11 ~ 2023/05)

初期は、インフラ1人、開発3人という構成でした。

正確には、リリース後の3ヶ月はインフラ担当(初期インフラ構築は外部委託)もおらず、開発1人という時期もありましたが、インフラ担当がjoinした頃から実質SRE的な活動をし始めたため、その前のフェーズは割愛します。

メンバーの役割

当時のメンバーの役割は、下記のような感じでした。

- インフラ担当者の責務
    - インフラ構築、アラートの整備やDevOps周りの整備、オンコール担当など
- 開発者の責務
    - 機能開発、QA

この当時、私はサーバーサイド兼インフラ担当としてjoinし、インフラの構築や、当時あったシステム運用周りの課題の解決などをしていました。

このときにやったことはブログにしてあるので、よかったら参考にしてください。
小さいチームで実践する!開発速度・信頼性向上のためにやってよかったシステム改善3選

当時の課題

また、当時インフラ担当だった私は、下記のような課題を抱えていました。

- オンコールが属人化し、1人で休日も毎週PCを持ち歩いてインシデント対応をしていた
- インフラが関連する実装はインフラメンバーが担当していたため逐一、依頼が発生していた

上記の課題があったことと、当時のメンバーが全員Terraformやインフラをやっていきたいという意欲があったことを考慮して開発者が運用まで行うフルサイクル開発体制を目指すことにしました。

また、フルサイクル開発体制に下記のような期待をしていました。

• チームが小さいうちに越境しやすくすることで開発スピードが速くなる
• チームで運用を意識しながら開発できるようになることで、中長期的に運用しやすいシステムが構築できるようになる
• 信頼性の責任を早いうちからチーム全体でもたせることで開発速度と信頼性のバランスが取りやすくなる

[フェーズ2] フルサイクル開発体制化 (サーバーサイド開発4人) (2023/05 ~ 2023/08)

このフェーズでは、フルサイクル開発体制を目指すためにインフラ担当という枠組みをなくし、インフラ担当含めた全員で開発・運用の役割を担いました。

メンバーの役割

- とにかく全員開発する
- とにかく全員でオンコールを回す
- システムメンテナンスなどを分担してやる
- 開発に必要なインフラリソースは開発者が作成する

このフェーズでよかったことは、開発者が必要なミドルウェアを立ち上げたりアラートを設定したり、システム構成の冗長化をする経験ができたことです。システムメンテナンスも複数人が経験することができ冗長化できました。

当時の課題

しかし、同時に下記のような課題も浮き彫りになりました。

- 信頼性や運用面で旗振りや課題整理をする人がおらず、開発に比重が偏った
- 大きめの運用課題をこなす時間が誰も取れない
- インフラ開発や運用周りでノウハウ共有の仕組みやルールが何も無く、元インフラ担当者と開発者のやり取りが多く発生した
    - インフラ周りのレビューやインフラ面リリースフローが確立されていない
    - 運用周りで何を考慮すればいいかのノウハウ共有ができていない
    - インシデント対応のフローが確立されていない

この状況から、フルサイクル開発体制を正しく回す仕組み作りや、推進役、サポートをする役割が必要だと考えました。

[フェーズ3] EnablingSRE(1名) x フルサイクル開発体制期　(Enabling SRE 1人, サーバーサイド開発3 ~ 5人) (2023/09 ~ 2024/08)

このフェーズでは、フルサイクル開発体制がうまく回る仕組みづくりや推進、サポートを担うEnablingSREの役割を立てることにしました。

メンバーの役割

- EnablingSRE (1名)
    - フルサイクル開発体制がうまく回る仕組みづくりや推進、サポート
- 開発者
    - 開発から運用まで一気通貫で行う

そして、EnablingSREの活動としてロードマップを作成し、どのようなステップでフルサイクル開発体制を浸透させていくかの計画を立てました。

図1. EnablingSREロードマップ

図2. フルサイクル開発体制浸透ロードマップ

また、フルサイクル開発体制を推進するに当たり、下記を整備していきました。

• システムのプロテクション周りの強化
  • 人的ミス防止対策としてシステム権限の最小化やプロテクションの強化
• インフラオンボーディング / インフラ開発フローの整備
• SLI / SLOをチームが存在する機能ドメインごとに分離
  • このときのことはブログにしてあるので、良ければ参考にしてください
    • クラシルリワードチーム SLO導入の工夫と現在地
• 障害対応フローの明文化とオンコールオンボーディング制度導入
• システム運用のアラート化
  • 運用上確認が必要なものをアラートのwarningチャンネルに流すようにして、クリティカルになり得る問題の気付きの属人化を解消
    • 例)
      • データベースのコネクション上限アラート
      • AWS Healthの通知など
• 関連システム(NewRelic / インシデント管理ツールなど)のIaC化
  • みんなで運用していけるようにOps系のツール類をコード化
• システム課題の優先順位付けや管理の仕組み化

また、この時期に開発・インフラともに知見のある開発メンバーがチームにjoinしてくれ、途中でEnablingSRE役をバトンタッチしてSREが担えるメンバーも冗長化することができました。

そのEnablingSREメンバーが開発チーム内でもテックリード的な役割を担ってくれていたこともあり、開発メンバーへの浸透もしやすい状態でフルサイクル開発体制が少しずつ回り初めました。この時期にフルサイクル開発体制の中でできるようになっていたことは下記です。

• 開発メンバーのオンコール参加と障害対応フローに沿った障害対応
• ポストモーテム作成と振り返りを開発者全員で行う
• 開発で必要なインフラリソースを開発メンバーが追加する
• SLI / SLOが抵触したときに開発者が改善するアクションが取れる
• システムアラートの確認 / トリアージが徐々にできるようになる

当時の課題

しかし、まだまだ課題は残ってしまいました。

- 運用周りの継続的な改善
    - 運用系の課題解消がどうしても開発タスクの後回しになってしまう
    - 大きめの運用課題が解消されていかない
- 開発者が自律的に課題を出し、改善サイクルが回っている状態を作れていない
- 重めのインフラタスク (一から構築が必要な場合など) に関しては開発者の学習機会がうまく取れず属人化が続く

当時このような課題をどう解消していくか、というフェーズでしたが、サービスの複雑性がましてきたことやチームメンバーの増加などにより更に課題がでてきました。

[フェーズ3.5] さらにフルサイクル開発体制の課題が爆発してきた時期 (Enabling SRE 1人,サーバーサイド開発5 ~ 10人)(2024/08 ~ 2025/01)

フェーズ3の後半で、サーバーサイドメンバーの人数が一気に2倍程度にスケールしました。それに伴い、 チームやPdMの数も増えました。

そしてサービスも引き続きすごいスピードで成長しており、機能や依存関係を持つ基盤(ポイント基盤・ID基盤など)も増えサービスの複雑度も増していました。

この時期から、プロアクティブなシステムメンテナンス（DBのEOL対応など）をメンバーをローテーションしつつ実施できてきたことがいい点としてありました。

当時の課題

一方で、下記のような課題がでてくるようになりました。

- サーバーサイドの開発メンバーが増えてチームの状況の見通しが悪くなった
- システム運用を対応するメンバーが固定化してきた
- 続・どうしても開発優先になり運用がおろそかになる
- トイルが増える

この頃になると、忙しい開発メンバーの代わりにEnablingSREメンバーがシステム運用の対応をする割合が多くなり、健全ではない状況になりました。また、PdMのメンバーにフルサイクル開発をやっているということが十分に浸透できておらず、開発メンバーも運用タスクと開発タスクの優先順位付けが難しくなるようになりました。

そして、EnablingSREが本来やるべきことに注力できなくなり、組織としての制度や仕組みを作る必要が出てきました。

[フェーズ4] DevOpsレーンの作成とEnablingSREのチーム化 (2025/02 ~ )

2025年2月から、EnablingSREをチーム化をすることになりました。このフェーズでは、組織としてシステム運用を正しく長期的に行っていける仕組みを築いていく必要がありました。

また、チームの拡大に伴ってしっかりシステム運用を見れる人材を育成する機会の必要性もでてきました。

そこで、CTOやEMと方針をすり合わせながら、下記のような体制に変更しました。

メンバーの役割

• [新しいチーム] DevOpsレーン (1名)
  • 開発チームから半年間チームにjoinしてもらい、SREチームと伴走しながら運用の自動化やインフラ構築によってシステム運用のスキルを身に着ける
• EnablingSREチーム (2名)
  • 引き続きEnablingSRE. フルサイクル開発体制がうまく回る仕組みづくりや推進、サポート
• 開発者
  • フルサイクル開発体制で、自身の責務範囲のシステム運用を担当する
    
    ※ 「運用」となっているところがDevOpsレーン

また、チームがスケールしたりチームメンバーの入れ替えがあったとしても安定してシステムの運用を実施していけるよう、フルサイクル開発体制に必要な仕組み化に取り組んでいます。

• フルサイクル開発体制のための運用評価制度
• フルサイクル開発体制における運用責任の明確化
• 開発チーム外への取り組みの浸透
• DevOpsレーンによる開発メンバーのローテーション
• Production Readiness Checkの策定
• 運用の自動化

施策の詳細は長くなってしまうため、後続のブログで紹介します！

[追記] 後続ブログが投稿されました！
https://zenn.dev/dely_jp/articles/towards-sustainable-devops

まとめ

まだまだこれから実際に施策を適用していく段階になるので、これからも様々な課題に遭遇すると思いますが、継続して安定したシステムを運用し、サービスの信頼性の担保をしていけるようSREチームとして頑張っていきたいと思います！