プロダクションエンジニアリング

# プロダクションエンジニアリング ## 定義プロダクションエンジニアリング(Production Engineering, PE)とは、運用の問題はソフトウェアソリューションを通じて解決すべきであり、ソフトウェアを実際に構築しているエンジニアこそがそのソフトウェアをプロダクションで運用する最善の担当者であるという考え方に基づく職種・組織モデルである。Facebook では、ソフトウェアエンジニアリング(SWE)と運用の統合という概念を復活させる試みとして位置づけられ、単なる従来型の運用チームの改称ではなく、責任範囲・報告構造・採用基準・キャリアパスを含む組織全体の再設計を伴う。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 13 Facebookにおけるプロダクションエンジニアリング]] ch.13 p.217-218) ## 横断的知見 - **ch.13(2018年原書)は SREcon15(2015年)の同一人物(Pedro Canahuati)による語りを、より広いフレームワーク群で裏付け直す**: SREcon15 では SRE→SRO+AppOps→Production Engineering への組織変革が「2009年〜2015年の5段階」として語られ、SRO は 2014年3月31日に解散したと記録される。ch.13 はこれと同じ変革史を「約4年」という粒度で振り返りつつ、SREcon15 には無かった具体的な運用フレームワーク——集中型報告+分散型配属という組織設計、新チーム発足の4要因、サービスピラミッド、3フェーズモデル、Hack-A-Month——を追加する。同一人物・同一組織の異なる時点・異なる媒体(カンファレンストーク→書籍インタビュー)の語りが、事実関係(SRO解散・FBAR・改称)では一致しつつ、書籍インタビューの方がより体系化された運用ノウハウを開示している点が対比できる。(Source: [[@2015__SREcon15__Notes from Production Engineering]], [[@2021__OReillyJapan__SREの探求 - Chapter 13 Facebookにおけるプロダクションエンジニアリング]] ch.13 p.218-222) - **SWE 対 AppOps の人員比率(1:10〜1:40)は、SREcon15 が定性的に語った「てんてこ舞い」を定量化する具体的な負荷指標を追加する**: SREcon15 は「AppOps エンジニアの大半が24時間365日のオンコールに対応しなければならず、火消し作業が常態化した」と定性的に記述するが、当時の人員比率までは開示していない。ch.13 は、当時のモデルが「サービス(ニュースフィード・広告・Web チャット・検索・データインフラ)あたり1名の AppOps エンジニア」であり、SWE との比率が1対10、場合により1対40に達していたと具体的な数値を示す。この比率は、SIE(SREcon23 EMEA)の「エンジニア総数の5〜10%を専任SREチームが占めて破綻した」というSoundCloud型の閾値([[SRE組織変革]]既出)とは異なる種類の崩壊——専任チームの相対規模ではなく、1人が支える対象サービス数の過多——であり、派遣型モデルが破綻する経路は少なくとも2通り(チーム規模の相対的過大/1人あたり負荷の過大)あることを示す。(Source: [[@2015__SREcon15__Notes from Production Engineering]], [[@2021__OReillyJapan__SREの探求 - Chapter 13 Facebookにおけるプロダクションエンジニアリング]] ch.13 p.219) - **Facebook の PE モデルは、SoundCloud(6章)・Spotify(7章)が到達した「配る(Infrastructure/Tools)」位置とは異なり、独立した報告ラインを保った「一緒にやる(Embedded)」+ 完全なオンコール共有という位置に留まり続ける**: [[SREエンゲージメントモデル]] の既出知見は、SoundCloud が「引き受ける→一緒にやる→配る」の3位置を試行錯誤の末「配る」(共通デプロイプラットフォーム Bazooka の提供)へ、Spotify が専任チームを経由せず直接「配る」(ゴールデンパス)へ到達したことを記録する。これに対し Facebook の PE は、SWE のすぐ隣に配属され(分散型の配属構造)、週単位でオンコールを共有し、機能と安定性を対等な立場で議論する「一緒にやる(Embedded)」の位置に組織として定着しており、共有基盤の提供へ完全に移行するのではなく、独立した報告ライン(集中型の報告構造)を維持したまま Embedded であり続ける点が、他の2社と異なる第3の到達形態である。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 13 Facebookにおけるプロダクションエンジニアリング]] ch.13 p.222-227, [[@2021__OReillyJapan__SREの探求 - Chapter 6 専任SREチームなしでSREの原則を適用する方法]], [[@2021__OReillyJapan__SREの探求 - Chapter 7 SREのいないSRE：Spotifyのケーススタディ]]) - **「誰がオンコールを担当するか」という Pedro の一次判定基準は、Netflix の「中枢神経系」モデル(1章)と正反対の設計思想を体現する**: [[SREエンゲージメントモデル]] の既出知見は、Netflix のコア SRE チームが個々のマイクロサービスの信頼性を自ら所有せず、発生場所を問わずすべての障害を横断的に把握し対応すべきチームを判断する「中枢神経系」として機能すると記録する。ch.13 で Pedro は、他組織が自社の PE モデルにどれだけ近いかを判定する最初の質問として「誰がオンコールを担当するのか」を挙げ、SWE(または SWE と運用チームの共有)以外——SRE・PE・DevOps といった別チームが一次対応する——であれば「私たちが定義したような PE モデルを構築しようとしているのではない」と明言する。両者を並べると、Facebook の PE モデルは「サービスを構築した者がオンコールを担当する」ことを組織設計の中核的な判定基準に据えるのに対し、Netflix は逆に「誰が対応すべきかを横断的に判断する専任機能」を中核に据えており、大規模組織における障害対応の設計思想が対極に分かれることが分かる。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 13 Facebookにおけるプロダクションエンジニアリング]] ch.13 p.239-240, [[@2021__OReillyJapan__SREの探求 - Chapter 1 SREにおけるコンテキストとコントロール]]) - **ch.13 の「オンコール共有 = PE モデルの判定基準」という主張は、SREcon22 EMEA の O'Connor が警告する「toxic exceptionalism」の反例として読める**: [[SRE組織変革]] の既出知見は、Dave O'Connor がオンコールを SRE の特権として複雑化・ゲートキープする文化を「toxic exceptionalism(毒性的例外主義)」と呼び、Facebook SRO の「クラッチ」化と同型の構造だと指摘したことを記録する。ch.13 で Pedro が示す「コードを書いてリリースした者が所有者」という原則と、週単位の SWE/PE オンコール共有ローテーションは、この toxic exceptionalism とは逆方向の設計であり、オンコールを PE の専有物にせず SWE と対等に配分することで排他性そのものを構造的に排除している。両者を並べると、オンコールの配分様式は「特権化(toxic exceptionalism)」と「対等な共有(Facebook PE)」という両極に分かれ、Facebook の SRO 解散(2014年)は前者から後者への移行そのものだったと位置づけられる。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 13 Facebookにおけるプロダクションエンジニアリング]] ch.13 p.225-227, [[@2015__SREcon15__Notes from Production Engineering]]) ## 未解決の問い - ch.13 が示す新チーム発足の4要因(3人以上・18-24か月分の作業量・専属マネージャー・連携する SWE チームの存在)は、SoundCloud(6章)やSpotify(7章)の組織設計とどう対応するか。両社の事例では明示的なチェックリストは記述されておらず、比較の材料が本 concept の現ソース群にはまだ無い。 - 「サービスピラミッド」(Andrew Ryan考案、マズローの欲求段階説に基づく)は、Mickey Dickerson が O'Reilly のカンファレンスで語ったという類似の欲求段階説とどこまで一致するか。ch.13 では言及のみで詳細は未確認。 - SWE:AppOps 比率1:10〜1:40という当時の負荷指標は、現在(ch.13 収録時点)の SWE:PE 比率にどこまで改善したか。ch.13 には現在時点の比率の開示がない。 - Facebook の PE モデル(独立報告ライン+完全なオンコール共有)は、SoundCloud・Spotify が最終的に到達した「配る」位置と比べて、どちらがより長期的にスケールするか。3社とも異なる時点・異なる規模での記述であり、本 concept の現ソース群では優劣を判定する材料がない。 - Hack-A-Month(1年以上の在籍者への1か月間の他プロジェクト経験推奨)は、他の SRE 系組織(SoundCloud・Spotify・SIE等)の流動性施策とどう比較できるか。他ソースに同種の制度の記述はまだ無い。 ## 関連 - [[SRE組織変革]] — Facebook の SRE→SRO+AppOps→PE への組織変革史(SREcon15/16との突き合わせ) - [[SREエンゲージメントモデル]] — PE の「一緒にやる(Embedded)」+オンコール共有という位置づけと、SoundCloud/Spotify/Netflixとの対比 - [[分隊型運用]] — Spotify の分隊型運用との比較対象 - [[オンコール自動化]] — FBAR(FaceBook Auto Remediation) - [[SRE採用面接]] — PE の採用で重視される資質(集中力・協力的コミュニケーション・技術知識・柔軟性・SPOFにならない意欲) - [[Facebook]] / [[Pedro Canahuati]] / [[David N. Blank-Edelman]] / [[Andrew Ryan]] - [[@2021__OReillyJapan__SREの探求 - Chapter 13 Facebookにおけるプロダクションエンジニアリング]] — 本 concept の主ソース - [[@2015__SREcon15__Notes from Production Engineering]] / [[@2016__SREcon16__Incident Response @ FB, Facebook's SEV Process]] — 同一組織変革の先行する独立ソース - [[@2021__OReillyJapan__SREの探求 - Chapter 6 専任SREチームなしでSREの原則を適用する方法]](SoundCloud) / [[@2021__OReillyJapan__SREの探求 - Chapter 7 SREのいないSRE：Spotifyのケーススタディ]](Spotify) / [[@2021__OReillyJapan__SREの探求 - Chapter 1 SREにおけるコンテキストとコントロール]](Netflix) — 「専任SREチームを持たない組織」の他の実例との対比 ## 出典 - Pedro Canahuati, David N. Blank-Edelman, 「Facebook におけるプロダクションエンジニアリング」, David N. Blank-Edelman(編)『SREの探求』, オライリー・ジャパン, 2021, 13 章. - [[@2015__SREcon15__Notes from Production Engineering]](SREcon15, 2015-03-13) - [[@2016__SREcon16__Incident Response @ FB, Facebook's SEV Process]](SREcon16 Europe, 2016-07)