コードは書いた。heartbeatの監視ロジックも実装した。.envもある。Railwayにもデプロイ済み。自動化OSは稼働中のはずだった。
でも、何かが引っかかっていた。
ログを見ると、監視のpingが一度も飛んでいない。通知も来ていない。「あれ、タイミングの問題かな」と思いながらコードを開いた瞬間、気づいた。
if name == “main“:
start_heartbeat()
この一行。全部ここに書いていた。
本番はgunicornで動いている。mainは一度も呼ばれない。つまり、heartbeat監視は一度も起動していなかった。デプロイした日からずっと、監視ゼロの状態で本番が走り続けていた。
「監視している」と思っていた自分が、最も危うい状態だった。
Turning Point（転換）―― 「壊れている」ではなく「見えていなかった」
問題はコードの品質ではなかった。
実行環境の違いを無視して書いたことが原因だった。ローカルではpython3 server.pyで動かすからmainに入る。本番のgunicornはそうじゃない。この差を埋めるだけでよかった。
dashboard/app.pyのstartup()関数にheartbeatの起動処理を移植。gunicornが立ち上がった瞬間に実行されるフックに乗せた。デプロイして、ログを眺める。
pingが飛んだ。それだけのことだったが、「稼働確認」と「稼働の実態」がようやく一致した瞬間だった。
同じ日、.envの棚卸しも着手した。
空のトークン。存在しないアカウントの変数。2つの変数が1行に結合した破損行。Bangkok
PeachのLINEトークンが401エラーを返し続けていて、自動返信が静かに止まっていた。ユーザーには届いていない。通知も来ない。止まっていることすら、気づけない状態。
「動いている」と「壊れていない」は別物だ、と改めて実感した。
トークンを棚卸しして、死んでいる変数を削除し、必要なものを再発行。Railwayに反映して、レスポンスを確認する。200 OK。
自動返信が再び動き出した。
Block 3「After（希望）」―― 「ゼロ」を確認できる仕組みへ
今日直したのは2つ。でも、本当に直したのは「確認できない状態」だった。
コードがあるから動いている、は思い込みだった。デプロイしたから反映された、も確認するまでは仮説に過ぎない。自動化を信頼するためには、「動いていることを証明する仕組み」が先にいる。
完璧なシステムはない。でも、壊れたときに気づけるシステムは作れる。
自動化を本気で使い倒したいなら、動かすことより「壊れをキャッチする設計」に時間をかけた方が、結果的に速く進める。今日、それを体で理解した。
次は、監視の通知先をLINEに直結させる。止まった瞬間にスマホに届く。それが整えば、ようやく「安心して任せられる」自動化OSに一歩近づく。
コメント