９月１日（土）午前５時−９時まで、８月２０日のトランスがぶっとんだための全学停電の修理のため、停電である。朝５時だぜ！！
ファイルサーバであるbは前日に落とし、月曜日に起動しても問題ない。使うのが生理の人間だけだからな。分散サテライトも前日に落として月曜日起動で問題ないでしょ。利用者は学群学生だし、まだ夏休みだし。これらは担当者が対応するからいいでしょ。
k, m, t , QR はリモートで午前５時直前にシャットダウンすればいいが、セキュリティドアのサーバは、当然ながらインターネットに接続していないのでリモートで落とすことはできない。しかし、このサーバのUPSは１時間以上持つのがわかっているから、朝５時前に起きて、サーバをリモートでシャットダウンして、一眠りして、朝６時ころ大学に出てきてセキュリティドアのサーバを落として、UPS の電源をきって．．． また９時頃、大学に出てきて、UPSの起動とサーバの起動をすればいい．．．なんて甘い考えがいけなかった。
目がさめたのが朝６時直前。やば！！　この時点では全学停電だからリモートでシャットダウンできない。
大学にきたのが６時１０分。
m はUPS で動いていたが、t のUPSはもたなかった。バッテリーがそろそろアウトだからな。k とQR は，別の管理者がやることになっていいたから落ちていたんだろう。 確認する暇もない。
あわてて、セキュリティドアのサーバをシャットダウン。m をシャットダウン 。セキュリティドアのサーバとm, t, QR, b のUPSを落とす。
tだけが、異常修了だったわけで、HD がこけていないことを祈るだけ。でも はproxy の機能だけだから、こけちゃっても再構築は簡単だし、その間、生理グループのネットへの接続は可能だからなんとかなるだろ。
いったん自宅へ。コンビニに寄って朝食を買って、自宅で朝飯食べて、９時に再度大学に来て、全てのUPSを起動。セキュリティドアのサーバを起動。t, m, QR, bを起動。k の担当者はさらに遅れて登場。k 起動。
問題のtama は起動しただけではproxy が動いてくれなかったので、実験室から リモートで再起動。動いた。いがった。
セキュリティドアのサーバがドア開閉情報を記録しているのを確認した。９時頃沢山の大学院学生が来ている。停電時、医学の建物内では、冷凍庫のアラームがあちこち鳴っていた。 冷凍庫がちゃんと動いていることを確認しないとヤバい研究室が一杯あるからね。下っ端が来る事になっていたんだろう。
m, t, k がちゃんと動作している事を確認。 QRの確認は月曜日だな。利用者だけどID, パスワード忘れたし、利用できる環境にないし。で、月曜日朝、動作確認した。
めでたし、めでたし。が、．．．．月曜日の朝、動いていないセグメントがあった。ユーザからのクレームだ。て、クレームがないとわからん。いちいちすべてのセグメントが動作しているかを確認できない。
原因はセグメントを仕切っているスイッチが起動時に設定をちゃんと読まなかったらしい。２度再起動して問題解決。
このスイッチは学情が管理している。これはまずいかも。迅速な対応ができなくなるかもしれない。ただのスイッチングハブで一時的に置換すればいいのだろうか。管理者なのに実務管理者に任せているので、いまいち理解していない、まずいな。