ドン・ジョーンズ。 「環境に統合されたIT監視システムを作成します。」 第2章IT管理における個々のサイトの管理慣行の排除

統合IT監視システムに関する本の翻訳を続けています。 質問の陰謀の後、著者はそれらに徐々に答え始めます。



この本には、既製のレシピ、特定のソフトウェアへのリンク、および詳細な実装手法（このための特定の監視システムに関する本が多数あります）が含まれていないことを思い出してください。ここで紹介する資料は、使用できる、またはオプションとして何も続行できない手法のセットですしないでください。



したがって、第2章。情報が断片化されないようにするための対処方法について。 すでに監視システムを使用している人にとって、多くのことはおなじみのようです。



内容



第1章IT環境の管理：間違っている4つのこと

第2章IT管理における個々のサイトの管理慣行の排除

第3章すべてを単一のIT管理サイクルに接続する

第4章監視：データセンターの向こう側

第5章：問題を解決策に変える

第6章：例による統合管理

第2章IT管理における個々のサイトの管理慣行の排除

前の章で、現代のITにおける最大の問題の1つは、技術的に分離されたドメイン全体でITを管理する方法であるという意見を表明しました：DBAはDBMSサーバーを担当し、Windows管理者はマシンを担当し、VMware管理者は仮想化インフラストラクチャを担当します、などなど。さらに。 実際、ITチームに狭い専門家を配置するという既存の慣行を受け入れてキャンセルすることは提案しません。これは実際、重大なメリットです。 ただし、これらの専門家がそれぞれ独自の専用ツールを使用する場合、特定の困難が生じます。 この章では、これらの問題のいくつかを調査し、それらを解決するために何ができるか、およびより効率的な統合IT環境を作成する方法を確認します。

ツールが多すぎると、決定が少なすぎます

「ウォームとソフトの比較」は、パフォーマンスを測定し、問題を解決し、ITの他のコアプロセスと連携する方法に関して思い浮かぶ言葉です。 Exchange Server管理者に、メールシステムの速度が低下していることを伝えます。おそらく、ディスク帯域幅、プロセッサ使用率、RPC要求の数などを含む事前に作成されたカウンタのセットを使用して、高い確率でWindowsパフォーマンスモニタを起動します。さらに、ほぼ図のようになります。 2.1：





図2.1：Exchange Serverの監視。



Exchange管理者が自分のサーバーで何かを見つけられない場合、彼は問題を他の誰かに転送します。 MicrosoftディレクトリサービスはExchangeサーバーのパフォーマンスと正常性において非常に重要な役割を果たすため、おそらくこれはActive Directory管理者になります。 Active Directory管理者は、パフォーマンスを評価するためにお気に入りのユーティリティを実行します。ほとんどの場合、図2.2のようになります。 これは非常に特殊なツールで、 AD専用の特別なスクリーンと測定器があります。





図2.2：Active Directoryステータスの監視。



ディレクトリサービスに問題がない場合は、ネットワークインフラストラクチャの専門家に問題を問い合わせてください。 彼は、パフォーマンス評価画面を備えたエンタープライズルーター管理ソフトウェアのように見える別のツールを入手します。 図2.3を参照してください。





図2.3：Ciscoルーターヘルスモニタリング。



要約すると、すべてのツールが専門家を同じ結論に導きました-すべてが正常に機能します。 これは、ユーザーの観点から見ると、Exchangeは間違いなく「素晴らしい」とは言えないという事実にもかかわらずですが、同時に、専門家は問題を示す証拠を見つけられませんでした。 簡単に言えば、これはまさに「ツールが多く、答えが少ないとき」です。 今日の高度なITシステムでは、パフォーマンスは、可用性やスケーラビリティなどの他の機能とともに、多くのコンポーネントが相互に作用する結果です。 1つのサブシステムの作業を監視して、ITを完全に管理することはできません。 相互作用し相互依存する要素の複合体の働きを考慮する必要があります。



専門ツールへの依存は、ITの既存の質問に対する完全な回答を提供しません。 この依存症は、システムの拡張、サービスレベルアグリーメント（SLA）、およびその他の重要なタスクの管理が必要になったときに結びつき始めます。 実際、私はそのような特殊なツールが馬のまばたきのように機能する状況を見ました。視野を大幅に狭め、専門家に問題を解決させたり、できるだけ早くそれを特定させたりしません。

Heatherは彼の組織のDBAであり、DBMSソフトウェア、オペレーティングシステム、およびそれが動作するハードウェアを含むDBMSサーバー全体を担当しています。 一度、彼女は仕事でチケットを受け取ります。そのチケットでは、ユーザーはDBMSを使用するアプリケーションのパフォーマンスの急激な低下について不平を言いました。 彼女は監視ユーティリティを起動しましたが、問題は見つかりませんでした。 ほとんどの場合、サーバー上のプロセッサは完全にアンロードされ、ディスクとの交換は通常の制限内であり、メモリ消費も順調です。 しかし、彼女は、通常サーバー上にあるワークロードが通常よりも低いことに気付きました。 これにより、問題がネットワーク側のどこかにあるのではないかとの疑念が生じ、チケットをインフラストラクチャチームに転送しました。 スペシャリストはすぐにチケットを返却し、ネットワーク上に小さなプラグがありますが、それらはすべて彼女のサーバーから出るトラフィックによって引き起こされることを彼女に保証しました。



ヘザーはすべてを再度確認し、サーバー上のネットワークインターフェイスが静かに動作していることを確認しましたが、トラフィックは通常より少し大きくなっています。 徹底的なチェックを開始した彼女は、サーバーが記録しているチェックサムエラー（CRC）が多すぎることに気づきました。 また、通常のパッケージはコンピューターに到達するまでに時間がかかるため、顧客はこの問題をシステムの一般的な速度低下と見なしています。



ヘザーはまず第一に、彼女がよく知っていることをチェックしたという事実のために、これにより彼女は「壁に沿って問題を引き伸ばし」、ネットワークエンジニアにそれを渡して時間を浪費させました。 彼女はサーバーのネットワークインターフェースを監視する習慣がなく、そのパフォーマンスを評価する手順は、DBMSの問題をトラブルシューティングする際の標準チェックのルーチンルーチンの一部ではありませんでした。

専用ツールはコラボレーションを促進しません

複雑なITシステムのコンポーネントが相互に依存し、高度に相互接続されている場合、ITスペシャリストは専門家としてではなく、希望どおりに見えることがよくあります。 言い換えれば、ITを管理するこの方法は、個別のテクノロジードメインの作成を引き起こします。 DBAグループ、Active Directory管理者グループ、ネットワークインフラストラクチャグループなどが表示されます。 専門の専門家が幅広い機能グループに分かれている「マトリックス管理」を実践している企業でさえ、狭い技術セクターの存在を認めています。 このような場所が存在する主な理由は2つあり、ほぼすべてのITプロフェッショナルがそれらを説明できます。

• 「私はそれについて何も知りません。」 各専門家は、技術分野の専門家です。 DBAは、ルーターの監視や管理について何も理解しておらず、原則としてルーターとの連携を特に望んでいません。 ほとんどの組織では、スタッフに十分な時間がないため、大規模な相互専門化はほとんど効果がありません。 2番目と3番目の専門分野の訓練のための時間の再配分は、必然的に主要な仕事で職務を遂行するために必要な時間の減少につながります。
• 「私がすることを誰にも邪魔されたくない。」 ITプロフェッショナルは、自分の仕事をうまく行い、ほとんどの問題が変更の結果として発生し、これに非常に敏感であるという事実を理解したいと考えています。 誰かがどこかで手に負えない状態になると、問題が発生することが保証されます。 IT環境の一部で誰かが何かを変更していて、それについて何も知らない場合、外部の干渉に関連する問題を解決するための困難な時期をすでに待っています。

これらの議論は両方とも十分に深刻であり、ITチームの各スペシャリストが組織で使用される各テクノロジーの専門家になることは絶対に推奨しません。 ただし、これらの2つのステートメントに反映される多くのポイントには、若干の説明が必要です。 1つの理由（私は再び専門ツールに戻ります）は、技術的に独立した分野で使用されるツールがコミュニケーションの障壁の構築を引き起こし、 ITスペシャリスト間の表面的な協力さえもしないことです。 コラボレーションは、人間の良好な関係から生じますが、これらの関係でさえ、各スペシャリストが自分の個別のデータセットを見て、「別の楽譜から再生する」という事実としばしば矛盾します。 私は、管理者が誰のせいであるかを議論するのに何時間も費やした企業に行ってきました。 お互いにうなずき、証拠として、独自の専門ツールで撮影した独自の技術サイトからのデータを実証しました。

ダンはActive Directory管理者として会社で働いており、それぞれが仮想マシンで実行される数十個のドメインコントローラーを担当しています。 Pegは、仮想サーバーのインフラストラクチャの編成と、仮想マシンが実行されている物理ホストの管理を担当します。

ある日、夕食後、ペグはダンから電話を受けました。 ダンは、一部のドメインコントローラーのパフォーマンスの低下の問題に対処しようとし、物理仮想化ホスト上のコントローラーが必要とするリソースを使い果たしているものがあることを示唆しました。

ペグは仮想サーバーコンソールを開き、サーバーが物理CPUまたはメモリのリソースを使い果たしていないことをダンに保証します。ディスクとの交換は非常に正常であり、割り当てられた値の範囲内です。

Danオブジェクト。ActiveDirectory監視ユーティリティの値を参照します。このユーティリティは、CPUとメモリの最大使用率を示し、ディスクキューの長さも示します。つまり、データの読み取りと書き込みがディスクに遅くなります。 ペグは、すべてが物理サーバーで正常であると主張します。 Danは、仮想サーバーの設定を変更して、割り当てられるリソースを減らすことができるかどうかを尋ねますが、ペグは「いいえ」と言います。



2人の管理者が数時間サッカーをします。どちらもまったく異なるものが書かれた自分の画面を見ます。 彼らは共通の技術的言語を話すことができず、問題を解決するために協力することはできません。

実際、すべてのIT専門家が技術の専門家である必要はありません -それは弱いです。 しかし、パフォーマンス、パフォーマンス、スケーラビリティ、可用性などの問題において、相互のやり取りのプロセスを簡素化する必要があります。 同時に、技術領域ごとに個別のばらばらのツールを使用する場合、これは難しい作業になります。 ネットワーク管理者は 、データベースサーバーを監視する手段を絶対に必要としません。これは、データベース管理者が、ネットワークハードウェアを管理する人が作業ツールにアクセスすることを特に望んでいないためです。



別の技術的な専門分野を指す専門ソフトウェアの存在は、先ほどお話ししたまさにこれらの2つの困難をもたらします。



最終的に、さまざまな専門家が使用するすべてのパフォーマンス情報が1つの画面に収集される統一されたツールセットがあれば、問題を解決できます。 この場合、全員が同じルールでプレイし、同じデータを調べます。これは、環境の全体像を反映し、内部の依存関係に満ちています。 誰もが問題がどこにあるかを見ることができ、 この後のみ、彼らは自分の好きな特別なツールを入手し、そのようなニーズがある場合、対象分野で問題を修正し始めることができます。

曇りの問題。 ローカルおよびリモート監視の統合

統合された監視コンソールの概念は、組織がますます多くのITインフラストラクチャをクラウドに移行し始めるにつれて、さらに重要になります。

クラウドには新しいものは何もありません

私は「クラウド」という用語の大ファンではないことを認めなければなりません。 彼は1マイル離れたところからマーケティングや広告の匂いがしており、実際、彼には超自然的なものは何もありません。 組織は、長年にわたってIT要素の一部を外部委託していました。 おそらく、これに最もよく使用されるサービスはWebホスティングでした。 社外の誰かの機器にデプロイされた単一のWebサイトを削除するか、サードパーティのデータセンターにサーバーを配置するかのいずれかです。

私たちの議論では、「クラウド」の概念は、ITの一部の要素を指しているだけであり、ITの一部はアウトソーシングされ、基盤となるインフラストラクチャを隠していることに同意します。 たとえば、ホスティング会社のデータセンターにサーバーを配置し続ける場合、通常、ネットワークの内部構造、インターネットへの接続方法、ルーターの種類などに関する詳細情報はありません。この場合のデータセンターは、あなたがお金を払う抽象的な何か。 たとえば、Windows AzureやAmazon Elastic Cloudが提供する最新のクラウドコンピューティングモデルでは、仮想マシンが実行されている物理ホストがわかりません。 物理層の抽象化、およびデータストレージ、ネットワーク通信などの関連要素については、お金を支払います。 「サービスとしてのソフトウェア（SaaS）」サービスを使用する場合、基盤となるインフラストラクチャ全体を抽象化するために料金を支払うため、注文したソフトウェアの作業にどの仮想マシンが関与しているかさえわかりません。

インフラストラクチャの大規模または小規模のサブシステムの数がクラウドサービスプロバイダーの手に渡ったとしても、これらのコンポーネントはビジネスの一部です 。 通常の機能に依存する重要なビジネスアプリケーションとプロセスがまだあります。 リモートインフラストラクチャを制御できなくなり、特定の時点で内部で何が行われているかを理解する能力が低下します。



この場合、特殊なツールは完全に使用できなくなります。 間違いなく、アウトソーシングの一般的な考え方の一部は、現在他の人が取り組んでいるタスクについてあまり心配することではありませんが 、社外に移動したITシステムは、 あなたが個人的に責任を負うビジネスのサポートにまだ関与しています 。 したがって、少なくとも、クラウドに取り込まれた要素の作業が環境の残りの部分にどのように影響するかを確認する必要があります。 さらに、問題の特定の原因で信頼できる「指を突く」能力が必要です。たとえそれがアウトソースされたアイテムであっても、障害の除去に直接影響を与える能力はありません。 これは、統合監視がIT環境において正当な位置を占める場所です。 たとえば、図2.4。 Amazon Web Servicesなどの一部の外部委託コンポーネントを含む、一部のインフラストラクチャコンポーネントの一般的なステータスを示す、非常に単純な「統合モニタリングダッシュボード」が表示されます。





図2.4：統合された監視のための一連の指標。



インジケーターパネルのアイデアは、パフォーマンスの問題がどこから始まるかを目ですばやく判断し、必要に応じて詳細にすばやくアクセスし、問題がクラウドの終わりにある場合は修正を開始するか、問題をエスカレーションすることです。誰が責任を負いますか。



完全に理解できると考えてください。ビジネスに影響を与えるIT環境の一部を外部委託する組織は、遅かれ早かれクラウドで何かがうまくいかない場合に大きなトラブルに備える必要があります。 はい、もちろん、あなたはクラウドパートナーとサービスレベル契約（SLA）を持っていますが、これらのSLAを注意深く読んでください-原則として、彼らはSLAの条件が満たされていない場合に支払いを払い戻すと述べています。問題は、SLAの失敗によって引き起こされたビジネスへの損害の補償に関するものです。 したがって、インフラストラクチャを最大限に制御することは完全にあなたの利益になります。

そして、すでにそのようなシステムを構築している場合、事態が悪化することが判明するとすぐに、アウトソーシングパートナーにすぐに連絡して、誰かに問題の解決を開始してもらうことができます。 したがって、ビジネスへの悪影響は少なくとも最小限に抑えられます。

不足しているサイト

パフォーマンスの監視、管理手順、スケーラビリティの計画などに関しては、「サイトの欠落」と呼ばれる別の問題があります。 テクノロジーのみに焦点を当てた当社のITアプローチは、周囲を非常に近視眼的に見ることにつながります。 たとえば、図2.5の図を見てみましょう。 これは、すべてのIT管理者が単一のアプリケーションのコンポーネントの構造を見る必要があるときに描く典型的な（単純化されていないとしても）スキームです。





図2.5：アプリケーション構造。



問題は、この写真に明らかに欠落しているサイトがあることです。 たとえば、インフラストラクチャはどこにありますか？ この絵を描いた人は、インフラストラクチャ、スイッチ、ルーターなどを扱っていないようでした。これは含まれていません。 クラウドに運ばれるコンポーネントの一部とまったく同じであることが暗示されています。 おそらく、図2.6は周囲のより正確な表示になるでしょう。





図2.6：詳細なアプリケーション図



しかし、このスキームでも、おそらく何かが欠けています（ たとえば、無停電電源装置制御システム-pr.perev。 ）。 これは現実であり、おそらく今日のITに存在する最大の危険の1つです。通常の理解を超えた環境の特定の部分は注意から外れます。



繰り返しになりますが、統合監視は利点となります。 サーバーなどの1つの技術部分のみに焦点を当てるのではなく、 彼は技術的に独立していて、 どこからでも情報を収集できます。



実際、統合監視システムが環境内の新しいコンポーネントを個別に検索できる場合はさらに優れています。 ソフトウェアは、人間と同じ前提で導かれ、同じ技術的偏見を経験する必要はありません。 一般的に、統合コンソールは、Hyper-Vのスペシャリストであるか、他のブランドよりもシスコルーターを好むかどうかに関係なく、あなたが誰であるかは関係ありません。 彼女は現実をそのまま知覚し、さまざまなコンポーネントを検索し、環境の正確で完全な図を作成します。 その後、システムはこれらのコンポーネントの監視を開始し（必要に応じて、個々のコンポーネントにアクセスするためにユーザー名とパスワードを要求することができます）、包括的で統一されたインジケータパネルを作成できます。 自動検索機能の欠如が時々問題になるインフラストラクチャに遭遇しました：

Terryは、コアビジネスアプリケーションを推進するインフラストラクチャコンポーネントを担当しています。 コンポーネントは、ルーター、スイッチ、DBMSサーバー、仮想化サーバー、メールサーバーであり、SaaS販売管理アプリケーションとしてもアウトソースされています。 テリーは統合監視システムについて耳にし、彼の会社は環境の統合監視を提供するサービスにも投資しました。 Terryは各コンポーネントと、監視コンソールに表示されるすべてのものをインジケーターの形で慎重に構成しました。

ある日、アプリケーションの1つが完全に機能しなくなりました。 テリーは監視コンソールに行き、「アラーム」を示すいくつかのインジケータを見ました。 彼はすぐに、チャネルがクラウドにあるアプリケーションにアクセスできないことを知りました。 インフラストラクチャインジケータの状態をさらに調べると、この接続を経由したルーターが完全に機能し、ファイアウォールの状態も正常であることがわかりました。 テリーは完全に混乱していた。

数時間の手動作業とケーブルトラッキングにより、テリーが考えもしなかった環境の構造について何かが明らかになりました。ファイアウォールの反対側には欠陥のあるルーターがありました。 インターネットへの接続は別のチャネルを経由し、ビジネスアプリケーションへの接続が機能しなかったため、インターネットへの接続は完全に機能していました。 この「余分な」ルーターは、誰もがずっと忘れていた古い継承デバイスでした。



自動検出機能を備えた監視ソリューションは、何も「忘れる」ことはありません。 この追加のルーターを見つけてインジケーターパネルに追加することで、テリーは間違いなく問題をより迅速に切り分けることができます。

自動検出は、テクノロジードメイン外にあり、一般的には関係のないコンポーネントの識別にも役立ちます。 ルーターやスイッチなどのインフラストラクチャコンポーネントは、孤立した要素の最も一般的に使用される例です。これは、すべての組織がこれらのデバイスをサポートする専門の専門家を持っているわけではないためです。 ただし、従来のアプリケーションとサーバー、専用の機器、その他のコンポーネントは、誰の責任範囲内になくても簡単に表示できます。 自動検出により、このような省略が回避されます。

ITのすべてが問題であるわけではありません：注文、ルーティング、サービスの提供。

ほとんどの組織は、IT部門を「消防隊」と見なしがちです。なぜなら、彼らの観点から見ると、ITは問題を解決するために存在しているからです。 もちろん、これはそうではありません。また、すべての組織は日常のタスクを実行する際にITにはるかに依存しており、緊急に問題を解決するだけでなくIT部門を必要とします。 しかし、「火を消す」ことは広く注目を集めているが、ルーチン作業はそれほど顕著ではありません。



この態度の結果として、IT管理者はまず第一に、重大なインシデントの結果を簡単に排除できるツールを使用しようとしています。 統合された監視システムはここでうまく適合します。 一方、これまでのところ何も起こっていない場合、それらは私たちにとって必要ではないようです。 それらは、可用性と可用性の領域でのみ問題をより速く解決するために必要です。 そうだね



そうでもない。 真に統一された管理には、ITプロセスのすべての参加者の日常業務の促進も伴います。

たとえば、ユーザーは、単純なパスワードのリセットやユーザーアカウントのロック解除から、新しいハードウェアやソフトウェアのリクエストまで、日常の日常的なサービスを注文して受け取る必要があります。

誰かがこれを大胆な発言であると考え、これらの日常的な要求は問題のように処理されるべきだと思います。 ITILなどのITフレームワークを見ると、それがどのように進むのかがわかります。日常的なIT手順は、問題解決も含む統一された管理プロセスの一部である必要があります。



統合管理（単なる「監視」ではなく）が、問題の解決と日常的なITサービスの実行に関連する作業に提供できる幅広い機能の一部を検討してください。

• ワークフロー-問題が発生した場合、それらは構造化されたプロセスまたはワークフローに向けられる必要があります。 これは、必須手順のチェーンを強制的に通過させることで、問題解決をより効果的にするのに役立ちます。 問題とさまざまなルーチンサービスを解決するためのワークフローは異なりますが、ワークフローを管理および追跡する機能を備えていることは大きなメリットになります。
• 調整。 ワークフローには承認を含める必要があります。 この機能は、ソフトウェアおよびハードウェアの変更の要求、セキュリティ手順の要求などの日常的なサービスで最も明白であり、これは問題の解決と同じくらい重要です。 設定を変更してデバイスを再起動しても、すべてのタスクを解決できるわけではありません。 場合によっては、より大きな変更を行う必要があり、正式に承認ルートを通過して、これらの変更が有用であることを確認できるようにする必要があります。
• リクエストルーティング 通常、問題を修正するスペシャリストが最後にその問題を聞いた人です。 最初の行にいる人たち-あなたのヘルプデスクとエンドユーザーは、それに「反応する」最初の人たちです。 , . : , . .
• . -. , . , , . , -.
• . « » , .

もちろん、他の機能もあります。それらについてはさらに検討します。ほとんどの日常的なIT要求と問題の解決策をより効率的かつ一貫して処理するために必要な基本的な特性がリストされています。

次のエピソードでは...

この章では、テクノロジードメインと専門家の境界を消去する方法について説明しましたが、これが完全に実行可能でない場合は、少なくともそれらの間のギャップを解消します。



この章では、技術領域と専門家の間の境界を消去する方法、または少なくともそれらの間の通路を確立する方法について説明します。これは、最新の監視およびIT管理における主要な問題の1つを解決するのに役立ちます。



次の章では、より複雑なトピック、つまり単一の管理サイクルにすべての関係者を関与させる方法に焦点を当てます。コミュニケーションの改善についてです。残念ながら、コミュニケーションは非常に多くの場合、オプションの二次的なタスクです-私たちは自分自身で努力する必要がありますそれらに対処しますが、状況が私たちを支配し始めたとき、私たちは可能な限りこれらの努力を非常に簡単に適用し始めます。そのため、コミュニケーションをより「自動化」するようにプロセスとツールを調整し、多くの労力をかけることなくすべての従業員が管理プロセスに参加できるようにする必要があります。



第1章に



進む第3章に進む