OS選定のポイントを整理する

操作に慣れていること

　ここで言う「操作」とは、GUI（Graphical User Interface）やCUI（Character-based User Interface）の別はもちろん、コマンドの挙動の違いやディレクトリ構造の違いなども含んでいる。プロダクト／ディストリビューションを選ぶ際は、このことも非常に大きな問題となる。

　GUIとCUIの違いについて説明は不要と思われるが、ディレクトリ構造の違いについては、イメージできないかもしれないので解説する。例えば、同じLinux系サーバOSでも、Apacheの設定ファイルの位置だけでもこのように違う。

　Debian GNU/Linux → /etc/apache2
　CentOS → /etc/httpd

　システム構築時にはあまり関係が無いこうした違いも、運用時には、トラブル発生時の対応速度や品質にかかわる重要な問題となる。CentOSに慣れている者がDebian GNU/LinuxでApacheの対応を行うとき、あるべきはずの場所に設定ファイルが無いと、ファイルを探す手間が余計にかかる。これは、平常時ならばまだしも、非常時においては対応作業の遅れを引き起こしうる。

　ただ、これは、1つのOSだけ慣れておけば良い、という意味ではない。いろいろなOSに対応できるのが、本当の意味での技術者だ。よって、今のサーバOSのほかに、各サーバOSのいずれかもう一系統にも慣れておきたい。慣れ方としては、現在稼働しているシステムをほかの系統でも作ってみるといった方法がある。これなら、そのサーバOSの挙動を知ることができるだけでなく、アプリケーションやハードウェアに対する知識も深まるため、技術力アップの近道としておすすめだ。

バージョンアップ内容が「2：8」

　ソフトウェアに改善とバグは付き物である。よってバージョンアップは不可避ではあるが、このバージョンアップに対する開発スタンスを見ることで、安心して使い続けることができるサーバOSであるかを判断できる。

　理想的な開発スタンスは、「新しいハードウェアや技術への対応を忘れていないこと」「常にバグ修正に目が向けられていること」の2つだ。割合としては、新機能とバグ修正の件数比率が2：8から3：7といったところが、安心して使えるOSのラインだろう。

　例えば技術力の不足のために新しいハードウェアや新技術への対応が止まっているということなどは、件数に現れる。そうしたサーバOSは先行きが不安だ。逆に新機能の比率が高すぎる場合は、バグ修正がおろそかになっているかもしれず、サーバOSとしては致命的である。

　一方、バグ修正の比率が高ければ、バグだらけという可能性も考えられる。これは全体の件数も関連してくるため一律に言えないが、傾向を見るには十分だ。あるいは、枯れ始めていて開発に行き詰まりが生じているという可能性も考えられる。

　こうした情報は、サーバOSのベンダーが提供しているChangeLog（ソフトウェアの変更履歴）から得ることができる。これは、サーバOSだけでなく、システム系全体で採用できる方法であり、ChangeLogと名のつくものはぜひとも読むようにしたい。前回筆者がリストアップしたOSはおおむねこの2つの基準を満たしているので、参考にするのが良いだろう。

　以上、当社の選択基準を紹介した。もちろんこの選択方法がすべてではない。現場では読者自身で考えてほしい。未知の解を導き出すこの「考える力」こそ、人間にとって、ことシステム屋にとって、非常に価値ある能力なのだ。

　次回は、実際に目的を設定し、アプリケーションやハードウェア、サーバOSの選択から実際の構築までを解説する。