戻せる変更にしておく

デプロイ（新しい版を本番に出すこと）で問題が出たとき、すぐ前の版に戻せるかで、障害の長さが決まります。戻せる変更にするための考え方は3つです。

• 小さく出す: 一度に出す変更が小さいほど、何が原因か分かり、戻すのも簡単
• データの変更は、古い版でも新しい版でも動く形にする: 第2回の「広げる → 埋める → 締める」は、そのための手順でもある。列を足しただけの段階なら、古い版に戻しても動く
• 戻せない変更は、別に出す: データを消す・埋め直すなど、戻せない変更はほかの変更と混ぜない

機能フラグ：出すことと、見せることを分ける

機能フラグは、コードは本番に出しておき、誰に見せるかを設定で切り替える仕組みです。

naminori のAIキャリア診断は、この形で作りました。

• 公開のフラグが OFF の間は、管理者としてログインしている人だけが使える
• フラグは管理画面から切り替えられる。デプロイしなくても、公開・非公開を変えられる
• 回答を暗号化するための鍵が無い環境では、フラグに関係なく機能ごと止まる

こうしておくと、本番の本当のデータと環境で管理者が先に確かめてから公開でき、問題があればデプロイせずにすぐ引っ込められます。ただし、フラグは増えるほど組み合わせが増えます。公開して落ち着いたフラグは、片付ける予定も一緒に決めておきます。

デプロイの手順を1本にする

デプロイのやり方が人によって違うと、事故が起きたときに何が違ったのか分かりません。naminori では、デプロイは1つのスクリプトで行い、変更は必ずレビューの仕組み（プルリクエスト）を通してから本番に出します。スクリプトは、必要な設定がそろっているかを先に確かめ、本番に出す前には確認を求めます。

OSと部品の更新を止めない

OS・データベース・言語・ライブラリには、サポートの期限があります。期限が過ぎると、見つかった脆弱性（セキュリティの穴）が直されなくなります。

更新を後回しにすると、一度に上げる段数が増えます。naminori の本番サーバの更新（2026年10月）は、まさにそうでした。

• データベースの古い版は、本家のサポートが2026年11月で終わる予定だった
• OSは、新しい版へ直接は上げられず、2段階（1つ上の版を経由）で上げる必要があった
• 夜中にメンテナンス表示を出して作業し、止めていた時間は44分（上限は90分と決めていた）

止めて行う更新は、準備が本体です。naminori では、事前に次を確かめました。

• 今のプログラムが、新しいOSの上でもそのまま動くか（手元で再現して確認）
• データベースを新しい版に移したとき、全テーブルの件数が一致するか（106テーブルが一致）
• 途中で失敗したときの戻し方（段階ごとの戻し方と、サーバ全体の写しから戻す方法）

小さな更新は、利用者の少ない時間に自動で

一方、日々の小さな更新は自動で当てています。ただし、自動更新の時刻を既定のままにしていたところ、平日の午後3時台にデータベースの更新が入って約4秒止まり、その間のアクセス2件がエラーになりました。そこで、自動更新の時刻を深夜3時に変えています（この変更もサーバの上だけの設定なので、台帳に書いてあります）。

言語の版を脆弱性の対応で上げたときは、古い版も戻す用に残してから切り替えました。

この講座のまとめ

• 保守運用の第一前提は、長期的に困らない設計を最初からすること
• データは、広げる → 埋める → 締める。新しい約束は新しいデータにだけかける
• 「動かなかった」ことに気づく仕組みを、処理と一緒に作る
• 通知は重さと行き先を分け、次にやることを添える
• ログは、いつ・誰が・何を。出さないものと、残す期間を決める
• 設定はコードに。できないものは台帳に
• 戻せる形で出し、更新を溜めない

• 戻せる変更にする3つの考え方
• 機能フラグで、出すことと見せることを分ける（naminori の実例）
• デプロイの手順を1本にする
• OSと部品の更新を止めない、講座のまとめ