システム管理者様のお悩みをお聞きしている際に、最近よく耳にするのが「サイレント障害」です。いろいろな解釈がありますが、広い意味でいうと「エラーとして把握できないシステムトラブルの総称」とここでは定義いたします。

具体的な事象でいうと、監視ツールを導入しており、通常はトラブルが発生するとアラートとして検知するが、アラート検知ではない(サイレント)状態でも利用ユーザーから「つながりにくい」「遅くて使いものにならない」といったクレームで発覚する障害です。皆さま口をそろえて「解決までに非常に時間がかかった」とおっしゃいます。

ネットワークは冗長化構成であり、サーバーも仮想環境で安定的に稼働し、ロードバランサーの管理も万全という環境であっても、この「サイレント障害」は発生します。特に大規模や複雑なシステムで発生頻度が高い傾向にあります。

システムのトラブルは大きく3つの事象に分けられると考えています。

1.　ハードウェアの限界

2.　システムリソースの限界

3.　システムの稼働状況の変化

「1. ハードウェアの限界」は、機器故障やファシリティの問題で発生します。このトラブルについては死活・稼働監視にて状態を把握することが可能です。「2. システムリソースの限界」と「3. システムの稼働状況の変化」は、大体が稼働監視ならびに性能監視で把握することが可能です。

ただし、今回のテーマとなる「サイレント障害」は2. または 3. ならびに複合型の要因で発生いたしますので、今までの監視手法では捉えられないということになります。

ここで、サイレント障害のトラブル例を上げさせていただきます。

上記の状態であっても、監視装置からするとネットワークの疎通も問題なく、稼働監視としてActiveを正としていたので正常状態だったのですが、サービス利用ユーザーから多数の連絡を貰い、初めてシステムにトラブルが発生したことを把握したとのことです。

また、「サイレント障害」の特長として「解決までに非常に時間がかかった」との声を冒頭で紹介しましたが、監視装置でトラブル状況が把握できないので、大規模や複雑なシステムでは、「どこが問題か？」「影響範囲はどこまでか？」というトラブル特定作業に膨大な時間や人を費やさなくてはいけなくなります。

クレームの連絡の応対や、トラブルの特定作業や修正・変更作業、そしてシステムが回復した後の報告やお詫びの対応で、結果的には膨大な損失と疲労感だけが残ったとのことです。

システムを安定化させるといいますが、システム監視はどちらかというと安定的に動いているのかといったことよりも、「異常」を検知することがメインとなっています。一般的な監視手法である、疎通の確認や、Trap/Syslogで異常メッセージを検知するといったことでお分かり頂けるかと思います。

この「サイレント障害」の対策として、我々は「システムが安定的に動いているのか」をベースにした今までの監視とは違う手法を用いることで対応できるのでは、と考えています。

つまり、「いつも通りシステムが動いているか」を性能監視で取得した安定稼働中のデータを元に学習をさせ、そのデータから変化があった場合に「何か問題が起きた」として、判断させる手法になります。実際この手法は System Answer G2 で新たな性能監視機能「ベースライン監視」として機能化しております。

「いつも通りシステムが動いているか」という観点は対象システム毎にどう捉えるかは異なってきますが、例えばトラブル例で挙げたシステムでは、トラフィックの周期性を把握する、あるいは定期的に重い処理をおこなうサーバーであれば、CPUやDisk I/O といったリソースの変動を捉えることで可能と考えています。

「サイレント障害」の発生頻度が高く、発生時の影響度が大きい大規模システムは、この周期性というものが非常に顕著に出ます。サービスが正常に稼働していればトラフィックが上がるべきところが、何らかの問題で上がっていないといった、「いつも通りに動いていない」ことを検知する事で、初期対応を迅速におこなえるのではないでしょうか。

「ベースライン監視」により、システム管理者の悩みである「サイレント障害」の対応を迅速かつ的確におこなうことができます。また、xSPといった自社以外のシステム運用をされている事業者様では、対象システムのサービスの正常性を把握することが非常に難しいのですが、この機能を活用することでサービス状況を細かく把握しなくても、「いつも通りか？(正常状態なのか？)」といった観点で対応することで、運用の簡便化だけでなく運用サービスの品質向上が可能ではと考えております。