こちらの記事はSRE Advent Calendar 2023の14日目のエントリです。
13日目はれおすけさんさんのSRE team を立ち上げて5年半の変遷と個人的にこれからやりたいことでした。
はじめに
はじめましてラクスというSaaS会社でSREをしています@mekkaと言います。
普段はSREチームのマネジメントをしつつ、各プロダクトチームのモダナイズのお手伝いなどをしています。
チーム設立からようやく2年くらい（採用の関係で機能していない期間も含めて）になるので、これまでやってきたことを振り返ろうかと思います。
0からのチーム立ち上げでしたので四苦八苦しながら進めてきましたが、この経験が何かの参考になれば幸いです。
弊社の組織紹介
弊社はToB向けのプロダクトを複数展開していまして、SaaS業界では古参の部類に入るかと思います。
歴史が長いことで技術的な負債を抱えたシステムも多く、それを改善する打ち手も無く漠然とした不安を抱えていました。
また、開発チームとインフラチームが分離した組織体制のため、コミュニケーションも乏しくDevOpsが進む気配も無いという状態でSREチームの活動が始まりました。
一人目のSRE（2021年10月ごろ）
DevOpsが進んでいない・・・そこで、両方の知見のあるメンバーを集めたチームを作って旨いことやればいいんではないか！ という今考えるとだいぶ適当なアイディアからSREチームは発足しました。
振り返ってみるとだいぶ雑な理屈でチームが立ち上がったとは思います。
このタイミングで私のところにお声掛けがあり、SREチームを立ち上げてDevOpsを推進しつつ、モダナイズや自動化を進めて欲しいという事でした。
当時の私は、アプリにもインフラにも口出しできてモダナイズ出来るなら楽しそうじゃん ！くらいのノリでOKしたのでだいぶあやふやなままでSREチームが発進しました。
チームの役割を決める（2022年1月ごろ）
チームを作れと言われても、さて何をやったらいいものか？ これがなかなか整理できずに悩みました。
SREチームという名前は付いていても業務内容は各社それぞれ、特にこれが答えというものはありません。
多いケースとしてはインフラを担当しているケースですが、弊社の場合は既にインフラを担当しているメンバーがいるので、インフラの業務を期待されているわけでもありません。
そこで、As-Is／To-Beで最終的に目指す理想のシステムと組織について、現状とのギャップを整理した上でそれを拡充する様な形で役割を検討しました。
- 理想のシステム
- 変更に強く自立型で運用出来る
- 柔軟にスケール出来る
- システムの状況を正しく把握できる
- 理想の組織
- 自立して開発、運用を回せる組織
- 役割ごとに専門性を保持したチームが連携している
要約するとクラウドネイティブなシステムや組織が目指すべき場所ということになります。
この理想と比べて現状はどうだったかと言うと以下の感じでした。
- 現状のシステム
- 変更の際は人手による暖かい手作業
- スケールアウトができずスケールアップで対応
- システムの状況が分からないので長年の感によるデバッグ
- 現状の組織
- 開発チームは開発のみ、運用はインフラチームにお任せ
- 特定の人に頼っており業務負担に偏りがある
肌感では感じていましたが、実際に書き出してみるとだいぶ遠い事がよく分かるなと思った事を覚えています。
とは言え一つずつでも進めないと仕方ないので、このタイミングでSREチームとして2つの役割を定めました。
- 小さく新技術を試してノウハウを蓄積すること
- 蓄積したノウハウを各プロダクトへ還元すること
クラウドネイティブ化を推進するために、各プロダクトチームに対してEnabling SREの活動を進めるというのがチームの役割となりました。
※当時はそんなかっこいい単語は知らなかったので、出島でチョコチョコと試して全国へ売りに行く出島政策かなーとか言っていました
ノウハウを集めるための活動（2022年3月ごろ）
まずはノウハウを集めるところから始めましたがイキナリ挫折します。
そもそもチームとしての実績が無く、トップダウンという訳でもない、なかなか新技術を試そうという協力者が現れません。
当時の私はなんで誰もチャレンジしないんだ！ と憤慨していましたが、今考えれば信頼が無いのだから当たり前です。
ここで考え方を改め、あっちから来るのを待つのではなく、自分達で何か実績を作る方向にシフトしました。
たまたま、社内でプロダクトの契約管理に関連する新システムの開発の話があり、これをSREチームで巻取ることで、新技術の知見を貯めようということになりました。
SREチームではアプリケーション開発をメインにやってきたメンバーが大半なので、アプリケーション開発は特に問題にならなかったのですが、インフラ部分で苦戦することになります。
Kubernetes導入の検討
弊社のシステム基盤はその多くがオンプレミスで動いています。（一部AWSも存在します）
クラウドネイティブなシステムを目指していこうとするとコンテナの利用が当たり前になりますが、これまでコンテナ技術を利用していなかったため、オンプレ環境にはコンテナを動かすための基盤が存在しません。
将来的な事を考えるとSREチームだけではなく、既存のプロダクトにも関わることなので、インフラ部（SREチームはインフラ部に所属）内でテックリード、マネージャーを交えてコンテナ基盤の扱いについて議論を進めました。
結果的に最終的にはオンプレミスでKubernetesの運用をすることで合意しました。
ただし、この時点ではノウハウが少ないため、SREチームでのシステム開発時はAWSのEKSを利用してKubernetesの取り扱いに慣れることから始める事としました。
※将来的にオンプレミスで下ろす想定です
この時点でKubernetesを触ったことがあるメンバーは私を含め数名のみ・・・という状態でこれでは流石に進められないということでKuberenetes完全ガイドの輪読会やハンズオン、外部のトレーニングも活用してメンバーの学習の場を作る様にしました。
SREチームとしては輪読会のファシリテートをしたり、テスト環境の提供やハンズオンの実施するといった形でリードしていきました。
これらの活動にはインフラチームだけではなく開発チームからも参加してもらえたので、SREチームの活動を理解してもらうのにもとても役に立ったと思います。
システム開発のその後（2023年3月ごろ）
ノウハウを集めるために始めたシステム開発ですが、その後着々と進みEKSの環境も出来、GitOpsの環境も整い後はローンチを待つだけとなりました。
が、ここで衝撃の展開で会社内の諸事情でシステムは凍結となりました。
やるせない気持ちになりましたが、開発の中で纏めたKubernetesやGitOpsのノウハウは丁度、同時期に開発をしていた別システムへ投入することで日の目を見ることとなります。
とりあえず貯めたノウハウは無駄では無かった・・・と自分達を慰めつつ、会社として一歩前進した事は素直に嬉しかったです。
そして当面は開発が続くかな？ と思っていた矢先でしたのでこのタイミングで再度、自分達のミッションや今後のロードマップを再整理することにしました。
ミッションとロードマップの再整理（2023年6月ごろ）
以前はなんとなくチームの目的を決めていましたが、だいぶ自分達のやりたいことが明確になってきていたので、このタイミングでミッションとビジョンを明文化しました。
ミッション
開発組織のDevOps文化を醸成しプロダクトの価値を高速に提供する
ビジョン
開発とインフラを繋ぐHubとしてモダナイズを実現する
この時はチームトポロジーを参考にしつつ、将来的な組織のあり方、各チームの専門性などを考慮しつつ自分達の役割を再定義しています。
開発チームはストリームアラインドチームへ、インフラチームはプラットフォームチームへと進化していくと想定して、自分達はそのプラットフォームを上手に使いこなすためのイネーブリングチームとなる という構想です。
上記の様な組織に変えていくためには技術的な面でのサポートも必要となりますので、そこについてもSREチームとしてイネーブリングしていくこととしています。
開発チームに対してはマイクロサービスへのリファクタリングやマニフェスト作成のサポート、インフラチームにはKubernetesを始めとするプラットフォーム構築のサポートなどを行っています。
現在の状況（2023年11月ごろ）
2023年度に既存の1システムでPoCを行い、その成果を関係者へ共有し、次年度更に範囲を拡大していくことを目指しています。
まずは、関係者に成功体験をしてもらおう！ ということでSREチームで既存システムをコンテナに移行し、GitOps環境でのCI/CDを実際に体験してもらうことから始めています。
実際に体験してみればこれまでの方法（古からある手順書を作って手作業によるデプロイってやつです）よりも遥かに早く、安全にリリース出来ることが分かり、開発チームもインフラチームも協力してくれる様になりました。
現在は次年度のローンチに向けて以下の作業を進めています。
- Kubernetes基盤
- VMWare Tanzuを基盤に構築
- CIパイプライン
- GitHub上に構築、併せて、社内のGitLabからGitHubへ移行
- CDパイプライン
- ArgoCD／ArgoEvent／ArgoWorkflowを構築
- マニフェストテンプレート管理
- Helmの導入とテンプレートの構成検討
- Secret管理
- Hashicorp VaultとVault Secrets Operatorの導入
- Observability環境
- Grafana／Tempo／Loki／Prometheusの導入
開発チーム、インフラチームはプロダクトの開発タスクもあるため、可能なものはSREで巻き取って進める様にしています。
これまでの経験から、可能なものは巻き取って進めることでSREチームへの信頼貯金が増えるということは分かっているので積極的に巻き取るようにしています。
ただし、その場合も最終的には運用するのは自分達（開発／インフラ）なので、ノウハウは引き継いでもらうということを約束してもらっています。
まとめ
振り返ってみると最初はだいぶワガママな動きをしていたと思います。
兎に角、僕の思う良いシステムにするんだ という思いが強すぎて関係者との会話もせずに思いを押し付けていました。
途中でプロダクトが頓挫しましたが、皆の幸せ・自分ができること・協力をえる と思考を整理する時間が取れたので遠回りをしましたが結果的には良かったと思っています。
ミッション・ビジョンにも掲げていますが、私の思うSRE（弊社のパターンという方が適切かもしれません）は縁の下の力持ちだと思っています。
プロダクトが価値を産んでこそ会社が成り立ちますので、その人達がうまく立ち回れる様に適切なフォローをしていく、その際はSREも丸投げせずに自分ごととして一緒に頑張るという姿勢で今後も活動していきたいと思います。
明日は@katainaka0503さんの記事です。まだまだ続きますので盛り上がっていきましょう。