# タイムスケール分離と監視粒度 ## 定義 タイムスケール分離と監視粒度とは、[[Mark Burgess]] が提示する考え方であり、インフラ管理における問題は固有の時間スケール(T)を持ち、観測(サンプリング)・是正(remediation)の頻度をこの固有スケールに一致させなければ系が不安定化する、という設計原則である。タイムスケールの分離度合いは系全体の結合強度(coupling strength)の指標であり、良い分離は弱結合・安定を、悪い分離は強結合・脆弱性をもたらす。人間が関与できる限界を示す「KT境界(kernel-thought boundary)」の外側では自動化が必須になる。中心テーゼは「力学は常に意味論に勝る(Dynamics always trump semantics)」——ソフトウェアは意味論的問題の解決には長けているが、その問題を引き起こす力学的過程そのものへの対応を怠りがちである。(Source: [[@2014__markburgess.org__Infrastructure Management Timescales]]) ## 横断的知見 - **監視アラームのタイムスケール不一致は、[[アラート疲労]] が扱う「大量の低品質アラートによるオペレータ応答性の低下」とは異なる、より根源的な設計レベルの原因を指摘する**: [[アラート疲労]] に蓄積された事例(Jalleda/Zynga、Chen/Baidu 等)は主に「アラート量が多すぎる」ことへの介入(インセンティブ設計・技術的削減・SLI 集約)を扱うが、Burgess の指摘はそれ以前の設計原理——「マイクロ秒スケールで発生するエラーを、分〜時間スケールで応答する人間にそのまま渡すこと自体が構造的に誤っている」——を提示する。つまりアラート疲労の産業的解決策の多くは「人間が処理しきれる量までアラートを絞る」ことに焦点を当てるのに対し、Burgess は「そもそも人間の応答タイムスケールと問題の発生タイムスケールが一致しない場合、量を絞っても不一致自体は解消されず、閉ループの自動化に置き換えるべきだ」という一段上流の原則を提供する。両者は補完的であり、[[アラート疲労]] の「監視対象の優先順位付け」「多数コンポーネント監視→単一SLIへの置換」といった解決パターンは、結果的に Burgess の言うタイムスケール一致に近づく設計変更として再解釈できる。(Source: [[@2014__markburgess.org__Infrastructure Management Timescales]], [[アラート疲労]]) - **「仕様書に記載された時間遅れの値を鵜呑みにする危険性」という論点は、[[制御ループの安定性とタイムラグ補償]] における Apollo 誘導コンピュータの事例と同型の力学的整合の問題である**: [[制御ループの安定性とタイムラグ補償]] は Apollo LM の降下エンジンにおいて、ICD 記載のタイムラグ値(0.3秒)と実機の実際のタイムラグ(約0.075秒)が乖離しており、経験的観察に基づく補償(0.2秒)がたまたま安定な飛行を実現した事例を扱う。これは Burgess の「是正の実行時間は問題自身のタイムスケールと一致していなければならない(Maintenance Theorem)」という一般原理の具体例と位置づけられる——両ソースとも、意味論的に正しく見える設計(仕様通りの実装、機能的に正しい構成管理プロセス)が、力学的なタイムスケールの不一致によって不安定化しうることを示す点で一致する。Apollo の事例は「不一致を経験的観察が偶然打ち消した」特殊ケースだが、Burgess はこれを一般原理として定式化した点で先行する。(Source: [[@2014__markburgess.org__Infrastructure Management Timescales]], [[制御ループの安定性とタイムラグ補償]]) - **2014 年の「タイムスケール分離」原則は、同著者の 2000 年の論文が定量モデルとして先取りしていた**: [[@2000__arXiv__On the theory of system administration]](Burgess, 2000-03)の §3「On scales」は「高レベルの現象は低レベルの細部にほとんど依存しない(separation of scales の原理)」を一般原則として述べ、§6.2「Interactions of time scales」では自動システムの応答時間 t_auto(nT_p + T_e(A) ≥ t_auto ≥ T_e(A))と人間の応答時間 t_human(∞ ≥ t_human ≥ T_w(H) + T_d(H) + T_e(H))を明示的な不等式で比較し、T_w(H) > T_e(A) が成り立つ限り自動システムが常に人間に勝てることを示す(式16〜22)。これは 2014 年記事の「KT境界」「Dynamics trump semantics」というスローガン的表現の 14 年前の定量的な原型であり、2000 年論文は日周期の待機時間モデル T_w(H) > 4(1 + sin(t/24)) という具体的な数式まで与えている点で、2014 年記事より厳密である。一方 2014 年記事の「監視サンプリング周期と問題の固有時間スケールを一致させる」という観測(observation)側の主張は、2000 年論文には明示的に現れず(2000 年論文はもっぱら是正(remediation)の応答時間比較に焦点を当てる)、Burgess の思考が「是正のタイムスケール」から「観測込みの全体ループのタイムスケール」へと拡張された系譜として読める。(Source: [[@2000__arXiv__On the theory of system administration]], [[@2014__markburgess.org__Infrastructure Management Timescales]]) ## 未解決の問い - Burgess は「KT境界(人間が関与できなくなる限界)」を概念として提示するが、具体的にどの時間スケール(ミリ秒、マイクロ秒等)がこの境界に相当するかは定量化されていない。本 wiki の他の監視・アラート関連ソースで、人間の意思決定に要する時間の定量的知見(反応時間の実測データ等)と突き合わせられるか。 - 「エラスティックスケーリングは構成管理プロセスでは解決できない」という 2014 年時点の指摘は、Kubernetes の HPA(Horizontal Pod Autoscaler)や現代のコンテナオーケストレーション基盤でどこまで解消されたか、あるいは依然として同じ力学的不一致が形を変えて残っているか。本 wiki に蓄積されているコンテナオーケストレーション関連ソースとの突き合わせが今後の課題。 - Burgess が提唱する Shannon 誤り訂正定理・Burgess Maintenance Theorem の具体的な数式・証明は本記事には記載されていない。原典(*In Search of Certainty*)を追加で ingest すれば、この概念ページの定義セクションをより厳密化できる。 ## 関連 - ソース: [[@2014__markburgess.org__Infrastructure Management Timescales]] - エンティティ: [[Mark Burgess]] - 概念: [[アラート疲労]] / [[制御ループの安定性とタイムラグ補償]] ## 出典 - [[@2014__markburgess.org__Infrastructure Management Timescales]]