「ネットワーク障害発生！即時、情シスが機器を再起動して復旧！ただし機器のログが消えてしまったので原因が特定できなかった」これはよくある話である。
ネットワーク障害時、機器の再起動だけで復旧する場合が多い。よって、業務継続を優先し即再起動をかける。ところが、ネットワーク機器の多くは再起動するとログが消えてしまうのだ。そのため、なぜ障害が起きたのか特定しにくくなる。そして、あとから駆け付けたベンダーに「ログが残っていないので原因がわかりませんね」と告げられるのだ。（もっとも、ログ解析しても原因不明で終わるケースも多いが）
「ネットワーク障害発生！ベンダーに対応依頼！ただしベンダーの状況確認のため、復旧＝業務再開まで時間がかかった」これもよくある話である。ベンダーが状況を確認しようと機器へのアクセルやログ取得に悪戦苦闘し、再起動して復旧するまでとても時間がかかることがある。当然業務がその間ストップしている。
筆者の経験の話で恐縮だが、ベンダーは必ずしも業務継続を目的としていないように思える。業務継続のための回避策よりも、根本解決のための調査を優先する傾向にある。これは仕方のないことかもしれないが、ベンダーは保守を担当している以上、障害の説明責任というか、説明をしなければならないという思いがある。なので、機器へのアクセスやログ取得に時間をかけてしまうのだろう。
これらの問題は、ネットワーク機器を再起動するとログが消えてしまう、ということが一部起因している。要は情シスが回避策として、即再起動してもログが残れば後にベンダーが検証できるというわけだ。しかし、先述の通り外部記憶装置にログ保存できないネットワーク機器は多数ある。そこで、Syslogサーバーの出番である。とはいっても、今回の目標は「再起動時にログが残ること」であるので、高機能で高価格なログシステムを導入する必要はない。また、Linuxサーバーを立てれば実績のある無料のSyslogサーバーアプリが付属しているが、運用が煩雑になることを恐れる場合もあるだろう。
実はWindowsでもSyslogサーバーアプリがあり無料で導入できる。ただし、Windows系の無料Syslogサーバーは、機器ごと、タイミングごとのテキストファイルをサーバーにため込むだけのものだ。ログレベル（デバック、情報、エラー、緊急など）やログ出力項目次第だが、古いログを削除するコマンドを仕込んでおなないと、ファイル数が膨大になってしまう。結合や削除は簡単なコマンドで実現できるが、それ面倒であれば中程度のSyslogサーバーアプリを購入したほうがいいだろう。もちろん今回の目標に必要ない、ログ解析などの機能は不要なのであまり高額なものはいらない。
Syslogサーバーは簡単に導入できるので、すぐにネットワーク機器を再起動し業務を継続させるために導入したほうが良い。
ユーザーからのクレーム数は停止時間に比例するであろうから。
2025年1月