~各社の取り組みや課題から学ぶ会~」のイベントレポートをお届けします。今回は3社のSREエンジニアが集まり各社の取り組み事例を発表していただきました。SREを導入するまでの道のり(道半ば編)」についてお話ししたいと思います。Xのプロダクト開発を行うスクラムチームでテックリードをやっている酒井と申します。SREは昨年から導入検討を始めて、現在はスクラムチーム全体での運用推進という形で携わっています。Xは、ヘッドハンターや企業からスカウトが届いたり、求人に自ら応募ができるハイクラス転職サービスです。Xですが、おかげさまで、サービスが急成長しておりまして、それに伴いシステムの負荷もかなり増えている状況になっていきました。XでSRE活動を始めた契機ということで、SREを導入する必要があるのではと考えました。XでSREをやることになった理由は大きく2つあり、1つ目は先ほど説明したアクセス数の急増により実際にサービスレベルが低下するリスクが顕在化してきたこと。問題が発生して顧客からクレームが来てから対策を打つなど後手に回ってしまっていたということもあります。Xの属する転職サービス市場というものが非常にコモディティ化が進んでいること。要はどのサービスも大体できることは同じなんです。登録するデータなんかも職務経歴書ぐらいで他のサービスに移行するスイッチングコストも低い。なると、サービスレベルが低いと簡単に競合サービスに乗り換えられてしまうという現状があります。2023より)上記の考えから体制を構築しました。スクラムの共有とSLOのチューニングなど、上記想定で活動を始めたが、なかなか上手くいかない面もありました。リソース確保のためのスクラムチームへの説明1つ目はスクラムチームへどうやって説明するか、ということです。重要機能(CUJ)の体験が良くなり、ユーザー満足度の維持向上に寄与これらを詳細に、事業影響にまで踏み込んで、非エンジニアにもわかりやすく説明するということを継続して、少しずつ理解してもらってきた、という状況です。プロダクト開発体制の再編によるSRE活動への影響このような感じで、ステークホルダーに説明しながら、少数体制ではあるものの徐々にSRE活動を軌道に乗せてきたわけですが、ここで「プロダクト開発体制の再編」という次の試練が訪れます。Xのスクラムチームは2つあり、SRE担当がそれぞれ数名いましたが、担当領域ごとに5つのチームに分割されました。すると、SRE経験のある人がいないチームができあがります。その方が多くなりました。それぞれ担当領域が異なるチームなので、各チームでCUJを分担して自律的に担当範囲のSREを実践してもらう必要があります。これまでSRE運用してきたメンバーによる各チームへの説明・引き継ぎ、いわゆるスキトラというものをやっていくことになりました。SREならではの良かった点として、1つ目はプロダクト開発とSREを一人称でできるということです。SLOのアラートでリスクを検知して対策を打ちましょう、となった時に自分で対応できます。同じプロダクト開発チームの中で、ビジネス影響を考慮した上で優先度付けや担当アサインができます。このことによって早く問題解決ができているのではないかと考えています。日常的な改善活動がやりやすい2つ目は、日々のSREの改善活動の中でこの辺の実装変えた方が良いよねという会話も、実際にビジネスロジックを実装する開発エンジニア同士でできるのでスムーズにできます。トイル削減もスクラムの改善チケットと同様にスプリントタスクに組み込めるというのがあります。プラットフォームチームとの協力体制を構築しやすい3つ目は、インフラ周りのメトリクスを見ているプラットフォームチームとの協力体制を構築しやすいことです。PFとプロダクト両方の視点でメトリクスやプロセス改善ができるので、プラットフォームエンジニアリングを実践する上でもやりやすいのではと考えています。