止血とは

原因を突き止めるには時間がかかります。その間も利用者は困り続けます。一時対応（止血）は、原因が分かる前に、被害の広がりを止めることです。けがの手当てと同じで、まず血を止め、治すのはその後です。

止血の手段と、後から困ること

再起動の前に、証拠を残す

再起動は、たいてい効きます。だから危ないのです。メモリの中の状態、一時ファイル、固まっていた処理は、再起動で全部消えます。直ったけれど、なぜ壊れたかは分からない。そして、同じ条件がそろうと同じ障害がまた来ます。

再起動する前に、最低限これだけは残します。

• いつ、何をしたら直ったか（時刻と操作）
• その時点のログ（再起動の前後で消える・流れるものがあれば写しを取る）
• 動いていた処理やメモリ・ディスクの使い方（画面の写しでもよい）

データや設定を直す前に、退避する

本番のデータや設定を手で直すときは、直す前の状態を必ず残します。naminori では、サーバ上のファイルを変えるときは 名前.bak-年月日-時分 の形で写しを残す決まりにしています。記事の本文を書き換えるときも、先に本番の本文を退避しています。

cp -p feature.conf feature.conf.bak-20261024-1016
# （feature.conf を編集する）
diff feature.conf.bak-20261024-1016 feature.conf

1c1
< feature_apply_notify=on
---
> feature_apply_notify=off

cp -p は日時などの情報も保ったまま写します。diff で、何を変えたかを自分の目で確かめてから次に進みます。日付の部分は $(date +%Y%m%d-%H%M) と書けば、その時点の時刻が入ります。

機能を止める手段は、前もって用意しておく

「この機能だけ止めたい」と思っても、その仕組みが無ければ、コードを書き換えて公開し直すしかありません。障害の最中にそれをやるのは危険です。

naminori の AIキャリア診断には、公開するかどうかの切り替えが1つあり、切ると管理者だけが使える状態に戻せます。新しい機能を少しずつ公開するために作ったものですが、止血の手段にもなります。

また、naminori の通知の部品は、「通知は副次的な処理。通知先が止まっても、利用者のリクエストを壊さない」という方針で作ってあり、通知に失敗したら記録だけ残して処理を続けます。第2回の「応募は保存されたのに失敗と表示」は、まさにこの方針から外れた作りで起きた障害でした。ついでの処理が失敗しても本体を止めない作りにしておくと、止血そのものが要らなくなります。

サーバ上で直接変えたものは、台帳に書く

止血のために、サーバ上で設定を直接変えることがあります。そのままにすると、サーバを作り直した瞬間に消えますし、次に触る人は「本当の設定はどれか」が分かりません。naminori では、サーバ上でだけ変えた設定を一覧表（台帳）に1行書く決まりにしています。値そのもの（パスワードなど）は書かず、何を・なぜ変えたかを書きます。

失敗したら、それ以上触らない

naminori でサーバのOSを更新したときの台本は、途中で失敗したら自動で元に戻そうとせず、その場で止まって知らせるように作りました。慌てて次々と操作すると、元の状態が分からなくなり、証拠も消えるからです。止めて、状態を残して、人が判断します。

一時対応は「一時」

止血の後には、必ず「いつ、何に戻すか」と「恒久対応を誰がやるか」を残します。一時対応のまま忘れられた設定は、半年後に誰かを困らせます。

• 止血は原因より先
• 止血の手段と、それぞれ後から困ること
• 再起動の前に証拠を残す
• データや設定は退避してから直す
• 機能を止める手段と、本体を止めない作り
• サーバ上の変更は台帳に書く