いろいろな仕事を渡り歩き、今はインフラ系エンジニアをやっている。いろんな業種からの視点も交えてコラムを綴らせていただきます。

ひな型理論

»

■ひな型理論とは

 これは私が勝手に考えた理論だ。例えばサーバを構築したり、クライアントPCを大量にセットアップする時、よくひな型を作る。このひな型が適当だと、必ずいい加減なシステムが出来上がってしまいう。簡単にいえば、ひな型がしょぼいとプロジェクトが失敗するという理論である。

 原理としては簡単だ。もともとのモデルになるひな型がしょぼいと、結果もしょぼくなる。この理論でいけば、きちんとしたひな型を固めておけばいい結果に結びつくということだ。クライアントPCをばら撒く場合だとモデルとなる1台のセットアップ、サーバを構築する場合だと検証機になるんだろうか。そこらへんをきちんと作り込むことがプロジェクト成功への鍵になる。

■そもそもひな型作ってる?

 IT系の業務でいろいろ携わってきたが、このひな型を作るのが一番うまかったのが、クライアントPCを管理するセクションだった。一番分かりやすいからだろう。検証機を一台用意して、そこでクライアントのひな型を作り込む。出来上がったらバックアップソフトでOSのイメージを作成してばら撒く。このように、業務の流れにひな型の作成という考え方が浸透しているからだ。

 この、バックアップソフトで作るOSのイメージが大事なのだ。ポイントごとにバックアップを取って、ポイント毎にシステムをロールバックできる体制を整える。設定を間違えた時や、詰まった時にレストアして、確実に分るところからやり直す。これをやらないと、構築中のトラブルは切り分けが難しくなる。

 このようなひな型作成や管理のノウハウがあると、構成するシステムが複雑でもぶれが無くなる。が、サーバ構築のプロジェクトではここら辺があきれる程に貧弱だ。ひな型以前に、OSのバックアップ、レストアすらろくにできないようなプロジェクトさえある。

 システムのバックアップは、完成した時に行うものではない。出戻りができるための命綱だ。サーバにおけるバージョン管理くらいに思ってもいいかもしれない。そのくらいに重要だが、サーバの構築系のプロジェクトでは、なぜか誰もやろうとはしない。

■スキルは磨くが認識が取り残されている

 このひな型の作成、管理のノウハウが広まらないのは、エンジニアの認識が追いついていないからだ。スキルが低いからではない。実際、スキルの高くてもOSのバックアップ、レストアはあまりやらない人は多い。

 おそらく、OSのバックアップに関しては「リスキー」というイメージがあるので、やらないのではないだろうか。確かに時間はかかるが慣れていれば確実に戻せる。ここら辺は回数を重ねて実感するしかない。また、パーテションやMBRに関する知識など、普通に仕事だけではなかなか使わないようなノウハウが求められる。自作機でマルチブートするなど、マニアックな構成をするような人でないと、バックアップに関するリスキーなイメージの払拭は難しい。

 できるスキルはあっても、認識がついてこなければ活用されることはない。このひな型を活用する方法は、バックアップとレストアをちゅうちょなくできる人でなければ、なかなか活用できない。バックアップとレストアが完璧にできるスキルがあったとしても、非常時にしか使わないという認識では、そういう発想が浮かばない。

 スキルを磨くことで、できる選択肢は増える。しかし、選択肢を吟味するとなると、スキルとは別に工夫とか試行錯誤が求められる。業務でしかITに携わっていないと、選択肢を上層部に丸投げしたり、直接結果に結びつかないものが切り捨てられるので、ここら辺がどうしても薄くなる。

■作りこむなら、ひな型がないとやってられない

 システムの完成度を高めるには、一度構築して取りあえず動く段階までもっていく。そこまでできた段階で設定内容を吟味して、またシステムを作り直す。という手法をとる。普段、個人用の検証環境を作成するときはそういう方法を取っている。作りこむと設定項目が増える。なので、必ず、OSのフルバックアップや、ソフトウェアの基本設定のコンフィグファイルのひな型は作成する。

 これをしておくと、似たようなケースで流用できたり、同じ構成のシステムを何台も作ることができる。また、トラブルが起きてもすぐにロールバックできる。また、細かく設定内容を見直していく場合、ひな型がないと作業が複雑になってやっていけない。

 おそらく、業務で細かくひな型を取って検証するのは現実的に無理だと思う。しかし、スキルアップのための検証を行う時には、ぜひ実行してみて欲しい。このひな型を作り込むことで、検証作業の密度が高くなる。仮想環境を使えば、ファイルのコピーだけでOSごとバックアップできる。最近じゃHDの容量もバカみたいにでかいので問題もない。

 ひな型理論。本来なら現場で適用されるべきかもしれないが、まずは個人から適用してみてはどうだろう。ひな型は、作った分だけ、資産として使えるのだから。

~おまけ~

 今回はシステムの構築向けの話です。コーディングする人はどうなんでしょう。ひな型というよりフレームワークみたいなものになるんでしょうか。

 個人でシステム構築の検証環境を構築する時はよく仮想環境を使う。ただ、Windows系のOSやシステムを検証する時って、ライセンス関連が問題になる。そういう人は、Technetサブスクリプションを使ってみてはどうだろうか。検証用のライセンスが格安で利用できる。

 体験版を使用してもいいのだが、数カ月でライセンスが切れるので、ひな型を作っても使えなくなってしまう場合がある。検証用のライセンスがあると、そういう時に便利だ。時間があれば、そこら辺のノウハウも書いてみたいと思う。

 

Comment(0)