はじめに
モニクルでSREをしているbeaverjrです。
この記事では、私が2023年7月に弊社初の専任SREとして入社してからの経験を振り返り、行ってきたこと、実際に直面した挑戦やそこから得られた学びを共有します。
今回は技術的な面ではなく、SREチーム・個人としてどのように成長してきたか、その過程でどのようにSREのイネーブリングの取り組みを進めてきたかに焦点を当てて紹介したいと思います。
※イネーブリング：この文章では組織にSREの原則と実践を広め、根付かせることを目指す活動を意味します。
SREチーム立ち上げの背景
弊社はエンジニア全員がフルサイクルエンジニアとして活躍できる組織を目指しています。このビジョンの実現に向け、2023年7月にSREチームが設立されました。
立ち上げからの取り組み①：チームビルディング
チームビルディングの過程では、まず共通の目標とビジョンを確立するためにチームの方針を定めました。それに続き、SREの原則と実践に対する深い理解を共有・拡張するための輪読会（SRE Study）を実施しました。
チームの方針の確認
まず私たちは何を目指すべきか、どのような価値を提供したいかについて、ブレストを行いました。
- モニクルがどうなったら嬉しいか？
- SREとしてどんなことを達成したいか？
について問うことで、チームの方針を下記のように定めることができました。
- 開発チーム全体が共通認識を持ってプロダクトの改善に取り組める状態にする
- インフラ作業や障害対応の属人化をなくす
- プロダクト間での開発・運用のナレッジ共有の促進
この方針をもとにSRE活動の企画・実行、各チームへのイネーブリングを実施していくことを確認しました。
輪読会（SRE Study）
SREを組織に広めていくにあたり、SREチーム自体が「SREとは何か」を深く理解することが必要であると考え、週次での輪読会(SRE Study)を開始しました。
こちらは現在も続いており、ちょうど3冊目を読み終えるところになります。
読んだ本は下記の通りです。
SRE サイトリライアビリティエンジニアリング 選定理由: いわゆるSRE本です。Googleが提唱するSREの定義と実践方法から、SREの根本的な理解を深めることを目的としました。
実践への応用: SREの概念を基に、チームのミッション、ビジョン、バリュー（MVV）を作成しました。現在はインシデント管理プロセスの標準化や、プロダクションミーティングの導入を通じて、効率的な運用とコミュニケーションの向上を目指しています。
システム運用アンチパターン 選定理由: 運用における一般的な失敗パターンとそれらを回避する戦略を学ぶことで、より信頼性の高いシステム運用を目指すことを目的としました。
実践への応用: アラートの見直しと整理、効果的なダッシュボードの作成、ナレッジベースによる知識共有等、具体的な取り組みに落とし込んでいます。他にも組織文化の醸成、組織→部門→チーム→個人に紐づく目標設定の仕方も参考にしています。
プロダクトマネージャーのしごと 選定理由: SREがプロダクト開発にどのように貢献できるかを理解し、プロダクトマネジメントの視点からも価値を提供する方法を探求しました。実際に読んでみると、職種に関わらず有効な仕事上のTipsを多数得ることができました。
実践への応用: 弊社の開発チームは基本的にフルリモートであるため、特にリモートワークを行う上での同期・非同期のコミュニケーションの工夫を参考にして実践しています。個人的には、失敗を乗り越え、謙虚に地道に活動し、信頼を築いていこうというマインドセットに感銘を受け、日々意識するようにしています。
SRE Studyの振り返り
SRE Studyを通じて読んだ本は、SREの原理やベストプラクティス、システム運用のアンチパターンといった重要なテーマを扱っていますが、本に書いてあることをそのまま実践すればうまくいく、というものではもちろんありません。実際の業務では、理論を現実の状況に合わせて調整し、適用する柔軟性が求められます。
それでも、SRE Studyで学んだ知識は、私たちのSRE活動の土台となっていることは間違いありません。これらの本は、理論だけでなく実践的な視点も提供してくれており、特に実際のプロジェクトにおける具体的な問題解決や、改善策のアイデアを得る上で非常に役立っています。
一人では読みきれなかったであろう本も、チームでの輪読会を通して読み切ることができ、何より楽しく読書することができました。SRE Studyはチームビルディングの機会でもあり、共通の言語と理解を育てるためのプラットフォームであると思っています。今後も継続していきたい活動の一つです。
立ち上げからの取り組み②：開発チームへのイネーブリング
開発チームへのイネーブリング活動においては、
- SRE成熟度評価のフレームワークの導入
- 監視の基礎を学ぶための輪読会の開催
- プロダクションミーティング
を通じて、開発チームがSREの原則を理解し、日々の業務に活かせるようになることを目指しました。
SRE成熟度評価
モニクルは複数のプロダクトを開発しており、各プロダクトごとにチームが分かれています。各チームに対して横断的にSRE推進を進めるにあたり、私たちはサイバーエージェントグループによって実施されている先進的な取り組み、「SRE成熟度評価」のフレームワークを導入しました。このフレームワークは、チームごとのSRE活動の現状を評価し、それぞれのプロダクトチームがより効果的にSREを推進できるようなガイドラインを提供します。詳細は以下のリンクから確認できます。
SRE成熟度評価導入の振り返り
SRE成熟度評価のフレームワークの導入は、SREのイネーブリングをどこから始め、どのように進めていけばよいのかを理解する上で非常に役立ちました。具体的な改善計画を立て、その実施を定期的に振り返ることにより、各プロダクトチームのSRE実践を段階的に向上させています。このフレームワークは取り組み自体の過不足や負荷を考慮する項目も含んでいるため、より持続可能な方法で改善を進めることができていると実感しています。
チーム外での「入門監視」輪読会
組織内でのイネーブリング活動として、チーム外のメンバーを対象とした任意参加の輪読会を開催しました。対象の本は「入門監視」で、サービス信頼性の階層の土台となるモニタリングについて、基本概念とその重要性を開発チームと共に学ぶことを目的としました。
SRE サイトリライアビリティエンジニアリング 図III -1 サービスの信頼性の階層
「入門監視」輪読会の振り返り
FigJamを使用して、ディスカッション形式での輪読会を行いました。さまざまなバックグラウンドを持つ方が集まり、監視に対する知見や、本を読んでしっくりきた点やわからなかった点を共有してディスカッションすることで、モニタリングに関する共通の理解を進めることができたと感じています。
この輪読会は、組織内で他のチームのメンバーと交流を深める貴重な機会となりました。日頃は異なるプロジェクトに携わっておりなかなか交流の場が持てない中で、このような形で経験や知見を共有できたことは非常に有意義でした。異なる視点を持つメンバーとの対話を通じて、新たなアイデアが生まれたり、既存の問題に対する新しい解決策が見つかることもありました。
今後もこのような交流と学習の機会を持つことで、組織文化の醸成を促していきたいと思います。
プロダクションミーティング
プロダクションミーティングは、SREチームと開発チームが連携して、サービスの運用状況を定期的にレビューし、問題の発見、改善のために協力するための取り組みです。
プロダクションミーティングのアジェンダでは、一週間のサービス運用状況、リリース予定・報告、発生したインシデントとその対応、現在進行中のリスク要因やSRE成熟度評価の改善タスクの進捗についてレビューします。
これらのアジェンダとは別にテーマを決めて、監視設定の相談やインシデント対応フローの整備等を実施することもあります。
導入背景
プロダクションミーティングの導入は、開発チームからのフィードバックが大きなきっかけでした。SREチームに相談したいことがあった際、どこまで依頼していいかや相談するタイミングなど判断に迷う、というフィードバックを受け、SREが他のチームから見てアクセスしにくい「クローズドな」存在になりがちであることに気づきました。これを改善するためには、開発チームとのより密接な関係構築と積極的な情報共有が必要であると考え、SREチームと開発チームとの間で定期的な対話の場を提供することを目的としてプロダクションミーティングを開始することにしました。
プロダクションミーティングの振り返り
これまでのプロダクションミーティングを振り返ると、明確な成果としてはチーム全体の問題解決能力の向上に繋げることができていると感じます。特に効果を実感したのはインシデント発生時の対応です。インシデントレベルの定義やフローを整備したことで、インシデント発生時にも慌てず、体系的に対処できる体制を構築できました。それと同時に属人化の排除という明確な課題も見えてきたため、今後注力して取り組んでいきたいと思います。
SREチーム形成期での反省と学び
最初はSREの役割や原則、プラクティスに対する理解、またプロダクトや開発チームの状況に対する理解が十分ではなく、開発チームに単に改善タスクを依頼する形で進めてしまった点について、大きな反省があります。その後、改めてプロダクションミーティングを実施しながら改善活動を進める中で、SREの本質は、ただ単に改善すべき点を挙げたりタスクを依頼するのではなく、インシデント対応に参加したり、監視項目を一緒に考えたり、ポストモーテムを協力して書いたりなど、開発チームと密接に協力しながら共通のゴールに向かって課題を解決していくことにあると理解しました。
さらに、SREとは根気強く、地道な努力を要する活動であることも実感しました。この仕事は、目立つ成果がすぐに現れるものではないですが、一歩一歩確実に前進していくことで、最終的には組織全体としての成長と成功につなげていけるといいと思っています。
今後の展望
今後はさらに活動範囲を広げ、より明確な実績を事業にもたらしていくことを目指しています。私たちの活動が、単に技術的な問題解決に留まらず、経営にとっても価値ある指標となり得るよう、注力している事業の信頼性向上に対する具体的な提案をできるようになるといいと考えています。
そのためには、プロダクトに対する深い理解と、それを支える技術的な専門知識が必要です。これからも継続的に学び、開発チームと協力し合いながら前進していきたいと思います。
この記事が、これからSREチームの立ち上げを検討している方々にとって参考になれば幸いです。
Discussion