コックピットのパイロットが忙しそうにしていたら、深刻な状況に対処していると思っていいでしょう。警告が鳴り、不確かさのために呆然となり、地面が近づきつつある、、、。
何かに似ていませんか？サーバー・モニタからのアラートとは逼迫性が違いますが、結果は同じかもしれません：クラッシュ。個人の身体に外傷はないかもしれませんが、会社は損害を被ります。緊急事態に対処する最適な時間は、緊急事態に陥る前なのです。言う容易く行うは難し、の部類かもしれませんが。セーフ・ランディングのためのサーバー監視術を、フライトの緊急事態になぞらえてご紹介します。
1. フライトの特性把握
「正常」の定義づけ。正常に稼動しているとき、ネットワークはどう機能していますか？正常なときの様子がわからなければ、何か問題が発生したときにスムーズに対応することはできません。 ネットワークを継続的に監視していけば、正常稼動時の動作を把握することができます。そうすることで、通常の動作と大きく異なる（些細ではない）偏差があった場合に警告を出すよう調整できます。特性を知り正常稼動状態を熟知していればより適切に偏差に対応できます。
2. 天候状態
天候状態 - 外部環境の把握。ネットワークにとっての「天候」は、トラフィックの潮流の満ち干きです。警告の嵐につながるトラフィックの急上昇は、予測可能な状況 - たとえばスーパーボウル - からも、予測不可能なイベント（ドラマチックなニュースビデオのリリースなど）からも、発生する可能性があります。ネットワークが過酷な天候にどのように反応するかを知っておくことは非常に重要です。警告の嵐の中を飛ぶ前には、十分な計画が必要です。
3. 静寂 — 静か過ぎる
アラートの完全な欠如は、それ自体が警告サインになり得ます。通常のネットワーク運用では一定量の「ノイズ」が生成されるのが普通です。警告システムでノイズが発生していない場合は、警告プロセスに問題がある可能性があります。つまり、トラブルが発生する兆候を見つけられない可能性があります。ソリューションが正常に稼動していることを確認し、アラートのしきい値を調整して「許容」偏差の余裕を確保します。
4. コックピットのリソース管理
クルーの能力を最大限に生かす必要があります。警告には重大さのレベルがありますが、レベルに応じて適切なユーザーに送信されるようになっていますか？IT管理者は、知る必要がある警告を、効果的な方法（電子メールやテキストメッセージなど）で受け取るべきです。そうでなければ、別のレベルで処理できる警告も受け取り、警告であふれてしまい、「警告疲労」に陥ります。設定が調整されていない場合は、ポリシーを見直して警告のレベルと受け手を調整します。
5. 警告システムをオフにしない
アラートをメールで受け取る場合、警告メールがスパム・フォルダーに入らないことを確認しましょう。ほかの警告用メディアの場合も同様の注意が必要です。さっと確認だけすればいいような警告が多いのも事実ですが、どんな警告が届いているのかはチェックする必要があります。煩わしくてもオフにはしないでください。
6. 耐空性の確保
アラートを出す監視ソリューションは様々で、機能にも違いがあります。飛行機なら耐空性が高いものを選ぶと同様、サーバー監視ツールが必要な機能を満たしていなければ、できるだけ早く置き換えることを考えてください。
7. パニックにならない！
「パニックにならない」というのはすべての中で最も簡単なアドバイスですが、緊急時には覚えておくのが最も難しいものかもしれません。ネットワーク監視ソリューションは、パニックになったときには助けることができません。落ち着きを取り戻すのが一番です。
8. 飛行機を操縦する
クラッシュサイトから回収されたフライトレコーダーは、クルーが特定の問題に気をとられて、飛行機を操縦しているという大前提を忘れてしまっていることを示唆することがよくあります。アラートは使いこなすべきツールです。乗客がスムーズなフライトを続けられることを優先し、アラートへの対応がかえって混乱を引き起こすようなことは防がなければなりません。
サーバー監視を最善のものにするのは、特定の技術ソリューションではありません。アラートは提供される情報です。アラートを効果的に利用して対処し、ネットワークのタービュランスを最小に押さえながらユーザーがネットワークを快適に使用できるようにするのは、ネットワークを運用するIT管理者であることを忘れないでください。