レベル: 初級 Cameron Laird (Cameron@Lairds.com), Vice President, Phaseit, Inc.
2002年 5月 01日 いま扱っているサーバーやプログラムに対して、みなさんができる最善のこと、それはThomas A. LimoncelliとChristine HoganによるThe Practice of System and Network Administration を自分用に1冊購入することです。この新刊書は、管理者向けに書かれたものですが、開発者にとってもためになる教訓に満ちています。800ページ近いこの本の中で、Linuxに言及しているのは1箇所だけで、しかも間接的にですが、そこで説明されている信条は、日々の作業の意味を納得させてくれることでしょう。
The Practice of System and Network Administration (以下では単にPractice という) の価値については、すでに他の評者も喧伝しているところです。それに「サーバー・クリニック」の守備範囲はプログラミングであり、管理 (administration) ではありません。なのに、ここでこの本を取り上げるのには、どんな意味があるのでしょうか。
単に管理者の問題にとどまらない
このコラムでPractice を紹介するのには、いくつかの理由があります。まず第1に、この本には隠された利得があり、それを世の中に広く知ってほしいと思うからです。それは、管理だけにとどまらず、開発にも適用できるという点です。
第2に、今後このコラムで、今回触れたいろいろな参考文献を参照することになるだろうということです。期待しておいてください。前回のコラムのテーマとPractice は、いずれも今後のコラムに何度も登場することでしょう。ですから、最初にこれらのテーマをよく理解しておくのが最高のアプローチとなるでしょう。
Practiceの違うところ
ほぼこれまでの10年間、UNIXシステム管理者が標準的に参考にする2冊の書籍がありました。Nemeth他著のUNIX System Administration Handbook と、それに少し遅れをとるAeleen Frisch著のEssential System Administration の2冊です。たとえば、プリンター・キューに何か障害が起こったとすると、当然のごとく、この2冊のどちらかを引っぱり出してきて、問題の解決につながるコマンドを見つけ出してきます。最近では、良いものもあれば悪いものもありますが、とくにLinuxシステムの管理を対象とした書籍も多数出されています。
Practice は、そうしたものとは異なっています。Practiceは、そうした本を補完するとともに、ある程度それらの本をすべて無用のものとしています。管理に関するほとんどの書籍には、コードがたくさん示されています。sendmail.cf の例、数々のシェル・スクリプト、top のコマンド・ライン引数などです。Practice の場合、もう少し理論的な知識を扱っており、それはほぼMark Burgess著のPrinciples of Network and System Administration と同じレベルのものです。Practice の趣旨は、事務的な雑用と化していることのあまりにも多い管理の「手続き (how)」を、プロが実践する「理屈 (why)」に高めることなのです。
Practice は、これを、基本的に特定のプログラムや製品を引き合いに出さずに行っています。実際、特定のオペレーティング・システムを前提にした話などありません。その考え方は、MacOSにも、UNIXにも、Windowsにも、あるいはその他の企業オペレーティング・システムにも、等しく当てはまります。
管理の例を示さない管理の本なんて、極端だと思われるでしょうか。Practice に対する評価は、真っ二つに分かれています。ほとんどの読者は、必携の書だと結論を下すか、気に入らない、献本されたって受け取らないとするかのいずれかです。私は、もちろん、前者に属します。究極的には、Practice の理論は、すべて、実践的です。
たとえば、電子メールに関する第19章について言えば、メール・ループがあったり、キューが詰まった (wedged queue)場合、あるいはフィルターによってスパム・メールを除外するとか、受信ボックスのサイズを制限するとか、トラフィックをアーカイブ化するとか、定型の断り書きを自動作成する必要があるというような場合に、それに対する直接的な答は何ら示されていません。その代わり、諸々のタスクが機能するために維持する必要のある概念を分かりやすい言葉で提示しています。それは、信頼性、拡張容易性 (scalability) 、管理容易性 (manageability) といったものです。
それでは、著者ならびに私は、問題を解決するための方法を何ひとつ示すことのない本が、どういう意味で「実践的」だと主張しようというのでしょうか。重要なことは、みなさんの知っていることが方法だけだとしたら、その方法が有効なちっぽけな領域から離れたとたん、もううまくやっていくことができないということです。Practice は、みなさんが解決手段の見つけ方を知っていることを前提としています。この本は、そうした手段を、もっと深い理解で補完するという役割を引き受け、もっと一般的な新しい事態にみなさんが対処できるようにしようとしているのです。また、つねに、すべての章において、Practice は、管理権限を獲得する上での基本として、自動化、標準への準拠、良質な文書作成、明確なコミュニケーションを強調します。
このことに焦点を絞ることで、Practice とシステム管理に関するそれ以前の世代の書籍との間のもう1つの違いが明らかになってきます。管理に関する従来の書籍は、いくぶん百科事典的な意味をもつ「リファレンス」でした。IP割り当ての問題に対する答がほしいときには、そのトピックを扱う章を調べるといった具合です。対照的に、Practice の読者の多くが行うことは、この本を素直に最初から読み進んでいくことです。物語的に「小説」のように。読者は、管理に関するすべての原理を首尾一貫した形で理解しようと勉強し、その後、個々の「ハウツー」へのリンクを求めて、この本のWebサイト (以下の参考文献の "EverythingSysadmin" 参照) を開くのです。
これは、おそらく世の流れに沿ったものなのでしょう。私は、コードや「manページ」にあふれたPurple Book (Nemethの本の「巷間での名前」) に対するニーズは、今後、減り続けていくだろうと思っています。われわれは、そうした情報をますますオンラインで求めることになります。とはいっても、Practice に詰め込まれているような実際の経験に基づく解説、分析、助言は、まだ紙の形で必要とされます。
サーバー・プログラミングが意味すること
では、サーバー側のアプリケーションを開発している「サーバー・クリニック」の読者にとっては、どんな点が重要なのでしょうか。まず、Practice が良書だという点です。情報はちょうどよいレベルの抽象度で与えられています -- サーバーはどこが違うのか？ どのようにして管理ポリシーを制度化するのか？ システムの配備をするには何をしなくてはいけないか？ 自分自身のキャリアをどうやって形成していくか？ -- など、あなた自身の仕事に必要な内容です。また、管理者の考え方 (あるいは管理者だったら当然考えるべきこと) が理解できれば、仕事をスムーズに進めることができます。
その他、LimoncelliとHoganの管理に対するアプローチは独特で、プログラマーにとってためになるテーマを強調しています。彼らは、管理の設計やサポートについて、明快に要点を6個挙げています。単純性 (simplicity)、明快性 (clarity)、一般性 (generality)、自動化 (automation)、コミュニケーション (communication)、および「基礎的なことから (basics first)」の6つです。少なくとも管理者と同じぐらい、プログラマーにもこれらのことが必要です。
Limoncelliは、その生活全部をmake ファイルを中心に組み立てているようです。彼は、この本のテキスト自体に、もっと正確に言えば、テキストを作成するために彼とHoganが使用していた「マクロ」に、バージョン管理を利用していました。重要なことは、make が素晴らしい言語だということではありません。実際、そういうわけではありません。重要なのは、変更を管理したり、復元を保証するための確立された1つの技法なのです。プログラマーであるみなさんにとっての大きな課題は、絶え間なく行われる変更、すなわち、新しいプロトコル、アプリケーション・プログラミング・インターフェース (API)、顧客の要求、ハードウェア的な制約条件などにうまく対処することです。こうしたすべての可変性を、自動化や一般化によって管理する立場にいると考えてみてください。Practice は、これに対して正しい態度で臨んでおり、教えとなることをたくさん含んでいます。
私がいくつか質問してみたところ、LimoncelliとHoganは、サーバーの考え方について、この本にはないいくつかのヒントを返してきてくれました。Limoncelliは、「サーバー・プログラミングは、変更管理が必要条件となるという点が異なっている」と強調しています。彼は、また、サービスとサーバーを区別するのが好きです。「金があれば馬鹿でもサーバーを買えるが、サービスを問題なく稼働させるには、数多くの頭脳が必要だ」と。
これらのスローガンから、今月の宿題が浮かび上がってきます。多くのショップでは、サーバーがダウンしたときに、ポケベル・システムなどの通報装置にアラームを発するようにして、サーバーを監視しています。しかしながら、みなさんが本当にほしいのは、さまざまなサービスです。サーバーは、その目的のための手段にすぎません。とすると、Practice で勉強した当然の帰結として、サービス・モニターを構築しようということになります。そのような商品もいくつかありますし、多くの組織が「内製」バージョンを稼働させていますが、まだ満足できるものに出会ったことがありません。
これがどんな動作をすることになるのか概観してみましょう。/etc/service スタイルの割り当てテーブル (100.1.2.3および100.1.2.5がHTTPに、100.1.2.6がSMTPに割り当てられる) があったとして、モニターは監視されるホスト上のすべてのポートをチェックします。モニターは、定義されたサービスが存在し、他のポートがどれもオープンしていないことを確認します。結果は記録され (Practice は、記録をとることの意味をよく理解させてくれます)、割り当てテーブルはリビジョン管理を行いながら保守されます (バージョン管理は、HoganとLimoncelliのもう1つの良い習慣です)。これを実践してみてください。きっと、驚くべき結果が得られることでしょう。みなさんのネットワークにたくさんの脆弱性や「ストレス・ポイント」があることを発見するのではないでしょうか。
来月の「サーバー・クリニック」では、プログラミングの手助けとなりそうな、実際に動作するコードを紹介したいと思います。今回のクリニックで提供できる一番のお手伝いは、Practice をお読みください、という助言です。
参考文献
著者について  | 
| | Cameronは、Phaseit, Inc. の常勤のコンサルタントです。オープン・ソースなどの技術的なトピックについて、数々の執筆や発言を行っています。Cameronのメール・アドレスはclaird@phaseit.net です。 |
記事の評価
| 
