カレンダー

2020/07
   
161718
19202122232425
262728293031 
       

広告

Twitter

記事検索

ランダムボタン

2度あることは3度ある

by 唐草 [2020/06/19]



 今週に入ってから職場のリモート授業を支える要のWebサーバの調子が悪くなってきていた。現場の工夫もあり、表面的には約1700科目の授業は概ねうまく進行しているように見える。だが、細かいところに目を向けるとほころびが出始めていた。
 授業資料や課題の追加はできるのに、削除がうまくできなくなってしまったのだ。消せないだけなので「非表示にして誤魔化す」という運用でカバーしてくれたこともあり、授業進行に大きな支障は出ていなかった。とは言え、削除したはずのものが復活したり、削除中のまま居残ったりという不可解な事象が日を追うごとに増えていった。その様子は、データの幽霊がさまよっているかのようであった。
 要のサーバは、ちょっとびっくりするぐらい控えめなスペックのPCだ。メモリこそ64GBと潤沢に積んでいるが、それ以外は5年ぐらい前の市販品を組み合わせた普通の自作PC。普通に使うのでは8000人の学生のリモート授業を支えることはできない。限界目いっぱいの過激なチューニングをしまくって毎日をやり過ごしている。
 だから、今回のような不可解な現象が発生するとその原因として、スペック不足や他人にはおすすめできない過激な設定を疑ってしまう。事実、これが原因だったこともある。
 だが、今回に限っては違った。もし、手元に最新のスーパーマシンがあったとしても全く同じことが起きていた。原因はハードでもなく、ソフトの設定でもなかった。サーバの中に何百万とあるファイルの内の、たった1つの名前のミスが原因だったのだ。
 あろうことにそのファイルは、ぼくが書いたソフトに含まれていた。あるプラットフォーム向けの拡張機能を作って先週末に導入したのだが、削除関連のファイル名が間違っていた。本来は拡張機能の名前と同じにしなくてはならないのだが、テンプレートとして提供されていたときの名前のままだった。
 どちらも同じ"ne"から始まる名前だったので完全に見落としていた。たった数文字のミスで、サーバの裏側のプロセスが崩壊しかけてしまった。
 大事になる前に問題発見して対処できたのがせめてもの救いである。と言いたいところなのだが、このミス2度目なんだよなぁ。度し難い。