更新の作業時間を決める：停止・中止・再開の担当表

公開日: 2026-09-14 ／運用・復元 #更新 #運用設計 #停止時間

更新の予定には、開始時刻だけでなく、中止する時刻と再開を確認する人も書く。動かなかった時の復元までが作業時間に収まるかを先に確かめる。

作業の名前を具体化する

「サーバー更新」では、OS、Docker、DB、アプリのどれを変えるのかが分からない。対象の現在版と変更先、設定差分、DB変更の有無を分ける。すべてを同時に変えるほど、問題の原因と戻す対象が増える。

Docker Composeでは再起動と構成変更の適用は同じ操作ではない。restartの公式資料は、Composeファイルの変更がrestartでは反映されないと説明する。設定を直して再起動しただけで、反映済みと記録しない。確認日: 2026年9月14日。

操作の違いは再起動・更新・復元の手順整理にまとめている。実行前に業務側へ渡す予定は、下の作業票で作る。

下表は実績ではなく、各チームで埋めるための書式だ。日時と担当が空欄のままなら、変更を開始する前に決める。

「バックアップを取得済み」と「その保存物を戻せる」は違う。初めて戻す操作を停止時間の最後に試す計画にはしない。サンプル復元の照合項目を出発点に、実アプリに必要な確認を加える。

架空の作業枠を60分とし、復元と確認に25分、連絡に5分を確保する例なら、更新を試し続けられるのは最大30分になる。これは推奨時間でも、実際の復元時間でもない。自分の環境で確認した作業量へ置き換える。

停止時間を全部更新に使うと、失敗を判断してから戻す時間がない。逆に、復元に必要な時間が分からないなら、60分の枠で戻せると約束できない。

新しいアプリがDBの構造やデータを書き換えた後、古いアプリが同じDBを扱えるとは限らない。対象リリースの更新・切戻し手順を読み、戻す単位を決める。データを失う可能性がある手順なら、業務側へ影響を説明したうえで実行者が計画する。

外部APIの変更も同じ作業枠に重なる場合は、自分のサーバーを戻すだけで解消するかを確認する。外部の障害や変更まで「サーバーを再起動すれば戻る」とまとめない。

トップページの200だけで終えず、対象となった機能の読み込み・保存・処理を、許可された試験データで確かめる。定期処理なら最後の成功対象と未処理分を照合する。監視の記事に、HTTPが正常でも処理が古い例がある。

予定の時間に担当者が対応できない場合は、日程を変えるか担当を用意する。自己管理の負担が続けられないなら、管理サービスの担当境界へ戻り、契約で引き受けてもらえる作業を確認する。