こんにちは、Bill One SRE チームの上司陽平（@paper2）です。組織によって SRE のあり方は多種多様で、求められる役割も異なります。Bill One の SRE チームについて社外の方とお話しする中で、世間一般のイメージとの差異を感じることがありました。そこで皆さんに Bill One SRE チームについて知っていただきたいと思い、以前登壇*1した際の資料をベースに SRE チームを紹介してみたいと思います。
この記事では初めに SRE チームを紹介するために必要な Bill One 全体の情報をお伝えします。次に Bill One SRE のミッションとビジョンを説明します。その上で、Bill One SRE の取り組みについて話していきます。最後までお付き合いいただけますと幸いです。
なお、本記事は【Bill One 開発 Unit ブログリレー】という連載記事のひとつです。
アジェンダ
- Bill One のご紹介
- Bill One SRE のビジョンとミッション
- SRE プラクティスの実践状況
- その他の取り組み
- まとめ
Bill One のご紹介
Sansan 株式会社が提供するインボイス管理サービス「Bill One」は、私が2022年8月に入社した当時からずっと成長を続けていて、そんなプロダクトの勢いに負けじと日々奮闘しています笑
プロダクトが成長するにつれて組織が大きくなるため、組織構造にもスケーラビリティが必要となります。そこで Bill One では上長が可能な限り権限を委譲してボトルネックにならないようなスケーラブルな組織を目指しています。
例えば上記の左図のように権限委譲をしない組織を考えてみてください。グループリーダなどの上位者が権限委譲をせず全ての意思決定を行いたい場合、承認作業に追われてボトルネックになることが考えられます。Bill One ではそのような状態に陥らないように可能な限りの権限を委譲しています。
そのためメンバは相談を重ねて自らが最終判断することを大切にしています。これらの考えは文化としても明文化されていて、各メンバが日々意識しながら活動をしています。私は判断の数だけ成長できると考えているのでこの文化は組織の成長のためにとても重要だと思います。
次に Bill One 開発 Unit のチーム体制をご紹介します。SRE は Embedded 含め様々なチーム様式がありますが、 Bill One では1つのチームとして活動をしています。
また、上記のチームとは別に Bill One 開発 Unit では横串チームというものがあります。横串チームは開発組織横断の課題を解決する有志メンバによるチームで、任意結成・任意解散です。
例えば私は IaC (Infrastructure as Code) 改善チームに所属し、IaC 化の推進や IaC に関わる様々な課題解決を有志のメンバ8人で行なっています。何か問題を解決したいと思った時に同志が集まり、皆んなでわいわいしながら解決できる横串の仕組みが私はとても好きだったりします！！組織にも、集まってくれるメンバにも感謝しかないです！！
最後にアーキテクチャと体制について紹介します。Bill One ではマイクロサービスを採用しています。主要マイクロサービスが6個存在し、各マイクロサービスを1~2の機能開発チームで担当しています。
さて、、、お疲れ様でした。Bill One SREチームを理解するために必要な Bill One 組織について説明しました。それでは本題の SRE チームの紹介に入っていきたいと思います。お疲れの方はここで一息入れてください☕
Bill One SRE のビジョンとミッション
それでは、Bill One SRE のビジョンとミッションの説明に入っていきます。それぞれ背景や意図などを踏まえて説明していきます。
先ほどご説明した通り、Bill One では開発組織のスケーラビリティも重要になります。そこで Bill One の成長のためにも SRE チームがボトルネックになり、開発組織のスケーラビリティを低下させてはいけないという観点がありました。
それも踏まえ「自律的に高い信頼性を維持できる開発チームを支えるための触媒となる」というビジョンを定義しています。触媒とは化学反応の反応速度を速める物質で、自身は反応の前後で変化しないものをいいます。ここでは「なくても進めるけど、あるともっと進める」といったような感じで使っています。まだまだわかりづらいですよね？？図も使いながら説明してみます笑
上図のように各マイクロサービスの開発・運用・信頼性向上を担当する機能開発チームが実施している世界を目指しています。これが前提です。そこに SRE チームが加わると下図のようにより信頼性を維持しやすくなる、そのような存在を目指しています。
Bill One SRE はこのビジョンをあるべき姿として定義し、日々GAPを埋める活動をしています。当然そこまでの課題は多く存在します。それも踏まえ、ミッションは「開発チームが自律的に動ける仕組みを整えつつ、信頼性と開発効率の向上をリードする」としています。現状 SRE チームメンバの専門性が必要なタスクは SRE が主導しています。並行してそれらを機能開発チームに委譲する仕組みづくりを検討・推進しています。
SRE プラクティスの実践
次に Bill One SRE が上記のビジョン・ミッションを掲げた上でどのような取り組みをしているか紹介していきます。当セクションでは以下の SRE の代表的なプラクティスに着目してご紹介してみます！！
まずは SLI / SLO です。Bill One ではユーザリクエストのレスポンスレイテンシとエラー率を SLI としています。バーンレートを活用し、SLIが急激に低下した場合にアラートを発報しています。
次にトイルの削減についてです。ここは SRE の取り組みと言いつつ、実は意識的には何もしていないところになります（ここも自組織が好きな一つの理由だったりします！！）。というのも、各メンバが個人・または横串チームなどで自律的に削減活動を実施してるため、SRE として活動せずとも各々トイルを削減できているためです。例えば、運用改善横串チームでは運用作業におけるトイルの収集、タスク化、優先度付け、各チームへの実装依頼などを実施しています。
最後に可観測性向上周りです。アプリおよびインフラのログをトレースに紐付け、ユーザの1リクエストに関する各コンポーネントのログを抽出可能にしています。これにより多くの問題は解決可能です。一方で性能問題など細かい挙動の把握が必要な際に課題を感じており、APM の導入などを最近は進めています。
その他の取り組み
本当はもっともっと話したいのですが、皆さんもそろそろお疲れだと思うので、、、、その他の取り組みについては以下に例をダイジェストとして挙げてみます！！（私も書き疲れてきました☕）
[性能改善]
- 負荷試験による性能劣化原因の特定、解消による信頼性向上
- SRE チームで週次のメトリクス確認、懸念点を機能開発チームと解消
[可観測性向上]
- 分散トレーシングの活用、改善
- サービスダッシュボードの作成
[開発者の自律的な信頼性向上の文化づくり]
- SRE のビジョン・ミッションの定義、開発組織全体への共有
- ポストモーテムの推進
- インフラの課題解決を SRE の支援を前提に適宜機能開発チームに依頼
おわりに
Bill One の SRE についてお話ししました。 Bill One の組織あってこその Bill One SRE のカタチがあると思いますし、私は Bill One の SRE として活動でき毎日とても楽しんでいます！！ついつい自組織のおすすめポイントも紹介してしまいました笑 もし Bill One SRE に興味をお持ちいただけましたら、採用情報もご確認いただけますと幸いです。最後までお付き合いいただきありがとうございました！！☕
*1:2023年3月9日「Google Cloud Innovators Live Japan 実録！SRE」
