珍しく,さくらインターネットの一部ネットワーク障害で23時頃から10分ほどデライトが応答不能になった。捌き手自体は正常に動いていたが,ウェブ捌きから出場捌きへの ping
が通じなかった。会員メニューも同様に応答せず,ネット上に同様の報告が複数あったためネットワーク障害の可能性が高いと判断したが,しばらくして公式情報が出た。
SSH 筒路の再接続が必要だったため,離れていたら長時間サービス停止の可能性があった。対策を練っておく。
ping
}{希哲16年11月19日}{希哲16年11月19日の副日記}{公式情報}{対策を練っておく}{サービス停止}{同様の報告}(41)最近安定していたデライトが今日に限って妙に壊衝しているなと思い,17時30分頃から本腰を入れて調査開始。
ここのところ出振るいしていないため実装の問題とは考えにくく,出力録を見ても違了の痕跡が無いため,deln_tmo.cron の誤作動であることはすぐに見当が付いた。出力録譜類を見ると,昨日30日のちょうど23時から譜類が激増していたため,何らかの期限による問題であると気付いた。
試しに wget を実行してみると,SSL 証明書の検証で失敗していた。有効期限はまだ少し先だが,調べてみると Let's Encrypt のルート証明書に関する問題で,以前から警告されていたらしい。
18時前,いったん –no-check-certificate
を付けて対処した。似たような問題は将来的にも起こりうるので,根本的な改善策を見つけたい。
今後,「古い環境」に Let's Encrypt 自体が正式には対応しなくなるという話だが,その古さというのが希哲10(2016)年以前とのこと。もともとデライトは古い舞覧への対応に手が回っていないため,実質的な非対応舞覧に近く,大きな影響は無いだろう。
今後,対応舞覧を広げる時に Let's Encrypt の採用継続を検討することにした。
どうも1分間隔で落とされては0.1秒後に再起動するということを繰り返していたようだ。違了処理と輪郭選り手抜控機能のおかげもあり致命的な問題にはならなかった。
さらに本腰を入れて調査開始してから30分ほどの解決で,ついこのあいだのデバッグ環境整備の効果を実感することも出来,障害対応の良い経験になった。