皆さんこんにちは、エンジニアリンググループの高橋(@tshohe1)です。
この記事はエムスリーSREがお届けするブログリレーの15日目です。
他の記事でも何度か説明されていますが、エムスリーでは2019年頃からチーム横断的なシステムを管理する「コアSRE」とは別に、サービスチーム内にて各サービスのインフラを重点的に見る「チームSRE」というポジションを新たに設けています（チームSRE化の流れの詳細については下記ブログリレー最初の記事*1を御覧ください）。
私は入社時点ではコアSRE（当時はまだインフラチーム*2）として働いていましたが、2019年頃からサービスチーム側SREと兼務したりコアSREに戻ったりまたチーム側SREに移動したりとふらふらしている謎の存在になっていました。
現時点ではコア/チーム側両方に所属していた者はいないはずなので、本記事ではコアSRE側の視点/チームSRE側の視点でどのような差があったのか、これまでの経験から得たものを簡単にまとめてみたいと思います。
サービスチーム側へ参加するまで
元々はコアSREチームのメンバーとして、各チームのインフラ環境を横断的に見ていたのですが、チームSRE化及びクラウド化が進むにつれて各サービスの実行環境はサービスチーム側で管理することが増えてきました。
共通のインフラ環境の整備はインパクトも大きくとてもやりがいはあるのですが、個人的には各事業側のサービス運用の方に強い興味があったこともあり、可能な限りサービス側に近いSREとして働けるようにチームリーダーと相談をしながら段階的に移動していきました。
以下で両環境で感じたことをまとめていきます。
コアSREの視点
コアSREとして働いていた際（チームSRE推進前）に思っていたこととしては下記が挙げられます。
サービス数が多く管理が難しい
チームSRE化が推進されるまではオンプレに数多くあるサービスのインフラに関わる変更を一手に引き受けていたこともあり、見るべきものがかなり多く混乱しやすい状況でした。
またサービス全体に関わる修正（脆弱性、インシデント対応など）も一手に引き受ける都合上、何かあったときに急激に負荷が上がりやすい状況でもありました。
ビジネス側との距離がある
あとはやはりコアSRE側と各サービス側のビジネスサイドだと流石に距離が遠いなと思うことが多くありました。
過去の SLI / SLO*3 に関する取り組みの際のルールでは下記のように 各ビジネス側 <---> 各チームエンジニア <---> コアSRE という経路でやりとりするようにしていたのですが、実際にビジネスサイドとチーム側のエンジニア間でどのようなやり取りがあり、どのような改善がなされているのかが非常に見えにくかったです（SRE 文化が十分に浸透していれば別にいちいち見る必要も無いとは思いますが）。
かといってコアSRE側で全チームのビジネスサイドと相談して進めていくのはリソース的に現実的ではないのでチーム内に監視を切り出すのは非常に良かったと思います。
チームSREの視点
次に、チームSRE側として働いている際（チームSRE推進後）に感じたことです。
より良い SLI/SLO 監視の設定が可能になった
2018年頃に各サービスに対して設定していた SLI / SLO もあるにはありました。しかし、その運用についてはあまり効果的ではなかった点もありました。
SLI の調整要望はサービス側から出てくることも少なく（別に闇雲にいじればいいというものでもないですが）、またコアSRE側もサービスについて詳細まで把握できていないため、基本的に最初に設定された値を見守るだけのような状況になっていることも多かったです。
その様な状況の中、サービスの仕様を熟知しているビジネスサイドと近いところにいるエンジニアがSREというロールを兼ねることで、これまでの仮置していた SLI / SLO よりもサービスの実態に合った値を設定できるようになったと思います。
14日目の記事もその一例かと思います。
ポストモーテムをより集中して実施することが出来た
コアSREで各チームのインフラを見ていた際は、時間の都合もあり、ポストモーテムの振り返りを定例として実施していました。インシデントの件数が多いときは、その場で明確なアクション決定まで相談しきれないこともあった気がします。
チーム内SREの場合は管理サービスが少ないことで単一のインシデントにフォーカスできるため、原因分析から詳細/明確なアクションをチーム内で共有するところまで一気通貫で進めやすくなったと思います。
- どこが落ちるとビジネス的にダメージが大きいのか、ビジネスサイドと距離が近いので把握しやすい
- チーム内の全エンジニアで振り返るようになったことでアプリケーション側の改善まで繋げやすくなった など
まとめ
サービスチーム内で個別にSREを立てることでより管理するサービス範囲が限定され、集中して運用にあたることができるようになった点がやはり大きいなと思いました。
また今回いい点を多く述べましたが、チーム側単独で完結するようになったことで情報がチーム間で分断される懸念もあるかと思います。今後は各サービスチームSRE/コアSREが協調し、各々見えない視点を補っていくことがエムスリーのシステム全体の信頼性向上に繋がるような気もしてます。
チームSRE間での情報共有方法や、チーム内SREが進んでいないチームの支援などは今後の課題ではありますが、色々とやり方はありそうな気がします。（下記はコアSRE内で出ていた案）
- 各チームのSRE代表1名を集めたSREサミット
- チームSRE化が進んでいないチームとコアSREメンバーを入れ替える制度（交換留学制度？） など
We are Hiring!
エムスリーでは共通インフラを整備して全体の信頼性を底上げするコアSRE、サービス個別の信頼性を改善するチームSREの両方を絶賛募集中です！
少しでもご興味あればぜひお気軽にご応募ください！！
