長い間システム管理をやっていると勘みたいなものがついてきます。例えばHDDの書き込み音パターンからメモリスワップ発生を検知しレスポンス低下を予知する、サーバに触って感じた温度でCPUが高温になっていることを検知し何らかのプロセスが暴走していることを発見する、スイッチ(スイッチングHUB)のLEDの光り方からネットワーク帯域使用率が異常に高いことを検知しワームやウィルスに感染しているサーバがあることを発見する、などといった感じです。そこで今回はそんな勘の中でも個人的によい思い出がほとんどないメール系サービスのことを書いてみたいと思います。

メール系サービスのトラブルと言えば

安定稼動していたメール系サービスで異常が起きた場合、経験上DNSまわりのトラブルであることが非常に多かったです。無論これは環境によってそうでない場合ももちろんあるでしょうが、私の知り合いに聞いても共感してくださる方が非常に多かったので、どこも似た状況なのかもしれません。

DNSまわりのトラブルにもいろいろあります。例えば以下のような感じです。

  1. DNSサーバが全て落ちていた。
  2. 管理下のDNSサーバは生きていたが、上位DNSが落ちていた。
  3. ファイアウォールルールの変更でDNSへのアクセスができなくなった。
  4. MXレコード書き間違い。
  5. プライマリDNSサーバが落ちていた。ただしセカンダリDNSは生きていた。
1～4の場合はメールが届かずエラーになるので現象にすぐ気づきやすいのですが、問題は5です。メールを送信しようとすると、数秒固まった後何事もなかったようにメールが送信されていきます。このような状況に遭遇した場合、メールがきちんと送信されることから「まぁいいか」と放置されるケースがよくありますが、こういった数秒固まってから何事もなかったように処理が継続されるケースの多くは5のようなケースであることが多いので、その場合はDNSサーバをチェックしてみることをお勧めします。（もしくは/etc/resolv.confファイルの書き間違いも同様）

メール系サービスでのDNS以外のトラブル原因

ついでに安定稼動していたメール系サービスのトラブルで、DNS以外の原因でよくあるものを書いてみます。

  • HDD容量が満杯
  • ファイアウォール設定変更ミス
  • スパム大量受信によるレスポンス低下
などでしょうか。それでも私の場合は、メール系サービスで障害が合った場合、大抵DNSまわりを調べれば解決できてしまうパターンが本当に多かったです。全体の80%以上？

今後のご参考になれば幸いです。