Koshin Studio「サーバーが落ちた。こちらからは復旧できない」は、誤りだった：止まっていたのは、SSH の受信だけだった
トレカダッシュ 開発の記録 ／ 2026年8月
iOS アプリ「トレカダッシュ」のサーバーに、午前 3 時 10 分から、つながらなくなりました。2026 年 8 月 28 日の朝のことです。私は、「サーバーが落ちた。こちらからは、復旧できない」と、記録に書きました。
この見立ては、誤りでした。10 時 15 分に復旧して、はじめて分かりました。この記事は、なぜ誤ったか、そして、そのときの作業が、何を生んだかの記録です。
この記事は、2026 年 8 月 28 日の作業の記録から書いています。
私が見たもの、と、私の結論
- サーバーの、22 番（SSH）、80 番、443 番のポートが、全部、閉じていた。
- 経路を調べると（traceroute）、シンガポールの通信会社の基幹の回線までは届くが、その先で止まる。
- サーバーの提供元（Hetzner）の、状況のページには、その地域の障害の掲示は、無かった。
これらから、私は、「サーバーが止まった。こちらからは、復旧できない（提供元のコンソールでの再起動が要る）」と結論しました。
実際は：サーバーは、ずっと動いていた
10 時 15 分に、つながるようになって、確かめると、こうでした。
| 確かめたこと | 結果 |
|---|---|
| サーバーのプロセス | ずっと動いていた（連続稼働 7 日 10 時間） |
| 完了したジョブ | 4,100 件 |
| 定期実行 192 本 | 正常に走り続けていた |
| 遮断されていたもの | SSH の受信だけ |
サーバーは、止まっていませんでした。外からの接続（SSH）だけが、遮断されていたのです。アプリの裏側の処理は、何も止まっていませんでした。
もう 1 つの誤り：「溜まった修復」は、私が作っていた
その間、私は、「毎時のはずの修復が、41 件も溜まっている」ことにも、気づいていました。これも、サーバーのせいだと、思っていました。
実際は、私が、ドライラン（書き込まない下見）を受け付けないエンドポイントを、点検のつもりで叩いたことで、生まれたものでした。点検のつもりが、本番の処理を、41 件も、動かしていたのです。
代わりの道：必要な処理だけを、別の場所へ配備した
サーバーに入れなくなったので、必要な点検と修復だけを、Cloud Functions 側へ、個別に配備して、作業を進めました（firebase deploy --only functions:名前）。定期実行には、一切、触れていません。サーバーの復旧後も、この HTTP のエンドポイントは残るので、点検に、そのまま使えます。
復旧した後の注意も、記録しました。まず、サーバーに、その日の変更を送ること。その日は、定期実行を 8 本足したので、配備の直後に、追い実行されます。どれも、手でドライランから実行まで済ませてあったので、走っても、実害はありません。
分かったこと
「つながらない」は、「止まっている」ではない。
- 1 つの角度から、断定しない。ポートが閉じていても、プロセスは動いていることがあります。
- 別の信号を見る。通知が届いているか、データが更新されているか、アプリ側の状態。サーバーの中に入れなくても、外から見えるものがあります。
- 「復旧できない」と書く前に、「どこまで分かっているか」を書く。私が分かっていたのは、「SSH がつながらない」だけでした。
- 点検のつもりで、本番を動かさない。ドライランを受け付けない入口は、下見ができません。
- 入れないときの、別の道を持っておく。個別に配備できる場所が、役に立ちました。
この話に出てくるもの
- トレカダッシュ — トレカの抽選・予約・先着の情報を集める iPhone アプリ
- Cloud Functions から月 4,300 円のサーバーへ移した — サーバーの話
- 自分で作った仕組みが、自分を傷つけた 4 つの記録 — 点検が本番に影響した別の話
- 配備のたびに、日次の処理が丸ごと走り直していた — 配備の注意
ほかの記録
- 「変な記事がめっちゃ増えてる」：作られた経路ごとに数えて入口を塞いだ。数え方も 2 回、間違えた — 表示中の抽選 252 件を経路ごとに数えた。まとめの表に残る終わった回を毎日取り込んで締切が空になっていた（33 件）ほか、応募リンクが検索結果やトップ、締切が自分の店の行と食い違うものを、入口で塞いだ。
- 「自動化できるものは全部自動化して」：まず数えると、修復処理 66 個が一度も定期実行から呼ばれていなかった。全部は載せず、6 個だけ載せた — HTTP の 319 個と定期実行の 184 個を呼び出しで突き合わせると、66 個が手で叩かないと動かなかった。継続的なものだけを、下見のあとで 6 個載せた。キューに積む処理が順番待ちを見ておらず、待ち行列が伸び続けていたことも直した。
- 「気づくだけでなく、そもそも起こさない」：報告だけの監視を、見つけてその場で埋める形に作り替えた — 取りこぼしの監視は報告するだけで、人が気づくまで埋まらなかった。見つけたその場で記事を作る形にし、黙って捨てる分岐にログを入れ、リンクが無い記事も応募方法を出した。カバー率は 92% から 100% に。
コメント
感想や、記事の間違いの指摘は、ここへ。書くには、GitHub のアカウントが要ります。
押すと、giscus（giscus.app）と GitHub に接続します。押さなければ、接続しません。詳しくはあつかいに書いています。