トータル監視

トータル監視運用サービス

 ITインフラは増々複雑になり、単体の試験を行ってもトータルでお客さまの満足するサービスを提供できているかが分らなくなりました。

 これからは、個別監視からITインフラサービスのトータル監視への変更が必要です。

トータル監視運用サービスのパンフレット(pdfファイル)


1. エンドユーザ(お客さま)からの質問・対応

 情報システム部門の皆さまは、次のような質問がきて困られていませんか。

[check]トラブル・故障を事前に発見できず、「使えない。早く直して欲しい」と苦情を言われる。
[check]レスポンスが遅いと苦情を言われるがどこを調べて良いか分からない。
[check]「昨日のITサービスの調子が悪かったのでは」と聞かれても、何もデータがないので答えられない。
[check]急な故障、トラブルの対応で1日潰れてしまう。


2. お客さま(情報システム責任者)が欲しい情報

1.エンドユーザが、(問題なく) 使えているのか、使えていないのか。

   エンドユーザの申告による不具合を 0 に

2.使えている場合でも、使えているエビデンスを提供できること。

   例:「昨日、〇〇へのアクセスが問題があったのでは」
     の質問に対して、エビデンスを持って答えられること。
   ⇒ 常時監視による、レスポンスの見える化によって実現

3.何らかの対処が必要なのか、必要でないのか。

    必要であれば、その方法

   予兆による不具合の事前発見

これらの情報をお客さま(情報システム責任者)と協力して提供に努めます。


3. 個別監視とトータル監視の比較(イメージ)

 個別監視の場合、個々の機器の試験を行いますが、全機器のトータルの動作を確認していないため、トータルとして正常かどうかが分りません。

 一方、トータル監視では、端末からサーバまで、経由する全ての機器を通した試験を行うことにより、トータルとして正常かどうかを把握できます。

 不具合の兆候はレスポンスに現れることが多いので、レスポンスをシビアに観察することが重要です。

個別監視とトータル監視の比較(イメージ)

画像をクリックすると拡大します


4. 個別監視(現状) 

 現状のITインフラの保守サービスは、多くの場合、単体の監視を行っていますが、個々の機器に異常がなくてもトータルとして、
 ・使えない
 ・使えないことがある
 ・遅い等の不便がある

といった様なことが生じます。
調べてみても分からない場合が多く、エンドユーザの不満はつのり、情報システム部門の方の稼働が膨らみます。

従来の個別の監視

画像をクリックすると拡大します

5. トータル監視運用(今後の期待される監視)

 エンドユーザからみたトータルの試験が潜在的な故障や分かり難い故障を発見することが可能です。

ポイントは次の5点です。【保守サービス特徴をご参照下さい】
①上位から(縦方向のend-to-end軸)の試験
②クライアントからサーバまで(横方向のend-to-end軸)の試験
③全装置(規模軸)の試験
④常時監視(時間軸)
⑤カスタマイズ試験 

トータル監視の概念図

画像をクリックすると拡大します

【IPアドレス監視 ⇒ ホスト名による監視へ】
 IPアドレスの代わりに、ホスト名を指定することにより、
・冗長化機器の中に不具合の機器がある場合
・DNS、FW等の接続を支援する機器の不具合
・キャリア内の冗長機器に不具合がある場合
を 常時監視、レスポンス監視をすることで、いち早くトラブルの原因箇所を特定することが可能です。

トータル監視運用の考え方を利用して、お客さまのトラブルを解決した例をご参照下さい。【Sales Forceのアプリのレスポンスが非常に遅い


6. 保守設計について(従来)

 少し前のITインフラ構成は、サーバを基本的に自社で所持していましたので、構成は単純で、ネットワーク担当、サーバ担当に分かれ、個別に個々の機器の監視を行うことでITインフラの保守・運用を実施していました。
トータル監視(従来の監視構成

 個別の機器のアラームを監視しておけばアプリケーションが問題なく動いていたのが実態でした。

 従来の保守設計は、まず、どの機器が、何台あり、その機器を如何に監視していくかでした。機器構成が単純であるため、この方法でも特に問題がありませんでした。


従来の保守設計

 保守の実施は、あくまで、機器が中心で、機器が異常でないかを調べていました。


7. 保守設計(クラウド時代)

 クラウド時代になり、一部は自社にサーバを置き、一部は、外部のクラウド業者のサービスを利用することになり、ITインフラは複雑化し、個々の機器に異常がなくても、アプリケーションが問題なく利用できているのかどうかをエビデンスを持って示すことが難しくなってきました。

トータル監視(現状)


クラウド時代の保守設計は、
ずばり、「アプリケーション・ファースト」で設計を行うことです。

トータル監視の保守設計

 次に示す通り、四つのステップで保守設計を行って行きます。機器からの設計ではなく、アプリケーション(人)のレベルから機器のレベルに落として設計を行って行きます。


(1)第一ステップ
 利用しているアプリケーション及び利用している機器を書き出します。
〇メール : オンプレミス
〇スケジューラ :オンプレミス
〇営業支援システム :クラウド
〇経理システム  :クラウド
〇人事システム  :オンプレミス
〇受発注システム :オンプレミス
......

この場合、オンプレミス、クラウドサービスの利用の区別を付けずに書き出します。

(2)第二ステップ
 アプリケーションを利用するための補助的な機器を書き出します。
〇DNSサーバ
〇ADサーバ
〇DBサーバ
〇その他認証サーバ
〇冗長化装置(ロードバランサー)

(3)第三ステップ
 クライアントからサーバにアクセスする場合に経由する機器を全て書き出します。主としてネットワーク機器となります。
〇ルータ
〇スイッチ
〇冗長化機器(バックアップ機器等)
〇WiFi機器

(4)第四ステップ
 クライアントに関する項目を書き出します。
〇ウィルスソフト 等


8. EEC(End to End Checker )の情報システムへの適用

 トータル監視を行うために、EEC(End to End Checker )を適用します。
 従来のネットワーク監視装置ですと、ipがリーチブルでなければ監視ができないことが多いですが、EECを用いますとFW(ファイヤーウォール)を超えた試験も可能になります。 FW超え試験のページへ

 また、ipアドレスで試験を行うのでなく、サーバのホスト名で試験を行うことにより、DNS、ロードバランサ等の装置のトータルチェックも可能となります。

<EECの情報システムでの設置例>
 EECの設置イメージを示します。

① 自社で所持しているサーバ
  赤の太線矢印
② クラウドサービスを利用しているサーバ
  青の太線点線矢印
③ 自社、VPN内のルータ、スイッチ等の機器
  赤の細線矢印
④ 自社で所持している各種サーバ(FW、AD等)
  赤の太線矢印、青の太線点線矢印

について、レスポンスを把握し、
エンドユーザがストレスなく利用できているか
を常に把握することが可能となります。
EECの設置例


9. 試験設置~効果の確認~導入 までのスケジュールイメージ

 効果を確認して頂くために試験設置を行います。
試験設置までには、お客さまのITインフラ環境の調査・保守設計のために2~3週間を予定しております。

その後、試験設置を行い、1~3カ月後に効果の確認を行って貰います。

本格導入までには、お客さまの環境に応じて2~5カ月程度を予定しております。

試験設置~効果の確認~導入 までのスケジュールイメージ

表をクリックすると拡大します

  保守サービス特徴のページへ

  ネットワークの遅延のページへ

  アプリケーションの遅延ページへ

  お問合せのページへ

a:2205 t:1 y:1

最新の更新 RSS  Valid XHTML 1.0 Transitional