どの組織においても、その生産性は従業員のコンピュータの性能にかかっています。
もしそれらのコンピュータの動作が遅くなったり、クラッシュしたりすると、従業員の生産性が低下し、組織全体の機動性も損なわれてしまいます。
これほど多くのリスクが伴う中、 のパフォーマンス監視（ ）は、人材とテクノロジーを最大限に活用したいと考えるあらゆる組織にとって、不可欠な機能です。
ここでは、組織が を活用して、従業員のコンピュータ、サーバー、その他のデバイスといったエンドポイント のパフォーマンスを効果的かつ効率的に監視するための、7つのベストプラクティスをご紹介します。
1. あらゆる種類のエンドポイントを監視します
物事をシンプルにしておきたいという誘惑に駆られます。 仮に、組織内のエンドポイントの 90 パーセントがWindowsマシンであるとしましょう。 Windowsマシンを監視するためのツールに投資し、そのためのプロセスを構築します。
確かに、 のLinuxサーバー（）はありますが、それらは人々のオフィスや自宅のオフィスには設置されていません。 また、一部の幹部はMacを愛用しています。 それらの機械がうまく機能していると信じておられることでしょう。何しろ、誰も不満を言っていませんから。 また、Windowsマシンに関して、あなたがどれほど素晴らしい仕事をしているかを示すグラフもたくさんあります。
しかし、それらの他のエンドポイントも重要です。 また、パフォーマンスの問題が発生すると、直接的あるいは間接的に、他の多くのユーザーに影響を及ぼす可能性があります。 （CFOのMacがクラッシュして、購入の承認ができなくなると、多くの人がその影響を痛感することになるでしょう。）
ですから、いずれにせよ、組織内のあらゆる種類のエンドポイント（Windows、macOS、Linux）を監視するためのツールとプロセスを確実に整備しておいてください。
2。 すべてのエンドポイントを監視します（そうです、 のすべての エンドポイントを監視します）
組織内のあらゆる種類のエンドポイントに対応した監視ツールを導入していたとしても、一部のエンドポイント、あるいは多くのエンドポイントが見落とされている可能性は十分にあります。 そう申し上げるのは、企業のパフォーマンス監視の実態を評価するために訪問すると、通常、パフォーマンス監視レポートからエンドポイントの約 10-20 パーセントが除外されていることが判明するからです。
つまり、エンドポイントの 10-20 パーセントがパフォーマンス低下のリスクにさらされており、その結果、それらのエンドポイントを使用する従業員は不満を感じ、生産性が低下することになります。
いずれにせよ、組織内のすべてのエンドポイントを確実に監視できるよう、ツールやプロセスを整備してください。
3。 全体像を把握しましょう
すべてのエンドポイントを見つけることは、ひとまず一つのことです。 IT部門や事業部門の責任者が、管理対象となっているすべてのエンドポイントの「全体像」を把握できるようにすることも、また別の課題です。
パフォーマンスを効果的に監視するには、多くの場合、全体像を把握することが必要です。つまり、ダッシュボード画面を通じて、例えばシカゴのオフィスは順調である一方、シンシナティでは昨夜のアプリケーションのアップグレード後にメモリエラーが発生し、エンドポイントがクラッシュしているといった状況を確認できるような視点です。
企業全体のパフォーマンスを監視するには、企業全体を俯瞰できるだけでなく、パフォーマンスの問題が発生しているエンドポイントの詳細も確認できるようにしてください。
4。 エンドユーザーにとって分かりやすくしましょう
多くの組織では、従業員がヘルプデスクにパフォーマンスの問題を報告すると、その従業員の業務への支障は、そこからようやく始まるのです。 ほとんどのパフォーマンス監視プラットフォームでは、ITエンジニアが問題のトラブルシューティングを行うために、従業員の業務を中断させたり、業務と競合したりする必要があります。
従業員は、自身のエンドポイントに新しい診断用またはリモート制御用のアプリケーションをインストールするよう求められた場合、それに応じる必要があるかもしれません。 この問題の調査は、公式な業務――つまり、その従業員の職務の一環としての業務――が終了するまで、開始できない可能性があります。 もしその問題が断続的に発生し、従業員が行っていた何らかの作業に起因するものであった場合、トラブルシューティングを行う最適な機会を逃してしまったことになります。
もっと良い方法はあるでしょうか？ エンジニアがユーザーの作業を妨げることなく、エンドポイントで何が起きているかを調査できるツールをご利用ください。 エンジニアが、従業員に一切の手間をかけさせたり、クライアントをインストールさせたり、ダイアログボックスをクリックさせたり、1時間も電話対応をさせたりすることなく、プロセスやメモリ使用状況、その他の重要なデータを検査できるようにします。
5。 ローカルで記録し、グローバルでトラブルシューティングを行う
多くのパフォーマンス監視プラットフォームが、侵入型の調査手法に依存している理由の一つは、エンジニアが実際にネットワーク経由でエンドポイントに接続するまでは、エンドポイントの活動に関するデータにほとんど、あるいはまったくアクセスできないためです。
このアプローチには、2つの大きな欠点があります。それは、ユーザーの作業を中断させてしまうことと、エンジニアがアクセスできるデータに制限が生じることです。 問題が断続的に発生する場合や、数時間あるいは数日前に起きた他の事象と何らかの関連がある場合、調査を担当するエンジニアはこうした見落としをしてしまう可能性が高いでしょう。
別のアプローチとしては、エンドポイントにパフォーマンスデータをローカルに記録させる方法があります。そうすれば、エンジニアが問題を調査する際、ローカルのデータストアからすぐに豊富なデータにアクセスして分析に活用できるようになります。
データはすでに収集済みですので、エンジニアはデータを収集するためにユーザーの作業を中断させる必要がありません。 また、データがローカルに保存されるため、エンジニアは、すべてのエンドポイントが詳細なメトリクスを中央管理コンソールに継続的に送信する必要なく、そのデータにアクセスすることができます。
とはいえ、ネットワーク上で膨大な量のデータが収集され、トラフィックの混雑を引き起こすような状況でなくても、エンジニアは、ローカルLANやWAN、ヘルプデスクセンター、セキュリティ運用管理センター、さらには在宅勤務先など、どこからでもエンドポイントのトラブルシューティングを行うことができます。
その結果、トラブルシューティングに役立つより質の高い情報が得られ、問題の解決が早まり、エンドユーザーとエンジニアの双方にとってより便利なやり取りが可能になります。
6。 社内開発チームを支援してください
エンドポイントのパフォーマンスに関する詳細な情報を収集・共有することで、IT運用チームは、社内開発チームが従業員向けに開発しているアプリケーションのトラブルシューティングを支援することができるようになります。
数百から数千のエンドポイントにわたるプロセス実行、メモリ割り当て、ディスク使用状況、その他の主要な指標に関するリアルタイムおよび過去のパフォーマンスデータは、開発者がテスト環境での限定的な展開では検出できなかったり、適切に特定できなかったりした問題のトラブルシューティングや修正に役立ちます。
パフォーマンスのモニタリングは、すべての従業員に適用できる一般的なツールと考えられがちですが、たとえソフトウェア開発スイートの正式な構成要素でなかったとしても、開発組織にとっては貴重なツールとなります。
7。 平均修復時間（MTTR）を短縮する
MTTR（ ）は、おそらくあらゆるパフォーマンス監視手法における究極の指標と言えるでしょう。
問題が発生した場合、ITチームはどれくらいの速さで解決できるでしょうか？ 必要な情報を素早く、簡単に見つけることができるでしょうか？ その問題の影響を受けている従業員の業務を妨げることなく、原因を突き止めることはできるでしょうか？
このような指標を追跡することで、IT部門は自社のパフォーマンス評価ツールや手順の価値を評価することができます。 パフォーマンス監視に活用している人材、プロセス、テクノロジーがMTTRの短縮につながらないのであれば、それは、それらの人材、プロセス、テクノロジーにまだ改善の余地があることを示しています。
これらのベストプラクティスに従うことで、MTTRを短縮し、従業員の日常業務に支障をきたすことなくパフォーマンスを最適化できるほか、社内の開発チームが些細な問題をより迅速に解決できるよう支援し、セキュリティ上の脆弱性やその他の運用リスクへの対応を迅速化することで、その恩恵を受けることができます。
詳細については、私の以前のブログ記事「 」および「Taniumがパフォーマンス監視をより良くする10 の方法」をご覧ください。
実際に動作をご覧になりたい方は、 から、今すぐデモにご登録ください： 。
