本記事は『ITレジリエンスの教科書 止まらないシステムから止まっても素早く復旧するシステムへ』（大和総研 ）の「2-4 検知策に関するルール」から一部を抜粋したものです。掲載に際して編集しています。
検知策に関するルール
検知策は、「監視などでイレギュラーな事象を早期に見つける対策」であり、予防策でリスクをカバーしきれずに残念ながらシステム障害として顕在化してしまった場合、あるいはその予兆がある場合にいち早く発見する策です。
そのため、事業部門や利用者が気付かないうちに、システム運用者が発見できることが望ましいです。なぜなら、システム障害の種類などにもよりますが、自ら発見すれば障害の拡大を防げたり、障害内容やその原因、解決策、復旧の見込みなどについて利用者により詳しく伝達できたりする可能性が高くなるからです。
どうすればいかに早くイレギュラーな事象を発見できるかについて解説します。
監視の基礎
(1) 監視の対象
システムが推奨するサービスや、それを構成する機器・OS・プログラム（アプリケーション）などの異常をいち早く発見するためには、監視を行う必要があります。
監視には、対象に応じていくつかの種類がありますが、まずベースとなるシステムの監視があります。サーバーやネットワーク機器などのハードウェアそのもの、それら機器などの冗長構成の状況、リソースの使用状況、稼働している各種プロセス（処理）、ハードウェアやプロセスなどが出力したログが対象になります。通常、ハードウェアやミドルウェアなどは、事故の状態やエラーなどを通知する、あるいはログに記録する機能を標準的に有しているので、それを利用します。プログラム（アプリケーション）において、特別なアラートやエラーを出力する必要がある場合は、開発する中でログに記録する機能を組み込んでおきます。
続いてイベントの監視があります。システムイベントは内部的なもので、バッチ処理やサービス開始処理の遅延などを把握するものです。業務イベントは外部的なもので、対外接続された相手に本来送るべきデータをまだ送っていない場合などがあります。これらの監視は、実際には定められた期限までに処理が完了したかを確認する定時点監視で行います。
次にサービスの監視ですが、継続的にサービスが提供できているか、そして画面の応答時間などサービスレベルが適切か（SLO/SLAを遵守など）を監視します。
最後に、昨今、システム構築にあたって利用が拡大しているクラウドサービスに対する監視があります。
なお、冗長構成が機能しない中途半端な状態である「半死に」に対しては、システムの監視では検知できません。イベントの監視では処理が機能しないことで検知できる場合もありますが、それはたまたま定時点監視に設定した時刻に近いときだけです。それに対し、サービスの監視であれば、応答がないことからほぼリアルタイムに機能していないことを検知できます。
また、クラウドサービスにおけるシステムに対する監視は、IaaS・IDaaS・SaaS内、つまりクラウドサービスプロバイダーの内部で行われます。その際の障害は当然通知されますが、監視の範囲やタイミング、頻度などはオンプレミスのように自社の事情に合わせた自由度があるわけではありません。ましてや予兆の検知・通知などは十分に兼ね備えていません。しかも昨今、それぞれの機能に特徴がある複数のクラウドを使い分ける、あるいは連携させるマルチクラウドが普及しています。
マルチクラウドの利用においては、それぞれのクラウドサービスそのものが稼働しているか、応答時間などのサービスレベルが適切かを監視することも重要になってきます。
このようなシステム構成になってくると、自社システムや複数クラウドサービスとの接続も多くなります。また、機能を小型化したコンテナ技術に伴って管理すべき粒度が小さくなり、管理対象も増えてきます。そのため、発生する障害も複雑になり、従来の個々の監視だけでは問題を把握・理解することが難しくなっています。サービス監視（UI/UXの監視）はその対応方法のひとつであり、「可観測性」（オブザーバビリティ）の向上に寄与します。
(2) 監視対象の特定と方法
ハードウェアやミドルウェアなどについては、付属する純正ツールや市販のミドルウェアなどで、比較的容易に監視の対象を特定しやすいです（状態や利用状況の情報もツールによりほぼ自動的に収集できます）。
しかし、業務系データのファイルは自らが設計したものなので、監視システムにその所在（フォルダ）やファイル名などを登録し、上限値の使用率などを事前に登録する必要があります。対象として登録しない限り、当然ですが監視されないので、ある周期で構成管理台帳などと突き合わせて確認するなど、確実に監視されるようにしましょう。
監視の方法は2種類あります。1つ目は、アラート、アラーム、エラーといった異常な状態を検知する異常監視です。これは、前述のようにハードウェア、ミドルウェアやプログラムが自ら通知するタイプのものです。
しかし、異常監視の最大の欠点は、異常がないからといって正常稼働しているとは言い切れない点です。たとえば、業務処理で画面操作が1件もないからエラーもないのか、画面操作を実行するプログラム（アプリケーション）がハングアップ（処理が滞留）しているからエラー出力ができないのかがわかりません。
そこで重要となるのが、もうひとつの正常稼働監視です。これは、機能やサービスが異常終了せずに存在しているか（死活監視）、あるいは機能しているか（送信データのデータ番号が増加しているかなど）を積極的に確認し、確認できなかった場合にエラーとするものです。システム系（インフラ系）では以前から行われている監視方法ですが、プログラム（アプリケーション）についてはあまり行われてきませんでした。しかし、サービスに対する監視方法として、インターネット上のサービスの発展とともに普及してきました。
(3) アラートとアラームの差異
エラーは、たとえば業務系でいうとデータの書式や属性が異なる、数字に不整合があるなど、事象はイメージしやすいと思いますが、アラートとアラームの差異はわかりにくいのではないでしょうか。
アラートとは、通知の受け手が予期していない事態の発生を伝える警告であり、日常生活でいえば、自然災害の発生に伴う警戒警報にあたります。ハードウェアの中には自ら予兆発見機能を有している製品もあり、たとえばストレージ（ディスク）では、読込み・書込みのリトライ（エラー後の再読込み・書込み）の回数が一定の値を超えると、予防保守（予防交換）を促すアラートを通知します。
一方、アラームとは、あらかじめ設定した値に到達したことを伝える警告であり、日常生活でいえば、時刻を知らせてくれる目覚まし時計です。たとえば、ある業務ファイルの使用率があらかじめ設定した数値に達した際に通知します。
システム監視のリソースやプロセス、イベントなどは対象の種類こそ違いますが、通常、アラームに段階を設けます。これは、いきなり限界値を超えると即座にシステム停止となり得るためです。
最初のアラームは、重要な警戒レベルに達したことを知らせるもので、このまま放置するとシステム停止になりかねないことを警告します。この警告後は、具体的にはリソース増強などのリスク軽減策の実行を検討します。
次のアラームは、危険なレベルに達したことを知らせるもので、もうすぐシステム停止になってしまう可能性が極めて高い状況になったことを警告します。この警告後は、コンティンジェンシープランの発動を検討しなければなりません。
(4) 監視の例外
画面を操作している際の何らかの入力エラーは、画面にエラー表示を行い、利用者に対して正しい操作を促します。このようなエラーは、システムレベルのエラーとしては扱いません。
ただし、あまりにこのようなエラーが頻出する場合は、画面（UI）の作りが悪い可能性があり得るので、構築部門が改善点を把握するために操作ログなどを定期的に監視する場合もあります。
(5) 監視の工夫・見直し
同一の事象で監視表示が過度に多い場合、他の監視対象からの重要なサインの見落としを生み、障害対応の初動を遅らせる原因となり得ます。同一の監視メッセージが大量に出力されるような場合、他の監視メッセージの見落としにつながらないよう、何件出力されているといった集約表示を行うようにするなど、表示量の抑止の検討も重要です。監視対象とする事象や監視メッセージは、障害発生時の影響度を十分に検討した上で厳選する必要があります。
重要警戒メッセージが通知されたら、当日のデータなどについて前日との比較や前週同曜日比などを分析し、あわせて政治、経済の重要ニュースなどを確認し、一時的な現象によるものかどうかを判断する必要もあります。業務によってはさまざまな特性があり、五十日（ゴトウビ。毎月の5と10の納金などの日）や年度末・年度初などには、普段と違う傾向が出ることもあるので、それらの特殊日も考慮する必要があります。
システム環境には、OS・ミドルウェアのバージョンアップや新たな業務機能の追加、法制度の変更に伴う保守、システム構成・構造の改善など、さまざまな変化があり、データの処理性能にも影響を与えます。そのため、システム状況を常に把握し、トレンド分析を行い、それに応じて監視の設定も見直しましょう。
アラームは対策の実行時間を考慮して設計する
(1) リソース系のアラーム
アラームのもととなるチェックポイントは、通常、2つ（もしくはそれ以上）設けます。
「危険」の対象となるポイントは、検知後、コンティンジェンシープランの発動作業時間とその効果が出るまでの時間を求め、その時間がリソースなどのどれくらいの使用率に相当するのかを計算し、それを余裕分として100％から逆算して設定します。この余裕分がないとシステム停止が起きるおそれが高いからです。コンティンジェンシープランの例としては、処理負荷軽減のために一部のサービスを停止するなどです。
次に、「重要警戒」対象となるポイントを決めます。このポイントは、危険ポイントに達しないようにリソース増強などの予防策を打つタイミングですから、予防策の作業時間を求め、その時間がリソースなどのどれくらいの使用率に相当するのかを計算し、それを余裕分として危険の対象となるポイントから逆算して設定します。
この予防策の大きな要因を占めるのが、増強する機器や部品の調達時間と、調達後の作業時間です。よってこの調達時間を短縮するために、事前に予備機を設ける、あるいは冗長構成とすることが考えられますが、それはサービスの重要性とコストとの兼ね合いで決定します。
なお、たとえばAWSのオンデマンド型のリソース増強オプションであるAuto Scaling機能を利用する場合、事前の定義により、この重要警戒の検知と増強作業を自動で行ってくれます。これは、パブリッククラウドを利用する、大きな利点のひとつです。
(2) イベント系のアラーム
イベントの監視は、実際には定められた期限（SLO/SLA）までの間に処理が完了したかを確認する定時点監視です。
バッチ処理にせよ、対外接続のファイル送受信にせよ、新規稼働時は処理量に基づき推定した処理時間に障害対応などの余裕時間を加味し、SLO/SLAの期限より手前に「危険」時刻を設定します。そして、実績の蓄積により得られる平均終了時刻近辺に「重要警戒」時刻を設定します。
これらはデータ量によって変動するので、状況を常に把握し、データ量の増加具合に対する処理の効率化も図りますが、状況に応じてSLO/SLAの変更を委託者と調整する必要もあります。
