2026-08-22 公開 ／ サーバー・インフラ

予備を持つのをやめた。壊れた同期を直さず、方式ごと畳んだ判断

本番の内容を予備側へ定期的に送る仕組みを持っていました。ある時、その送り先が構成変更で無くなったあとも、送る側だけが動き続けて失敗し続けていたと気づきました。直すことはできました。直さずに、予備を持つこと自体をやめました。個人で運用するうえで、この判断が正しかったと思っている理由を書きます。

気づいた状態

構成を見直したとき、予備として使っていた側を役目ごと変更しました。そのときに「そこへ送る」処理のほうを止め忘れていました。

結果として、定期実行は毎回動き、毎回接続に失敗し、毎回失敗として記録されていました。この状態が、気づくまでの間ずっと続いていました。

失敗していたこと自体は、記録を見れば分かります。ただ、その記録を見に行く動機がありませんでした。予備は普段使わないものなので、健全かどうかを確かめる機会が来ないのです。使うのは本番が壊れたときだけで、そのときに初めて「送られていなかった」と分かります。

2つの選択肢

案1: 送り先を作り直して、同期を復活させる

素直な直し方です。予備をもう一度用意して、送り先を設定し直せば、元の構成に戻ります。

案2: 予備を持つのをやめる

こちらを採りました。理由を順に書きます。

やめた理由

1. 予備の健全性を確認し続けるコストが、予備の価値を上回っていた

予備は、持っているだけでは意味がありません。いつでも使える状態であることを確認し続けて、初めて価値が出ます。そして今回まさに、その確認をしていませんでした。

確認を仕組みとして入れることはできます。ただその確認自体もまた、壊れても誰も困らない仕組みです。確認を確認する仕組みが要る、という話になりかけました。個人の運用でこの階層を積むのは無理があります。

2. 復旧の手順書があれば、時間はかかるが必ず戻せる

機体を失った場合、新しく作り直して復旧させる手順は用意してあります。この手順を使えば、時間はかかりますが、確実に元へ戻ります。

予備を持つことで買えるのは、この時間の短縮だけです。そしてその時間を短縮する価値が、個人のサイトでどれだけあるかを考えました。答えは「短縮できたほうが嬉しいが、そのために確認の階層を積むほどではない」でした。

3. 半端な予備は、判断を鈍らせる

これが決め手でした。「予備がある」と思っていると、壊れたときに予備へ切り替えようとします。実際には予備が古い、あるいは壊れているとしても、まずそちらを試します。

そのぶん復旧が遅れます。予備が無いと最初から分かっていれば、迷わず手順書に沿って作り直しにかかれます。あやふやな予備は、無い場合より遅くなりうるということです。

やめるときにやったこと

単に止めるだけでは、また同じことが起きます。次を守りました。

• 止めるのは定期実行のほうで、処理そのものは消さない。方針が変わって復活させる可能性はあります。消してしまうと、作り直しになります
• 止めた理由を、止めた場所に書く。処理だけ残して止めておくと、後から見た人（数か月後の自分を含む）が「なぜ止まっているのか」で悩みます。悪くすると、良かれと思って再開されます
• 代わりに何で担保するかを、同じ場所に書く。「予備は無い。壊れたら手順書で作り直す」と明示しておかないと、この判断は単なるやり残しに見えます

2つ目と3つ目は、やめる判断を「やめた」と記録しないと、やり忘れと区別がつかないという点で同じです。止まっている仕組みは、意図して止めたのか放置なのか、外から見て分かりません。

「増やす」より「持たないと決める」ほうが難しい

この件でいちばん時間がかかったのは、技術的な作業ではなく持たないと決めることでした。

何かを増やす判断は正当化しやすいです。「安全のため」「万一に備えて」と言えば、それ以上の説明はあまり求められません。減らす判断のほうが、説明の負担が重いのです。「なぜ予備を持たないのか」には答える必要があります。

ただ、増やしたものには維持と確認の義務が付いてきます。そして個人の運用では、この義務を果たせる総量に上限があります。上限を超えると、増やしたもの全部が「あるつもりで機能していない」状態に向かいます。今回の失敗した同期は、まさにその状態でした。

だから今は、何かを足すときに「これを健全だと確認し続けられるか」を先に考えるようにしています。答えが「たぶん忘れる」なら、それは足すべきではなく、足さないことを明記すべきものです。

持ち帰れること

• 予備の仕組みは、失敗に気づく力が最も弱い。壊れても誰も困らないので、使う日まで壊れていることが分かりません
• 予備は持つだけでは価値が無く、確認し続けて初めて価値が出る。確認のコストを、予備の価値と比べます
• あやふやな予備は、無い場合より復旧を遅らせる。まずそちらを試してしまうからです
• やめる判断は、記録しないとやり忘れと区別がつかない。止めた理由と、代わりに何で担保するかを、止めた場所に書きます
• 処理は消さずに、起動だけ止める。方針が変わったときに作り直さずに済みます
• 足す前に「健全だと確認し続けられるか」を考える。「たぶん忘れる」なら、足さないことを明記するほうが正直です

結果として構成はひとつ簡単になりました。簡単になったぶん、残ったものを確認する余力ができています。持てる数には上限があって、その上限は思っているより低い、というのがこの件の結論でした。