サイトを停止せずに更新できますか？

既存のサイトを利用可能なまま、多くの更新を公開できます。コンテンツやデザインの変更、新しいページ、十分に準備したソフトウェアのリリースでは、よく実現できる方法です。

ただし、どの変更にも当てはまる保証ではありません。処理中の注文、会員アカウント、互換性のないソフトウェアのバージョン、インフラ、外部サービスに関わる更新では、決められたメンテナンス時間が必要になることがあります。大切なのは、サイトがオンラインかどうかだけではありません。何が引き続き使えるのか、変更をどう確認するのか、想定どおりに動かなかった場合にどうするのかを明らかにすることです。

サイトの稼働中にできる更新は？

文章の修正、画像の差し替え、新しい記事やページ、個別の見た目の調整は、サイト全体を停止せずに準備して公開できることがよくあります。サイトとリリース手順が対応していれば、小規模なソフトウェア変更も同様に公開できる場合があります。

更新の種類だけでは判断できません。一般的なコンテンツ編集でも、あるサイトではメニュー、検索、キャッシュされたページ、生成ファイルに影響し、別のサイトでは1ページだけの変更で済むことがあります。慣れた作業であっても、そのシステムの中で確認する必要があります。

「オンライン」にも実務上の意味が必要です。トップページが正常に表示されても、問い合わせ、支払い、ログイン、検索、管理機能が動作するとは限りません。事業に重要な機能は、それぞれ個別に確認する必要があります。

ステージングサイトで何を防げますか？

ステージングサイトは、変更を訪問者に公開する前に準備して確認するための別環境です。作業中に未完成のレイアウト、書きかけの文章、明らかな機能不具合が公開サイトに出るのを防ぐのに役立ちます。

ステージングは不確実さを減らしますが、なくすわけではありません。テスト用の複製は、データ、トラフィック、設定、認証情報、接続サービス、サーバー資源が本番環境と異なる場合があります。テストの成功は有用な根拠ですが、本番環境で同じ動作をする保証ではありません。

公開後に何を確認するのかは、引き続きリリース計画で定める必要があります。

空白ページを表示せずに新しいバージョンへ切り替えるには？

一つの方法は、訪問者には既存バージョンを提供し続けながら、新しいバージョンを別に準備することです。準備したバージョンをテストした後でのみ、トラフィックを切り替えます。重大な問題が見つかった場合は、以前のバージョンへ戻せることがあります。

この方法は一般にブルーグリーンデプロイと呼ばれます。AWSの説明では、異なるアプリケーションバージョンを実行する2つの環境の間でトラフィックを切り替える手法です。停止をほぼゼロにし、以前の環境へすばやく戻ることを目指します。

ブルーグリーンデプロイだけが更新方法ではありません。ファイルをアトミックに置き換えるシステム、サーバーを1台ずつ更新する方法、新バージョンに一部のトラフィックだけを送る方法、必要な準備が整ってから完成済みの機能を有効化する方法もあります。適切な方法は、サイト、ホスティング、データ、変更が失敗した場合の影響によって異なります。

データベースの変更はなぜ別扱いなのですか？

データベースには、現在の注文、アカウント、予約、フォームの送信内容、在庫、会員情報、公開済みコンテンツが保存されている場合があります。リリース中も、旧版と新版の両方がそのデータを扱える必要があるかもしれません。

ソフトウェアの一方のバージョンだけが理解できる形にデータベース構造を変更すると、以前のバージョンに戻すのが簡単でなくなることがあります。時間のかかる変更は、通常のサイト処理と資源を取り合う場合もあります。そのため、データベースの準備とアプリケーションの更新を分けたり、一定期間は新旧の構造に互換性を持たせたり、管理された単位でデータを移行したりするリリースがあります。

GitLabの公開しているデータベース移行ガイドからは、計画がどれほど詳細になり得るかが分かります。通常、デプロイ後、バックグラウンドの各移行を区別し、タイミング、可逆性、トランザクション、ロック競合への配慮を求めています。これらの具体的な方法がすべてのサイトに適するわけではありませんが、リアルタイムデータの変更には独自のリリースと復旧計画が必要という原則は広く役立ちます。

バックアップはロールバックと同じですか？

いいえ。バックアップは、保存しておき、復元できるデータやファイルの複製です。ロールバックは、リリースがうまくいかなかったとき、既知の正常な状態に戻るために準備しておく手順です。

バックアップの復元には時間がかかる場合があり、作成後に発生した有効な注文、問い合わせ、編集、アカウント変更を上書きすることもあります。サイトのコードはすぐ戻せても、データベース変更や、外部の決済、予約、メールサービスですでに完了した処理までは取り消せないことがあります。

責任ある計画では、元に戻せるもの、追加の修正で対応するもの、変更中に作成されたデータの扱いを明らかにします。AWSの変更失敗時のガイダンスは、デプロイ前に復旧手順を準備し、監視によって変更の成否を判断することを勧めています。

更新後も古いページが表示されることがあるのはなぜですか？

更新中もサイトを利用できる一方で、訪問者によってページやファイルの異なるバージョンが短時間表示される場合があります。ブラウザー、コンテンツ配信ネットワーク、サーバーキャッシュ、生成ページは、期限切れ、再検証、または意図的な削除まで古い内容を保持することがあります。

これは停止とは異なります。それでも、価格、規約、キャンペーン情報、在庫状況など、時間に敏感な情報を変更する場合には重要です。

キャッシュの削除範囲も適切にする必要があります。Cloudflareは可能な限り対象を絞った削除を勧めています。キャッシュ全体を消去すると、内容が再びキャッシュされるまで、その後のリクエストがオリジンサーバーに戻るためです。すべてのキャッシュを一括で捨てるのではなく、変更したページやファイルをリリース計画で特定しましょう。

メンテナンス時間を設けるのが適切なのはどんな場合ですか？

更新中にサイトを完全稼働させることのリスクが、短時間の告知済み中断より大きい場合、メンテナンス時間が適切なことがあります。たとえば、次のような場合です。

• 更新中にリアルタイムデータを安全に変更できない。
• 旧版と新版が同じデータ構造で動作できない。
• インフラやネットワーク経路を一度の管理された手順で変更する必要がある。
• 外部サービス提供者が中断を求めている、または並行テストの方法がない。
• 安全な稼働中の変更に必要なほど、現行サイトをまだ把握できていない。
• 一定時間作業を止めた方が、復旧を明確かつ迅速に行える。

メンテナンス時間には、理由、範囲、見込み時間、復旧判断、連絡計画を定めます。問い合わせ、注文、予約、会員アクセスに依存する事業では、「メンテナンスのためサイトを停止します」という案内だけでは不十分です。

更新を承認する前に何を確認すべきですか？

• どのページや機能が変わりますか？
• 作業中、訪問者やスタッフは何を引き続き利用できますか？
• 変更は公開サイトとは別の環境で準備しますか？
• 問い合わせ、支払い、予約、アカウント変更などのリアルタイムデータをどう保護しますか？
• リリース成功を確認するため、どのような検査を行いますか？
• 検査に失敗した場合の復旧計画は何ですか？
• 有効な新しいデータを取り消さずにソフトウェアを戻せますか？
• ホスティング、決済、メール、本人確認、予約などの外部サービスが時期に影響しますか？
• 続行、修復、ロールバックの判断は誰が行いますか？
• 影響を受ける利用者に、いつ、どのように知らせますか？

回答で技術的なコマンドをすべて説明する必要はありません。事業への影響が分かることが大切です。

LINK-Vはサイト更新にどう取り組みますか？

サイトを評価または保守する際、公開方法を決める前に、サイト、ホスティング、CMS、データベース、連携、バックアップ、アクセス権、運用上のリスクを確認します。適切な方法は変更内容と既存のシステムによって異なります。

通常の更新は落ち着いて適切な範囲で行い、中断を管理する必要がある場合は率直にお伝えすることを目指しています。日々の販売、問い合わせ、予約、会員サービス、情報発信をサイトで支えている場合は、保守体制と継続的なケアを評価できます。