ドン・ジョーンズ。 「環境での統合IT監視システムの作成」第1章IT環境の管理：間違っている4つのこと

翻訳者から

私が監視を開始した瞬間から多くの時間が経過し、最初に監視が特定の技術的タスクであった場合、時間の経過とともに（少なくとも個人的には）その価値は多くのステップを上回り、今では成り立っていますたとえば、企業情報システムなど、ビジネスを行うための基本的なツールとともに。



ITインフラストラクチャの監視をテーマにした記事と翻訳の一部を広め始めた後、このトピックについて非常に狭く技術的な理解に出くわす必要がありました。それはかつて持っていたものなので、これを体系的に提示する考えがありました。 私はゆっくりとこのトピックに関する記事を書き始めましたが、直感的なものは紙にはあまり合いませんでした。木の後ろには森がありませんでした。 もちろん、私たちは皆Googleと他の著者が書いたものをスパイする能力を持っていますが、それはそこにはありませんでした。 数え切れないほどの記事とブログ投稿が、オペレーティングシステムの次のバージョンで別の監視システムをとめる技術的側面と、これに関連する困難を英雄的に克服することに捧げられました。 モニタリング方法論、メトリックの選択の原則、プロセスの正しい構築およびビジネスとのリンクの原則に関する記事はほとんどありませんでした。また、特定の問題を解決するためにモニタリングを適用する特定のケースについても説明しました。 そして、偶然にも、Don Jonesの非常に小さな本「Creating a Unified IT Monitoring System in Your Environment（ENG）」の手に落ちました。



これが必要なものでした-哲学を説明し、いくつかの概念を示し、いくつかの領域をリストしました。その後、ITおよび組織全体で監視システムを機能させることができ、詳細から全体像が最終的に形になり始めました。 私は自分でいくつかのアイデアを思いつきましたが、私は専門家の間で面白くて議論に値すると思われる多くの新しいものを見つけてうれしかったです。 そして最も驚いたことに、この本は無料でした。



翻訳することにしたのはなぜですか？ もちろん、ハーバーの住民の3分の2がよく読んで英語を話すことは間違いありませんが、これを行う方法を知らない人、または彼がそれほど多くの英語の手紙を習得する忍耐を持っていない人について考える必要があります。 個人的にロシア語で読むことを好みます。特に、ロシア語への論争の的になっている用語（hello、PMBOK！）に関係のない用語ですが、重要で感情的なトピックに関連しています。 翻訳は私の個人的なイニシアチブです。私はそれから実質的な利益を得ることはありません。私はそれを幅広い読者に新しい知識をもたらす唯一の仕事だと考えています。 私の唯一のメリットは、著者が表現したロシア語の考えを語ることです。 :)



さらに、ここに含まれるアイデアや提案についても話したいと思います。 メンタリティ、ライフスタイル、法的枠組みの違いが著者によって記述されたものとは異なる特定の問題を引き起こす可能性があることは周知の事実であり、おそらくそれらに対処するための試行済みの方法が既に試され、テストされています。



この本は、まず第一に、ITマネージャーに役立ちます-部門およびサービスの責任者、IT監視プロジェクトマネージャー、チーフおよびリーディングスペシャリスト、いつかはマネージャーになり、組織全体の活動が何を意味するかを理解しようとするシステム管理者。



PS特に明記しない限り、本文中の斜体の強調はすべて著作権です。

内容



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

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

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

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

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

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

著者から。 リアルタイムパブリッシャーの紹介

Realtimeは、7年間にわたり、電子的に配信される予定の高品質の書籍を何十冊も作成しました。 また、読者には無料です。 私たちは、読者の利益のために各本を作成する負担を引き受けることに同意したスポンサーとの寛大なサポートと協力を通して、この出版モデルを機能させることができました。



これまで出版物を完全に無料で提供してきましたが、品質が私たちの主な目標よりも低いことを意味することをためらわないでください。 私の仕事の目標は、私たちの本が同じくらい良いものであることを確認することであり、ほとんどの場合、40ドル以上かかる印刷本よりも優れています。 私たちの電子出版モデルには、印刷された本に比べていくつかの重大な利点があります。著者が書いた直後に文字通り章を取得します（これはモデルに存在する「リアルタイム」アスペクトです）。テクノロジーの新しいトレンド。 また、私たちの本は広告ではなく、白書でもないことを強調したいと思います。 私たちは独立した出版会社であり、私の仕事の重要な側面は、著者が制限や留保なしに専門家の意見を表明できるプラットフォームを提供することです。 私たちは出版物に対する完全な編集管理を維持しており、近年非常に多くの質の高い本を作成できたことを誇りに思います。



特に友人や同僚からこの本を受け取った場合は、私たちのサイトnexus.realtimepublishers.comにアクセスしてください。 さまざまなトピックに関する他の書籍が多数あります。もちろん、興味のあるものを見つけることができます。費用はかかりません。 今後も教育目的でRealtimeに引き続きご参加ください。



喜んで



シリーズの編集者であるドン・ジョーンズ。

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

IT業界が始まった当初、「監視」という概念は、メインフレームが設置されたキャビネットの中で電灯の焼損を求めてさまよう人を意味していました。 もちろん、これは、意図していたよりも少し難しい条件で動作する真空装置の故障を特定する正しい方法ではありませんでした。 したがって、当時の監視は、問題に対応するための非常に反応的な方法でした。



同時に、ヘルプデスクは、電話に応答するのと同じ男でした。1人または別の数十人の「コンピューター関係者」が、カードをリーダーに押し込む、燃え尽きたランプを追跡するなどの支援を必要としていました。 チケット、知識ベース、サービスレベル契約（SLA）の概念はまだ発明されていません。 その後、IT管理は大幅に改善されましたが、残念ながら、改善される可能性があるはずのレベルまで改善されていません。 確かに、私たちの作業ツールは非常に複雑で成熟したものになっていますが、これらのツールの使用方法はIT管理プロセスであり、ある意味では、無線管を交換するためのリアクティブな方法のレベルのままです。



論理的にはITがその作業をサポートする必要がありますが、多くの組織でIT管理慣行が基づいている概念のいくつかは実際にそれらを害します。 この章の説明は、本書の以降の章にスムーズに移行するいくつかの重要なトピックに焦点を当てます。 目標は、IT管理がどのように機能するか、特に監視するべきかについての考え方を変えることです。 ITが組織にもたらす価値と、IT環境の管理を改善する方法。

IT管​​理：どのようにこれに到達したか、そしてなぜ私たちが持っているものを持っているのか

ITの存在の初めに、今日の標準のプリズムを通してそれらを考慮する場合、比較的単純なシステム、さらには単純化されたシステムを扱いました。 ITスペシャリストのチームは、多くの場合、発生した問題を解決できる人で構成されていました。これは、ITを車の形で考えた場合、システムにそれほど多くの「可動部品」がなかったからです。 機械はそれ自体が複雑であり、さまざまなことを行うことができましたが、同時に一人で完全に理解されました。



ITカーが宇宙船になり始めたので、徐々に専門化が必要になりました。 個人用システムは非常に複雑になっているため、各システムを監視、保守、管理できる特定の知識を持つ専門家が必要です。



メッセージングシステム。 データベース インフラストラクチャコンポーネント。 ディレクトリサービス



これらのシステムを作成するベンダーは、サードパーティのメーカーと協力して、当社の専門家が各システムを監視および管理するのに役立つツールを開発しました。 ある時点ですべてが素晴らしく見えたが、実際にはこれらのタスクを実行する他の方法はなかったかもしれないが、すべてがうまくいかなかったことがそこにあったが、それが独自のドメイン（ドメイン固有のサイロ）の形成につながった-それぞれ独自の個別のツール、手順、専門知識を備えている-多くのITサービス内で「分離した塔」の問題となっているもの。



そして今、私たちのシステムが非常に複雑になり、膨大な数の接続があり、さらにシステムが私たち自身のデータセンターの外にますます配置されるようになると、すぐに現在に移ります。 ユーザーが問題に遭遇した場合、どの複雑なシステムに問題があるのかをユーザーが特定できないことは明らかです。 彼らは、彼らが見ているものと、彼らの意見では、この問題がどのように現れるのかを教えてくれます。これは、いくつかのシステムの相互作用とそれらの相互依存性の結果です。 ユーザーには全体的な環境、つまり一般的に「IT」が表示されます。これは、データベース、サーバー、ディレクトリ、ファイル、ネットワークなど、バックエンドで表示されるものとは多少異なります。 その結果、問題の真の原因を追跡するのに多くの時間を費やすことが多く、さらに悪いことに、差し迫った事件を見ることさえありません。問題は、個々の人だけでなく、環境全体の作業の最終結果を見るときにのみ存在するためですパーツ。 ユーザーはプロセスから完全に離婚したように感じます。また、ヘルプデスクはITから切り離されることもあります。 同時に、IT管理は、環境全体を考慮するのではなく、ネットワーク内の各システムに固有のメトリックを使用せざるを得ないため、パフォーマンスや可用性などの問題に完全に陥り、困難な時期を迎えています。



ITサービスの構築方法により、ビジネスレベルで非常に具体的な問題が発生し、世界中で共通の懸念事項および苦情の原因となっています。

• IT部門は、ビジネスSLAの定義と照合が困難です。 「メールサーバーは常に99％動作します」-このSLAはビジネス向けではなく、技術的な契約です。 「メールは、メールシステムの外部ユーザーと内部ユーザーの間で99％シームレスに送信されます」-これはビジネスレベルのSLAですが、このステートメントには単純なメールサーバーよりもかなり多くのシステムが含まれるため、測定が困難です（実際にはローカルITサービスの責任の範囲外にあるシステムの責任をサブスクライブすることは非常に慎重です 。
• ITシステムの全体的な「健全性」の指標に基づいて複雑な状況を事前に予測するのは困難であるため、ITサービスはほとんどの場合、問題解決において事後対応を維持します。
• 問題が発生すると、ITは多くの場合、その原因を詳細に把握するのに時間がかかりすぎます。
• ITで使用されるパフォーマンスと「システムヘルス」の概念は、データベースサーバー、ディレクトリサービスサーバー、ネットワークデバイスなどのシステムに基づいており、ユーザーおよび組織全体がこれらのシステムによって提供されるサービスをどのように認識するかではありません。
• ITサービスは一生懸命働いており、ビジネスに役立つ新しいテクノロジーを採用しています。 奇妙に聞こえるかもしれませんが、事実は変わりません。通常、変更は多くのトラブルの引き金となるため、ITサービスは多くの場合、変更に抵抗する組織の大部分です。 障害のあるシステムは誰にも役に立たないが、会社の構造に迅速に変更を導入できないことも、近い将来の組織の能力と柔軟性に脅威を与える可能性がある。
• ITサービスは非常に懸命に働いており、チームの経験と能力を大幅に超える、または物理的なアクセシビリティを超えた新しいテクノロジーを適応させています。特に、通常「クラウドコンピューティング」の概念の下で組み合わされる外部委託オファーの場合はそうです。 これらのテクノロジーとアプローチは以前とは大きく異なるため、ITは新しいシステムの監視と管理に自信を持っていません。 したがって、彼らはそのような決定の実施に抵抗し、彼らの実施が組織に損害を与えることを恐れます。
• サービスデスクに最先端のセルフヘルプシステムがある場合でも、ユーザーはITに関して非常に無力であり、状況から離婚していると感じます。

これらのビジネスレベルの障害はすべて、ITの管理方法の直接的な結果です。 通常、監視およびIT管理プロセスには4つの主要な問題があります。 もちろん、すべての組織が一度にそれらをすべて持っているわけではなく、ほとんどの組織は少なくともそれらのことを聞いており、それらに対抗するために懸命に働いています。 ただし、企業は4つの問題すべてについてアイデアを持っていることを明確に理解する必要があり、これが行われた場合、ほぼすぐに前述のビジネス上の問題に対処することができます。

問題1：別の領域（「タワー」）でITを管理します。

図1.1、1.2、および1.3は、今日のIT監視および管理における基本的な問題の1つを示しています。





図1.1：WindowsパフォーマンスモニターでのWindowsパフォーマンスの測定。





図1.2：SQL ServerパフォーマンスでのDBMSサーバーパフォーマンスの測定。





図1.3：ルーターのプロセッサ負荷の測定



数値は、ITシステムのさまざまなコンポーネントのパフォーマンス/負荷状態を表します。 これらの各画像は、特定のタスクの結果を追跡するために多少専門化されたツールによって作成されます。 たとえば、ルーターのパフォーマンスを追跡するために使用されるソフトウェアは、データベースサーバーや、別のネットワーク上にあるルーターに対しても同様の状況を再現できません。



これは非常に一般的で根本的な問題であり、ほとんどのIT専門家はこれが問題であることを認めたくさえありません。 これらの個別の厳密に特定のツールの使用は、ITの作業において非常に定着した自然な慣行であるため、ほとんどの人は他のことを考えられません。 それでも、問題の監視と解決に関しては、これらの特殊なツールの使用を、防衛の最前線として過去に残す必要があります。



なんで？



主な理由の1つは、これらのツールでは「1ページ」にとどまることができないためです。 特定のツールが関係する場合、IT専門家間の論理的かつ学際的な議論は失敗します。 「DBMSサーバーを見ると、そのパフォーマンスは毎分200トランザクション以上です」とある専門家は言います。 「まあ、それはルータが毎分10,000パケット以上を処理するので問題になる可能性があります。」 2人のスペシャリストは、生産性について生産的に話すことができる共通言語を持っていません。それぞれのスペシャリストは、自分たちの「塔」、つまり主に使用する技術の深い技術的側面に縛られているからです。



また、フィールド固有のツールキットは、すべてのITサービスにおける最悪のプラクティス、つまりシステムを分離して見ることを奨励します。 DBMS管理者は、ルーターがどのように機能するか、つまりメールサーバーのパフォーマンスの良し悪し、またはディレクトリサービスインフラストラクチャが期待どおりに機能することを確認するために何を調べる必要があるかを知りません。 したがって、DBMS管理者は馬の目隠しをして、データベースサーバーのみを確認しますが、彼のサーバーは真空で動作しません。 他のシステムは、それ自体が残りのインフラストラクチャに影響を与えるように、作業に影響を与えます。 すべてが一緒に機能しますが 、あまりにも特殊なツールを使用しているため、 表示できません。 基本的に、これは、個々の「タワー」にアクセスするために設計された特別なツールが単一のチームで動作し、誰もが必要とする情報を共通のコンテキストに移動できる新しいツールが必要であることを意味します。 疑いもなく、専門ツールは常に需要がありますが、情報への最初のアクセスラインではありません。

ジェリーは中規模企業の典型的なIT部門で働いています。 彼の専門はWindowsサーバーの管理です。 彼のチームには、Webアプリケーション、MS SQL ServerおよびOracle、VMware vShpere、ネットワークインフラストラクチャの専門家がいます。 CRM（顧客関係管理）やメールなど、一部の企業アプリケーションは外部委託されています。



最近、電子注文確認を含む顧客の電子メールメッセージの送信を停止するインシデントが発生しました。 問題を解決するために、彼らは当初、理由が外部委託された郵便サービスにある可能性があるという仮定でジェリーを雇いました。 しかし、ジェリーはメールがうまくいくことを知りました。 彼はこの問題をWebソリューションのスペシャリストに紹介しました。Webソリューションのスペシャリストは、Webサイト自体は正常に機能していることを確認しましたが、送信したメールはどこかに折り返されていました。 ジェリーはメールホスティング会社のチケットに記入し、システムが正常に機能しており、クライアントのWebサーバーが使用するパスワードを確認するのがいいと答えました。



1日以上がホスティング会社とさまざまな専門家とのやり取りを経て、問題は最終的に企業のファイアウォールにまで及びました。 少し前までは、新しいバージョンへのアップグレードが行われ、企業ネットワークの境界、つまり企業のWebサーバーが存在する場所からの送信メールトラフィックがブロックされました。 彼らはネットワークの専門家を呼んで、ファイアウォールを再構成し、問題は解決しました。

このストーリーは問題の本質を正確に示しています。ITスペシャリストのチームを特定のプリンシパルとして管理する場合、問題を解決するために協力する能力を大幅に妨げます。 彼らが仕事をするために特別なツールを必要とするという事実は、個々の所有物とより効果的な共同仕事の境界の破壊に対する障害であってはなりません。 これは、インフラストラクチャの一部が外部委託されている場合に特に重要になります。 ホスティング会社は、提供するシステムを除き、他のシステムに対して責任を負わないため、主権のある「国家」です。 ただし、システムとプロセスがシステムに依存しているため、自分のチームは、これらのシステムがデータセンターに正しく立っているかのように、誤動作の場合に何をすべきかを監視し、知ることができるはずです。

問題2：ユーザー、サービスデスク、およびIT管理の間には接続がありません。

コミュニケーションは、チームを機能させる重要なコンポーネントです。 この場合、組織を代表する「チーム」も例外ではありません。 ITの場合、通常はヘルプデスク組織にシステムを使用します。これは、これが通信の合理的な方法であることを意味しますが、これで十分とは限りません。 ヘルプデスクシステムは、原則として、問題への対応とその後の反応管理の概念に基づいており、定義上、実際には予防的ではありません 。



たとえば、このシステムのパフォーマンスが低下したり、一定期間無効になることをユーザーにどのように通知しますか？ おそらく電子メールによって、さらにいくつかの問題が発生します。

• 重要なメッセージは、ユーザーが毎日受信する電子メールの流入で失われる傾向があります。
• メッセージを理解していない、または受信していないユーザーは、ヘルプデスクを通過する傾向があります。ヘルプデスクは、思考プロセスに干渉したり、非接触でイベントの予定を説明したりすることはできません。

ほとんどのITチームは、組織全体でのコミュニケーションを成功させるために必要なものを十分に認識しています。次に例を示します。

• サービスレベル契約（SLA）
• 現在のSLAステータス-実装方法。
• 計画的な停止と減速
• 個々のサービスの平均応答時間
• 現在進行中の問題。

ほとんどのITチームの問題は、組織全体でこれらのトピックに関する情報を交換することです。 一部の企業は電子メールに依存していますが、前述したように、電子メールは不十分であり、あまり効果的ではありません。 一部のオフィスでは、メモを発行するSharePointポータルなどの内部Webサイトを使用していますが、これらのサイトはヘルプデスクと直接統合されていないため、両方のシステムの情報を同期するには追加の手順が必要であり、ユーザーが必要です定期的にポータルにアクセスする必要があることに注意してください。

トムは、中規模の製造会社のセールスマネージャーとして働いています。 最近、トムが見込み客を追跡し、新しいアカウントを作成するために使用したアプリケーションは、非常にゆっくりと応答し始め、その日のうちに完全に凍結しました。 トムの最初の反応は、会社のITサービスのヘルプデスクを呼び出すことでした。 ヘルプデスクの技術スペシャリストは、「私たちは知っています、それに取り組んでいます」と疲れた声でトムに話し、電話を切った。 トムは、システムがいつ再び機能するかについての情報を持っていないため、ヘルプデスクに電話して、状況をより詳細に調べることを恐れていました。



1日の終わりに、ヘルプデスクは、ほぼすべての売り手からの電話を録音しました。各売り手は、何が起こっているのかを理解するために、独自のイニシアチブを呼びました。 最終的に、ヘルプデスクはコールの登録を停止し、「チケットは既に開いています」とコールしたすべての人に通知し、電話を切りました。 最後に、ITマネージャーの1人が、サーバーが故障しており、アプリケーションが翌朝まで機能しないことを説明する電子メールを最終的に送信しました。 トムはこれを以前に知りたいと思っています。 彼は終日顧客に電話をかけるつもりだったが、アプリケーションがあまり長く利用できないという情報がタイムリーに届くなら、彼は何か他のものを取り上げるか、あるいは休みさえ取るだろう。

管理コミュニケーションは簡単ではないのと同じくらい重要です。 サービス、反応時間、サービスの不足などのレベルで正直な数値を保証する-これは、経営陣が十分に開発されたIT意思決定を行う必要がある場合に非常に重要ですが、信頼できる情報を取得するのは容易ではありません。

問題3：両方を測定します。

この問題は、おそらく、ITサービスの中心にあります。つまり、ビジネスのニーズに合わせてテクノロジーを適応させないことです。 次の例は、まさにそのようなシナリオを示しています。

シェリーは会計で働いています。 最近、総勘定元帳を閉じようとしている間、会計プログラムは非常にゆっくりと動き始めました。 彼女は、問題を報告するためにITヘルプデスクに電話しました。 技術者は彼女の話を聞いて、次のように言いました。 チケットを開いて、そこで行われていることを確認してもらいますが、サービス契約パラメーターは応答時間に違反していないため、これは優先度の低いチケットになります。



シェリーはゆっくりと反応するプログラムに苦労し続けました。 最後に、誰かが来て彼女のデスクトップを見ると思いました。 彼女は、他のすべてのプログラムが正常に機能することを実証しました。 彼女は、部署の他の従業員がこのアプリケーションで同様の問題を抱えていることを指摘しました。

ある技術者が他のすべてのアプリケーションを強制的に閉じてからコンピューターを再起動しましたが、すべてが以前のままでした。 彼は肩をすくめ、スマートフォンでメモを取り、立ち去った。

翌朝、アプリケーションの応答時間は改善されましたが、それでも通常とはほど遠い状態です。シェリーは引き続きヘルプデスクに電話をかけ、アプリケーションの何が問題なのかを見つけようとしましたが、ITサービスが問題を修正しようとしてあきらめたようで、問題があることを認めることさえ拒否しました。

残念ながら、この種の状況は多くの組織でしばしば発生します。この例は、いくつかの問題が同時に発生したときに何が起こるかを正確に示しています。ITはチームとしてではなく、異なる専門家のグループとして機能し、これらの各グループは「遅い」という言葉を独自に理解しています。主な理由は誰もが 間違ったものを測定していたことです。図1.4は、通常のITサービスがマルチコンポーネントの分散アプリケーションをどのように見るかを示しています。図1.4分散アプリケーションの





ITサービスビュー。



彼らはコンポーネントを見ます。各コンポーネントの専門家は、プロセッサ使用率、応答時間などの技術的な指標を使用してパフォーマンスを測定します。コンポーネントのいずれかが許容範囲外になると、エンジニアの1人がチェックを開始します。図1.5は、ユーザーが同じアプリケーションをどのように見るかを示しています。





図1.5分散アプリケーションのユーザービュー。



ユーザーは内部構造を表示しません（非常に頻繁に-表示できません）。彼のためのアプリケーションがあり、期待通りに答えるか、そうでないかのどちらかです。それは、「プロセッサの使用率の許容レベル」との任意の特定のコンポーネントを動作する場合、ユーザーは全く違いはありません-彼は知っていないことそれは意味します。彼は、アプリケーションが機能するかどうかを気にします。図5に示すように、ユーザーとITエンジニアの認識の間に大きなギャップが生じます。 1.6。





図 1.6。ユーザーとITエンジニアによるパフォーマンス測定。



ユーザーとITサービスは異なることを測定します。IT指向のSLAは、DBMSサーバーに送信された要求に対する特定の応答時間を示す場合がありますが、ユーザーの観点からアプリケーションが「遅い」場合、これはほとんど役に立ちません。さらに悪いことに、サービスやコンポーネントのクラウドへの移行を開始すると、データセンターでの使用に慣れている方法でコンポーネントのパフォーマンスを判断する能力のほとんどを失います。結果？どちらの側も、そのようなSLAの規定に満足しません。



これはすべて変更する必要があります。ユーザーの観点から物事を測定する方法を学ぶ必要があります。個々のコンポーネントのパフォーマンスは重要ですが、特定の職場で感じられる全体的なパフォーマンスに影響を与える範囲においてのみ重要です。ユーザーとITサービスの両方が同じページにあるようなSLAを登録し、これを正常に実行できる方法とツールでこれらのSLAの実行を制御する必要があります。一部の組織は、移行中、またはサービスの提供に基づいて既にITの業務に切り替えていると報告しています-これは、広義の意味では、企業がITサービスの業務を組織のさまざまな部門およびユーザー向けの一連のサービスの形で実装する方法を模索していることを意味します。ただし、多くの場合、これらのサービス指向の組織は依然としてコンポーネントとデバイスに焦点を当てており、一般的に言って、サービス指向のアプローチではありません。電話交換機がクラッシュした場合、電話会社に電話をかけたり（おそらく携帯電話から）、スイッチやトランクについて質問したりしません。通常のブザーが再びハンドセットに表示されるタイミングを尋ねます。内部構造はユーザーにとって重要ではありません。あなたの期待の信用は、特定の電話会社のオフィスがどれくらいの期間作動不能になるかに基づいてはいません。あなたは、どれだけの時間、良好な電話接続の欠如を許容できるかを自問します。情報技術サービスが移動するのは、このようなモデルです。電話交換機がクラッシュした場合、電話会社に電話をかけたり（おそらく携帯電話から）、スイッチやトランクについて質問したりしません。通常のブザーが再びハンドセットに表示されるタイミングを尋ねます。内部構造はユーザーにとって重要ではありません。あなたの期待の信用は、特定の電話会社のオフィスがどれくらいの期間作動不能になるかに基づいてはいません。あなたは、どれだけの時間、良好な電話接続の欠如を許容できるかを自問します。情報技術サービスが移動するのは、このようなモデルです。電話交換機がクラッシュした場合、電話会社に電話をかけたり（おそらく携帯電話から）、スイッチやトランクについて質問したりしません。通常のブザーが再びハンドセットに表示されるタイミングを尋ねます。内部構造はユーザーにとって重要ではありません。あなたの期待の信用は、特定の電話会社のオフィスがどれくらいの期間作動不能になるかに基づいてはいません。あなたは、どれだけの時間、良好な電話接続の欠如を許容できるかを自問します。情報技術サービスが移動するのは、このようなモデルです。内部構造はユーザーにとって重要ではありません。あなたの期待の信用は、特定の電話会社のオフィスがどれくらいの期間作動不能になるかに基づいてはいません。あなたは、どれだけの時間、良好な電話接続の欠如を許容できるかを自問します。情報技術サービスが移動するのは、このようなモデルです。内部構造はユーザーにとって重要ではありません。あなたの期待の信用は、特定の電話会社のオフィスがどれくらいの期間作動不能になるかに基づいてはいません。あなたは、どれだけの時間、良好な電話接続の欠如を許容できるかを自問します。情報技術サービスが移動するのは、このようなモデルです。

問題4：知識を失っています

私たちが検討する最後の問題のある実践は、初期知識の喪失です。純粋に人間の弱点であり、率直に言って、どこでも具体的に対処することは困難です。これを理解するために、一般的なケースを見てみましょう。

. . , - :

« Oracle», - , — « , - ».

« Oracle», — , « Oracle ».

«, . ».

« , !».

«, - … , ».

残念ながら、個人の心にはあまりにも多くの知識が蓄積されています。実際、さらに悲しい真実は、多くの企業がこの問題に「対処」する方法です。一部のIT専門家は休日を完全に拒否し、視界や手の届かない他の活動に従事することを許可しません。社外でのトレーニング、会議への出張、教育を継続し、新しいスキルを習得するためのあらゆるものが含まれます。



基本的なスキルを電子文書に移し、保存し、アクセスしやすくすることを期待して、「知識ベース」を構築しようと中途半端な試みをした企業の指を頼りにすることができます。問題は、多くのITプロフェッショナルが必ずしも優れたライターではないため、知識ベースを埋めるプロセスが非常に難しいことです。さらに、時間がかかるため、組織は、特に毎日の緊急のタスクと要件に直面して、この目的のために非常に消極的です。



私が言ったように、この状況を修正することは困難です。 ITサービスは状況を理解し、原則として、何かを行う必要があることに同意します。しかし、彼らは技術者ではなく、このための能力が非常に限られていることがよくあります。通常、問題とその解決策をヘルプデスクにチケットの形式で登録する必要があることを反映する管理要件を作成できますが、そのようなシステムでの検索は、困難または時間のかかることがよくあります。インターネットで検索する場合すべての間違った結果が表示されます。これは、標準のクエリ手順の実行中に画面に表示されます。



しかし、この問題を解決する方法を見つけなければなりません。同社のインフラの知識-とどのように問題を解決するためにすべき蓄積および保存されます。この要件は、将来発生する問題を迅速に解決するのに役立つだけでなく、それらの発生を防ぐのにも役立ち、ITの分野で十分な情報に基づいた意思決定を行うことができます。

統合管理は問題をどの程度正確に修正しますか？

この本は、これら4つの迷惑な瞬間を修正する方法に専念しており、私がこれに対して提案する方法は、「統合管理」という統合された概念の傘の下で収集することができます。中心となる統合管理は、すべてを1か所にまとめることになります。



個別のIT分野間の「特定のプリンシパル」の境界を取り壊し、必要なものをすべて1つのコンソールに配置し、各スペシャリストに1つの共通のデータセットを処理させ、全員が問題に取り組むようにします。これは、ユーザー、IT、およびマネージャーをITサービスとパフォーマンスの単一のウィンドウにまとめる方法で行います。サービスレベルなどに透明性を追加し、ユーザーが表示できるようにします周囲で何が起こり、より多くの情報を得ます。



バックエンドで使用する不明瞭で純粋に技術的な指標を使用する代わりに、ユーザーに理解できる情報を提供します。 SLAの概念全体を、主にユーザーとそのリーダーシップにとって意味のあるものに再構築します。これにより、一部のITサービスを「クラウド」にアウトソーシングするのが避けられない「ハイブリッドIT」への移行に耐えることができます。



その結果、問題を解決する方法など、環境に関する情報を収集する方法を見つけることができます。これにより、このような質問がある場合に将来時間を節約できます。これに加えて、この情報により、経営者は将来の技術と投資の選択に関してより良い決定を下すことができます。



組織が従業員の一部を当局に売却することを強制しないようにこれを行うようにし、また、実装に半減期を必要としません。もちろん、これには外部委託ソリューションの検索を含む、いくらかの創造性が必要です。内部システムのアウトソーシング監視の考え方は比較的新しいものであり、どのように適用できるかを確認します。



私たちが考えるもののほとんどは、近年普及しているITILを含め、今日多くの組織がすでに実装している管理フレームワークのサポートに対処するのに役立つことを強調しなければなりません。私が提供する新しいプロセスと手法を活用するためにITILの専門家である必要はありません。ITIL（または他のフレームワーク）の実装について考える必要はありません。ただし、一連の組織的な手順を既に使用している場合は、この本で提供されているすべてがそれらに完全に適合することを知って喜んでいるでしょう。

おわりに

この章では、この本の残りの章で説明する4つの重要なトピックをリストします。そして、それらの基礎は、多くの専門家がITが今日対処しなければならない最も深刻で根本的な問題と考えるものであり、残りの修正方法に集中する多くの事柄も含んでいます。新しいツールは、新しいツールを選択するだけでなく、これらの新しいソリューションを実装するために選択する基盤となる可能性がありますが、使用する管理哲学と使用するプラクティスの変更に注意を払います。



第2章では、個々のサイトのITインフラストラクチャを管理するという最初の問題のあるプラクティスについて説明します。組織が多かれ少なかれこの道に従うことを余儀なくされる技術的理由を見て、現在の慣行を変えるためにあなたが出発できる方向を探ります。



第3章では、ITエグゼクティブ、ユーザー、サービスデスクなどの関係者について説明します。プロセスへのすべての従業員の一般的な関与によってのみ、ITが組織のニーズによりよく適応できるようになります。



3番目の問題のある実践は、外部の検索に飛び込む第4章の議論の主題になります。監視のためのデータセンター。最終目標は、この章で説明する問題を解決することであり、組織のITによって生み出される価値にさらに焦点を当てます。



第5章では、問題を解決策に変える方法について説明します。現代の組織は、ヘルプデスクを通過する情報を追跡してナレッジシステムを構築する必要性を完全に認識していますが、これらのプロセスをIT管理システム全体の一部として管理する方法は、当初計画されていた付加価値と比べて大きな違いになります。



最終的な結論は第6章で作成され、新しい統一された管理手法を使用するIT環境の視覚化を試みます。また、これらの更新されたプラクティスが実際にどのように機能するかを確認するのに役立つ一連のストーリーも提供します。