「サーバで直した」で終わらせると、次の人が踏む

障害の対応で、サーバに入って設定ファイルを直接書き換える。その場は直ります。困るのは、それがどこにも書かれていないことです。

• サーバを作り直した瞬間に、その設定は消える
• デプロイ（新しい版を本番に出すこと）の仕組みは、その設定を知らないので元に戻さない
• 半年後に別の人が触ったとき、なぜそうなっているのか誰にも分からない

第1回の「人が入れ替わる」が、いちばん効いてくる場所です。

設定の置き場所は3つに分ける

いちばんよいのは、できるものはコードにすることです。naminori では、定期処理の時刻表はコードに書き、デプロイのたびにそこから作り直しています。サーバの上で直接書き換えても次のデプロイで上書きされるので、直すならコードの側、と決めています。

コードにできないものは、台帳に書く

それでもサーバの上にしか置けない設定は残ります。講座34の第7回でも触れたとおり、naminori では、サーバの上だけにある設定の台帳を作り、次の決まりで運用しています。

1. サーバの設定を変えたら、台帳に1行足す（何を・どこを・なぜ）
2. 変える前のファイルを、日時の付いた名前で退避する
3. 秘密の値は台帳に書かない。名前と役割までにする
4. サーバを作り直すときは、台帳を上から順に適用し直す

naminori の実例：設定の置き場所が2つあった

第4回の「定期処理が6週間止まっていた」件には、もう1つ原因がありました。

• データベースにつなぐための設定が、Webアプリを動かす仕組みの設定の中にだけ書かれていた
• 定期処理は別の仕組みで動くので、その設定を受け取れず、データベースにつながらなかった

直したあとは、設定を1つのファイルに移し、Webアプリと定期処理の両方がそこを読むようにしました。移す前には、すべての値が元と一致することを照合しています。

その途中でもう1つつまずきました。最初、そのファイルを管理者しか読めない権限で作ったため、定期処理が読めず、「道具は見つかるのにデータベースにつながらない」状態になりました。権限も設定の一部です。

失ったら戻らないものは、最初に退避を決める

naminori のAIキャリア診断は、回答と結果を暗号化して保存しています。その鍵はサーバの上にあり、鍵を失うと診断の回答と結果が読めなくなります。台帳には「作り直すときは、退避したファイルから鍵を移す」と書いてあります。

設定を変えたら、反映されたことまで確かめる

設定ファイルによっては、サービスを起動したときにしか読まれないものがあります。naminori で通知の鍵を差し替えたときも、ファイルを書き換えるだけでは反映されず、再起動が必要でした。差し替えの手順として、次を台帳に残しています。

• 差し替える前に退避する
• 書き換える行が1つだけであることを、先に確かめる
• 通知を送らずに、新しい鍵が有効かを確かめる
• 再起動し、動いているプロセスが新しい値を読んだことを確かめる
• 最後に1件送って、届くことを確かめる

• サーバで直接変えた設定が消える理由
• コード・サーバの上・秘密の置き場の3つ
• サーバの上だけにある設定の台帳（naminori の実例）
• 設定の置き場所が2つあった件と、反映の確かめ方