第IV部 ケーススタディ ・ 第16章
本章は著者の Uber 在籍時代を再現した3つのドキュメントで構成される。いずれも2014年当時のサービスプロビジョニングチームの視点で書かれた社内向けドキュメントとして読むよう促される。ドキュメント16-1は Python モノリスからの移行を促進するためのインフラチームの方針、16-2はプロビジョニングがなぜ遅々として進まなかったのかを示すシステムモデル、16-3はサービスオーケストレーションのエコシステムが今後どう進化するかを描いた Wardley マップである。
読み方の指針も与えられている。実際に戦略を適用したい場合は最初（方針）から最後（探究）へ順に読む。一方、背後の思考プロセスを理解したい場合は「探究」から始めて「診断」へと逆順に読むとよい。これは第11章で論じられた「読むこと」と「考えること」を分けるアプローチに沿っている。本書の章本文は脚注として著者の解説が添えられている。
このドキュメントは「方針と運用」「診断」「探究」という構成を持つ、典型的な戦略ドキュメントである。方針セクションでは、Uber のサービスプラットフォームを拡張するうえで採用した複数の指針が示される。中心は「セルフサービス化への投資を最大化するため、手動プロビジョニングへのリソース割り当てを制限する」こと。手動作業にはフルタイムのエンジニアを1名のみ固定し、残りのエンジニアは将来のプロビジョニングを高速化する自動化に充てる。さらに「ポートとサービス名の衝突を避ける単一の信頼できる情報源を維持する」「チケットベースの依頼ではなく適切なツールチェーンで作業を効率化する」「ユーザー入力を必要としない、適切なデフォルト値を備えた仕組みを初期化フェーズで提供する」といった運用上の指針が並ぶ。
診断セクションでは現状が率直に把握される。多くのプロダクトエンジニアリングチームが中央集権的なモノリスからの脱却を目指し、毎週2〜3件のサービスプロビジョニングリクエストが発生していた。このペースはプロダクトエンジニア組織の規模に比例して増え、遅延はますます拡大していた。サービスプロビジョニングは複数の手作業ステップ（ポート割り当て、Puppet 設定の生成・テスト・マージ、Clusto でのサーバー容量割り当て）からなり、各ステップに情報の欠落・誤りや Puppet エラーといった手戻りが入り込む。SRE（サイト信頼性エンジニア）に依存する設計のため、リクエスト1件あたり1週間かかることもあった。チームへの増員（手動処理能力を500%増やす）でもエラーを完全排除してもバックログは解消しないことが分かっており、結論として(1)遅延は拡大し続けている、(2)チームへの採用増は現実的でない、(3)セルフサービスへの移行が唯一の選択肢である、と診断された。
探究セクションでは、業界の同種事例（Google や Facebook の事例、Mesos/Aurora、Kubernetes の採用検討など）を参照しつつ、自社の選択を位置づける。Uber は当初オープンソースの Clusto と Puppet を使って解決していたが、スケールに伴う限界が見えてきていた。著者はここで、実例の戦略ドキュメントを読む価値として、プレスリリースのような完成された主張ではなく、トレードオフや迷いを含んだ現場の思考が読めることを挙げている。
この戦略の核心は、サービスオンボーディングのプロセスを理解し、それを加速させるレバーを見つけることにあった。そこで著者は、オンボーディングのプロセスをシステムモデルとして表現し、実際にモデルを動かして仮説を検証していく。モデルは「リクエストされたサービス」から始まり、「進行中のプロビジョニングサービス」「ポートと名前の割り当て」「Puppet 設定の生成・テスト・マージ」を経て「Clusto でのサーバー容量割り当て」に至るパイプラインとして描かれる。さらに「採用率」から「プロダクトエンジニア」、そこから「リクエストされたサービス」へと向かうリンク（直接は流入しないが影響を与える関係）も加えられる。
モデリングの要点は、エラーフローの扱いにある。初期スケッチにはエラーがなかったが、現実には「情報の欠落・誤り」がポート割り当て段階と Puppet 設定段階の2回発生し、リクエストを初期段階へ差し戻す。とくに後段で起きるほど手戻りは大きい。また「Puppet エラー」がマージ済み設定の段階で発生し、1つ前のステップへ差し戻す。これらをモデルに組み込むと、例えば各ラウンドで「リクエストの20%が情報欠落で差し戻る（Leak 0.8 / 0.2 に分岐）」というように、エラー率を数値で表現できる。比較的低いエラー率でも、システム全体のスループットは有意に低下する。
モデルを実際に動かして得られた「学び」が重要だ。第一に、成功率100%（エラーゼロ）でモデリングしても、新規サービスのリクエストバックログは時間とともに増加し続ける。つまり問題は「現在のプロセスを運用するチームの効率」ではなく「根本的なアプローチそのものが機能していない」点にある。第二に、手動チームの人員を500%増やしても、入ってくるリクエストのバックログは解消しない。第三に、モデルの感度分析（特定のエラー率を20%から50%へ引き上げて比較）から、スケッチ時点での想定（Puppet 生成エラーが最重要）とは異なり、実際にはプロセス初期段階の高いエラー率のほうが、後続の潜在的エラーを複合的に増幅させて深刻な影響を与えると判明した。最終的に、唯一バックログを解消できるのはセルフサービスプロビジョニングへの移行（InflightServices の上限を撤廃する）であることが、モデルによって示された。
このドキュメントは、ユーザーのトラフィックが6か月ごとに倍増する中で、最も効果的な移行先を決めるためのインプットとして、当時のオーケストレーションフレームワークの進化を Wardley マップで検討したものである。マップには「プロダクトエンジニア」「サービスプロビジョニングチーム」「サーバー運用チーム」という3つの社内チームと、それらが依存するコンポーネント（サービスへのトラフィックルーティング、クラスターメタデータ、リソーススケジューリング、サーバーベンダー、データセンター契約など）が、可視性（縦軸）と進化段階（横軸：ジェネシス→カスタム→プロダクト→コモディティ）の上に配置される。
現状分析では、サービスプロビジョニングチームがアプリケーションをサーバーから抽象化しており、プロダクトエンジニアはアプリケーション機能の開発に集中できている。現在のバリューチェーンの課題（コスト効率の高いスケーリング、信頼性の高いデプロイメント、迅速なデプロイメント）はすべて「リソーススケジューリング」という同一の根本問題に根ざしていると見抜く。著者はリソーススケジューリングの業界トレンドを理解することが、効果的な選択の土台になると確信していた。
将来の状態への移行では、クラスターメタデータとリソーススケジューリングが多くの問題の根にあると分析する。Uber は当初オープンソースの Clusto（Digg 社製、Consul に似た目標）と Puppet＋カスタムスクリプトでこれを解決していたが、広く普及せずスケールにも限界があった。Mesos や Kubernetes のようなコモディティ化したオーケストレーションフレームワークの採用が有力で、サーバー設定にも物理インフラよりクラウドインフラ（AWS など）の採用が将来的に妥当だと見る。最も重要な点として、Puppet への投資を続けることは業界の進化の方向に逆らうため、避けるべきだと結論づける。
この Uber のサービスマイグレーション戦略は非常にうまく機能し、ごく小さなチームで一連の複雑な問題を解決した。一方で著者は、彼らが整備したサービスアーキテクチャ上で開発するエンジニアたちに対しては、劣悪な開発者体験をもたらしてしまった点をマイナス面として率直に認める。戦略とは結局のところトレードオフの検討に他ならず、こうした課題を認めることこそが、プレスリリースよりも実際の戦略ドキュメントを読むほうがはるかに価値がある理由の1つだと述べる。
なお著者は、この種の「初期は極めてうまく機能するが、後になって問題化する」戦略を具体的に議論するための概念として「戦略フェーズ」を第23章で導入することにも触れている。本章の戦略はその好例であり、成功と副作用の両面から振り返るべき素材として位置づけられている。