# Google ## 概要 Site Reliability Engineering(SRE)を提唱・確立した企業。本 wiki では [[@2026__GoogleSRE__AI in SRE - Engineering the Future of Reliable Operations]] の発行主体として登場し、AI-Ops(本番運用への AI 自律性導入)を **Cloud・Ads・YouTube・Search** の本番にまたがって実装・展開していると報告する。Gemini を基盤に [[Detectr]]・[[AI Operator]]・[[Actus]] 等の社内システムを構築し、自律度を [[SRE AI Autonomy Levels]](L0–L4)で統治する。 本 wiki に**初めて入る産業界・本番運用の一次情報源**であり、それまでの [[University of Illinois Urbana-Champaign]]・[[Microsoft]]・[[Adobe]] といった学術/製品寄りの所属とは異なり、大規模本番での自律緩和の実績を主張する立場を代表する。 ## B4:WAN向けトラフィックエンジニアリング(SDN本 第2章) Google は自社データセンター間を結ぶプライベートバックボーン B4 を、ベアメタルスイッチと SDN によって全面的に構築・公開してきた。B4 の中核は、アプリケーションクラスの要求に応じてネットワークをプロビジョニングするトラフィックエンジニアリング(TE)制御プログラムであり、経路計算をルーティングと同様の完全な分散処理に留める MPLS ベースの TE の限界(局所最適化しかできずグローバルな最適化に近づけない)を、経路計算を論理的に集中させた SDN コントローラへ移すことで解消する。リンク障害時にはコントローラがトラフィック需要の新しいマッピングを計算し、リンクが過負荷にならないようスイッチへ転送を指示する。B4 は運用を重ねる中で、全トラフィックを一律に扱う方式から、遅延・可用性への許容度が異なる複数のトラフィッククラス(ユーザーデータのリモートコピー、分散データソースへのリモートストレージアクセス、複数データセンター間の状態同期を伴う大規模データプッシュ)を区別する方式へ進化した。集中制御・送信側でのレート制限・トラフィッククラスの区別を組み合わせることで、Google はリンク利用率をほぼ 100% まで押し上げた。これは、バーストやリンク・スイッチ障害への備えとして通常 30〜40% 程度に抑えて設計される WAN リンクの典型値の 2〜3 倍にあたる。(Source: [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 2 Use Cases]] §2.3) Amin Vahdat・David Clark・Jennifer Rexford による ACM Queue 誌の対談("A Purpose-built Global Network: Google's Move to SDN", 2015年12月)が、Google が SDN を採用するに至った思考過程を詳しく伝える一次資料として同章から挙げられている。 ## 関連プロダクト/システム - [[Detectr]] — Gemini 駆動の outage 検知。 - [[AI Operator]] — L2/L3 で稼働する一次対応エージェント。 - [[Actus]] — アクチュエーションの安全ゲートウェイ。 - [[Model Context Protocol]] — 本番ツールへの自然言語インターフェース標準。 - [[AI Insights]] — 過去インシデントを連続レビューして知見と risk category を抽出する社内システム。Gemini embedding + vector DB 基盤([[@2026__Google Cloud Blog__AI in SRE - Where Google is Deploying Agentic AI to Improve Operations]])。 - [[Agent Development Kit]](ADK) — エージェント開発プラットフォーム。Google SRE AI のエージェント構築基盤。 - [[Gemini Enterprise Agent Platform]] — フルスタック AI 基盤。**Vertex AI のリブランド**(本 wiki 内で 2026-05-29 にリブランド事実が一次確認)。 - [[TimesFM]] — 時系列基盤モデル。Google SRE AI の異常検知レイヤに組み込まれる。 - Gemini — 上記システムの基盤 LLM(社内ファインチューン版を含む)。 - [[XProf]] — [[OpenXLA]] エコシステムの ML プロファイリングシステム。TPU/GPU/サードパーティアクセラレーターを 0.3% 未満のオーバーヘッドで統一プロファイリング。MLPerf 受賞・Google 社内効率改善に貢献。([[@2026__MLSys2026__XProf - An Open, Scalable and Extensible Profiling System for the Modern ML Stack]]) [[Stanko Novakovic]](CXLベースのメモリプーリングシステム[[@2023__ASPLOS__Pond - CXL-Based Memory Pooling Systems for Cloud Platforms|Pond]]、ASPLOS '23の共著者)は、論文発表時点でGoogle所属として記載されている(研究自体は[[Microsoft Azure]]在籍時に実施)。(Source: [[@2023__ASPLOS__Pond - CXL-Based Memory Pooling Systems for Cloud Platforms]]) ## 関連 - ソース: [[@2026__GoogleSRE__AI in SRE - Engineering the Future of Reliable Operations]] / [[@2026__MLSys2026__XProf - An Open, Scalable and Extensible Profiling System for the Modern ML Stack]] / [[@2022__OReillyJapan__SREエンタープライズロードマップ - Chapter 2 なぜ信頼性のためにSREというアプローチをとるのか？]] / [[@2023__ASPLOS__Pond - CXL-Based Memory Pooling Systems for Cloud Platforms]] / [[@2022__MLSys__Pathways - Asynchronous Distributed Dataflow for ML]] / [[@2022__SIGCOMM__Jupiter Evolving - Transforming Google's Datacenter Network via Optical Circuit Switches and Software-Defined Networking]] / [[@1998__TechReport__The PageRank Citation Ranking - Bringing Order to the Web]] - 概念: [[SRE AI Autonomy Levels]] / [[agentic SRE]] / [[AIOps]] / [[MLプロファイリング]] - 関連 MOC: [[SRE - MOC]] / [[LLM4SRE - MOC]] / [[Systems for ML - MOC]] ## データセンター運用の機械学習 2014年の [[@2014__Google__Machine Learning Applications for Data Center Optimization]] では、Googleの実運用センサーデータからニューラルネットワークでPUEを予測し、冷却設備の設定値感度分析、異常メーター検知、設備構成の事前シミュレーションへ利用している。(Source: [[@2014__Google__Machine Learning Applications for Data Center Optimization]]) ## 水平スケーリングへの移行とSREの起源 初期の Google は、他の多くのテナントと同様に、より大きく強力なコンピュータを購入する垂直スケーリングでサーバー群(フリート)を管理していた。Google が異彩を放ったのは、このモデルから、より多くの安価なコンピュータを購入する水平スケーリングへ早期に移行したことである。第一次ドットコムブームの頃、多くのテナントが見栄えのする高価なハードウェアをケージに収めていたのに対し、Google は膨大な量のコモディティハードウェアを置き、単一マシンの故障を常に想定してソフトウェアで対処した。この移行における重要な選択は、水平シフトに伴う運用コストを意図的にスケールさせない——管理下のマシン台数に比例して運用チームの人員を配置しない(サブリニアスケーリング)——というものであり、この技術的・財政的な選択が組織的な選択を促し、SRE の起源になったとされる。Google はマシンの台数ではなく、クラスタ・サービス・プラットフォームといったより高次の指標でスケーリングすることを選んだ。(Source: [[@2022__OReillyJapan__SREエンタープライズロードマップ - Chapter 2 なぜ信頼性のためにSREというアプローチをとるのか？]]) ## 分散データベース基盤 Google は 2000 年代〜2010 年代にかけて大規模分散ストレージ・データベースの基盤システム群を設計・実装した: - [[@2004__OSDI__MapReduce - Simplified Data Processing on Large Clusters]] — map/reduce の2関数だけで大規模クラスタ上の並列分散計算を記述できるプログラミングモデルとその耐障害実装。[[Jeffrey Dean]]・[[Sanjay Ghemawat]]、OSDI 2004。2004年8月時点で月29,423ジョブ・入力3,288TBの規模で本番稼働し、検索インデックス生成システムの書き換えに使用された。 - [[Bigtable]] — ペタバイト規模の構造化データを管理する分散ストレージシステム。(row, column, timestamp) → string の多次元疎マップをデータモデルとする。[[@2006__OSDI__Bigtable - A Distributed Storage System for Structured Data]]（[[Jeffrey Dean]]・[[Sanjay Ghemawat]] ほか、OSDI 2006）。 - [[@2026__SIGMOD Companion__Twenty Years of Bigtable]] — [[Bigtable]] の 20 年運用経験を報告する SIGMOD Companion 2026 論文。10 EB データ・ピーク 70 億 QPS 規模、レプリケーション、SQL、CDC、CRDT、マテリアライズドビュー、外部コンパクション、オートサイジング、Bigtable SRE チームによるサービス運用への移行を整理する。 - [[Google File System]]（GFS）— 大規模データの分散ファイルシステム。Bigtable のログと SSTable の永続化層。 - [[Chubby]] — 分散ロックサービス。Bigtable のマスタ選出・タブレットサーバ管理に使用。 - [[Spanner]] — 外部一貫性を持つグローバル分散データベース。TrueTime で commit wait を実現。[[@2013__TOCS__Spanner - Google's Globally Distributed Database]]（[[James C. Corbett]]・[[Jeffrey Dean]] ほか、OSDI 2012 / TOCS 2013）。 - [[F1]](AdWords 分散 SQL データベース)— Spanner 上に構築した分散リレーショナル DB。100 TB 超・5 ナイン可用性・フル SQL をスケーラブルに提供。階層スキーマ・楽観的トランザクション・非ブロッキングスキーマ変更が特徴。[[@2013__VLDB__F1 - A Distributed SQL Database That Scales]]（[[Jeff Shute]] ほか、VLDB 2013）。 - [[@2017__arXiv__The Case for Learned Index Structures]] — [[Tim Kraska]]・[[Alex Beutel]]・[[Ed H. Chi]]・[[Jeffrey Dean]]・[[Neoklis Polyzotis]] による [[Learned Index]] の提案。B-Tree・ハッシュマップ・Bloom filter を learned model と補助構造で置き換える設計方向を示す。Kraska は MIT 所属表記だが、論文注記では Google 所属中の研究である。 - [[@2010__VLDB__Dremel - Interactive Analysis of Web-Scale Datasets]] — [[Sergey Melnik]] ほか(全員 Google, Inc. 所属)による対話的クエリシステム Dremel の提案(VLDB 2010)。ネストデータ向けの列指向ストレージ(repetition level / definition level)とウェブ検索由来の多段サービス木を組み合わせ、兆行規模のテーブルへの集計クエリを数秒で実行する。2006 年から社内本番稼働し、[[MapReduce]] を置き換えずに補完する設計思想を明示する。[[Google File System]]・[[Bigtable]] を「in situ」アクセス対象のストレージ層として利用する。 ## 可用性・SLO 研究 Google は可用性メトリクスと SLO 定義の分野でも先駆的な研究を発表している: - [[@2017__HotOS__Thinking about Availability in Large Service Infrastructures]]（[[Jeffrey C. Mogul]] ほか）— 可用性へのセキュリティ的思考・フェイルスタティック設計。 - [[@2019__HotOS__Nines are Not Enough - Meaningful Metrics for Clouds]]（[[Jeffrey C. Mogul]]・[[John Wilkes]]）— SLE/CBE 枠組みによるリスク分担、「ナインだけでは不十分」。 - [[@2020__NSDI__Meaningful Availability]]（[[Tamás Hauer]] ほか）— ウィンドウ付きユーザーアップタイム、G Suite 本番で展開。 ## RPC インフラ特性研究 Google は自社フリート全体の RPC 動作を 700 日間・722 億サンプル規模で初めて大規模計測し、先行研究の前提(マイクロ秒スケール)を実証的に否定した: - [[@2023__SOSP__A Cloud-Scale Characterization of Remote Procedure Calls]]（Seemakhupt・Stephens・Khan ほか [[Arvind Krishnamurthy]]・David Culler・Henry Levy、SOSP 2023）— Google Search・Gmail・Maps・YouTube と [[Spanner]]・[[Bigtable]]・F1 を支える 10,000+ RPC メソッドを対象に、RPC レイテンシがミリ秒スケール・コールグラフが広く浅い・圧縮が CPU コストの最大要因(3.1%)であることを実証。[[Stubby]](gRPC 相当の内部 RPC ライブラリ)・[[Monarch]](メトリクス TSDB)・[[Dapper]](分散トレーシング)を計装ツールとして使用。 ## Dapper 分散トレーシング基盤 [[Dapper]] は Google が 2008 年頃から本番稼働させた大規模分散システムトレーシング基盤である。スレッドローカルストレージへのトレースコンテキスト付与と RPC ライブラリへの計装集中により、アプリケーションコードを変更せずに Google 規模の分散システム全体をトレースすることを実現した。[[OpenTracing]] および [[OpenTelemetry]] の設計思想の直接の起源である。 - [[@2010__Google__Dapper - A Large-Scale Distributed Systems Tracing Infrastructure]] — [[Benjamin H. Sigelman]] ほか 8 名による Google Technical Report(2010 年 4 月)。本番 2 年超の経験・設計目標・サンプリング・API 公開によるエコシステム効果を報告。 ## テールレイテンシ耐性技術 [[Jeffrey Dean]]・[[Luiz André Barroso]] は [[@2013__CACM__The Tail at Scale]](CACM 2013)で、Google の [[Bigtable]]・クラスタレベル分散ファイルシステム・大規模ファンアウト検索システムでの実測をもとに、レイテンシばらつきの原因分類とヘッジリクエスト・タイドリクエスト・カナリアリクエスト・マイクロパーティションなどの tail-tolerant 技術を体系化した。フォールトトレラントコンピューティングとの類推により、既存のフォールトトレランス用リソースを低オーバーヘッドで転用できる点を報告する。 ## セキュリティインシデント対応へのLLM統合 Googleのdetection and responseチームは、[[@2025__SOUPS__Integrating Large Language Models into Security Incident Response]](SOUPS 2025)で、LLM(Gemini 1.5 Flash)によるセキュリティインシデント要約の自動化・支援を18名の社内セキュリティアナリストと50件の実インシデントを用いて評価した。自律的なLLM要約は人間要約に61%のケースで劣後した一方、人間がLLM出力を編集する協働モデルは人間単独の要約より77%のケースで好まれた。→ [[LLMインシデント要約]] ## インシデント分析プログラム Google SRE はプロダクション障害を横断分析するプログラムを 2014 年に立ち上げた。GQM（Goal Question Metric）フィードバックモデルを用い、全プロダクトの障害データを収集・整理・分析・還流（Socialize）するサイクルを構築した。[[Sue Lueder]]（SRE Program Manager）が SREcon 2015 でプログラムの設計・インシデントタイムライン・根本原因カテゴリ・重大度フラグを公開した。 - [[@2015__SREcon15__What Brought Us Down - Outage Trend Analysis at Google]]（[[Sue Lueder]]、2015 年 3 月 SREcon15 Santa Clara） ## TPU v1(ドメイン固有アーキテクチャの初期実装) Google は2015年から Tensor Processing Unit(TPU)を本番投入し、深層ニューラルネットワーク推論の性能・エネルギー効率を汎用 CPU 比で改善するドメイン固有アーキテクチャ(DSA)の代表例となった。[[@2019__CACM__A New Golden Age for Computer Architecture]](Hennessy と [[David A. Patterson]] による Turing Lecture 記事)は TPU v1 の内部構成を Figure 8 として紹介し、256×256 の Systolic Array 構造を持つ Matrix Multiply Unit(64K MAC/サイクル)と、DRAM ベースのキャッシュに代えてユーザー制御の 24 MB ローカルメモリを採用した設計を解説する。Google データセンターの6種の代表的推論ワークロード加重平均で、TPU v1 は汎用 CPU 比29倍の性能、80倍超のエネルギー効率を達成したと報告されている。→ [[ドメイン固有アーキテクチャ]] TPU v1 の一次資料である [[@2017__ISCA__In-Datacenter Performance Analysis of a Tensor Processing Unit]](Jouppi ほか、ISCA 2017)は、ピーク性能92 TOPS(65,536個の8ビットMAC)・28 MiBオンチップメモリという仕様と、Rooflineモデルによる6アプリ(MLP・LSTM・CNN各2種)の性能内訳、Haswell CPU比29.2倍・NVIDIA K80 GPU比15.3倍のスループット、性能/Watt(Incremental)でCPU比83倍・GPU比29倍という詳細な実測データを報告する。→ [[Google TPU]] ## ML フリート効率 Google は数千の TPU アクセラレーターからなる本番 ML フリートを Borg スケジューラーで運用しており、[[@2026__MLSys2026__Machine Learning Fleet Efficiency - Improving TPU Systems at Scale with ML Productivity Goodput]]（MLSys 2026 Industry Track）でその効率測定・最適化フレームワーク「ML Productivity Goodput（MPG）」を公開した。MPG は Scheduling Goodput × Runtime Goodput × Program Goodput に分解され、スタック全体のボトルネックを層別に特定する。全ジョブサイズで SG > 95% を達成し、非同期チェックポイント・AoT コンパイル・通信計算オーバーラップによる改善事例を報告する。→ [[ML Productivity Goodput]] / [[Borg]] ## TPUv4 スーパーコンピュータの耐障害運用 Google は 2020 年から [[TPUv4]](4096ノード・3Dトーラス型の第3世代 ML 訓練アクセラレータ)を、Google Cloud クラスタと社内ユーザー双方向けに本番運用している。中核は [[Palomar Optical Circuit Switch]](OCS)を用いた ICI(inter-chip interconnect)ファブリックのソフトウェア定義ネットワーキング(SDN)であり、64キューブ・6,144本の光 ICI リンクを48台の OCS で動的に再構成し、マシン・チップ・リンク障害を回避する。[[Borg]] クラスタスケジューラと Pod Manager・libtpunet・healthd が協調し、システム可用性 99.98%(訓練ジョブの約1%がハードウェア停止の影響を受ける)を達成する。日次故障率は TPU マシン 0.08%・ICI ケーブル 0.005%・OCS 0.04%、OCS と光ファイバのコストは pod 総資本コストの5%未満・稼働電力3%未満と報告される。([[@2024__NSDI__Resiliency at Scale - Managing Google's TPUv4 Machine Learning Supercomputer]]) ## 機械学習システムの技術的負債 [[D. Sculley]]ほか8名(Google, Inc.)は[[@2014__SE4ML2014__Machine Learning - The High-Interest Credit Card of Technical Debt]](SE4ML: Software Engineering for Machine Learning, NIPS 2014 Workshop)で、技術的負債の枠組みを機械学習システムに適用し、entanglement(CACE原則)・隠れたフィードバックループ・未宣言の消費者・データ依存性・glue code・pipeline jungles・configuration debtなど機械学習特有のリスク要因を体系化した。成熟した機械学習システムでは実際に機械学習を行うコードは最大でも5%程度で残りはglue codeになりうると報告し、データ依存性の自動アノテーション・静的解析ツールの導入により社内チームが四半期ごとに数千行の特徴関連コードを安全に削除できるようになった事例を挙げる。→ [[技術的負債]] ## インフラストラクチャ管理 Google は独自の Linux ディストリビューション「ProdNG」をソースからビルドして管理しており、ファイルレベル同期によるフリート管理方式を採用している。数千台の本番サーバーを Red Hat 7.1 から Debian ベースへ約 3〜4 年かけてライブアップグレードした経験は LISA '13 で報告された。 - [[@2013__LISA__Live Upgrading Thousands of Servers from an Ancient Red Hat Distribution to 10 Year Newer Debian Based One]]（[[Marc Merlin]]・[[Richard Gooch]] ほか、LISA 2013）— ProdNG 設計・ファイルレベル同期フリート管理・ELF バイナリパッチによる libc 差吸収・段階的 rpm→deb 移行を詳述。 ## 創業論文(検索エンジン Google の起源) Google の商用化以前、[[Sergey Brin]]・[[Lawrence Page]] は [[Stanford University]] 在籍中に大規模 Web 検索エンジンのプロトタイプを開発し、[[@1998__Computer Networks__The Anatomy of a Large-Scale Hypertextual Web Search Engine]](Computer Networks 1998、WWW7 1998 発表)として公開した。リンク構造由来のページ重要度指標 [[PageRank]] とアンカーテキスト索引化を核とし、2,400 万ページ規模のプロトタイプをクロール・索引化・検索できることを実証した。本 wiki における Google 関連の他ページ(SRE・分散システム基盤群)とは異なり、この論文は検索エンジンとしての Google の技術的起源を記録する。 ## インシデント対応レディネス訓練(DiRT / Wheel of Misfortune) Google は全社規模のインシデント対応テストプログラム Disaster Resilience Testing(DiRT)を長年運用している。Wheel of Misfortune と呼ぶ災害ロールプレイングで過去の実本番インシデントを再現し、応答者を訓練する。DiRT プログラムの初期には実行するにはリスクが高すぎるとみなされたテスト領域があったが、その領域に注力し続けることで多くは自動化され「取るに足らない」定期テストへと変わったと報告されている。テストの重心も、純技術的な問題の解決から、承認プロセスのような曖昧な人的プロセス上の問題の解決へと徐々にシフトしている。([[@2022__OReilly__Anatomy of an Incident - Chapter 2 Practicing Incident Response Readiness (Preparedness)]]) → [[カオスエンジニアリング]] / [[インシデントシミュレーション]] / [[障害注入]] > [!contradiction] DiRT の展開名表記 > [[@2022__OReilly__Anatomy of an Incident - Chapter 2 Practicing Incident Response Readiness (Preparedness)]] は DiRT を "Disaster Resilience Testing" と表記するが、DiRT プログラムを内側から解説する Google SRE 自身の一次資料([[@2022__OReillyJapan__カオスエンジニアリング - Chapter 5 Google DiRT 災害からの復旧テスト]])は本文中で "Disaster Recovery Testing" と表記する。どちらも略称は DiRT で一致し、プログラムの同一性に疑いはないが、展開名の表記が資料間で割れている。 ### DiRT プログラムの内部運用(『カオスエンジニアリング』5章、一次資料) [[Jason Cahoon]](Google SRE)による『カオスエンジニアリング ― 回復力のあるシステムの実践』5章は、DiRT の内部運用を Google SRE 自身の視点で詳述する一次資料である。DiRT は 2006 年に SRE によって開始され、クリティカルな**技術システムだけでなくビジネスプロセスにも**意図的に障害を注入する全社的プログラムとして設計された。参加はソフトウェアエンジニアリングや SRE の組織に限らず、物理セキュリティ・情報セキュリティ・データセンター運用・コミュニケーション・設備・IT・人事・金融ビジネス部門のメンバーがテストを設計・実行する点が特徴で、参加者のかなりの割合がソフトウェアエンジニアリング/SRE 組織以外に占められている。 テストは半構造化されたテンプレートに基づく計画書(ロールバック手順・既知のリスク・潜在的影響・依存関係・学びの目標を含む)から始まり、最低 2 名の外部レビュワー(うち 1 人以上は対象システムの技術的専門性を持つ)によるレビューを経て承認・スケジュールされる。実施後は「軽い振り返り」のテンプレートドキュメントで結果をまとめ、インデックス化して社内 Web UI で検索可能なアーカイブとして蓄積する。実施時の約束事として、(1) SLO を破るような影響を外部システムやユーザに与えない(セーフリストで個別免除しつつテスト全体は継続)、(2) 本番環境の緊急事態が常に DiRT の「緊急事態」より優先される、(3) 透明性のもとに実行する(メール件名・本文を「DiRT DiRT DiRT」で始め、ゾンビアタックのような風変わりなテーマを用いて実インシデントとの混同を防ぐ)、(4) コストを最小化し価値を最大化する、(5) 実際の機能停止障害のように取り組む、の 5 か条が定着している。大規模インフラテストの実施時間はサービスの[[エラーバジェット]]の残量から算出され、Borg の立ち退き率 SLO テストがその具体例として紹介される。(Source: [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 5 Google DiRT 災害からの復旧テスト]] §5.1-§5.2) ## インシデント応答組織アーキテクチャ(コンポーネント応答者 / SoS 応答者) Google は年間 2 兆超のクエリを 100 万台超のコンピュータ・8 万人超の従業員で支える技術基盤を、コンポーネント応答者と system-of-system(SoS)応答者という二層のオンコール体制で守っている。コンポーネント応答者は単一のコンポーネント・システムに専任し、深い専門知識とカスケード障害への第一線の防衛を担う。SoS 応答者はさらにプロダクト特化のインシデント対応チーム(IRT、例: Ads IRT・YouTube IRT)と、複数プロダクトにまたがる・オーナーシップが曖昧な・根本原因が広範囲なインシデントを扱う Technical incident response team(Tech IRT)に分かれる。Tech IRT のメンバーは 2 つ以上の異なるチームでコンポーネント応答者を務めた古参の Googler で構成され、24 時間 365 日のグローバルなページローテーションに参加しながら、年 2 回・2 週間の本番トレーニングと四半期ごとの実技デモを課される。この組織アーキテクチャが機能する条件として、共通プロトコル(FEMA の Incident Command System(ICS)の内部変種で、指揮・書記・広報などの役割を定義)・信頼(上級管理職ではなく現場の主題専門家に権限を与える)・敬意(エスカレーションを咎めない文化)・透明性(ポストモーテムの全社週次共有)の 4 特性を挙げる。重大度は Huge/Major/Medium/Minor/Negligible,Trivial/Test,Ignored の 6 区分で定義され、インシデント特定から解決までの目標時間は 3 日以内とされる。([[@2022__OReilly__Anatomy of an Incident - Chapter 3 Scaling Incident Management (Response)]]) → [[インシデント管理]] / [[Incident Commander]] / [[インシデント重大度評価]] ## セキュリティ危機管理: IMAGフレームワーク(『Building Secure and Reliable Systems』17章) Google のセキュリティインシデント対応チームに所属する Matt Linton は、信頼性インシデント対応に用いる IMAG(Incident Management at Google、ICS を土台とする指揮・統制・コミュニケーションの3要素フレームワーク)を、セキュリティ侵害対応にも同一の枠組みで適用できると論じる。侵害の可能性がある場面では、通常のSRE対応(先に直してから調べる)とは逆に、まず完全な調査を終えてから是正に着手するべきだとし、攻撃者に調査活動を気づかれないための運用セキュリティ(OpSec)——通信チャネルの分離・侵害端末への非ログイン・リモートフォレンジックエージェントの事前配備——を具体的に規定する。デジタルフォレンジック調査はフォレンジック・リバーシング・ハンティングの3グループに分割(シャーディング)し、長時間化するインシデントには12時間シフト上限・引き継ぎ・follow-the-sunローテーション・士気管理(食事・睡眠・ストレス発散・燃え尽き察知)を組み合わせて対応する。(Source: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 17 Crisis Management]] §Beginning Your Response, §Operational Security, §Sharding the investigation, §Handovers, §Morale) → [[危機時の指揮系統]] / [[インシデント対応時の運用セキュリティ]] / [[Incident Commander]] ## Project Aristotle と心理的安全性(『SREの探求』27章) Google 社内の「チーム開発」グループは、後に「プロジェクト・アリストテレス(Project Aristotle)」として公表されたリサーチに基づきチーム構築研修コースを開発した。同リサーチは、成功するチームであることを示す最も重要な指標が在職期間・年功序列・給与水準でなく心理的安全性(psychological safety)であることを明らかにした。[[John Looney]] は Google 時代に GFS(Google File System)をリプレースする 3 年プロジェクトの最中、バッテリー不良・ファームウェアのバグ・停電の重複によりストレージセルを丸ごと失い三日三晩の再構築を強いられたチームが意気消沈した際、マネージャーが「この3日間で過去3か月分より多くを学んだ」と指摘し祝杯を提案したことで、チームの状態が一変した経験を報告している。これは、心理的安全性を醸成する「チームがうまくいっているときにはそのことを明示する」実践の具体例として紹介される。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 27 SREにおける心理的安全性]] §27.1, §27.1.1.3) ## プライバシーエンジニアリング(『SREの探求』15章) Google のプライバシーエンジニアは、プロダクトのプライバシー上の潜在的問題を発見・解決する「防護(Guard)」、デフォルトで「正しいことをする」インフラストラクチャを構築する「強化(Strengthen)」、プライバシー上の「火事」に対応する「消火(Extinguish)」の3カテゴリで作業する。[[Betsy Beyer]] と [[Amber Yust]] は、SRE が培ってきたトイル削減・課題解決の一度きり原則・根本原因分析・関係管理・早期教育といったベストプラクティスがプライバシーエンジニアリングにそのまま応用できると論じ、信頼性の障害は修復可能だがプライバシー侵害は一般に不可逆であるという非対称性ゆえに、両者をトレードオフする場面ではプライバシー側に倒すべきだと結論づける。Google のエンジニア Lea Kissner は、プライバシーエンジニアを「ユーザーとインターネットの闇との間に立つ」存在と表現した。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 15 信頼性とプライバシーが交わるところ]] §15.1-§15.4) → [[プライバシーエンジニアリング]] ## Customer Reliability Engineering と SRE 導入判断の実務知(『SREの探求』3章) [[Luke Stone]] は 2002 年に AdSense の最初のテクニカルサポート担当エンジニアとして Google に入社し、Customer Reliability Engineering(CRE)チームの創設メンバーとして Google SRE に参加した。2014 年から Google Cloud Platform の仕事に携わり、SRE チーム新設を検討する社外の IT マネージャー・運用担当ディレクター・CTO 100 人超と面談してきた経験に基づき、「組織に SRE チームがふさわしいか」の判断基準を、SRE への動機(かっこよさ・データ駆動志向・リソースコミットメント)の妥当性という観点から論じている。効果的な SRE チームには専任メンバー・相互信頼・経営陣のバックアップ・開発チームとの物理的近接や協働という一定の環境が必要であり、既存チームに SRE というラベルを貼るだけの「名前だけの SRE」は成功しないと指摘する。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 3 なるほど、SREチームを作りたいのですね]] ch.3) → [[カーゴカルトSRE]] / [[SRE組織変革]] ## SRE 教育の一次記録: Wheel of Misfortune・Incident Manager・SRE Classroom(『SREの探求』20章) [[Laura Nolan]](元 Google SRE)は、Google が使う3種類のアクティブラーニング教材の内部運用を一次情報として記述している。Wheel of Misfortune はゲームマスター1名とオンコール担当者役1名の最小構成のロールプレイングで、Google はこの専用にダブリンの SRE 部門ビル内に円形劇場風の部屋を設計し、『スタートレック』の絶対に勝てないトレーニングシミュレーションにちなみ「コバヤシマル(Kobayashi Maru)」と呼んでいる(ホワイトボードと大型スクリーンを備え、最大規模のチームを収容できる規模)。Incident Manager はロール・アクション等のカードでインシデント管理プロセスに構造を与えるカードゲームで、SRECon Europe 2016 で実演され Google 社内でも活用された。SRE Classroom は2012年から Google の SRE(Nolan を含む)が運営する分散システム設計・キャパシティプランニングのワークショップで、USENIX LISA・SREcon・O'Reilly Velocity 等の外部カンファレンスでも開催されており、Google 社内では続けて実施すると約3日間かかる詳細版が新任 SRE 向けに用意されている。ワークショップの教材にはログ結合パイプライン Photon がよく使われる(参加者の日常業務から意図的に距離のあるシステムを選ぶことでより深い理解を促すため)。Google は最近、指導と教育を SRE の職務記述書に明示的に追加した。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 20 アクティブなティーチングとラーニング]] §20.1.1-§20.2) → [[アクティブラーニング]] / [[インシデントシミュレーション]] / [[GameDay]] この一次記録は、[[@2022__OReilly__Anatomy of an Incident - Chapter 2 Practicing Incident Response Readiness (Preparedness)]] が「DiRT プログラムの Wheel of Misfortune」として簡潔に紹介する内容を、実践者自身の視点から裏付け、かつ詳細化するものである。 ## 自動化テスト文化・レディネスレビュー・単一共有リポジトリ(『SREの探求』11章 = 『The DevOps Handbook』抜粋) [[Gene Kim]] が『The DevOps Handbook』から抜粋・編集した11章は、DevOpsコミュニティが当たり前に思う多くのプラクティスにGoogleが先駆者だったと指摘し、3つのパターンを挙げる。(1) [[Mike Bland]] の証言によれば、2000年代中頃の Google Web Server(GWS)チームは変更の困難さに苦しんでいたが、責任者 [[Bharat Mediratta]] が自動化テストを伴わない変更を受け付けない強硬路線を敷き、非公式グループ Testing Grouplet が5年かけてこの文化を全社へ伝播させた。2013年までにGoogleは1日4万行のコミット・1日5万件超のビルド・12万種類の自動化テストスイート・7,500万回の日次テスト実行という規模に達した。(2) ローンチレディネスレビュー(LRR)と引き継ぎレディネスレビュー(HRR)により、開発グループの自己管理から集中型運用グループ(SRE)への移行を、欠陥数・アラート・モニタリングカバレッジ・システムアーキテクチャ・デプロイプロセス・プロダクションハイジーンの6項目と規制・コンプライアンス評価で判定する(→ [[レディネスレビュー]])。[[Tom Limoncelli]] によれば、HRRでの承認が最も早いチームは設計段階からSREと最も早く協力していたチームである。(3) 単一の共有ソースコードリポジトリは2015年までに10億ファイル・20億行を格納し2万5,000人のエンジニア全員が使用しており、[[Rachel Potvin]]・[[Eran Messeri]]・[[Randy Shoup]] はこれを知識伝播・失敗防止・ライブラリバージョン一元管理の最も強力な仕組みと評する。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 11 DevOpsの幅広い実践現場で活用されているSREのパターン]] §11.1-§11.3) ## MLOpsケーススタディ:連続的モデルの汚染と広告クリック予測の障害(『信頼性の高い機械学習』15章) 『信頼性の高い機械学習』15章は、機密保持のためシステム名を伏せた Google 内部の2つの障害事例を、それぞれの担当者自身が寄稿している。 **連続的なMLモデルのトラフィック障害(執筆: Todd Phillips)**: 検索結果のクリック可能性を予測する連続的なMLモデルを含むシステムで、あるアプリの改善により最新クエリを再発行するコードが追加された。この改善が無関係な問題によるロールバック・再プッシュと重なるたびに重複クエリが発生し、クリックのないデータが連続的モデルの再学習用にステージングされ、モデルは世界的なクリック率が急落したと誤学習して予測値を過小評価した。アプリ担当とモデル担当が互いのシステムへの可視性を持たなかったことが原因特定を遅らせ、緩和策(ロールバック・再更新)自体がさらなる重複クエリと汚染を生んだ。最終的には緩和策を重ねることをやめ、システムが新しい世界の状態に自然に追いつくのを待つ判断が功を奏した。(Source: [[@2024__OReillyJapan__信頼性の高い機械学習 - Chapter 15 ケーススタディ：MLOpsの実践]] §15.2) **広告クリック予測モデル:データベース対現実(執筆: Daniel Papasian)**: Google の広告ターゲティングシステムは、広告表示ごとにデータベースへ行を挿入し、クリックログチームが不正クリック除去後の「クリーン」なフィードでクリックビットを更新する。ある月曜日、クリック確率の平均予測値が通常の10分の1に急落する障害が発生し、原因はクリーンなクリックフィードを生成するインフラが水曜日から日曜日まで機能停止し、モデルがこの期間の全広告表示を「クリックされなかった」と誤って学習したことにあった。クリックログチームは障害に気づいていたが、下流のMLプロセスがそのデータ完全性にどう依存しているかを認識していなかった。モデルは「クリックされる確率」ではなく「データベースにクリックとマークされる確率」を予測しているという教訓が導かれた。(Source: [[@2024__OReillyJapan__信頼性の高い機械学習 - Chapter 15 ケーススタディ：MLOpsの実践]] §15.5) ## SONiCのSDN活用: PINS(『実践SONiC入門』第2章) GoogleにおけるSONiCのユースケースはSDNであり、分散型SDNコントローラー「Orion」でデータセンターネットワークJupyterとグローバルネットワークB4を制御してきた経験を土台に、SONiCをSDN環境で活用するための[[PINS (P4 Integrated Network Stack)|PINS]](P4 Integrated Network Stack)機能を[[Open Networking Foundation]]・[[Microsoft]]・Intelと共同開発した。SDNコントローラーからの設定はP4Runtime経由でAPPL_DBに登録され、PINS関連エントリを処理するP4OrchによりASIC_DBのモデルに変換され書き込まれる。SONiCのフレームワークに統合することで、通常のスイッチ機能とGoogleのサービスに必要なP4によるSDN機能を同時に利用可能になっている。SDNコントローラーの開発・サービス統合自体が大規模プロジェクトであるため、Googleのようなハイパースケーラー以外でPINSを自社サービスに利用できるユーザーは少ないと見られるが、自社サービスに応じたSONiCの機能拡張が可能な事例として紹介されている。B4のトラフィックエンジニアリング(既出、SDNによる集中制御)とPINS(SONiCへのP4統合)は、いずれもGoogleが自社ネットワークの制御をソフトウェアで掌握するという同じ設計志向の異なる表れである。(Source: [[@2025__Gihyo__実践SONiC入門 - Chapter 2 SONiCの機能とユースケース]] ch.2 §2.2.5) ## WSCアーキテクチャ(『Computer Architecture: A Quantitative Approach』6章) Google のWSC(ウェアハウススケールコンピュータ)は電力・冷却・ネットワークの3階層で設計されている。電力は高圧送電線(110,000V超)から段階的に降圧され、ラック直上で240V ACから48V DCへ変換されたのち各サーバへ供給される。伝統的な施設規模の巨大UPSバッテリー室を持たず、ラックごとに小型UPSバッテリーを分散配置することで、ラック導入と同時にコストが発生する漸進的な投資モデルを実現している。冷却はホット/コールドアイル分離・80°F(27°C)超での機器運用・蒸発冷却塔の活用により、伝統的なチラー方式より少ないエネルギーで熱を除去する。この結果、Google WSC群15拠点の平均PUEは2008年の1.22から2017年には1.11まで改善した。ネットワークは第6世代スイッチ [[Jupiter (Google WSCネットワークスイッチ)|Jupiter]] のClosトポロジにより、ToRスイッチのオーバーサブスクリプションを3:1に抑えつつ最大二分帯域幅1.3Pbit/sを実現する。(Source: [[@2019__MorganKaufmann__Computer Architecture - A Quantitative Approach - Chapter 6 Warehouse-Scale Computers to Exploit Request-Level and Data-Level Parallelism]] §6.4, §6.6, §6.7) このWSCアーキテクチャの記述は、本ページ既出の「TPUv4 スーパーコンピュータの耐障害運用」節が扱う[[Palomar Optical Circuit Switch]]ベースのICIファブリック(TPUv4クラスタ内部の光再構成ネットワーク)とは異なる、WSC全体(ラック・アレイ・データセンター間)を対象とするネットワーク階層である。両者は「Googleが自社データセンター規模でネットワークとハードウェアを垂直統合的に設計する」という共通の設計思想を、異なるスケール(WSC全体 対 単一アクセラレータクラスタ内)で体現している。(Source: [[@2019__MorganKaufmann__Computer Architecture - A Quantitative Approach - Chapter 6 Warehouse-Scale Computers to Exploit Request-Level and Data-Level Parallelism]], [[@2024__NSDI__Resiliency at Scale - Managing Google's TPUv4 Machine Learning Supercomputer]]) ## 出典 - [[@2016__OSDI__TensorFlow - A System for Large-Scale Machine Learning]](データフローグラフで計算とミュータブルな共有状態を統一表現する機械学習システム。60チーム超が利用し複数の本番サービスに投入) - [[@2019__MorganKaufmann__Computer Architecture - A Quantitative Approach - Chapter 6 Warehouse-Scale Computers to Exploit Request-Level and Data-Level Parallelism]](§6.4, §6.6, §6.7: WSC電力・冷却・ネットワークアーキテクチャ、PUE推移) - [[@2025__Gihyo__実践SONiC入門 - Chapter 2 SONiCの機能とユースケース]](§2.2.5、PINSによるSONiC-SDN統合、P4Orchのデータフロー) - [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 17 Crisis Management]](Matt Linton、IMAGフレームワークによるセキュリティ危機対応、OpSec、デジタルフォレンジックのシャーディング、引き継ぎ・follow-the-sunローテーション) - [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 5 Google DiRT 災害からの復旧テスト]](Jason Cahoon による DiRT プログラムの一次資料。実施時の約束事5か条、セーフリスト、Borg 立ち退き率 SLO ケーススタディ) - [[@2024__OReillyJapan__信頼性の高い機械学習 - Chapter 15 ケーススタディ：MLOpsの実践]](§15.2: 連続的MLモデルのトラフィック障害。§15.5: 広告クリック予測モデルとクリックログパイプライン障害) - [[@2014__SE4ML2014__Machine Learning - The High-Interest Credit Card of Technical Debt]](技術的負債の枠組みを機械学習システムに適用、entanglement・CACE原則・glue code等のリスク要因の体系化) - [[@1998__Computer Networks__The Anatomy of a Large-Scale Hypertextual Web Search Engine]](Sergey Brin・Lawrence Page による検索エンジン Google の創業論文、PageRank の初出) - [[@2013__LISA__Live Upgrading Thousands of Servers from an Ancient Red Hat Distribution to 10 Year Newer Debian Based One]] - [[@2013__VLDB__F1 - A Distributed SQL Database That Scales]] - [[@2013__TOCS__Spanner - Google's Globally Distributed Database]] - [[@2006__OSDI__Bigtable - A Distributed Storage System for Structured Data]] - [[@2026__SIGMOD Companion__Twenty Years of Bigtable]] - [[@2026__GoogleSRE__AI in SRE - Engineering the Future of Reliable Operations]] - [[@2026__Google Cloud Blog__AI in SRE - Where Google is Deploying Agentic AI to Improve Operations]](Vertex AI → Gemini Enterprise Agent Platform リブランド、AI Insights、ADK、TimesFM の社内利用) - [[@2017__HotOS__Thinking about Availability in Large Service Infrastructures]] - [[@2019__HotOS__Nines are Not Enough - Meaningful Metrics for Clouds]] - [[@2020__NSDI__Meaningful Availability]] - [[@2023__SOSP__A Cloud-Scale Characterization of Remote Procedure Calls]] - [[@2026__MLSys2026__Machine Learning Fleet Efficiency - Improving TPU Systems at Scale with ML Productivity Goodput]] - [[@2017__arXiv__The Case for Learned Index Structures]] - [[@2025__SOUPS__Integrating Large Language Models into Security Incident Response]](セキュリティインシデント要約へのLLM統合、社内実証実験) - [[@2019__CACM__A New Golden Age for Computer Architecture]](TPU v1 の内部構成とドメイン固有アーキテクチャとしての性能・エネルギー効率評価) - [[@2017__ISCA__In-Datacenter Performance Analysis of a Tensor Processing Unit]](TPU v1 の一次資料。92 TOPS・65,536 MAC・28 MiBオンチップメモリ、Rooflineモデル、Haswell/K80比性能・電力効率の実測) - [[@2004__OSDI__MapReduce - Simplified Data Processing on Large Clusters]](map/reduce プログラミングモデルの提案、耐障害な大規模並列データ処理) - [[@2024__NSDI__Resiliency at Scale - Managing Google's TPUv4 Machine Learning Supercomputer]](TPUv4 の OCS ベース再構成性、日次故障率、システム可用性 99.98%) - [[@2013__CACM__The Tail at Scale]](レイテンシばらつきの原因分類と tail-tolerant 技術の体系化、Bigtable・分散ファイルシステム・検索システムでの実測) - [[@2022__OReilly__Anatomy of an Incident - Chapter 2 Practicing Incident Response Readiness (Preparedness)]](DiRT プログラムと Wheel of Misfortune による災害ロールプレイング、インシデント対応テストの設計手法) - [[@2022__OReilly__Anatomy of an Incident - Chapter 3 Scaling Incident Management (Response)]](コンポーネント応答者/SoS 応答者の組織アーキテクチャ、ICS 内部変種、共通プロトコル・信頼・敬意・透明性の4特性、重大度定義 Table 3-1) - [[@2022__OReillyJapan__SREエンタープライズロードマップ - Chapter 2 なぜ信頼性のためにSREというアプローチをとるのか？]](垂直スケーリングから水平スケーリングへの移行、サブリニアスケーリング、SREの組織的起源) - [[@2021__OReillyJapan__SREの探求 - Chapter 27 SREにおける心理的安全性]](Project Aristotle、GFS ストレージセル喪失からの回復エピソード) - [[@2021__OReillyJapan__SREの探求 - Chapter 3 なるほど、SREチームを作りたいのですね]](Luke Stone、CRE チーム創設、SRE 導入判断の実務知) - [[@2021__OReillyJapan__SREの探求 - Chapter 15 信頼性とプライバシーが交わるところ]](Betsy Beyer・Amber Yust、防護/強化/消火の3分類、SREベストプラクティスのプライバシーエンジニアリングへの応用) - [[@2021__OReillyJapan__SREの探求 - Chapter 20 アクティブなティーチングとラーニング]]([[Laura Nolan]]、Wheel of Misfortune・Incident Manager・SRE Classroom の一次記録、「コバヤシマル」訓練施設) - [[@2023__arXiv__The Flux Operator]]([[Aldo Culquicondor]]・[[Antonio Ojea]] が共著者。HPC ワークロードマネージャ [[Flux Framework]] を Kubernetes 内部で稼働させる Kubernetes Operator の共同開発。KubeCon Amsterdam '23 後、Culquicondor が Flux Operator を [[Kueue]] のジョブ種別として統合) - [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 2 Use Cases]](§2.3、B4 プライベートバックボーンのトラフィックエンジニアリング、リンク利用率ほぼ100%達成) - [[@2018__Impress__LeanとDevOpsの科学 - Chapter 3 組織文化のモデル化と測定、改善の方法]](Google 2015、チームパフォーマンスに関する2年間の調査研究) - [[@2018__Impress__LeanとDevOpsの科学 - Chapter 11 変革型リーダーシップとマネジメントの役割]]([[Kripa Krishnan]]による災害復旧テストのコラム、ACM Queue 2012) - [[@2018__Impress__LeanとDevOpsの科学 - Chapter 9 作業を持続可能にするデプロイ負荷とバーンアウトの軽減]](§9.2.2、「従業員の20%タイム」制度をバーンアウト軽減の好例として紹介) - [[@2018__Impress__LeanとDevOpsの科学 - Chapter 16 ハイパフォーマンスを実現するリーダーシップとマネジメント]](表16.1、Googleの20%タイム制度をリーダーシップのプラクティスとして再引用) - [[@2018__Impress__LeanとDevOpsの科学 - Chapter 14 アンケート調査を採用する理由]]([Google 2015]をアンケート調査でしか測定できない知見の例として再引用) - [[@1998__TechReport__The PageRank Citation Ranking - Bringing Order to the Web]](Google をフルテキスト検索エンジンとして言及し、PageRank をそのランキング要因の1つとする([BP])) ## チームパフォーマンスの調査研究(Accelerate 3章) Googleは社内でトップレベルのパフォーマンスを示すチームの間に共通の要因がないかを模索するべく2年間の調査研究プロジェクトを開始し、社員を対象に200件超のインタビューを行い、社内で活動中のチーム180超について250超の特徴を調べた([Google 2015])。有能なチームを生む主要因として「個々のメンバーの素養の総計」が浮かび上がるものと担当者は予想していたが、実際には「チームの個々のメンバーの素養よりも、各メンバーが他の関係者といかにやり取りし、作業をどう構成し、チームに対する自身の貢献をどう捉えるか」のほうが重要という結果が出た([Google 2015])。『LeanとDevOpsの科学』の著者らは、Westrumモデルを技術系組織に応用した自らの調査研究(組織文化がソフトウェアデリバリのパフォーマンスと組織のパフォーマンスを予測できるという結果)と、このGoogleの調査研究とが「まさに同じ考えで行われた」ものとして符合すると位置づける。(Source: [[@2018__Impress__LeanとDevOpsの科学 - Chapter 3 組織文化のモデル化と測定、改善の方法]] §3.4) 第14章「アンケート調査を採用する理由」は、アンケート調査でしか測定できない事柄がある根拠として同じ[Google 2015]を再度引用し、「組織文化は技術・組織パフォーマンスの予測指標であり、パフォーマンスのアウトカム(デプロイの頻度、リードタイム、MTTR、変更失敗率)の予測指標である」こと、「チームのダイナミクスと心理的安全性がチームのパフォーマンスを理解する上で最重要である」ことを示す調査研究として位置づける。(Source: [[@2018__Impress__LeanとDevOpsの科学 - Chapter 14 アンケート調査を採用する理由]] §14.5) ## 災害復旧テストによるチーム相互の関係構築(Accelerate 11章) 『LeanとDevOpsの科学』第11章のコラムは、Googleのクラウドオペレーションの責任者[[Kripa Krishnan]]が管理する災害復旧テストを、部門横断型の協働を促す事例として紹介する。多くの大手テクノロジー企業は、コンピュータシステムが自然災害や人為災害などで機能停止した場合をシミュレートしたり、あらかじめ計画したとおりに災害状況を創出して災害復旧のテストを実施したりしており、この場合チームはサービスのレベルを維持もしくは復活させるために一丸とならなければならない。Krishnanは、テストが成功するには組織がシステムやプロセスの障害を学習手段と見なすことから始めなければならないとし、テストをデザインするにあたり通常は共同作業することがない複数のグループのエンジニアが必然的に動員されるよう留意したと述べる。そのため万一壊滅的な状況になった場合でも、こうしたエンジニアたちの間ですでに強力な協力関係が形成されていることになる。(Source: [[@2018__Impress__LeanとDevOpsの科学 - Chapter 11 変革型リーダーシップとマネジメントの役割]] §11.3 p.147-148、ACM Queue 2012) ## 従業員の20%タイム制度とバーンアウト軽減(Accelerate 9章) 『LeanとDevOpsの科学』第9章は、リーンマネジメントが作業担当者に自身の作業を改善するための(時間も含めた)リソースを提供することの好例として、Googleの「従業員の20%タイム」を挙げる。これは従業員が自分の好きなプロジェクトに対して週の勤務時間の20%を使える制度であり、就業時間内に付加価値のある斬新かつ創造的な仕事をこなす余裕を生み、「この種の作業は勤務時間外に担当者が行うことを期待するのみ」といった事態に終止符を打つ効果を持つとされる。同章は、重症のバーンアウトと強い相関関係にある組織的要因の1つとして「組織のパフォーマンス」を挙げ、20%タイムのような制度がその具体例として位置づけられる。(Source: [[@2018__Impress__LeanとDevOpsの科学 - Chapter 9 作業を持続可能にするデプロイ負荷とバーンアウトの軽減]] §9.2.2 p.116-117) この一次記録は、[[@2022__OReillyJapan__カオスエンジニアリング - Chapter 5 Google DiRT 災害からの復旧テスト]]が[[Jason Cahoon]]の視点から詳述するDiRTプログラムと同じ「災害復旧テストによる部門横断的な準備」という主題を、2012年時点(本コラムの原出典ACM Queue)から独立に裏付ける、より早期の一次資料である。 『LeanとDevOpsの科学』第16章(ING Netherlandsの事例研究)の表16.1は、リーダーシップのプラクティスの1つとして「創造力開発のための予算と時間を確保する(Googleの20%を目標に)」を挙げ、本書調査研究がパフォーマンスとの相関を示したプラクティス(*印)の1つに位置づけている。第9章がバーンアウト軽減の好例として紹介したのと同じGoogleの20%タイム制度が、第16章では別の著者(Steve Bell・Karen Whitley Bell)によりリーダーシップ実践のベンチマークとして再度引用されている。(Source: [[@2018__Impress__LeanとDevOpsの科学 - Chapter 16 ハイパフォーマンスを実現するリーダーシップとマネジメント]] ch.16 表16.1 p.225) ## ホスト輻輳制御研究(SIGCOMM 2023) [[Arvind Krishnamurthy]]([[Google]] & [[University of Washington]])は、[[Cornell University]] の [[Saksham Agarwal]]・[[Rachit Agarwal]] と共に[[@2023__SIGCOMM__Host Congestion Control]](ACM SIGCOMM 2023)を発表した。ネットワークファブリックだけでなくNIC-CPU/メモリ間のホストネットワーク内で発生する「ホスト輻輳」を検知・応答する輻輳制御アーキテクチャ [[ホスト輻輳制御|hostCC]] を提案し、Linuxカーネルモジュールとして実装した。(Source: [[@2023__SIGCOMM__Host Congestion Control]])