こんにちはインフラ/SREグループの三橋です！
「SRE」という言葉は、もはやエンジニアリング界隈ではお馴染みのものになりましたが、その具体的な取り組み内容は、会社の規模やフェーズによって多種多様です。本記事では、弊社インフラ/SREグループの構成や活動内容、今後の方針についてご紹介します。同じようなフェーズでSRE活動を行われている方や、SREに興味をお持ちの方の参考になれば幸いです。
想定読者
- 弊社のSREグループにご興味をお持ちの方
- 弊社の選考に進むか悩まれている方
- 同じようなフェーズでSRE活動をされている方
- SREにご興味をお持ちの方
そもそもSREとは
すでに多くの場所で説明されているため簡潔にまとめます。SRE（Site Reliability Engineering）とは、システムの安定稼働を支えるためのプラクティスを指します。「class SRE implements DevOps」という言葉で表現されるように、DevOpsの概念をより具体的な形に落とし込んだものと考えると分かりやすいでしょう。
よくグループ名として使われることがありますが、SREはあくまでプラクティスであり、本来はソフトウェアエンジニアが身につけるべきスキルセットの一部と言えます。例えばプラクティスの一つにSLI/SLOというものがあります。これらはプロダクトの信頼性を測定する指標であり、開発と運用のどちらにリソースを注力すべきかを判断するための重要なガイドラインとなりうる指標です。
このように、SREは具体的な実践を通じて、システムの信頼性向上を目指します。
チーム紹介
現在のインフラ/SREグループのチーム構成は正社員2名とTopotalさん(SRE as a Service利用)の2名の合計4名の構成となっています。
2024年8月末時点では、正社員2名体制でプロダクト横断的にインフラ全般を担当しつつ、SRE活動は「片手間」と言える状況でした。同年9月に私が入社し、3名体制になったものの、すぐに1名がご卒業。結果として、SRE活動に本格的に注力できる体制には至っていませんでした。この状況を打開するため、12月からはTopotalさんにご協力いただくことになり、現在の4名体制が実現しています。
簡単にメンバーを紹介します。
- 私: これまでのクラウドアーキテクトやSRE活動の経験を活かし、アーキテクチャ上の課題提起や、本格的なSRE活動の実施に向けた土台作りに注力しています。
- もう一名のメンバー: 勤続5年目でドメインにも詳しく、課題の発見から解決まで自走できる頼りがいのある存在です。インフラ業務からSRE活動に至るまで幅広く対応してもらい、チームの中心的な役割を担っています。
- Topotalさん: 経験豊富なメンバーがアサインされているため、手が回っていない重めの改善タスクを中心に担当いただいています。(SRE as a Serviceの活用を通じて感じたことや得られた知見については、別のテックブログで改めて共有する予定ですので、ぜひお楽しみに！)
普段のコミュニケーション
私が関東、もう一名が関西に住んでいるため、フルリモートで働いています。Gatherを活用し、円滑なコミュニケーション体制を構築しています。以下のような定例会議や連携を通じて情報共有を行っています。
定例会議
- チーム定例
- 1週間のチケットの振り返り、AWSコスト確認、システムの稼働状況確認などを行っています。
- CTO & 上長との定例
- ツール導入や大きな構成変更についての報告、相談などを行っています。
- SRE勉強会
- 雑談ベースで様々なトピックについてディスカッションを行っています。
- Topotalさんとの定例
- 進捗報告やSRE関連の様々なトピックについてディスカッションを行っています。
- 朝会
- 毎朝15分でその日やることや連絡事項を共有しています。
プロダクトチームとの連携
- 定例や相談
- 定例や勉強会(任意)に参加したり、直接会話したりといったことをしています。これらはすべてGather上で行われています。
外部との連携
- AWSのソリューションアーキテクト(SA)の方と相談する場や、オブザーバビリティツールを提供するベンダーとのコミュニケーションの場も別途設定しています。
- 数ヶ月前まではチーム内に閉じていることが多かったですが、外部の協力を得られる体制が少しずつ整ってきています。
参考
何をやっているの
弊社のような成長フェーズにある組織では、成熟した組織とは異なり、幅広くさまざまな業務に取り組む必要があります。具体的には以下の業務を担当しています。
環境構築と運用保守
- 各プロダクトのクラウドインフラ、ミドルウェア、アプリケーションのセットアップ
- システム更改対応
- 不具合調査&是正対応
信頼性向上とトイル削減
- 性能試験の実施
- オブザーバビリティツール導入
- IaC化(AWS CDKによるコード化 ※現在一部terraform移行検討中)
- 自動化(リリース自動化、問い合わせ対応の自動チケット起票など)
セキュリティ強化と対応
- アーキテクチャ改善
- SSH接続撲滅運動
- セキュリティチェックシート対応
体制強化
- Vision/Missionの策定（チームの長期的な目標や価値観の明確化）
- ロードマップ策定 (次年度やることの設定)
- ドキュメント管理 (Notion化)
- SRE成熟度評価/WellArch評価（現在の運用体制やシステムアーキテクチャを評価し、改善点を明確化&優先度付け）
直近では、プロダクト開発組織のメンバーがNotionを導入してくださったこともあり、ドキュメント整備を積極的に進めています。一方で、SREという文脈ではSLI/SLOやインシデントレスポンスといった領域には、まだ十分に踏み込めていない状況です。
何をやりたいのか
チームのMissionは現在下記のように設定しています。
- 開発者がビジネス価値の提供(機能開発)に注力できる状態をつくること
- エンタープライズに求められるクオリティの非機能要件を実現すること
現状、インフラ/SREグループがすべてのインフラ運用を担っています。この体制では、プロダクトチームが運用に関与できず、インフラ/SREグループがボトルネックとなりがちです。また、信頼性向上やトイル削減といったSRE本来の活動に十分な時間を割けないという課題もあります。
これらの課題を解決し、チームのミッションを達成するために、以下の取り組みを進めていきます。
プロダクトチームへのインフラ業務の委譲
- プロダクトチームの自立性向上
- プロダクトチームが自律的にインフラ運用や信頼性向上を行えるように、ツールやガイドラインを整備します。
- マネージドサービスの活用
- プロダクトチームが機能開発に注力できるようにするため、可能な限り運用負担を軽減するマネージドサービスを活用します。
Platform SREとしての活動
- 共通基盤の整備
- 各プロダクトチームが利用しやすい共通のインフラ基盤を構築し、IaCやCI/CDパイプラインの標準化を進めます。
- 運用ツールの整備と活用推進
- プロダクトチームの日常的な運用負担を軽減するため、監視システムの設定やアラートルールの最適化を行い、オブザーバビリティツールを活用したシステム状況の可視化を進めます。
- SLI/SLOの策定支援
- 各プロダクトチームがSLI/SLOを策定し、それを基にした改善活動が行えるように支援します。
チーム自体のレジリエンス向上
- 属人性の排除とチーム運営の最適化
- チームメンバー間のスキルや業務の偏りを排除し、より持続可能な体制を構築します。
- チームへのカオスエンジニアリングの適用
- チーム自体のレジリエンスを向上させるため、将来的にカオスエンジニアリングをチームに適用し、チーム力を強化します。
参考
まとめ
いかがでしたでしょうか。これが現時点での弊社インフラ/SREグループの実態です。正直なところ、技術的にはまだレガシーな部分が多く、解決すべき課題も山積みです。ただ、事業ドメインとしては非常に将来性があり、今後の成長に十分な可能性を秘めています。
また、今後大きなアーキテクチャの改善も検討しているため、そのような経験を積みたいと考えていらっしゃる方にもぴったりの環境となっています。
弊社のインフラ/SREグループでは、裁量が大きく、自分で責任を持って様々なことにチャレンジできる環境です。自らの手で課題を発見し、解決に導く過程を通じて、大きなやりがいを感じていただけるはずです。
もしこの記事を読んで少しでもご興味をお持ちいただけましたら、ぜひお気軽にお話ししてみませんか？皆さまのご応募を心よりお待ちしています！
Discussion