ヌーラボにおけるSREの現在地 #ヌーラボ真夏のブログリレー2024

by iwa

2024/07/26

Nulab / TechBlog

この記事はヌーラバー真夏のブログリレー2024の10日目の記事です。

こんにちは。SRE課Platform Engineeringチームで、ヌーラボのコンテナプラットフォームの改善と標準化を推進しているiwa（@mananyuki）です。
ヌーラボのSREチームは、2019年にプロダクトを横断したチームとして結成されました。継続的にチームを改善しつつ進めていたのですが、いくつかの組織的な課題に直面しました。これらの課題を解決するために、エンジニアリングマネージャー（EM）と密にコミュニケーションを取りながら、組織体制の改善に取り組みました。
このブログでは、私たちが取り組んだ組織改善の経緯と具体的なプロセスを共有します。同じような課題を抱える他のSREチームや組織にとって参考になる情報を提供し、SREチームの役割や組織改善の重要性について理解を深める一助となれば幸いです。

用語の定義

本記事中では以下のように定義します。

SRE：Site Reliability Engineering
SREs：Site Reliability Engineers。SREを実践するソフトウェアエンジニアを指す
- この表記はGoogle – Site Reliability Engineeringを参考にしました

SREチームの現状と課題

プロダクトとSREチームの関わり

ヌーラボが提供するプロダクト

ヌーラボでは、Backlog、Cacoo、Nulab Appsという3つのプロダクトを提供しています。それぞれのプロダクトごとに開発チームが分かれており、技術スタックも以下のように異なります。

プロダクト	開発言語	インフラストラクチャ
Backlog	Scala / Go / TypeScript	Amazon EKS（Kubernetes） / Amazon ECS / Amazon EC2
Cacoo	Go / Java / TypeScript	Amazon EKS（Kubernetes） / Amazon EC2
Nulab Apps	Kotlin / Java / TypeScript	Amazon EKS（Kubernetes） / Amazon EC2 / AWS Lambda

いずれのプロダクトにおいても、インフラストラクチャ基盤にはAmazon Web Services（AWS）を採用しており、現在はコンテナを中心としてサービスを提供しています。

SREチームの体制

SREチームは、SRE課として全社的に横断する形で各プロダクトの信頼性を向上させる役割を担っています。
SREチームの中では、以下のように3つの役割があります。

プロダクトSREs：プロダクトの信頼性の向上や、運用負荷の軽減に注力する
プラットフォームSREs：コンテナプラットフォームの信頼性の向上や、運用負荷の軽減に注力する
エンジニアリングマネージャー（EM）：SREチームのパフォーマンスを最大化するためにプロジェクトの流量制御、組織の改善、技術的負債の受け入れや解消のための調整、経営層とメンバーを仲介する

また、プロダクトに対応する小規模のSREチームが存在します。それぞれのチームは特定のプロダクトにフォーカスして活動しています。
具体的には以下のようなチームです。

プロダクト	チーム名	役割
Backlog	Backlog Web Operation	プロダクトSREs
Backlog	Backlog Platform Engineering	プラットフォームSREs
Cacoo	Cacoo SRE	プロダクトSREs
Nulab Apps	Apps SRE	プロダクトSREs

プロダクトSREチームは、AWSのリソースの構築、プロダクトの監視の設計・改善、インシデント対応、脆弱性の評価および対応を担当します。
特に歴史のあるBacklogでは、プラットフォームSREチームを設けています。これは、コンテナプラットフォームに既存のサービスを移行したり、新機能を実装するプロジェクトにEmbedded SREsとして参加したり、コンテナプラットフォームの利用を促進する役割を担うチームです。また、プラットフォームSREチームはヌーラボ内に1チームしかないため、Kubernetesエキスパートとしてコンテナプラットフォームの標準化の役割も担います。

SREチームとプロダクト開発チームの関わり

プロダクトSREチーム・プラットフォームSREチームは、プロダクト開発チームと最低でも週に1回それぞれの状況を共有するミーティングを設けています。
新機能の開発といったAWSのリソースの構築が必要なプロジェクトには、Embedded SREsとして参加します。その場合は、プロジェクトの日次のミーティングに参加し、密にコミュニケーションします。必要であれば、プロダクト開発チームの提案するアーキテクチャを、特に信頼性・スケーラビリティの観点からレビューします。
また、Backlogではプロダクト開発チームが平日の日中のオンコール対応を行なっており、プロダクトSREチームはインシデント対応の補佐や、発生したインシデントの調査に協力します。
Backlog開発チームのオンコール対応については、以下の記事をご覧ください。

SREチームが抱える課題

SREチームが結成された2019年から大きな枠組みは変えず、これまで継続的に組織の改善を重ねてきました。
しかし、プロダクトを取り巻く状況の変化から、要求されるクラウドガバナンスの基準が高くなり、SREチームの担当する範囲が次第に増えてきました。そのため、SREチームが信頼性にフォーカスできない状況がしばしば発生するようになりました。
このような状況下に陥ったことで、特に多くのお客様に利用いただいているBacklogにおいて、一部のお客様が満足に利用できなくなるシステム障害が頻繁に発生しました。
また、お客様への価値提供を担うプロダクトの開発チームから、SREチームに停滞感があり開発フロー上のボトルネックとなっていると指摘されることがありました。
SREチームを取り巻く状況の理解がチーム内外でかなり異なり、昨年末からEMと共にSREチームの在り方について再考を始めました。

SREチームの改善を始めるきっかけ

SREチームの在り方の再考を始める前に、きっかけとなった出来事がありました。私が所属していたプラットフォームSREチームはメンバーの退職により私一人となり、EMと毎日のように今後のチームの在り方について話していました。
その中で、頻発したシステム障害やSREチームの停滞感への懸念を共有したところ、SREチームの課題を解決するためにどのような行動が必要か議論することが増えました。また、プロダクトSREチームがより信頼性にフォーカスした動き方を希望していると知りました。そのような背景から、実際にSREチームの在り方の再考を始めました。

SREチームの状況を認識する

まずは、プロダクトSREチームの状況を認識し、それぞれが抱える課題の解像度を上げるところから始めました。
プロダクトSREチームは、進捗やプロダクトのフィードバックを確認するミーティングを日時で開催しています。そのミーティングの中で抱えている課題のヒアリングを実施し、EMと私で取りまとめました。
その結果、以下のような課題が見えました。

クラウドガバナンスの基準の高まりによる業務負荷

プロダクトを取り巻く状況の変化から、要求されるクラウドガバナンスの基準が高くなっています。特にセキュリティを強化する取り組みが多く発生しています。
SREチームでは、業務負荷を鑑みて、小規模のプロダクトで優先して検証することで方針を定め、他のプロダクトに徐々に展開するという進め方を採用していました。この進め方では、方針を定めるチームの専門性およびプロダクトのアーキテクチャの理解が非常に重要になります。
しかし、単独のプロダクトSREチームで網羅するのは現実的でなく、実際に展開する段階になって多くの問題が発覚し、大規模プロダクトで難易度が高くなり業務負荷に繋がる結果となりました。

仕事の種類の多さによる認知負荷

プロダクトSREチームが抱える仕事は多岐にわたり、コンテキストスイッチが多く充分なパフォーマンスを発揮できていないとわかりました。
プロダクト開発チームのプロジェクトが複数走り、プロダクトSREチームの仕事が多い状況で、かつ前述したクラウドガバナンス対応もあり、信頼性にフォーカスすることが困難な状況でした。
さらに、セキュリティインシデントや脆弱性の対応といった不定期に発生する優先度の高い割り込みもあるため、信頼性に立ち向かう優先度が低くなっていました。

プロダクトSREチームの成熟度の差

あるプロダクトSREチームでは、一部のメンバーに知識が偏っており、負荷が集中していることがわかりました。
負荷が集中しているメンバーはコンテキストスイッチが非常に多く、充分な仕事ができていないことでモチベーションの低下が見られました。
これはプロダクトSREチームのケイパビリティが不足していることを意味し、組織的な対応が必要であると示唆していると考えます。

SREチームの課題の緩和策を実施する

SREチームの課題を洗い出したところ、前述した通り大きく3つに分けられました。

クラウドガバナンスの基準の高まりによる業務負荷
仕事の種類の多さによる認知負荷
プロダクトSREチームの成熟度の差

SREチームとして取り組むべき信頼性の向上に立ち向かえていない状況が特に問題で、すでに信頼性が下がりつつある兆候があり、迅速な緩和策の実施が期待されました。
幸いコンテナプラットフォームは充分に安定していたため、コンテナプラットフォームの改善の優先度を下げ、一時的にプロダクトSREチームに参加して、信頼性の向上に立ち向かいました。プロダクトSREチームが受け持っていたインシデント対応の一次受けを担当し、また、特に負荷の高いメンバーのタスクを引き受けることで状況の緩和を狙いました。
この緩和策は、プロダクト開発チームや、多少負荷が減り動きやすくなったプロダクトSREチームのメンバーの協力もあって、素早い再発防止策の実施に繋がりました。

SREチームの課題を分析する

ヒアリングを重ねる中で、SREチームの在り方に関心の高いメンバーが数人見つかりました。そこで、SREチームの在り方について考える分科会を発足して、課題を分析しました。
その中で、ヌーラボのSREsに期待される役割（ジョブディスクリプション）が明確でなく、SREsごとに仕事の認識が異なるとわかりました。そのため、分科会ではまずジョブディスクリプションを定義しました。私たちがやるべき仕事は何かの共通認識を得ることで、SREsの方向性が一致することを期待しました。
分科会で定義したヌーラボのSREsのジョブディスクリプションから、期待される仕事を簡単に抜粋すると以下の通りです。

サービスの信頼性の向上
SRE文化の醸成（Enabling SRE）
プロダクト開発チームの開発効率の向上
トイルの削減
費用対効果の高いインフラ増強
セキュリティのための継続的改善
運用・監視体制の継続的改善

次に、これらの仕事に立ち向かえない本質的な課題は何か分析しました。議論を重ねることで、いくつかの本質的な課題に分解できました。

課題のクロージングまで着目した動きができていない
- 技術の選定や解決策の妥当性を検証するプロセスがうまく回っていない
同じツールを使っているが、標準化が充分ではない
- ガイドラインは存在するが、形骸化していたり、記述が古かったり、標準化が充分ではなく認知負荷の高さに繋がっている

分析して得られたこれらの本質的な課題を、SREチームの組織改善の手がかりとしました。

SREチームの組織改善の取り組み

組織改善に取り組む前の準備——チームトポロジーを学ぶ

組織改善に取り組む準備として、どのような組織のパターンがあるのか、EMと私の間で理解を合わせることから始めました。
現在のハイパフォーマンスな開発組織は、『チームトポロジー価値あるソフトウェアをすばやく届ける適応型組織設計』（以下、『チームトポロジー』と記述）を元にした組織構造を取っていることが多いです。そのため、チームトポロジーの理解を深めて、同じ言葉で話せるようにすることを目標に、互いに学習を進めました。この学習には【資料公開】30分で分かった気になるチームトポロジー | Ryuzee.comが非常に役立ちました。
これより先では、チームトポロジーの4つの基本的なチームタイプと3つのインタラクションモードを元に話を進めます。ここでは、簡単な説明のみに済ませますので、詳細は書籍などをご参照ください。

チームタイプ

ストリームアラインドチーム：最も基本的なチームタイプで、お客様へ価値を届けるためにがんばるチーム
イネイブリングチーム：ストリームアラインドチームが必要なケイパビリティ（能力）を授けるチーム
コンプリケイテッド・サブシステムチーム：専門性の高い複雑なドメインを担当するチーム
プラットフォームチーム：ストリームアラインドチームが必要とするケイパビリティを標準化するチーム

インタラクションモード

コラボレーション：他のチームと密接に協力して作業すること
X-as-a-Service：最小限のコラボレーションで何かを利用または提供すること
ファシリテーション：障害を取り除くために他のチームを支援したり、支援を受けたりすること

（『チームトポロジー価値あるソフトウェアをすばやく届ける適応型組織設計』Chapter 7「チームインタラクションモード」より引用）

チームタイプとインタラクションモードの関係

チームトポロジーでは、4つの基本的なチームタイプにおいて典型的なインタラクションモードと、しばしば発生する偶発的なインタラクションモードが示されています。

	コラボレーション	X-as-a-Service	ファシリテーション
ストリームアラインドチーム	典型的	典型的	偶発的
イネイブリングチーム	偶発的		典型的
コンプリケイテッド・サブシステムチーム	偶発的	典型的
プラットフォームチーム	偶発的	典型的

（『チームトポロジー価値あるソフトウェアをすばやく届ける適応型組織設計』Chapter 7「チームインタラクションモード」より引用）

SREチームの課題の解決策

課題のクロージングまで着目した動きができていない

ヌーラボの開発組織では、アーキテクチャの意思決定の文書化のフォーマットとしてArchitecture Decision Records（ADR）を採用しています。
しかしながら、SREチームではアーキテクチャの決定に際して、ADRを記述するかはSREsの判断に委ねられており、ADRが書かれず意思決定の経緯を追いづらい状況がしばしば発生していました。この弊害として、プロダクトを横断した対応が必要な際に、アーキテクチャを決定したメンバーとそれぞれのプロダクトSREチームが、異なるコミュニケーションパスを利用し情報が散逸する問題もありました。
課題の解決策として、ADRを有効に活用することが良いと考えました。そこで、新たにアーキテクチャ決定にまつわるレビュープロセスを定義しました。また、技術面の専門性が高いメンバーをテックリードに据え、技術的な意思決定の責任者としました。
具体的には以下のようなレビュープロセスを設けています。

プロダクトを横断する対応が必要な時や、新たにツールを導入する時はADRを記述する
テックリードがADRをレビューし、プロダクト固有の懸念点を洗い出す
テックリードのレビューが通ったら、実際に対応を進める
対応する中で課題が見つかったら、ADR中でコミュニケーションを行い、新しい方針を決定する

情報が散逸しづらくADRの有効性を活かすレビュープロセスを採用したことで、対応する際の手戻りが少なくなり、それぞれが納得感を持って仕事を進められるようになりました。
また、テックリードを置いたことで、意思決定の高速化によるSREチームの停滞感の払拭という副次的な効果が得られました。
SREチームでは、チーム外からのプロダクトやプロジェクトに依存しない依頼が発生する際は、EMが一次受けして対応可否をプロダクトSREチームに確認し折り返していました。この際に技術的に可能かの判断を必要とする場合が多く、プロダクトSREチームはそれぞれ状況が異なるため、しばしば方針が一致しませんでした。そういう場面で、まずはEMからテックリードへ相談できるようになり、今までより素早い意思決定が可能になりました。

同じツールを使っているが、標準化が充分ではない

プロダクトSREチームがそれぞれでメンテナンスするドキュメントはあるのですが、業務負荷の高さからメンテナンスが滞るようになっていました。
これには、チームトポロジーのチームの類型をSREチームに当てはめて、解決を図りました。これは『チームトポロジー』の以下の箇所を参考にしました。

実は、４つの基本的なチームタイプをチームに割り当てるだけで、ほとんどの組織では大きな効果が得られる。チームがどのチームタイプになるかを認識することで、チームの最良の働き方を理解し、トポロジーのパターンにしたがって目的とふるまいを変えていけるようになるからだ。
『チームトポロジー　価値あるソフトウェアをすばやく届ける適応型組織設計』Chapter 5「これまでのチームを基本的なチームタイプに変換する」より引用

まず、前述したSREチームの体制に、チームタイプを割り当てました。

プロダクト	チーム名	役割	チームタイプ
Backlog	Backlog Web Operation	プロダクトSREs	ストリームアラインドチーム
Backlog	Backlog Platform Engineering	プラットフォームSREs	プラットフォームチーム
Cacoo	Cacoo SRE	プロダクトSREs	ストリームアラインドチーム
Nulab Apps	Apps SRE	プロダクトSREs	ストリームアラインドチーム

プロダクトSREチームは、各プロダクトの信頼性を価値とするストリームアラインドチームに定義しました。また、プラットフォームSREチームは、コンテナプラットフォームの提供を通じてプロダクトSREチームをサポートするプラットフォームチームに定義しました。
しかし、チームタイプを割り当てるだけでは課題の解決が難しいとわかりました。なぜなら、CacooとNulab Appsではストリームアラインドチーム自身でコンテナプラットフォームの面倒を見る必要があり、価値の提供に注力できる状況ではないためです。
そこで、プロダクトを横断するプラットフォームSREチームを組織することを検討しました。ですが、SREチーム内では充分な人数を確保することが難しく、期待した効果を得られそうにないことがわかりました。
一度視点を変えて、SREチームのみならずプロダクト開発チームにも目を向けたところ、全体的に認知負荷が高く、充分に価値提供に専念できていない状況が見えてきました。SREチームとプロダクト開発チーム全体に対して、認知負荷を下げていく取り組みを行うチームを組織する方針に切り替えました。
この方針転換により、開発者体験の向上に関心が高いソフトウェアエンジニアを社内募集し、最終的にSREsとソフトウェアエンジニアが混じったPlatform Engineeringチームを組織しました。このチームは、コンテナプラットフォームを標準化し、ガイドラインを作成する仕事を主としています。それにより、SREsとソフトウェアエンジニアの認知負荷を下げ、プロダクトの価値を高める仕事に注力できる状態を作ることをミッションと定義しています。Platform Engineeringチームについては、ヌーラボのPlatform Engineeringチームの今とこれからもご覧ください。
また、Platform Engineeringチームでは、プラットフォームチームだけでなく、プロダクトSREチームにKubernetesの知識を授けるイネイブリングチームの役割を含めています。これは、コンテナプラットフォームに採用するKubernetesの知識が、特定のチームに偏っていて、一部のプロダクトでは非常に運用負荷が高い状況にあるためです。プロダクトSREチームにケイパビリティを授け、一部のケイパビリティについて標準化することで、SREチーム全体のパフォーマンスを上げる狙いがあります。
最終的なSREチームの体制は以下のような形になりました。

プロダクト	チーム名	役割	チームタイプ
Backlog	Backlog Web Operation	プロダクトSREs	ストリームアラインドチーム
Cacoo	Cacoo SRE	プロダクトSREs	ストリームアラインドチーム
Nulab Apps	Apps SRE	プロダクトSREs	ストリームアラインドチーム
	Platform Engineering	プラットフォームSREs	プラットフォームチーム・イネイブリングチーム

チーム体制を変更したことで、それぞれのチームでやるべきことが明確になりました。また、Platform Engineeringチームで一部のプロダクトの運用負荷を下げる取り組みを行っており、ある程度の効果が見え始めています。これからはより認知負荷を下げるための取り組みに注力していく予定です。いま抱えている課題が完全に解決されたとは言えませんが、継続して改善する土台を作ることはできました。

それ以外で改善したこと

SREチームは組織における立ち位置の関係で、プロダクトを横断した対応や責任を持たなければならない領域が多く存在します。今回の組織改善では、そういった面になるべく名前をつけて認識し、担当者を明確化しました。

Cloud FinOpsリードの設置
CI/CDリードの設置
インシデント対応・管理SMEチームの設置

ハイパフォーマンスな開発組織、そしてSREチームに向けて

今回のブログでは、ハイパフォーマンスな開発組織を見据えた、SREチームの組織改善のプロセスについて紹介しました。
記事中で紹介した『チームトポロジー』は、ヌーラボのプロダクト開発チームにおいて実際にチームの分割に適用した例（クソデカチームを分割する）があり、非常に助けになりました。今後はよりハイパフォーマンスな開発組織を目指して、SREチームとプロダクト開発チームの垣根を超えて、コミットしていけたらと考えます。
ヌーラボではフルリモートかつフルフレックスな働き方を採用しており、それぞれの開発チームがプロダクトの価値を高めるためにパフォーマンス高く働いています。私たちSREチームはその価値を高めるための下支えとして、信頼性やセキュリティの向上、または開発生産性を高めるための仕掛け作りで、サポートしていきたいと考えています。
まだ道半ばであり、これからの組織改善は継続的に発信していきますので、ご期待ください。