本文へスキップ
Articles

2026-08-21 公開 / やらかした話

使われていない入口が開いたままだった。撤去を「中身」からしかやっていなかった

サーバーの設定を 点検していて、外から入れる口が1つ、使っていないのに開いたままになっているのを見つけました。その口の先へ実際に繋いでみると、受け取る相手はとっくに存在しません。機能しない入口だけが、誰でも叩ける状態で残っていたことになります。なぜ残ったのか、閉じるときに何を確認したのかを書きます。

見つかったもの: 先に何も無い入口

もともとは、別で動かしていたサービスへ中継するために開けた口でした。外から来た通信を、内側の別の場所へそのまま流す設定です。

そのサービスは、しばらく前に使うのをやめていました。やめたときに消したのは、動かしていた実体のほうです。プログラムも、データも、置き場所も片付けました。ところが「そこへ通す」という設定と、そのための入口だけは残っていました。

だから状態としてはこうなります。

公開しているページのどこからも、この口は参照されていませんでした。誰も使っていない、機能もしていない、それでも開いている。そういう状態です。

なぜ残ったのか: 撤去を中身側からしかやっていない

原因は単純で、片付けの手順が「中身を消す」で終わっていたからです。

何かをやめるとき、意識が向くのは実体のほうです。動いているものを止めて、ファイルを片付けて、置き場所を消す。ここまでやると「片付いた」という感覚になります。実際、動作としては完全に止まっています。

しかしそこへ至る経路は、実体とは別の場所に書かれています。入口を開ける設定、中継する設定、名前を解決する設定。これらは実体を消しても自動では消えません。そして消し忘れてもエラーになりません。通す先がいないだけで、設定としては正しく成立しているからです。

「動かなくなったこと」と「到達できなくなったこと」は別です。止めれば動かなくなりますが、入口は開いたままになりえます。片付けの完了条件を「動いていないこと」にしていると、この差が毎回残ります。

閉じる前に確認したこと: 自分が締め出されないか

閉じる作業自体は、設定を1行削って反映するだけです。ただしこの反映の仕方に落とし穴があり、そこは慎重にやりました。

この種の設定には、多くの場合2つの状態があります。

危ないのは、この2つがずれている場合です。作業中に一時的なルールを足したまま保存していないと、今は繋がっているのに、読み込み直した瞬間にその一時的なルールが消えます。そして管理用の接続がそのルールに依存していたら、反映した瞬間に自分が閉め出されます。閉め出された先には、繋いで直す手段がありません。

そこで、削除を反映する前に「今動いているルール」と「保存されているルール」を突き合わせて、管理用の接続に関わる分がどちらにも存在することを確認しました。一致していれば、読み込み直しても接続は維持されます。

この確認は数十秒で終わります。やらずに反映して閉め出された場合の復旧は、数十秒では済みません。

閉じたあとに確かめたこと

反映後、影響が無いことを一通り確認しました。

最後のひとつが本題ですが、他の3つを確認しないと「閉じた」とは言えません。閉じることは簡単で、閉じすぎることのほうが起こりやすいからです。

撤去の完了条件を書き換えた

この件のあと、何かをやめるときの手順に項目を足しました。「実体を消したか」だけでなく「そこへ至る経路を消したか」を別項目にするという変更です。

経路は実体より分散しています。入口の設定、中継の設定、参照しているリンク、名前の登録。実体は1箇所ですが、経路は複数の場所に散っています。だから「実体を消した」の勢いで一緒に消えることは、まずありません。

そして経路だけが残っても、何のエラーも出ません。それが一番の問題です。壊れているなら気づけますが、これは壊れていません。ただ意味を失ったまま、開いています。

私は今、やめる作業を「外から内へ」の順でやるようにしています。先に入口を閉じ、次に経路を消し、最後に実体を片付ける。この順なら、途中で作業が中断しても開いたまま忘れられる状態にはなりません。逆順だと、最後の工程を飛ばした時点で今回と同じことが起きます。

持ち帰れること

この口が見つかったのは、定期的な点検の中でした。普段の運用では絶対に見つかりません。使っていないものは、使っていないがゆえに目に入らないからです。「今使っているもの」を確認する作業と、「開いているものを全部数える」作業は別物だと考えるようになりました。