サイトの差し替えを止めずに行う手順|旧ファイルを消さない入れ替えと、切り戻しを残す順番
サイトの差し替えを止めずに行う手順|旧ファイルを消さない入れ替えと、切り戻しを残す順番
ホームページのデザインを新しくした。テーマを入れ替えることになった。制作会社から新しいファイル一式が届いた。このとき、公開中のフォルダをそのまま上書きするやり方は避けてください。
先に結論を書きます。同じサーバーの中でサイトを差し替えるときの正しい手順は、「消して入れる」ではなく「並べて置いて、名前を入れ替える」です。
- 今動いている一式を、手元とサーバーの両方に別名で残す
- 新しい版は、公開フォルダではなく別のフォルダへ置く
- 置いたものが欠けていないか機械的に照合する
- 最後にフォルダ名を入れ替えて切り替える(ここだけが一瞬)
- 切り替え後、目視ではなく数字で確認する
この形にすると、訪問者から見た停止時間はフォルダ名を入れ替える一瞬だけになります。そして問題が起きたときは、名前をもう一度入れ替えるだけで元に戻せます。
弊社は名古屋でホームページ制作と運用を行っています。この記事では、実際に84ファイル・11MBのテーマを本番差し替えしたときの手順と実測値をもとに、順番と確認方法を書きます。サーバーを引っ越す場合(ドメインの向き先を変える移転)は判断すべきことが別なので、そちらは別記事に譲ります。ここで扱うのは同じサーバーの中でファイルを入れ替える局面です。
—
なぜ「上書き」ではなく「入れ替え」なのか
公開フォルダを直接上書きすると、次の2つが同時に起きます。
1つ目は、停止時間が転送時間そのものになること。 ファイルを1つずつ送っている最中、サイトは「新しいファイルと古いファイルが混ざった状態」で公開され続けます。デザイン用のファイルだけ新しくなって、それを呼び出す側のファイルがまだ古い、という状態が数分続きます。この間に来た訪問者には、崩れた画面が表示されます。ファイル数が多いほど、この時間は伸びます。
2つ目は、戻す先が消えること。 上書きした瞬間、元のファイルはサーバー上から失われます。「戻したい」と思ったときに戻すものがない、という状態です。
入れ替え方式は、この2つを両方なくします。新しい版は別のフォルダに完成させておく。公開フォルダはその間ずっと古い版のまま、正常に動き続ける。最後にフォルダの名前を2回変えるだけで切り替わる。名前の変更はサーバー内部の操作なので、ファイル数がいくつあっても一瞬で終わります。
—
手順1:今動いているものを、2か所に残す
差し替え作業で最初にやるのは、新しいファイルを触ることではありません。今動いているものを確保することです。
保存先は2か所にします。
| 保存先 | 目的 |
|---|---|
| 手元のパソコン(またはローカルの作業フォルダ) | サーバー側で何が起きても残る。中身を比較する材料にもなる |
| 同じサーバーの中の別名フォルダ | 切り戻しが最速。名前を戻すだけで復旧する |
実際の作業では、公開中の一式(84ファイル・約11MB)を丸ごと手元へ取得したうえで、同じものをサーバー内にも テーマ名-バックアップ-日付時刻 という別名で置きました。日付と時刻をフォルダ名に入れておくと、後から見たときに「いつの版か」が名前だけで分かります。
サーバー内のコピーが効くのは、切り戻しの速さです。手元からアップし直すと、ファイル数が多い場合は数分から十数分かかります。サーバー内に置いてあれば、名前を変えるだけなので即座に戻ります。トラブル対応のときに、この差は大きく効きます。
ここで1つ注意があります。サイト全体のバックアップと、差し替える部分のバックアップは別物です。データベースを含むサイト全体のバックアップ(記事や設定を含むもの)は、それはそれで公開前に取っておくべきものです。実際の案件では、大きな変更の直前にサイト全体のバックアップ(約1.0GB)を別途作成しています。ただし、これは「サイト全体を巻き戻す」ための道具であって、デザインファイルだけを戻したいときには重すぎます。差し替える範囲のバックアップを、それとは別に用意してください。
—
手順2:新しい版は、公開フォルダの外に置く
新しいファイル一式は、公開中のフォルダではなく、別名の新しいフォルダへアップロードします。
このとき、フォルダ名には作業日時を入れておきます。テーマ名-新版-日付時刻 のような形です。作業が途中で中断しても、公開中のサイトには一切影響が出ません。何日かかっても構いません。訪問者は古い版を普通に見続けています。
この段階を挟むことのもう1つの利点は、アップロード自体の失敗を切り離せることです。回線が切れた、途中で止まった、権限で弾かれた。こうしたことは実務では普通に起きます。公開フォルダの外で起きている限り、それは「やり直せばいい作業」で済みます。
—
手順3:置いたものが欠けていないかを、機械的に照合する
ここが、この手順で最も重要な工程です。
アップロードは、静かに失敗します。 転送ツールは全ファイルを送ったつもりでも、実際には一部が0バイトで届いていたり、途中で切れていたり、文字コードの扱いで中身が変わっていたりすることがあります。そしてその多くは、画面を見ただけでは分かりません。
確認方法は、アップロードしたものを再びダウンロードして、手元の原本と1ファイルずつ突き合わせることです。ファイルの中身から計算される固定長の値(ハッシュ値)を両方で計算し、全ファイルで一致するかを見ます。実案件では84ファイル全件を照合し、不一致0を確認してから切り替えに進みました。
「目で見て確認しました」では足りません。1文字違うだけで動かなくなるファイルもあれば、1ファイル欠けているだけで表示が崩れるファイルもあります。全件を機械的に突き合わせて、はじめて「同じものが載っている」と言えます。
制作を外注している場合、この工程は依頼相手にやってもらうものです。差し替え作業を依頼するときに「アップロード後に全ファイルの照合をお願いします」と一言添えるだけで、事故の確率は大きく下がります。
—
手順4:名前を入れ替えて切り替える
照合が終わったら、切り替えます。作業はフォルダ名の変更2回だけです。
- 公開中のフォルダ
テーマ名→テーマ名-旧版-日付時刻に改名 - 新しいフォルダ
テーマ名-新版-日付時刻→テーマ名に改名
この2つは続けて実行します。1つ目と2つ目の間だけ、一瞬フォルダが存在しない状態になりますが、これはファイルの転送と違って一瞬で終わります。
この形にしておくと、切り戻しが「名前をもう一度入れ替えるだけ」になります。 新しい版で問題が見つかっても、慌てて手元からアップロードし直す必要がありません。順番を逆にたどるだけです。この安心感があると、確認作業を冷静にやれます。
—
手順5:切り替え後は、目視ではなく数字で確認する
切り替えたら、確認です。ここで見るべきものは決まっています。
実際の差し替えでは、次の項目を実測しました。
| 確認項目 | 結果 |
|---|---|
| 主要11ページのアクセス結果 | 全て正常応答(トップ・サービス2種・料金・エリア・事例・FAQ・会社概要・問い合わせ・プライバシー・特商法) |
| 配信されているテーマのバージョン表記 | 新しい版の番号になっていること |
| 検索避けの設定 | 意図した状態が維持されていること |
| プログラムのエラー表示 | 4ページで0件 |
| デザインファイルの中身 | 手元の原本とハッシュ値が一致 |
| スマホ向けの修正内容 | 配信されているファイルに含まれていること |
トップページだけ見て終わらせないでください。 確認するページの一覧は、作業前に作っておきます。行数のあるリストにして、上から順に潰していく形が確実です。
見た目では気づけない壊れ方がある
ここが実務で一番怖いところなので、詳しく書きます。
差し替え後に起こりうる壊れ方の中には、訪問者にとっては何も異常がなく、サイトも正常に表示され、エラーも一切出ないのに、検索エンジンから見た中身だけが壊れているというものがあります。
典型的なのが、検索エンジン向けに用意していたページの中身だけが、切り替え作業の後に元の簡易版へ戻ってしまうケースです。このとき周辺のファイルは全て正常に残るため、「ページが開けるか」「エラーページが正しく出るか」といった確認は全部合格してしまいます。訪問者から見れば何の問題もありません。壊れているのは、検索エンジンが読み取る部分だけです。
この種の欠損を検知する方法は1つです。ページの中身そのもの(タイトルタグの文字列やファイルの容量)を実測して、期待する値と突き合わせること。実際に運用しているサイトでは、正常な状態のファイルが50〜150KB、戻ってしまった状態が約5KBと10倍以上の差になるため、容量を見るだけでも判別できます。
そして、この確認は人の記憶に頼らない形にしておくべきです。この種の巻き戻りは、1日のうちに2度起きることもあります。よくある原因は2つで、ひとつは後述する削除を伴う同期でファイルごと消えること、もうひとつは切り替えの後に必要な生成処理を実行し忘れることです。どちらも人間の注意力で防ぐ種類のものではないので、確認手順そのものを一覧化して、作業の最後に必ず実行するものとして固定してください。制作を外注しているなら、「切り替え後の確認項目」を納品物としてもらっておくのが実務的です。
確認方法そのものが間違っていることもある
もう1つ、確認作業で起こりやすい取りこぼしを挙げます。
設定が正しく維持されているかを確かめるとき、確認する側の書き方が実際の出力とわずかに違うだけで、正常なのに「消えている」と判定してしまうことがあります。引用符の種類がシングルかダブルかという、それだけの違いで起こります。
教訓は単純です。「無い」という確認結果が出たときは、まず自分の確認方法を疑う。 特に、直前まであったはずのものが「無い」と出たときは、探し方のほうが間違っている可能性が高いです。実際の出力を一度そのまま画面に出して、目で形を確かめてから判定してください。
—
差し替えで最も危険なのは「削除同期」
ここまでの手順とは別に、差し替え作業でどうしても触れておくべきリスクがあります。転送ツールの「同期」機能です。
多くの転送ツールには、「手元のフォルダとサーバーのフォルダを同じ状態にする」という同期機能があります。便利な機能ですが、この設定には手元に無いファイルをサーバーから削除するというオプションがあり、これが有効になっていると、差し替えのたびに「手元の作業フォルダに入っていないファイル」が消えます。
消える対象になりやすいのは、後から個別に追加したファイルです。検索エンジン向けに生成したページ一式、エラーページ、サーバーの動作設定ファイル、サイトのアイコン画像などが該当します。これらは制作時の作業フォルダには入っておらず、後の改善作業でサーバーへ直接置かれたものであるため、同期の対象から漏れて削除されます。数時間前に実施したSEO改修が丸ごと巻き戻る、ということが実際に起こり得ます。
この事故が厄介なのは、「上書きされるファイル」だけを気にしていると絶対に気づけない点です。注意が向くのは「今から送るファイル」であって、「送らないから消えるファイル」ではありません。
防ぎ方は2つあります。
- 差し替えの前に、サーバー側のファイル一覧を取得して、手元の作業フォルダと突き合わせる。 サーバーにあって手元に無いファイルが1つでもあれば、削除同期は使えないと判断します。この確認自体は数十秒で終わります
- 削除を伴う同期は、原則として使わない。 追加と上書きだけの転送で足ります。不要になったファイルは、後から個別に消せば済みます
そして、削除を伴う操作は取り返しがつきません。 バックアップを取っていない状態でこの種の操作を実行すると、復元手段がなくなります。手順1のバックアップを飛ばさないでください。
—
「戻せる形」を設計に組み込む
ここまでは差し替えの手順の話でしたが、もう一段先の考え方も書いておきます。そもそも、元のデータを書き換えない形で変更を当てるという設計です。
既存サイトのデザインや文言を改善する案件で、次のような構成を採ったことがあります。
- 既存のページ編集ツールが持っている元データは、一切上書きしない
- 変更内容は、追加する部品の側に持たせて、表示のときに上から当てる
- 元に戻したいときは、その部品を止めるだけ
この形にしておくと、「一部だけ戻したい」「一旦全部戻して考えたい」という要望に、その場で応えられます。実際の運用でも、変更のたびに版番号を上げていき、1つ前の版に差し替えれば直前の状態に、部品ごと止めれば改善前の状態に戻る、という状態を維持しました。
すべての案件でこの形が取れるわけではありません。ただ、「戻す手段があるか」を発注時に確認する価値はあります。制作会社に依頼するとき、次の3つを聞いてみてください。
- 差し替え前のファイルは、どこに、いつまで残りますか
- 問題が起きたとき、元の表示に戻すまでにどのくらいかかりますか
- 戻す作業は、追加費用の対象になりますか
この3つに具体的に答えられる相手であれば、手順の設計はできています。
—
まとめ:差し替えの前に決めておく3つ
サイトの差し替えは、作業そのものより順番の設計で結果が決まります。着手前に次の3つを決めておいてください。
- バックアップの置き場所を2か所決める。 手元とサーバー内。サーバー内のコピーがあると、切り戻しが名前の変更だけで済みます
- 確認するページの一覧を作る。 トップだけ見て終わらせない。切り替え後に上から潰していくリストを、作業前に用意します
- 削除を伴う同期を使わないと決める。 使うなら、事前にサーバー側のファイル一覧と突き合わせる。ここを飛ばすと、過去の改善が静かに巻き戻ります
そして、切り替えそのものは最後に一瞬で済ませる。新しい版を別の場所に完成させてから、名前を入れ替える。 この形であれば、訪問者を待たせることも、戻せなくなることもありません。
ホームページの差し替えやリニューアルで、手順の組み方や確認項目の設計にお困りでしたら、お気軽にご相談ください。