f

すみません。上記ですが、ミス投稿してしまいました。
大変失礼いたしました。

＞　毎日のメールチェックが3-4時間かかってしまう
チェックしてなにするのでしょうか　”見て異常なしＯＫ”ならそんなメールは不要ということでしょう
”異常のときだけメールが出るようにする”ことはできないのでしょうか

立場的なものがあると思いますが
これが”取り決めでメールをチェックすることが仕事です”となっていたなら必要ですよね

@desatoさん コメントありがとうございます。
確かに通知の件数を減らすことを第一に考えるべきですね。

> チェックしてなにするのでしょうか　
チェックして正常／異常の1次切り分け→システムの担当者やエンドユーザにメール、チャット等で連絡してエスカレーション。ハード系の障害なら保守ベンダーを手配、予備機と交換、リストア実施、などですね。

> ”異常のときだけメールが出るようにする”ことはできないのでしょうか
そうですね。そういう方向に持っていきたいと思います。ただ、連続した通知の組み合わせで異常／正常を判断するケースがあったり、過去にジョブが動いていなかったのを発見するのが遅れた事があり、正常通知が必用なケースというのもあるので ケースバイケースではあります。

通知を減らすのは必用だなと思いましたが、いまいま問題だと感じてるのはメール開くのに数秒掛かったり Thunderbirdが重すぎる点でして、「メール通知」自体が何か別の方法はないものかと感じてます・・・。

Thunderbirdが重い　というのが原因なのでしょうか
POP３（自分のPCにメールを取り込む）ですか？　　SMTP（メールサーバにあるメールを見に行く）ですか？
自分のPCに取り込んだメールで古いものは消す　ということで軽くなりませんか？
メールサーバが原因なら　これもサーバにあるメールの古いものは消してしまう　ということはできませんか？

Thunderbird以外のメールツールではどうなのでしょう

＞　SMTP（メールサーバにあるメールを見に行く）ですか？
SMTP　ではなくって　IMAP　でした　　　　　　　　ペコリ

上記同じく論点が
１・Thunderbirdが重すぎる点
なのか、それとも
２・Thunderbirdを解決する事は置いといて、他にも通知方法に斬新なものない？
なのか、知りたし

そのうえで
A.”連続した通知の組み合わせで異常／正常を判断するケースがあったり”
B.”過去にジョブが動いていなかったのを発見するのが遅れた事があり”
C.”正常通知が必用なケースというのもあるので”
という ケースバイケース をすこし租借しないといいアドバイスできなさそうね

単純にBであれば行燈みたいのがいい気がするし、ただしCは拾えない
Aはそもそも、通知の仕組みでなく、監視の仕組みというか異常/正常判断のロジックに
問題を感じますし。

こうやって本質的な問題をすこしロジカルに分解して対応しませんか？

ちなみに「他にも通知方法に斬新なもの」であれば
・行燈（ソフトウェアあんどん）
・携帯メール通知/別メール（重くない警告専用）
・ホスティングの監視による携帯電話呼び出し
・携帯電話SMSなんてのもあったかな
・あとは日中は常駐アプリつくって警告
・業務アプリで分かるように通知
というのくらいでしょうかね
どれも斬新ではないですが・・・・・

みなさんコメントありがとうございます！
コメント拝見して問題を整理して一つずつ解決する必要があるなと思えてきました。

@desatoさん

メールはIMAPで、Thunderbirdでメールを消すと、ゴミ箱に移動するのに非常に時間がかかり、そのうちメモリ不足かなにかでアプリが落ちてしまい削除出来ない状態になってます…。

Shuriken、Sylpheedを試したところ動作が軽快でしたのでThunderbirdに問題がありそうです。
メールソフトの乗り換えを考えてみます。

@sysjojoさん

メールですか。今は振り分けルールでサブディレクトリに振り分けてました。
ルールでその他だけ目を通すのは時間短縮になりますね。

@くるしぃさん

論点としては「メール以外の通知手段はどういったものを使ってますか？」という感じです。

A,B,C というケースバイケースの咀嚼しないとというご指摘は 私自身が咀嚼できてないんだなあと気づきました。

通知手段よりも、監視とか成否の判定ロジックを整理したいと思います。

確かに、この質問だと何に対して答えを期待しているのか難しいです。そして、どのくらいの規模のシステム群を管理しているのか分かりませんが、根本的にメール１８０通は多すぎです。

言いたいことは分からないでもありませんが、これだけ多いと人的なチェック自体に無理を感じます。実際、エラーがあっても見過ごしたりしませんか？

さらに経営的な観点から答えると、死活監視に１日３〜４時間は時間（コスト）をかけ過ぎです。少し考え方を変えないといけないのではないでしょうか？

ジョブの監視ならメールを受信しなくても、JP1とかの運用監視ソフトの管理画面を見れば良いでしょうし、
単純な死活監視（Ping）なら、どっかのサーバにスクリプトでも組んで仕込んで纏めて実行すれば良いだけの話。

障害発生の頻度が多くて、もっと詳細な監視が必要だというなら、システム運用監視ソフトを導入するのが筋では？。１日８時間として、その半分の時間を監視に当ててるのなら、導入コストは十分ペイすると思います。

何れにしても、障害発生時の経緯を調べるのはメールの受信結果ではなく、各システムのログを見るのが第一歩なので、無理にメールを残す理由はないと思います。障害経緯の履歴が必要なら、死活監視の管理台帳でも用意して、何かアラートがあれば記入すれば良い話。それで、十分に要件を満たせると思います。

ちなみに、私の勤め先では上記の方法で日々の監視業務に割く時間を１０分程度に抑えています。なお、拠点数２０、サーバ数５０、利用者７００人くらいの規模です。

＞　みなさんは 監視の通知はどうされていますか？
これに答えていませんでしたね

サーバが２０台（仮想も含む）あります　
異常はメール出来ますがほとんど来たことがありません
ここ１年で来たのは
データバックアップで磁気テープが不良で”失敗しました”と
細かく切ってあったドライブの１つで”空き容量が少なくなりました”
の２つくらいです