# 分隊型運用 ## 定義 分隊型運用(Ops-in-Squads)とは、Spotify が採用する組織モデルであり、サービスに関するオンコールと運用の責任を、そのサービスを開発した分隊(squad、職能横断型の小さな自律チーム)自身へ引き渡す体制を指す。中央の SRE チームがサービスの信頼性を代行するのでも、SRE を各チームへ 1 名ずつ派遣するのでもなく、開発チームが自らオンコールを担う。実現の前提として (1) それまで運用チームが手作業で行っていた業務を代替するセルフサービス型ツール群の整備、(2) 開発者がプロダクションの問題をトラブルシューティングできるようにするドキュメンテーションとトレーニングの質向上、(3) この変更を推進するための開発者からの賛同、の3条件が必要とされる。SRE の大多数は開発チーム内にではなく、インフラストラクチャを中心とした複数の分隊(IO/SA 等)に所属し、セルフサービス型のインフラプロダクト(CI・デプロイ・モニタリング・フレームワーク)を提供することで機能分隊を支援する。大規模カスケード障害・デプロイ指導・インシデント管理・ポストモーテムのような分野横断的な懸念は、SRE という肩書きに限らない全社横断ワーキンググループ(例: 中央エスカレーション対応の IMOC ローテーションは SRE が半数にすぎない)が扱う。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 7 SREのいないSRE：Spotifyのケーススタディ]] ch.7 冒頭, §7.6.2) ## 横断的知見 - **分隊型運用(Spotify)と you build it, you run it + ProdEng(SoundCloud)は、「専任チームなしで運用責任を開発チームへ分散する」という同じ結論に、正反対の出発点から到達した**: SoundCloud(6章)は 2012 年、元 Google SRE を採用して「定石どおりの専任 SRE チーム」を試み、エンジニア総数に対しオンコール要件を満たす最小チーム規模が非現実的な比率を占めることで破綻し、次に SRE 派遣(embedded)も 1 チームに割ける人数の少なさから失敗した後、消去法的に you build it, you run it へ転換した。対して Spotify(7章)は、専任 SRE チームを模倣的に試みたことは一度もなく、創業時(2006年、社員6名中1名)から運用担当者がチームに常駐する「デフォルトの運用」文化を出発点とし、集中型の運用/SRE チームが徐々に肥大化した末に「集中型の運用 SRE チームはスケールできないシステムだと分かった」(§7.5.2)という自己認識から、能動的に分隊型運用へ移行した。SoundCloud は「専任チーム→派遣→分散」という2段階の失敗を経た消去法的経路、Spotify は「常駐→集中→分散」という漸進的な自己認識による経路であり、専任 SRE チームを持たない組織へ至る経路は単線ではないことを示す。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 7 SREのいないSRE：Spotifyのケーススタディ]] §7.1, §7.5, [[@2021__OReillyJapan__SREの探求 - Chapter 6 専任SREチームなしでSREの原則を適用する方法]] §6.1.1, §6.1.2) - **セルフサービス化の反作用(バックエンドのエントロピー増大)は、SoundCloud のデプロイプラットフォーム(Bazooka)構築では明示的に語られていない、Spotify 固有の教訓である**: Spotify は運用チームの手作業(プロビジョニング・DNS・Puppet レビュー)をセルフサービス化した結果、運用チームによる「サニティーチェック」が失われ、テスト不十分なサービスがプロダクションに入り込み、オンコール担当者が「プロダクションで何が実行されているか」を理解できないままページされる事態を招いた(§7.6.2)。SoundCloud のケーススタディ(6章)は Bazooka というデプロイプラットフォームの構築が新規サービス立ち上げの摩擦を減らしたことを成功として語るのみで、セルフサービス化そのものが生む品質低下の反作用には言及がない。これは、権限移譲とセルフサービス化を進める際に、移譲前に暗黙に存在していたゲートキーパー機能(サニティーチェック)を明示的に代替しないと、新たな信頼性リスクを生むという、成功事例(SoundCloud)だけでは見えない失敗モードを示す。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 7 SREのいないSRE：Spotifyのケーススタディ]] §7.6.2, [[@2021__OReillyJapan__SREの探求 - Chapter 6 専任SREチームなしでSREの原則を適用する方法]] §6.2.1) - **ProdEng の「公式権限もエラーバジェットのような強制力も持たないコンサルテーション型」という自己制限と、Spotify のゴールデンパス(義務化せず使いやすさで普及)は、権限によらない普及戦略という共通の設計思想を持つ**: SoundCloud の ProdEng はリリースを止める公式権限を持たず、デプロイプラットフォームという基盤サービスの提供を通じてゲートキーパーにならずに全チームとの接点を維持した(6章 §6.2.3)。Spotify のゴールデンパスも「公認のスタックを必須のソリューションとして義務付けるのではなく、とても簡単に使えるものにすることで、あえて他の何かを使う理由など見当たらないと思ってほしい」という思想で普及させた(7章 §7.7.1)。両者はいずれも強制ではなく「使いやすさ」でチームの選択を誘導するが、Spotify はこの戦略が Apollo 以外の言語・データパイプライン等の未対応領域で断片化(独自 Jenkins・Cassandra 未メンテナンス)を招き、最終的に一部の基盤(Jenkins・Cassandra)を運用チームが明示的にマネージドサービスとして「回収」する場面を記録しており(§7.7.3)、SoundCloud の記述には無い「強制なき普及戦略が失敗した場合の是正策」を補う。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 7 SREのいないSRE：Spotifyのケーススタディ]] §7.7.1, §7.7.3, [[@2021__OReillyJapan__SREの探求 - Chapter 6 専任SREチームなしでSREの原則を適用する方法]] §6.2.3) ## 未解決の問い - Spotify の IMOC(中央エスカレーション対応、SRE が半数)のような、SRE 肩書きに限らない全社横断ワーキンググループによる分野横断的懸念への対処は、SoundCloud の統合オンコールローテーション(6章 §6.3.1)とどう対応するか。両者はいずれも「専任チームでなく分散した人員がローテーションを構成する」点で似るが、IMOC は複数チームの一次オンコールの上位に位置するエスカレーション層である一方、SoundCloud の統合ローテーションは一次オンコールそのものである点で階層が異なる可能性があり、本 concept の現ソース群では厳密な対応関係は未検証。 - セルフサービス化の反作用(バックエンドのエントロピー増大)を防ぐために、Spotify はギルドによる標準策定・トレーニング・ドキュメンテーションで対処したが、この「サニティーチェックの代替」が具体的にどの程度の品質低下を防げたか(定量的な効果)は本章に記述がない。 - ゴールデンパスからの逸脱(独自 Jenkins・未メンテナンス Cassandra)を運用チームが「回収」する判断基準(どの時点で・どの逸脱を回収するか)は、本 concept の現ソース群では明示されていない。逸脱を許容し続ける場合と回収する場合を分ける条件は未解決。 - 分隊型運用モデルの「再評価」(§7.8)が具体的にどう進んだかは、原書執筆時点(2018年)以降の情報がなく、本 concept の現ソース群では追跡できていない。 ## 関連 - [[SREエンゲージメントモデル]] — 「配る(Infrastructure/Tools)」位置への到達という点で、分隊型運用とゴールデンパスは SoundCloud の ProdEng と同型の位置を占める - [[SRE組織変革]] — 専任 SRE チームを持たない組織への移行経路の一事例 - [[プラットフォームエンジニアリング]] — ゴールデンパス・セルフサービス型インフラプロダクトの設計思想 - [[Spotify]] / [[Drew Michel]] / [[Lynn Root]] / [[Johannes Russek]] - [[SoundCloud]] / [[Björn Rabenstein]] / [[Matthias Rampke]] — 専任 SRE チームなしで SRE 原則を適用するもう1つの経路 - [[@2021__OReillyJapan__SREの探求 - Chapter 7 SREのいないSRE：Spotifyのケーススタディ]] - [[@2021__OReillyJapan__SREの探求 - Chapter 6 専任SREチームなしでSREの原則を適用する方法]] ## 出典 - Daniel Prata Almeida, Saunak Jai Chakrabarti, Jeff Eklund, David Poblador i Garcia, Niklas Gustavsson, Mattias Jansson, Drew Michel, Lynn Root, Johannes Russek, 「SRE のいない SRE：Spotify のケーススタディ」, David N. Blank-Edelman(編)『SREの探求』, オライリー・ジャパン, 2021, 7 章. - Björn Rabenstein, Matthias Rampke, 「専任 SRE チームなしで SRE の原則を適用する方法」, David N. Blank-Edelman(編)『SREの探求』, オライリー・ジャパン, 2021, 6 章.