サーバー移転作業の実際（2004-12-06）

新しいサーバーに持って行く

新しいサーバーに、コンテンツを移すことは、今にして思えば、さほどの苦労は無かった。気をつけるべき事を列挙する。とりあえず、どうしてもやらなくてはならないことから。

HEAD要素部分
サイト内のリンクのなかで、HEAD要素内のリンク要素に絶対位置によるURIを指定が多かった。特に、スタイルシートへのリバースリンクは全て絶対位置指定になっていた。これは、旧サーバーの設定に不備があり、「拡張子CSSファイルのMINE TYPEをtext/plainとするため、Mozilla系ブラウザの標準準拠モードでスタイルシートが適用されない」という問題に対処するため、スタイルシートファイルをOCNのサーバーに置いていたからだ。
ほとんどのケースは、テンプレートの修正で解決した。
コンテンツそのものの修正
各ページの末尾にある、アドレス部分など、旧サーバーのURIが記入されている部分を修正した。アドレス要素に関しては、ライブラリの修正で解決した。コンテンツ内の修正は、旧URIの表示を新URIに置き換えるのであるが、このような単純な作業に、ドリームウィーバーの検索機能は極めて有効である。テンプレートとライブラリに加えて検索・置き換え機能を使うと、数時間でおおよその修正が可能である。ただし、コンテンツ内の修正の場合、単純に置き換えるだけだと文脈が通じなくなる場合があるので注意が必要。ひとつずつ確認しつつ修正する。面倒なら修正を諦める。
CGIの修正
久しぶりに、CGIをいじった。要するに、出来合いのフリースクリプトを修正し、セットアップしたという意味だが。まず、ダウンロード元のサイトで、バージョンアップの確認をした。場合によっては、重要なセキュリティ上の問題が修正されている場合がある。それから引っ越し作業に移る。これらの作業は、Fetchでダウンロードし、miで修正した後に、再びfechiで新サーバーにプットする。picoBBSのログをうまく移せずに苦労した。バイナリファイルである旨、注意書きがあったのだが、よく分からない。色々やっているうちに気がついたのだが、CGIを移すもっとも良い方法は、Fetchで両方のサーバーを開き、旧サーバーから新サーバーへ、Fetchi上でドラッグ＆ドロップするという方法である。物の見事に移動させることが出来る。パーミッションの再設定も要らなかったように思う。picoBBSのログも完璧。移した後に、必要なCGIスクリプトの修正を行えばよい。
リンクの変更を通知する
旧サイトは閉鎖するわけではないが、今後更新の見込みがない。つまり、放置である。契約を打ち切った後、コンテンツがどういう扱いを受けるのか判らない。おやこニュースをリンクページに掲載して下さっている、いわゆる相互リンク先にメール、あるいは掲示板等で通知することにした。実際に、それらのリンクを辿って来る来訪者はさほど多くない。久しぶりに、知人サイトを訪れると、ブログになっていたり、サーバー移転されていたり。それから、googleのサイト登録。yahooもやってみたが望み薄とおもう。それ以外の、ここのページにリンクされている物に関しては、直ちにリンク切れになるわけではないので、申し訳ないと思いつつ、関与しないことにした。アンテナ補足に関しても同様の扱い。

CGIの修正に手間取ったが、それ以外はDreamweaverのサイト管理機能（テンプレート・ライブラリ・検索）で、意外なほど手間は掛からなかった。

次に、単純に移すだけなら必要ないが、ついでなのでやったこと。

不要なファイルの削除、移動
コンテンツを移していて気がついたのだが、今まで存在しなかった新しいURIにファイルを置くわけで、すでに内容が古いものや不要な物を削除したところで、File Not Foundとなる心配が要らない。いっそのこと、というわけで、ディレクトリを修正した上で、幾らかのファイルを削除した。日記のようなページは、日が経つに連れ一つのディレクトリに大量のファイルがたまる。これを年度ごと、月ごとというように、新たにディレクトリを作って振り分けた。こういったサイト内のコンテンツの移動もドリームウィーバーのサイト管理機能は有効である。リンクを相対位置で指定していれば、ファイルの移動に伴うリンクの修正を完璧にこなしてくれる。
テンプレート・スタイルシートの修正
統合可能なテンプレートをまとめた。それに伴い、スタイルシートも一部修正。
ローカルの掃除
作りかけて、中途半端に終わったもの。結局使わなかった画像ファイルなどを削除。ドリームウィーバーの「サイト全体のリンクチェック」をおこない、単独ファイルを炙り出す。但し、実際にはそれほど楽な作業ではない。単独ファイルとしてリストアップされたものを、ひとつずつ開いて確認し、削除していく。同じ検索結果に出る「破損リンク」の一覧は、フラグメント識別子へのリンクが、全て破損リンクと判定されるため、全く役にたたない。
アクセス解析
各ページの読み出し数の総計をほとんど全てのページに表示するようにした。ホームページのみ、そのページの訪問者数を表示し、それ以外のページは、サイト全体の訪問者数の累計を表示している。

ドリームウィーバーのサイト管理機能のごく一部を使ったのだが、かなり強力。加えて、テンプレート＋ライブラリ＋外部スタイルシートのありがたさを痛感。

これからやろうと思うこととして、サイト変遷に関する説明のページを作るべきだろう。サイトマップか自己紹介に加えても良いかもしれない。サイトの移転に関する説明がないと、話が通じない部分が出てくる。

旧サーバーのコンテンツの扱い

新しいサーバーに移す方は、勢いでやってしまった。実際、手間もさほどのことはなかったし、何より、そのような物があること自体を、誰もご存じないわけだから、何がどうなろうと、誰かに迷惑は掛ける心配は要らない。一方で、旧サーバーのコンテンツの方は、様々な検索エンジンにリストアップされ、いくらかのアンテナに掛かっているからいくらかの配慮が必要である。ブックマークして下さっている人も居るかも知れない。そして、契約が切れた後は、私の管理を離れることになる。契約を打ち切る前に何とかしなくてはならない。「何とかする」とは、どうするべきなのか。その中身が問題であるが、旧サーバーのコンテンツの処分方法まで考えがおよんでいなかった。

これは要するに、閲覧者の便宜を如何に図るかと云うこと。それでは、閲覧者は何を求めて当サイトにやってくるのか。大多数を占める検索経由の来訪者にとって重要なことは、検索結果が自分の興味を満たしてくれる情報かどうか判断が付くことである。この場合必要なことは、リンクが切れないようにすることのみである。つまり、何もする必要はないということになる。但し、私の管理がおよばなくなった後に、急な削除でFile Not Foundとなる可能性を考え、ロボット拒否のメタ要素をヘッドに書き加えた。

検索結果に満足し、当サイトに興味を持った来訪者は、「次のページ」や、メニュー、ホーム、自己紹介などを探してサイトの内のリンクを辿ろうとするかも知れない。そのような訪問者に対して、ページの内容をそのまま残す一方で、ページが将来削除される可能性があり、同等のページが別のアドレスに移転していることを案内するべきである。また、興味をもった閲覧者をできるだけ新しいサイトに誘導するため、各ページの目立つところに、サイトの移転と、該当ページの新アドレス、および、サイト内のリンクのほとんどが新アドレスにジャンプする旨を、書き加えた上で、サイト内リンクを新サーバーの方にかけ替えた。（こういったやり方については、かなり迷った末）

サイト移転の際に、リダイレクトという手法を使うことがある。開いたはずのURIから、勝手に他のURIにジャンプしてしまう、あれである。1000ページを越える全てのページにリダイレクトを設定するのは無理と思い、せめて、ホームやメニュー、もくじのページに取り入れようと思ったのだが、結局止めてしまった。ブックマークやアンテナ経由の訪問者はリダイレクトでも構わないと思う。しかし、検索経由の一見さんにリダイレクトをお見舞いするのは、いかがなものだろう。リダイレクトは閲覧者にとって意図せぬ動作が起こることに他ならず、気分が良いはずがない。また、分かりやすい移転の告知があれば、閲覧者は必要に応じて新サーバーへのリンクをクリックするなり、アンテナやお気に入りを修正する位のことをやるだろう。閲覧者を信頼し、任せるという態度が必要なのだろう、と思った。