[自鯖] 我が家のサーバーでシステム構築をまじめにやってみる [更改]

Pocket

Tweet

決意表明なので、だらだら書きますw
次回からは、ちゃんと、目的とゴールを意識しておきます。

我が家のサーバーは、2003年2月から稼働を始め、すでに 6年以上経過しています。これまでの HW障害は HDDx1 が潰れたのみ。丹念に下調べをして、この時代でも少し時代遅れであった、Pentium !!! 1.13GHz (L2大きい版)を選択。枯れたハードウェアを選択した上、RAID を構成し、バックアップサーバーも準備したことでデータロスト0、年間の稼働率も 99.9% を続けてきました。

しかし、良いハードウェアを選択したとは言っても、すでに 6年が経過しており、どう考えてもやばい状態です。いつ壊れても、致し方ないと考えられます。
ですが、この blog 程度ならまだしも、他人にメアド開放して、いくらかサービスを提供しているプロバイダーとしては、今後もこのままのサーバーでよいかどうかを思案しなければならない時期にさしかかったわけです。

また、現行のサーバーではできなかったことも多々あり、さすがに 6年の時間経過は、劣化したシステム機能を提供するにしかとどまりません。ハードウェアに頼り切った可用性や、問題が表沙汰になったときに対処する運用では、今後、私がいなくなったとしても、嫁に引き継ぐことができません。

ということで、商売柄、まともにインフラのデザインをすべき力を、少し自分のサーバーにまわしてみようと考えたわけです。とはいえ、会社で得た知識をそのまま利用すると、会社との契約違反になるため、もっと汎化された、一般的なフロー・ツールを利用して自鯖の更改にあたることを決意しました。

今日は、ただの決意表明ですが、すでに一人ブレインストーミングでの要件洗い出しやら、次期システムのアーキテクチャーは思い描いています。
ただ、なぜ、そのようなアーキテクチャーを設計して、今後、どのように運用していくか、嫁や娘らにも実施してもらうには、そのアーキテクチャーを明示して残しておく必要があります。運用手順書だけを渡しても、たしかに、その範囲内の実施は可能でしょうが、なぜ、そのような構成になっているかが明確でない場合、オペレーター以上の作業を実施しようとしたときの行動規範が崩れてしまうわけです。

ことの重要性は、20世紀から認識していたものの、こうやってやってこなかったのは、自分の怠慢です。これからは、少し時間をかけつつも、ちゃんとドキュメントを残し、サーバー運用くらいはコモディティ化しておくことにします。

目標は次のようにします。

• アーキテクチャーの構造が理解できるようなモデルを明示する。
• トレーサビリティある設計を実施し、ドキュメントに反映されること
• 自鯖で必要な運用項目について、そのすべてを洗い出し、手順書化すること

書いたとたんにやる気を失ってきましたが、がんばる決意はします。ともかく、今のサーバーは新しくしないと、やばいことに変わりはないので。

今後の進め方。一般流通している書籍や、各ベンダーのサイトで公開されている情報を元に、あくまでも個人的な手法に従って、アーキテクチャーのデザインを実施します。
ターゲットはインフラだけで、アプリケーションの開発は含みません。現在稼働中のアプリケーションをそのままに、新インフラへのマイグレーションすることをゴールとします。
ゴールへの流れは次のように考えています。 ^[I] … Continue reading

1. 要件定義
2. 設計
3. 構築
4. テスト
5. 運用引継
6. 運用

次回は、要件定義局面をがんばります。何度も繰り返しますが、今日は、ただの決意表明ですw