# 収束型システム管理 ## 定義 収束型システム管理とは、システムの現在状態を、ポリシーが定める「理想状態」へ繰り返し近づけ続ける調整的(regulative)な営みとしてシステム管理を捉える考え方である。[[Mark Burgess]] は CFEngine の実装で用いた「convergence(収束)」概念(ポリシーの再実行のたびにホスト状態が理想状態へ近づき、理想状態においては操作が冪等になる)を、[[@2000__LISA__Theoretical System Administration]](USENIX LISA 2000)において一般理論へ拡張した。同論文は、システムの状態を n 次元格子上の点として表現し、理想状態を格子の原点に置くことで、任意の偏差ベクトル d に対する「補正操作の候補数」H(d) = (Σj dj)! / Πk(dk!) がユークリッド距離に対して階乗的に増大する一方、実際に必要な補正操作数自体は距離に対して線形にしか増えないことを示した。この定式化により、「システムを理想状態の近傍に保ち続けることが、遠く離れた状態から回復するより本質的に安価である」という主張が数理的に基礎づけられる。(Source: [[@2000__LISA__Theoretical System Administration]]) 中心定理(Burgess 2000 が引用する自身の先行研究 [3] の要約): 十分に完全なシステムポリシーの仕様は「理想平均状態」の概念を導く。理想平均状態は時間とともに(ゆっくりと)劣化する。システム管理の目的は、システムをできるだけこの理想状態に近く保つことである。(Source: [[@2000__LISA__Theoretical System Administration]]) ## 横断的知見 - 本 concept は当初単一ソース([[@2000__LISA__Theoretical System Administration]])のみに基づいていたが、2 ソース目として [[@2021__OReillyJapan__SREの探求 - Chapter 24 イミュータブルなインフラストラクチャとSRE]] が「収束を諦めて交換に切り替える」実務側の反例を提供した(詳細は次項)。今後も Kubernetes の reconciliation loop、Terraform/Ansible の宣言的インフラ管理、Chaos Engineering の定常状態仮説など、同じ「望ましい状態への収束」を扱う現代文献が ingest され次第、横断的な比較を蓄積する。 - **収束型の設定管理(Chef・Puppet)が動的スケーリング下で破綻する現象は、収束理論(Burgess 2000)が前提とする「理想状態はゆっくり劣化する」という仮定が崩れる具体例である**: Burgess(2000)の中心定理は「十分に完全なシステムポリシーの仕様は理想平均状態の概念を導き、理想平均状態は時間とともに(ゆっくり)劣化する」ことを前提に、理想状態近傍での補正コストが偏差に対して線形にしか増えないことを数理的に基礎づける。[[@2021__OReillyJapan__SREの探求 - Chapter 24 イミュータブルなインフラストラクチャとSRE]] は、この前提が崩れる具体的な運用状況を報告する——大規模 Web 運用でクラスタが動的にスケーリングし新しいノードが頻繁に追加される環境では、各ノードは「理想状態近傍から補正する」のではなく「ゼロの状態から理想状態まで毎回到達する」ことを求められ、ブート時に別ツール(Chef・Puppet)を実行して一から設定する構造そのものが時間的コストのボトルネックになる(ch.24 §24.1)。さらに ch.24 は「設定管理システム自体が完璧ではなく、ときどき実行に失敗する」(§24.5)と述べており、これは Burgess の数理モデルが暗黙に仮定する「補正操作は常に理想状態への到達に成功する」という前提が実務では保証されないことを示す。イミュータブルなインフラストラクチャは、この「毎回ゼロから到達」問題と「補正の失敗」問題の両方を、補正(convergence)ではなく交換(replacement)によって迂回する設計として位置づけられる——同じ「望ましい状態をどう保つか」という問題に対し、Burgess は収束というアプローチを理論的に正当化し、ch.24 は収束が破綻する条件下で交換という別のアプローチが選ばれる実務的経緯を記す。(Source: [[@2000__LISA__Theoretical System Administration]], [[@2021__OReillyJapan__SREの探求 - Chapter 24 イミュータブルなインフラストラクチャとSRE]] §24.1, §24.5) - **Burgess 自身が、収束理論の数理的定式化(2000)に先立ち著書(2004)の中で同じ主張を非形式的な「メタ原理」として提示している**: *Principles of Network and System Administration* 第1章(2004、第2版)は、[[@2000__LISA__Theoretical System Administration]] が発表された 4 年後に出版された同著者の教科書だが、Ch.1 §1.9 は数式を一切使わずに同じ主張を三つの「メタ原理」として述べる——Principle 1(ポリシーが基盤)は理想状態の仕様に、Principle 2(予測可能性)は「システム管理の最高次の目標は予測可能な系へ向けて働きかけることであり、これが信頼性・信頼・安全性の基盤になる」として収束理論が数理的に基礎づける「理想状態近傍にとどまることの価値」に、Principle 3(拡張性)は「ポリシーに従って成長する系」として理想状態の維持がスケールでも保たれるべきという要請に、それぞれ対応する。教科書という媒体では格子モデルや H(d) の階乗爆発の証明は現れず、「予測可能性には限界がある」「誤差の範囲内でしか語れない」という定性的な注意書きにとどまる。同一著者が同じ主張を論文(数理的定式化)と教科書(非形式的なメタ原理)という異なる抽象度で独立に提示している点で、収束理論が単発の論文結果ではなく著者の一貫した理論的立場であることが確認できる。(Source: [[@2000__LISA__Theoretical System Administration]], [[@2004__Wiley__Principles of Network and System Administration - Chapter 1 Introduction]] §1.9) - **同著者(2004)の第3章が与える「ポリシー」の正式な定義(Definition 2)は、収束理論の中心定理が前提とする「十分に完全なシステムポリシー」という語に、初めて内実を与える**: [[@2000__LISA__Theoretical System Administration]] の中心定理は「十分に完全なシステムポリシーの仕様は理想平均状態の概念を導く」と述べるが、「ポリシー」自体の定義には立ち入らない。同じ著者による教科書第3章は、ポリシーを「インフラの青写真・生産目標・行動の制限・刺激-応答チェックリストの4要素からなる、目標と願望を codify した声明」(Definition 2)として定義し、「ポリシーが定める状態は静的な凍結された設定ではなく動的な均衡(dynamical equilibrium)である」と明示する。この「動的な均衡」という表現は、本 concept の定義部が述べる「理想状態はゆっくり劣化し、システム管理はその近傍にシステムを保ち続ける」という主張と字面のレベルで一致する。第1章のメタ原理(既出の横断的知見)が収束理論を「予測可能性」という上位目標として非形式的に再提示したのに対し、第3章は収束理論が暗黙に前提する「ポリシー」という入力概念そのものを事後的に定義しており、両章は収束理論の異なる構成要素(目標/入力)をそれぞれ補完している。詳細な定義は [[ポリシー]] を参照。(Source: [[@2000__LISA__Theoretical System Administration]], [[@2004__Wiley__Principles of Network and System Administration - Chapter 3 Networked communities]] §3.2) - **第6章§6.7は、それまで別々の論文に分かれていた収束理論(LISA 2000)と免疫モデル(Computer Immunology 1998)を、著者自身の手で「競合(competition)・免疫(immunity)・収束(convergence)」という単一の三つ組に統合し直す**: 本ページはこれまで [[@2000__LISA__Theoretical System Administration]] の収束理論と、一方向参照のみで扱ってきた [[papers/1998__LISA__Computer Immunology|papers/1998__LISA__Computer Immunology]] の免疫モデルを、別個の理論的貢献として記録してきた。しかし *Principles of Network and System Administration* 第6章§6.7は、この2つを生物学的な負のフィードバック調整原理という共通の枠組みの中に位置づけ直す——競合は「系のある部分が制御不能に成長すると対抗物の産生を促す」という捕食者-被食者的なゲーム構造、免疫はその対抗物を生み出す自己修復の主体、収束はその自己修復が向かう先(理想状態への漸近、かつ理想状態で活動が止まるという性質)を指す、という三層構造として整理される。さらに免疫モデルの起源を von Neumann(1948)にまで遡らせ、IBM の Kephart(1994)・Forrest ら(免疫学的ウイルス検知)の系譜と Burgess 自身の統計力学的な系統(1998・2000年論文)が独立に同種の着想へ収束したと位置づける。これは、本ページがこれまで「2000年の論文で数理的に定式化され、2004年の教科書ではメタ原理として非形式的に再提示された」という一対一対応で記録してきた収束理論の系譜に、免疫モデルという第三の理論的支柱を明示的に接続する記述であり、教科書という媒体が単に理論の再提示にとどまらず、複数の先行論文を統合する役割を担っていることを示す。(Source: [[@2000__LISA__Theoretical System Administration]], [[@2004__Wiley__Principles of Network and System Administration - Chapter 6 Models of network and system administration]] §6.7) - **収束批判への正面からの応答(Traugottのcongruence論)は、本ページが既に記録してきた「収束が破綻する条件」を、著者自身が2004年時点で先取りして自覚していたことを示す**: 本ページは [[@2021__OReillyJapan__SREの探求 - Chapter 24 イミュータブルなインフラストラクチャとSRE]] が2020年代の実務から報告する「動的スケーリング下での収束型設定管理の破綻」を、収束理論の前提(理想状態はゆっくり劣化する)が崩れる実例として記録してきた。ところが第6章§6.7では、Burgess自身が2004年の時点で既に同種の批判を認識し、名指しで応答している——Traugottは「利用者の規律に十分な期待ができない以上、収束による均衡任せの管理では予測可能性を保証できず、仕様から逸脱したホストは一からワイプして再構築すべきだ」と主張し、これを収束と対比させて**congruence**と呼んだ。Burgess(収束派)は「可換な原子的操作の系列によって収束を保証することこそ、状態を保証しうる唯一信頼できる方法だ」と反論する。ch.24のイミュータブルインフラストラクチャ(交換によって収束を迂回する設計)は、この2004年時点のcongruence論が実務レベルで具体化・普及した後継と読める——収束 対 交換という対立軸は2020年代に初めて生まれたのではなく、収束理論の提唱者自身が自著の中で2004年に既に一度対峙していた論争の再燃である。(Source: [[@2004__Wiley__Principles of Network and System Administration - Chapter 6 Models of network and system administration]] §6.7, [[@2021__OReillyJapan__SREの探求 - Chapter 24 イミュータブルなインフラストラクチャとSRE]] §24.1) - **第4章のホスト単体レベルでの「再現性の原理」は、収束理論が暗黙に要求する前提条件を、ネットワーク全体の理論より手前の個別ホストの現場から補強する**: 本ページがこれまで扱ってきた収束理論(Burgess 2000)・免疫モデル・congruence論争(第6章)は、いずれもネットワーク全体でホスト群をどう理想状態へ収束させるかという上位のモデル論を扱う。これに対し[[@2004__Wiley__Principles of Network and System Administration - Chapter 4 Host management]]第4.8節「Logistics of kernel customization」は、個々のホストのカーネルカスタマイズが「OS配布物を変更しない」原則と「複数ホスト間の再現性」原則の両方と衝突しやすいと指摘し、実務的な解決策として「1台のホストでコンパイルし、共通のハードウェア基盤を持つ類似ホスト群へ配布する」こと、すなわち標準化されたハードウェアの上でのみ標準化されたカーネルが成立するという条件を示す。これは収束理論が数理的に前提とする「ホスト群が同じ理想状態へ収束できる」という仮定そのものが、ハードウェアの均一性という現場レベルの物理的条件に依存していることを具体的に裏づける——第4章は理論の抽象度を持たないが、収束が成立するための地に足のついた必要条件を補完する。また同章§4.6.8「Cloning systems」が挙げるディスクイメージの物理コピー・tarアーカイブによるホストの複製という2004年時点の手法は、パッケージテンプレートやNFS共有と並ぶ選択肢の一つとして提示されており、[[イミュータブルインフラストラクチャ]]が2020年代に整理する「ベースイメージの交換」という発想の技術的前身と読める——ただし第4章はこれを収束/交換という対立軸としては提示せず、単なる作業効率化の選択肢として並列に扱っている点で、後年の理論的な対立軸化(第6章のTraugott論争、ch.24)とは距離がある。(Source: [[@2004__Wiley__Principles of Network and System Administration - Chapter 4 Host management]] §4.6.8, §4.8「Logistics of kernel customization」) - **第7章は、収束を「原因の制御」「宣言的記述」「冪等な操作」という3つの実装原理へ分解し、これまで本ページが扱ってきた抽象的な収束理論(数理モデル・メタ原理・三つ組)を実装の層まで具体化する**: 本ページがこれまで記録してきた収束理論(第1・6章のメタ原理と統合、Burgess 2000の数理モデル)は、いずれも「なぜ収束が理想状態維持のコストを下げるか」を理論のレベルで論じる。*Principles of Network and System Administration* 第7章は、同じ収束を「どう実装するか」という設計判断のレベルへ降ろす。第一に §7.2 の「原因の制御 対 症状の制御」(Principle 41)という方法論的対立は、収束が理想状態そのものへ働きかける(原因の制御)のに対し、場当たり的な対症療法は理想状態からの逸脱の兆候だけを消す(症状の制御)という区別として読める——収束型システム管理が要求するのは常に前者である。第二に §7.4 の宣言的言語(declarative language)は、収束を実現する記述様式そのものを与える。cfengine は「初期状態から最終状態への手続き」でなく「最終状態(理想状態)だけ」を記述し、言語自身の標準手法群がそこへ至る経路を評価する——これは第6章・Burgess(2000)が「理想状態への収束」として抽象的に述べてきたことの、プログラミング言語設計としての具体化である。第三に §7.11 は cfengine の動作原理を「実行のたびに何かをすべきかを判定し、何もすべきことがなければ何もしない」という一文に凝縮する。これは收束理論の中心定理(理想状態近傍では補正コストが小さい)を、個々の実行における冪等性(idempotency)という具体的なプログラム的性質として言い換えたものであり、収束が単なる「理想状態への漸近」という数学的傾向ではなく、実装レベルでは「差分がなければ何もしない」という具体的なアルゴリズム上の判断であることを明らかにする。(Source: [[@2004__Wiley__Principles of Network and System Administration - Chapter 7 Configuration and maintenance]] §7.2, §7.4, §7.11) - **最終章§14.3が示す「中央集権的ルータ制御からルータの自律的協調(swarm intelligence)への移行」は、第6章§6.3のモデル類型論(スター型→メッシュ型→ピアツーピア型)が示す分散化の軌道を、著者自身がインターネット全体の実例で追認したものである**: 第6章は cfengine を「メッシュ・トポロジで各ホストが部分的自律を持つ」モデル4に位置づけ、中央集権・強制一元化のスター型(モデル1・2)から中央を持たないピアツーピア型(モデル6)までの6段階の分散化軸を提示していた(既出の横断的知見)。第14章§14.3は、この同じ分散化の軸をインターネットのルータ網という別の実例で語り直す——「ルータは当初中央権威によって制御されると考えられていたが、インターネットの規模はすぐに中央集権モデルの限界を超え、中央SNMP管理のようなボトルネック設計は廃れた。ルーティングが成功したのは、ルータどうしがポリシーの制約下で自律的に協調し経路を構築できたからだ」と述べ、これを swarm intelligence と呼ぶ。本ページが第6章から記録してきた「システム管理の分散化はホスト管理モデルの選択の問題である」という論点に対し、第14章は同じ著者の手で「分散化・自律化はシステム管理という営みそのものの将来の進化方向でもある」という予測を重ね書きし、モデル論(第6章)を将来展望(第14章)へ接続している。(Source: [[@2004__Wiley__Principles of Network and System Administration - Chapter 6 Models of network and system administration]] §6.3, [[@2004__Wiley__Principles of Network and System Administration - Chapter 14 Summary and outlook]] §14.3) - **最終章§14.4の「次世代OSは自己分析・自己修正能力を持つが、システム管理の中核原理は変わらない」という予測は、本ページが数理モデル(第2000年論文)・メタ原理(第1章)・実装原理(第7章)として積み上げてきた収束理論を、著者自身が将来の自動化の到達点として位置づけ直したものである**: 本ページはこれまで、収束理論がBurgessの一貫した理論的立場であることを、論文(数理的定式化)・教科書第1章(メタ原理)・教科書第7章(宣言的言語・冪等性という実装原理)という3つの異なる抽象度の記述の一致から確認してきた。教科書の最終章§14.4は、この理論そのものの将来を予測する——「システム管理の日々の定型業務は技術の向上とともに人手から機械へ置き換わり続けるが、システム管理の中核原理は変わらず、システム管理者の職務内容が変わるにとどまる」。これは、第7章が「収束」を「差分がなければ何もしない」という冪等な実行判断として実装レベルまで具体化した仕組みが、著者の見立てではさらに「自己分析・自己修正」という形で自動化されていく方向にあり、その自動化が進んでも収束理論が前提とする「理想状態へ向けて系を保つ」という中核原理自体は変わらないという予測として読める。ただし第14章はこの予測を定性的な見通しとして述べるにとどまり、第7章のような実装レベルの具体化(宣言的言語・クラスベーススケジューリング等)には踏み込んでいない。(Source: [[@2004__Wiley__Principles of Network and System Administration - Chapter 7 Configuration and maintenance]] §7.11, [[@2004__Wiley__Principles of Network and System Administration - Chapter 14 Summary and outlook]] §14.4) - **DevOpsサーベイ(Leite et al. 2019)の「コンテナ化 対 継続的構成収束」というツール分類上の対立は、本ページが ch.24 から記録してきた「収束 対 交換」という抽象的な対立軸を、Chef・Puppetの具体的な言語構成(idempotentなリソース宣言)のレベルで裏づける**: 本ページは [[@2021__OReillyJapan__SREの探求 - Chapter 24 イミュータブルなインフラストラクチャとSRE]] を典拠に、動的スケーリング下で収束型設定管理(Chef・Puppet)が破綻し、交換(イミュータブルなイメージ)へ切り替わる実務的経緯を記録してきた(既出の横断的知見)。[[@2019__ACM CSUR__A Survey of DevOps Concepts and Challenges - Chapter 6 Toolset]] §6.5は、これとは独立にDevOpsツールの分類という観点から同じ対立を論じる——Chefのpackageリソース(実行時にのみ具体的なパッケージマネージャへ解決)・Puppetのserviceリソース(起動コマンドでなく望ましい最終状態「running」を宣言)という言語構成そのものが収束理論の冪等性(第7章§7.11、本ページ既出)を実装する具体例であり、この収束型戦略が[[Docker]]に代表されるコンテナ化(環境全体をビルド時に生成し新バージョンごとに破棄・再構築する交換戦略)と「一見補完的だが実際は競合する」関係にあると明記する。さらにZhu et al.の実証結果(lightly baked imagesはheavily baked imagesより外部リソース依存が多く信頼性が低い)は、ch.24が定性的に述べる「収束の失敗しやすさ」に、デプロイ時の外部リソース依存という具体的な原因を与える。ch.24が実務者の経験談として「収束から交換へ」の転換を描いたのに対し、DevOpsサーベイは学術的なツール分類・実証研究の引用として同じ転換を独立に裏づける。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 24 イミュータブルなインフラストラクチャとSRE]] §24.1, §24.5, [[@2019__ACM CSUR__A Survey of DevOps Concepts and Challenges - Chapter 6 Toolset]] §6.5) - **Evard(1997, LISA)の計算機ライフサイクルモデルは、Burgess(2000, LISA)が3年後に定式化する収束理論の「Configured/理想状態」「Entropy/劣化」という語彙を、形式化以前の実務観察として先取りしている**: Evard は New・Clean・Configured・Unknown・Off の5状態と Build・Initialize・Update・Entropy・Debug・Rebuild・Retire の7プロセスからなるライフサイクルモデルを提案し、「計算機のライフサイクルにおける努力のほぼ全てはConfigured状態に到達し、そこに留まり続けようとすることに費やされる」と述べる。この「Configured」は Burgess(2000)の「理想状態(ideal state)」と同じ対象を指し、Evard の「Entropy」(構成が崩れて Unknown 状態へ至る過程)は Burgess の「理想平均状態はゆっくり劣化する」という前提と同じ現象の別の呼び方である。ただし Evard の記述は状態遷移図による定性的なモデルに留まり、Burgess のようなn次元格子上の距離・補正操作候補数という数理的定式化は持たない。Evard 自身も「システム管理には抽象化の理論が不足している」と課題提起するに留め、理論構築は将来課題として示唆するだけである。両論文は同じ LISA コミュニティの3年隔たる発表であり、Evard の実務観察の蓄積が、Burgess の理論化を必要とする土壌の一部だったと読める。(Source: [[@1997__LISA__An Analysis of UNIX System Configuration]], [[@2000__LISA__Theoretical System Administration]]) - **Evard(1997)の変化量の予想(change magnitude conjecture)C(U)≥kC(G)≥k²C(E)≥k³C(I)は、Burgess(2000)の数理モデルとは独立に、ファイル改訂頻度の実測データから導かれた経験則である**: Evard は Northeastern University の4年分の構成ファイル改訂データ(passwd 3913回・amd.home 3241回・netgroup 2000回超に対し、環境全体を定義するファイルは数回〜数十回)から、ユーザ単位(U)・グループ単位(G)・環境単位(E)・初期化単位(I)のファイル集合について変化頻度が桁単位で減衰するという予想を導いた。Burgess(2000)が格子モデル上での「理想状態からの距離」に対する補正操作候補数の階乗的増大を数理的に導出したのとは対照的に、Evard の予想は実測データからのボトムアップな一般化であり、著者自身「まだ形式的に証明されていない」「集合のより厳密な定義が必要」と明記する。両者はともに「変化には範囲(scope)に応じた構造がある」という直観を共有するが、Evard は経験的観測、Burgess は公理的モデル化という異なる方法で接近しており、この2つのアプローチが後年どう統合されたか(あるいはされなかったか)は本 wiki の現ソース群では未検証である。(Source: [[@1997__LISA__An Analysis of UNIX System Configuration]], [[@2000__LISA__Theoretical System Administration]]) - **一次資料が発見された: Traugottのcongruence論は、Burgessの著書(2004)を介した伝聞ではなく、著者自身によるLISA 2002論文で最初に定式化されていた**: 本ページはこれまで、Traugottのcongruence批判をBurgessの著書第6章§6.7が伝える二次的な記述としてのみ記録し、「両者を直接つなぐ文献はまだない」と未解決の問いに残していた。[[@2002__LISA__Why Order Matters - Turing Equivalence in Automated Systems Administration]](Traugott and Brown, LISA 2002)がその一次資料である。同論文は、Burgessの著書が要約する「congruence対convergence」の対立を、実は2004年の教科書出版に先立つ2002年の時点で、独立した理論的枠組み(発散・収束・合同の3分類、UNIXホストとチューリング機械の等価性)として既に完成させていた。したがって未解決の問いへの答えは判明した——実務コミュニティでの再発見ではなく、Traugottの議論はBurgessの著書出版より2年早く、独立した論文として公表・議論されていたものである。Traugott自身の論証では、congruenceが優位である根拠は収束理論(補正コストが理想状態近傍で線形)への反論ではなく、**変更順序の全数テストがN!で組合せ爆発する**という別のコスト論証(Crandom > Cpredict > Cpartial > Ctest)であり、Burgessの数理モデル(格子上の距離とH(d)の階乗)とは異なる角度から同じ「決定的な単一経路のほうが低コスト」という結論に至っている。(Source: [[@2002__LISA__Why Order Matters - Turing Equivalence in Automated Systems Administration]], [[@2004__Wiley__Principles of Network and System Administration - Chapter 6 Models of network and system administration]] §6.7) - **congruence志向のISconfとconvergence志向のcfengineを「対立するパラダイム」ではなく「補完的な機能」として統合した実装例が見つかった**: 本ページはこれまでTraugott(2002)のcongruence論とBurgess(収束派)の理論的対立(第6章§6.7)を、二者択一の論争として記録してきた。[[@2003__LISA__ISconf - Theory, Practice, and Beyond]](Luke Kanies, LISA 2003)は、congruence志向のCMSであるISconf(Traugottの前身論文[[@1998__LISA__Bootstrapping an Infrastructure]]に由来)の長年の実運用者という立場から、ISconfのhost typeと[[cfengine]]のclassのフォーマットがほぼ同一であることを利用し、パーサを書き換えて両者を相互接続する統合を実装した。統合後は、ISconfが持つ「ホストへの作業列の割り当て」という強みとcfengineの「ファイルパーミッション・プロセス監視などの豊富な機能」が補完し合い、ISconfのstanzaがホストtype単位でしか部分展開できないというテスト上の制約も、cfengineのclassによる柔軟なグルーピングで緩和された。これは、Traugott(2002)とBurgess(2004)が理論のレベルで対立させてきたcongruenceとconvergenceが、実装のレベルでは直交し両立しうることを示す実務的な反例であり、理論的対立と実務的統合が同じ2つのツール(ISconf/cfengine系譜)をめぐって別々に展開してきたことを示す。(Source: [[@2003__LISA__ISconf - Theory, Practice, and Beyond]]) ## 未解決の問い - Burgess(2000)の格子モデル(離散的な primitive 操作の n 次元空間)は、今日の宣言的インフラ管理(Kubernetes Operator パターン、Terraform state)の理論的定式化とどこまで対応するか。現代の reconciliation loop 実装は、この論文の「補正操作候補数の指数爆発」問題をどのように回避しているか(例: 差分計算による決定的な単一の補正パスの選択)。 - 理想平均状態 S*(t) が「ゆっくり劣化する」という前提は、現代のマイクロサービス環境(頻繁なデプロイ、動的なオートスケーリング)でも成立するか。ch.24 が報告する「動的スケーリング下での収束型設定管理の破綻」は、この前提が崩れる具体的な実務証拠として扱えるが、崩れる閾値(デプロイ頻度・スケーリング速度がどの程度になると収束が破綻するか)は定量化されていない。 - CFEngine の convergence 概念と、Chaos Engineering における「定常状態(steady state)」概念は、独立に発展したのか、それとも系譜上のつながりがあるか。 - Kubernetes の reconciliation loop はイミュータブルなコンテナイメージの交換と収束型のコントローラループを併用する。これは「収束 対 交換」という ch.24 が描く二項対立を統合した第三の設計と言えるか、それとも交換(イメージ)と収束(Pod 数・配置)という異なるレイヤーへの責務分離に過ぎないか。 - 第6章§6.7が提示する「競合・免疫・収束」の三つ組のうち、本ページはこれまで免疫と収束の2要素を個別に扱ってきたが、「競合(competition、捕食者-被食者的なゲーム構造)」という第三の要素は本ページにまだ独立に展開されていない。競合の視点(対抗物の産生と均衡)は、SREのエラーバジェットやカオスエンジニアリングのような「意図的に系へストレスを与えて均衡を探る」実践とどう対応するか。 - 第4章が示す「標準化されたハードウェアの上でのみ標準化されたカーネルが成立する」という条件は、収束理論の数理モデル(Burgess 2000)には明示的に現れない暗黙の前提である。この種の物理層の均一性が崩れた場合(異種ハードウェア混在環境)、収束理論の格子モデルはどう修正されるべきか。 - 第14章§14.4が予測する「自己分析・自己修正能力を持つ次世代OS」は、収束理論の実行主体を人間の管理者から系そのものへ移す方向の予測と読めるが、著者はこれを具体的な仕組み(第7章の宣言的言語・冪等性のような)としては述べていない。この予測は、後年のオートノミックコンピューティング(IBM, 2001年前後)や self-healing systems の議論とどこまで内容が重なるか、独立の系譜か。 - DevOpsサーベイ(Leite et al. 2019)§6.5は「コンテナ化対継続的構成収束の論争は文献上十分に検討されていない」と明記する。本ページが積み上げてきた収束理論(Burgess 2000・2004年教科書)は、Chef・Puppetの収束型設定管理が具体的にどのような数理的条件下でコンテナ化(交換)より優位/劣位になるかを定量的に説明できるか。Zhu et al.のlightly/heavily baked images比較は実証的な傍証を与えるが、本ページの収束理論(格子モデル・H(d)の階乗爆発)と直接接続する定式化はまだない。 - Evard(1997)の変化量の予想(C(U)≥kC(G)≥k²C(E)≥k³C(I))とBurgess(2000)の格子モデルは、後続の構成管理研究(cfengine 3以降、宣言的インフラ管理)でどちらか一方に統合されたか、それとも別系統のまま並存しているか。 - Traugott(2002)のN!組合せ爆発によるコスト論証(Crandom > Cpredict > Cpartial > Ctest)と、Burgess(2000)の格子モデルによるコスト論証(H(d)の階乗爆発)は、数学的に同値な議論の言い換えなのか、それとも独立した2つの論証が同じ結論(決定的な単一経路が最小コスト)に収斂したのか。本wikiではまだ形式的に比較されていない。 ## 関連 - [[@2000__LISA__Theoretical System Administration]] — 本概念の初出。CFEngine の convergence を一般理論化した中心論文。 - [[Mark Burgess]] — CFEngine の作者であり、本概念の提唱者。 - [[SREの工学化]] — 収束型システム管理は、坪内(2024)が言う「技芸から工学へ」の移行の具体的な数理実践例として位置づけられる。 - [[イミュータブルインフラストラクチャ]] / [[@2021__OReillyJapan__SREの探求 - Chapter 24 イミュータブルなインフラストラクチャとSRE]] — 収束(convergence)を諦め交換(replacement)に切り替えるという対立軸を提供する 2 ソース目。 - [[@2004__Wiley__Principles of Network and System Administration - Chapter 1 Introduction]] — 同著者が収束理論を非形式的な「メタ原理(予測可能性)」として教科書に落とし込んだ版。 - [[ポリシー]] / [[@2004__Wiley__Principles of Network and System Administration - Chapter 3 Networked communities]] — 収束理論が前提とする「ポリシー」概念の正式な定義を与える章。 - [[@2004__Wiley__Principles of Network and System Administration - Chapter 4 Host management]] — ホスト単体レベルでの再現性の原理とクローニング手法(収束/交換の対立軸の技術的前身)を示す章。 - [[@2004__Wiley__Principles of Network and System Administration - Chapter 6 Models of network and system administration]] — 収束を競合・免疫と並ぶ三つ組として統合的に再提示し、Traugottのcongruence論への応答を含む章。 - [[@2004__Wiley__Principles of Network and System Administration - Chapter 7 Configuration and maintenance]] — 収束を原因の制御・宣言的記述・冪等な操作という実装原理へ分解する章。 - [[@2004__Wiley__Principles of Network and System Administration - Chapter 14 Summary and outlook]] — 分散化(第6章)と自動化(第7章)の両テーマを将来予測として語り直す最終章。 - [[cfengine]] — 収束的意味論を実装するツール本体。 - [[@2019__ACM CSUR__A Survey of DevOps Concepts and Challenges - Chapter 6 Toolset]] / [[Chef]] / [[Puppet]] / [[Docker]] — DevOpsツール分類の観点から見た「コンテナ化(交換)対継続的構成収束(収束)」の対立、Zhu et al.のlightly/heavily baked images比較。 - 既存資産(一方向参照): [[papers/1998__LISA__Computer Immunology|papers/1998__LISA__Computer Immunology]](同著者の前年 LISA 論文、免疫モデルの初出。第6章§6.7で収束と統合的に位置づけ直される)、`structures/SRE - MOC.md` への一方向参照。 - ソース: [[@1997__LISA__An Analysis of UNIX System Configuration]] / [[@2002__LISA__Why Order Matters - Turing Equivalence in Automated Systems Administration]] / [[@2003__LISA__ISconf - Theory, Practice, and Beyond]] - エンティティ: [[Remy Evard]] / [[Lance Brown]] / [[Luke Kanies]] ## 出典 - [[@2000__LISA__Theoretical System Administration]](Mark Burgess, USENIX LISA 2000) - [[@2021__OReillyJapan__SREの探求 - Chapter 24 イミュータブルなインフラストラクチャとSRE]](Jonah Horowitz, §24.1, §24.5) - [[@2004__Wiley__Principles of Network and System Administration - Chapter 1 Introduction]](Mark Burgess, John Wiley & Sons, 2004, §1.9) - [[@2004__Wiley__Principles of Network and System Administration - Chapter 3 Networked communities]](Mark Burgess, John Wiley & Sons, 2004, §3.2) - [[@2004__Wiley__Principles of Network and System Administration - Chapter 4 Host management]](Mark Burgess, John Wiley & Sons, 2004, §4.6.8, §4.8) - [[@2004__Wiley__Principles of Network and System Administration - Chapter 6 Models of network and system administration]](Mark Burgess, John Wiley & Sons, 2004, §6.7) - [[@2004__Wiley__Principles of Network and System Administration - Chapter 7 Configuration and maintenance]](Mark Burgess, John Wiley & Sons, 2004, §7.2, §7.4, §7.11) - [[@2004__Wiley__Principles of Network and System Administration - Chapter 14 Summary and outlook]](Mark Burgess, John Wiley & Sons, 2004, §14.3, §14.4) - [[@2019__ACM CSUR__A Survey of DevOps Concepts and Challenges - Chapter 6 Toolset]](Leite・Rocha・Kon・Milojicic・Meirelles, ACM Computing Surveys 52(6), 2019, §6.5) - [[@2002__LISA__Why Order Matters - Turing Equivalence in Automated Systems Administration]](Traugottのcongruence論の一次資料。発散・収束・合同の3分類とチューリング等価性によるコスト論証) - [[@2003__LISA__ISconf - Theory, Practice, and Beyond]](Luke Kanies, USENIX LISA 2003。congruence志向のISconfとconvergence志向のcfengineを実装レベルで統合した経験)