はじめに
私はサイバーエージェントグループのサムザップで Embedded SRE をしている@cat_servant です。
本投稿内容は SRE Advent Calendar 2023の13日目の記事です。前日は、zoe302さんによる「SREチームを立ち上げて2年経過して今」でした。
SREチームを立ち上げてから約5年半が経ちました。振り返りも兼ねて経緯や成果についてまとめることで、SREsを始めようとしている人が自社でどう進めるかのお手伝いや、SREsについて興味ある人が増えるきっかけになればいいなと思っています。また、サムザップにも興味を持ってもらえたら嬉しいです。
立ち上げ
SRE Advent Calendar 2019 にて 立ち上げから1年半で SRE team としてどんな活動をしているのかを書きました。(移設前の古いブログの記事でごめんなさい...)
当時の体制を今の言葉で表すと、子会社専任SREs （子会社内横断SRE team）という組織パターンです。組織パターンや実装パターンについては CyberAgent SRE Technology map の PDF をご覧ください。
目標
SRE team 立ち上げ時の目標は 子会社内横断組織としての SRE team 1を解散することでした。前述の通り、組織全体で信頼性について考え実践できたら、専任チームはいらないよね！という考え方が根底にあります。振り返ると、最初から解散を目標とすることで、何を誰がどうできるようになれば解散できるか分かりやすく道筋を立てられたことがとても良かったなと感じています。
目標への進捗
結論からいうと、子会社内横断組織としてのSRE team は解散できました。....が、まだ組織全体で信頼性について考えるところまで到達できていません。今は SREs が Embedded SRE という役割で各プロジェクトへ配置され、それぞれで設計、開発、運用フェーズにおいてSREを実践している状態です。
そこからプロジェクト全体へ SREの実践をするための文化作りや情報共有をプロジェクトを跨いでSREsが各プロジェクトでやってきたことと、私個人がこれからやっていきたいことをまとめました。
具体的に実践してきたこと
- 最適化やインフラストラクチャに関連するタスク
- 運用中の大規模ゲームをオンプレミス環境からAWSへの移設
- マネージドサービスドリブンなアーキテクチャ設計と運用
- 時限オートスケーリングとスポットインスタンスによるリソースの最適化
- Blue/Green Deployment の検証
- Glue を用いた Aurora から BigQuery へのデータ転送処理の高速化
- CodeBuild を用いた Fargate開発環境の自動構築（CI/CD）
- phpや各種ライブラリのバージョンアップ
- 各種インスタンススペック見直しとコスト最適化
- gitlab から github へ
- 新しいサービスのインフラ設計、開発、運用
- トイルの削減と自動化
- chatopsによる運用タスクの誰でもできる化
- 時限処理による半自動化
- SRE実践
- ポストモーテムの運用
- アラートの整理 および WarRoom の運用
- datadog の導入と datadog APM の使用開始
- Inspectorを用いた継続的な脆弱性検知
- ログとBIツールの最適化
- プロダクトに対する負荷試験、セキュリティチェック、障害試験などの実践
- プロジェクト内のエンジニアに対するSRE業務の知見共有
- 仮決めしたSLOの本格的な運用
- プロジェクトを超えた情報共有
- 直近のプロジェクトトピックスの共有
- 障害情報や課題の共有
- 標準化、および 技術知見の蓄積
- ゲーム事業部内のSRE関連職種による情報共有
- AWS Summitや社内LTなどへの登壇
上記を実践していく中で感じた課題など
SREの実践をプロジェクトメンバーでしていくにあたり、さまざまな課題にぶつかりました。中には今でも苦しんでいるものもありますが、まとめておきます。
- 大きなインフラ系のタスクがあると SRE領域のタスクに使える時間が少なくなること
- メンテナンス、移設、負荷試験、新しい技術の検証など
- 注力ポイントの変化による優先順位の変化
- SREの実践が文化として根付くまで、根気よく進めること
- 新しいものを受け入れてもらうために自分でまず実践した
- ポストモーテムが書かれていないなど
- PDCA から OODA 変えたこと
- 丁寧に計画して進めるより、まずは方針を決めてやってみよう！の精神
- ダメなら改善してまた実践してみる柔軟さが大事
- メンバーの入れ替わりが影響しないようにしたい
- 非常に熱意のあるメンバーが行動できない際にどうするか
- 観測点や考え方、どう対応しているのかを日頃から一緒に実践して学んでもらう
- 文化として根付くまで根気よく進める大切さを学びました
- 非常に熱意のあるメンバーが行動できない際にどうするか
- オンボーディング時に文化を伝えるのに時間がかかってしまうこと
- 機会があるたびに改善中
個人的にこれからやりたいと思っていること
- オンボーディング強化
- 文化の伝達と時間があればドキュメント化
- SREs 以外ができることをどんどん増やす
- オンコール対応改善
- 対応できる特定のメンバーに負荷が偏っているので改善
- アラートメッセージや Runbook の改善
- SREs以外でも直感的に対応できるようにする
- SLO の本格的な制定と運用開始
- 不具合や障害などサービス安定性を指標に開発と改善の注力バランスを考える
- プロジェクトの寿命を伸ばしつつ、安静性を高める
- ゲームというサービスの特性上 CUJ は簡単に決まるが、SLIを決めるのが難しい
- ポストモーテムの振り返り会
- ポストモーテムを元に改善点がないか確認
- 同じような現象であれば対応できる人数を増やす
- エンジニアが対応せずに済むようなオートヒーリング、オートリカバリの仕組み導入検討
- SREのコミュニティ活動
- SRE NEXT 2023 にはコアスタッフとして参加した（いろいろな事情で不完全燃焼な状態）
- 来年もさまざまなイベントやコミュニティに参加して貢献していきたい
最後に
SRE team を立ち上げて5年半、チーム自体は解散しましたが、まだまだ組織全体でのSREの実践というところには課題が残っています。Embedded SRE という役割をしながら、設計・開発・運用をする日々にようやく慣れてきました。
以前と比べると SRE, devops や platform engineering に興味があるメンバー増えたり、SREの実践のために何が必要でそれを導入するためには何を考えておくべきなのかといった議論ができるようになりました。同じような考え、悩みを持っているメンバーが増えて改善のために議論ができる環境に感謝しつつ、これからもサービスの安定と信頼性を高めていきたいと思っています。
明日の記事は、mekkaさんです。残りの記事もお楽しみですね！
-
専任のメンバーが横断的にメイン担当とサブ担当のプロジェクトを割り当てられ、体制にも冗長性を担保しながらプロジェクト内外で連携して SRE を実践していました。 ↩