年々難しくなる「障害検知」のコツ - ＠IT情報マネジメント（情報元のブックマーク数）
年々障害検知が難しくなるか・・・確かに冗長化が一般化して、落ちているのか、半落ちなのかわからないことありますしね。
一般に、障害は次の3つに分類できます。
年々難しくなる「障害検知」のコツ (1/2) - ITmedia エンタープライズ
■ハードウェア障害
機器の故障
停電や過電流などによる機能停止
過負荷による機能停止、あるいは応答時間の大幅な遅れ など
■ソフトウェア障害
機能的な不具合（データが壊れる、使いたい機能が使えないなど）
非機能的なバグ（画面が乱れる、表示がずれるなど）
ソフトウェアが適切に構成されていないことによるデータの欠損
ソフトウェア間の互換性のなさによるデータの欠損
セキュリティ上のぜい弱性を突いた攻撃 など
■ヒューマン・エラーが原因の障害
過失による誤操作
思い込みや勘違いによる誤操作
以上のそれぞれが原因の障害は、枚挙にいとまがありません。
多重化が原因、自動マイグレーションが原因で、障害検知が難しいと。
さて、障害管理の目的は、おおまかに3つあります。
年々難しくなる「障害検知」のコツ (1/2) - ITmedia エンタープライズ
（1）障害の検知（障害が発生したことを知る）
（2）障害の復旧（障害を元の状態に戻す）
（3）原因の究明と再発防止（同じ障害が二度と起こらないよう努める）
ITIL的に言えば、（1）と（2）はインシデント管理の役割、（3）は問題管理の役割です。 ここでは（1）の「障害の検知」について詳しくお話しましょう。
障害が発生したことを知って初めて、障害対応が始まります。「障害が発生した瞬間」と、「その障害が発生したことを知る瞬間」との間には、どうしてもタイムラグがあります。そのため障害検知においては、「いかに素早く障害が発生したことを知るか」ということが重要なポイントになります。
しかし、昨今ではこのトリガがあまり信用できなくなってきている傾向にあります。具体的には、「障害が原因で業務が止まる」ことを防止するため、機器の多重化が進んでいることが挙げられます。また、一部のサーバ仮想化ソフトウェアは、「物理マシンに障害が発生すると、自動的にその物理マシン上で動作している仮想マシンを別の物理マシンに移動させて稼働を継続する」という機能を持ちます。
検知は、2種類か、、確かに。
ただ、どのメーカーの監視ツールを導入する場合でも、監視対象は大きく2種類に分けられます。それは、次の2種類です。
年々難しくなる「障害検知」のコツ (2/2) - ITmedia エンタープライズ
（1）「使えるか使えないか」という、0か1かの監視
（2）しきい値を設定することで障害を検知するタイプの監視
（1）は簡単です。ハードウェアの物理的な故障や、それが引き金となってのネットワークの寸断は、「使えるか使えないか」の世界ですから比較的分かりやすいと言えるでしょう。pingなどを使ってサーバのヘルスチェックを行い、ping が到達しなければ「障害」とみなします。この場合は、「何を監視するか」ということが重要な要素となります。
一方（2）は、CPU使用率、メモリ使用率、ハードディスクの空き容量、ネットワークのトラフィック量など、本来「性能管理で監視すべき範ちゅうのものを監視しよう」というものです。
これはサーバの一部の機能がダウンしたためにサーバが縮退運転を開始し、結果として過負荷が発生したり、逆に過負荷が原因でサーバがダウンしたりする、というような場合もあるためです。
つまり、障害によって性能が悪くなる場合、性能を監視することで障害を検知できますし、同様に、性能を監視することで、障害が起こる可能性を、実際に障害が発生する前に知ることもできるのです。
小さな結果も、早めに気づけば障害にならずに対応できる。非日常を確認して記録することが大切か。
そこでよくよく調べてみると、サーバの冷却ファンの部分にホコリがたまり、冷却効率が悪くなってCPUの温度が上がったために、CPUが熱暴走を起こさないように縮退運転をしていたことが分かりました。そのとき使っていた監視ツールには、筺体内の温度やCPU温度を監視する機能がなかったため、そのことに気付かなかったのです。結局、そのホコリを取り去ることでサーバは元通り元気になりましたが、そのままこのサーバを使い続けていたら、ある日突然、熱暴走していたかもしれません。
年々難しくなる「障害検知」のコツ (2/2) - ITmedia エンタープライズ
