長い間使っていたサーバを新しくしました。１月前半の作業割合としては、このサーバ更新がかなりを占めたのですが、どのような理由にせよ、サーバを換えるにはコストが掛かります。linux関連の記事では、サーバを替える際の技術情報が多く取り扱われるのが通例ですが、この記事では、経営者や部門責任者を対象に、「コスト管理」について、当方でのリプレースの流れを追いながら、さまざまなケースを併記してみたいと思います。
サーバを換える理由は？
当方の今回のケースでは、機材の一新とLinuxの入れ直しとなり、以下を目論見としました。- 機材の老朽化対策(※壊れていたわけではありませんが、連続で３年程度稼動していました)
- OSの基本(カーネル)、各種サーバソフトウェアのアップデート
- 機材は古いが、ハードウェア監視情報・目視による検査では、異常の要因は見つからない
- ただし、サーバのハードウェア自身が古いために、更新でランニングコストを下げることが出来るだろう。
- 同時に、明らかなパフォーマンスの向上が見込める
- メンテナンスモードに入っているソフトウェアが動作している。それをバージョンアップするためには、基本のカーネルからのアップデートが必要となる
- 以上から、サーバの変更を実施することに決定する
- では、リプレースのコストはどうだろうか？機材調達については●●円
- では、リプレースに伴う実務、コストの発生と損失見込はどうだろうか？
サーバを換えるために、どういったコストを見積もるか？
ハードウェア調達などの直接経費となるものについては、見積もりが簡単なので省きます。問題は、間接的に発生する内容です。計画を実施する際に発生するコスト・計画を実施することによって発生する損失を考えます。いずれも、サーバ運用・メンテナンス部門があれば、その部門内での年次計画などでコストを算出せざるをえませんので、問題はありません。サーバ運用を外注に委託している場合も、社内的なコスト管理は易しくなります。それが、パソコンに詳しい人などが中途半端に管理を兼任している(※ないしは業務命令で兼任させられている)場合、問題が発生します。そのような場合、技術レベルの問題もありますが、躓く原因はどこにでもあります。中小企業の場合、「兼任」においてその役務を担える環境下であるかどうか・その「兼任」が組織運営として失敗しているかどうかが問われます。残念ながら、トラブルの例を見ると、「兼任」は曖昧な環境下で行われている例が多く、兼任の負担などで、社外に管理させるよりも余計にコストがかかり、また波及して損失を発生させてしまうケースがままありますので、ご注意ください。では、当方の例ではどのように考えて進めたかを例示します。- 直接担当者(※自分)の能力であれば、最終的に稼動が完了するまで4時間@1人×5日、更に検証や調整などに2時間@1人×3日程度で完了するだろう
- サーバリプレースは直接利益を出さないが、その期間に対する直接担当者(※自分)の間接作業として実施できる
- 計画の上では、リプレース業務に携わっている間、直接担当者(※自分)の他業務には支障が出ないと予測できる、即ち損失はほぼ無い
- サーバに依存している直接利益は損なわれない(ゆらぎ範囲である)
「予測できない」問題とコストの発生があることを「予測する」
スムースに移行が進まないケースもありますので、時間コストにゆとりを持たせることが必要です。取り分け、ソフトウェア関連でのコンフィグレーションやり直しやデータベースの移行、プログラミングなどの作業が発生する場合、それらの作業がリストアップされていたとしても、習熟度や環境によって、時間が掛かる場合があります。問題を発生させないために
- コスト算出をきちんと行う。出費はコストに含まれますが、出費＝コストではありません。
- 必ず着手前にプランニングする
- 担当内容の役務を明確に
参考までに。当方が入れ替えたOSはCentOS5.1(32bit)＋RAID1による冗長化、メールサーバはPostfix2、データベースはMySQL4→5、ウェブ関連としてApache1.3+PHP4→Apache2+PHP5です。バージョンの変更に伴って、データベースのダンプと読み込み・PHPコードの若干の書き換えの手間などが若干発生しましたが、昔からの情報収集や準備によって慌てることもなく完了できました。気になっていた消費電力は50W→37Wとなり、また新しいハードウェアによる底上げで、サーバのパフォーマンスが向上しました。心なしか、sshで接続していてもレスポンスがいいような気がします。