[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debian-users:12223] Re: historical info

In <19990124173545Q.oka@debian.or.jp>
[debian-users:12215] Re: historical info, Jan.24 '99 17:35 JST
oka@debian.or.jp says:
=   もうちょっと現実的な事を挙げます。システム管理者がまだ未熟だっ
=   たり、冒険を冒して、とんでもない操作ミスをしてしまうっていう
=   のはどうでしょうか。

なるほど、人間系ですか。基本的にはfool-proofなものは作りたくな
いので、人間系によるものでない障害と同じリカバリプロセスを適用
することを考える事にしたいです。つまり、クリティカルな管理デー
タを明確にしておくことだけをシステム側ではやることにして、その
でーたをどう守るかについては、たとえばバックアップ運用をユーザ
側で策定する(それほど大袈裟でなくてもいいけど)とかですね。

単に一貫性をチェックするだけでなく、どの程度まで一貫性が失われ
たのかを計る事ができればなお有用でしょうね。


=   データの回復っていうのでちょっとまた変な考えが出てきました。
=   微分方程式系とか差分方程式系には、解の安定度みたいなのがあり
=   ますが、Debian システム(=系)をこういった式でシステムの状態空
=   間を大雑把にモデル化して安定度を判定できないかなー、と思った
=   りしました。
=   
=   # 本当の状態空間はそれこそハードディスクの容量分だけ考えなきゃ
=     ならんのかもしれませんが、かなり大雑把にできないかな、と。
=   
=   自己修復能力を持っている程、安定度が高くなりそうです。アトラ
=   クタを描いてみて(って何次元だろ^^;)弱点を調べるとか...。

＃くぅー、離散力学系ですか？非線形数学全開ですね。岡さんってそっ
　ち方面の専攻なんでしたっけ？そういえば、ロジスティックスとか
　やられてるようですが... それとも自動制御、非線形振動物理...

もしも最初から、どーしても簡単なものにはなりっこないっ！という
ことがわかっていて、それでもなんらかのメトリックを用意しなけれ
ばならないとしたら、岡さんがおっしゃるようなことも考えなければ
ならないかもしれない、というか、複雑なものを複雑なまま取り扱う
必要があるとしたらそれもまた良いアプローチになるだろうという印
象はうけます。

ただ、私のような業務アプリケーション方面のプログラマはたいてい
はもうちょっと還元主義的なアプローチをしますね(^^;つまり、複雑
さを取り払いあるいは畳み込む、簡素なものを組み合わせて複雑な問
題に挑む、というような。

あと、全然関係ないけど、自己回復能力が安定度に貢献しない場合も
ありますよ。アトラクタの中には重力源に接近すればする程系が不安
定になるものもありますから。ご存知でしょうけど。

＃Chaotic な設計アプローチは岡さんにお任せします ;-)


=   kenn> かですよね。それ、管理対象として考えてないです私は。
=   
=   え、どうしてですか。簡単ではないのは分かりますが、ゴミが溜まっ
=   たら容量が減ってシステムを圧迫しますよ...。
[...]
=   たぶん、徹底した管理メカニズムを提供しようとすると、アプリケー
=   ションのファイルはさらに属性化されて、もっとしんどいパッケー
=   ジモデルになりそうな気もしますが、考えてないうちは何とも言え
=   ないです。

一般的なモデルが出て来ないと思うんですよ。INN ならまだはっきり
していて、/var/lib/news/{history*,active} とかすぐに列挙できま
すが、より一般的に、あるアプリケーションがそのインストールから
アンインストールまでのライフサイクル中に生成したり継続して維持
したりするデータがあるとして、それをどうパッケージ構成管理側で
把握するか、ということです。ファイル単位でこまごまと管理するプ
リミティブな管理か、さもなくば各パッケージ毎特化したものになる
か... いずれにしろ「管理開始」をインストール時におこない、アン
インストール時に「管理終了」するという切り方では無理だと思いま
す。

やるならディレクトリ単位の管理でしょうか。パッケージのインストー
ル事前条件として「私はライフサイクルスパン中で独自データを生成
する(そしてそのおき場所として/var/lib/newsを期待する)」という
のを設けておけば、これは管理下に置く事ができますね。


=   kenn> タが矛盾するような場合かな。一貫性が保たれているかどうかを検査
=   kenn> できる仕組みが要りそうですね。
=   
=   はい。これは
=   
=    1. ソースパッケージ → バイナリパッケージ
=    2. パッケージのアップロード
=    3. システムへのインストール
=   
=   の3つの境界で(静的|動的)検査が必要です。lintian は今のパッケー
=   ジの中途半端なモデルを抱えて苦しんでますから再整理が必要です。

銘記しておきます。


=   う。UML は本を買ったものの、自分で書く分には即コーディングに
=   なってしまうし、人と交換する事なんか無かったのであんまり使え
=   ません...。時間ができたら再勉強します。

Usecase がきちんとかければプロになれます ;-)
あ、いえ、プロになることはけっしておすすめはしません ^^;


 -.- . -. -.
Ken Nakagaki <kenn@xxxxxxxxxxxxxxxxx>
「会社は主にそれ自身の慣性によって前進している」-- Gerry Spence