記事の次の翻訳を発表します。 今日はOptanixのブログからの短いプロモーション記事です。 Kishore Ramamurthy 著「インフラストラクチャだけでなくサービスを管理する必要がある理由」 。
別の広告に時間を費やすのはなぜですか？ 急いで結論を出さないでください。 私の意見では、この記事は興味深いです。 IT管理に対するサービスアプローチの価値を説明する明確な例を示しています。 ITからではなくITからの両方で、CMDBおよびサービスリソースモデルの管理に対するその有用性を正当化するためのテンプレートとして利用できます。
面白い？ 猫をお願いします。 同意しませんか？ コメントを残してください。 反対するだけでなく、出版物の評価を下げたいですか？ 特にコメントを残してください。
以下、イタリック体で、翻訳者のコメント。
あなたが電車に乗っていると想像してください。 駅に来て、列車が出発する準備ができているのを見てください。しかし、兆候はありません。どの方向にあるべきかは言うまでもありません。 出発を待っている列車のあるプラットフォームは半ダースです。 どのようにして目的地に到着しますか？ インフラストラクチャ全体が目の前にありますが、駅を出るサービストレインについては何もわかっていません。
ITインフラストラクチャを管理するだけであれば、同様の状況になります。 サーバー、データベース、ストレージアレイ、およびネットワークデバイスがどこにあるかは知っていますが、データがIT環境を通じてどのように送信されるかはわかりません。 たとえば、データベースはeコマースポータルをサポートしていますか、生産バランスの追跡に使用されていますか、それとも両方のケースで使用されていますか？
ITインフラストラクチャの個々のコンポーネントのレベルで理解するだけでは十分ではありません。 これらすべてのコンポーネントがどのように連携してビジネスサービスを提供するかを理解する必要があります。そうでなければ、盲人の旅に匹敵します。 特定のビジネスサービスの提供に関係するコンポーネントとその関係を知る必要があります。 そして、これは存在しませんが、ビジネスが消費するサービスは危険にさらされています。
これを回避するには、サービスを管理する必要があります。
変更がビジネスに与える影響を理解する
最初の理由は、変更自体です。 変更を行うたびに、あなたが最初であり、ビジネスサービスへの潜在的な影響を認識する必要があります。 たとえば、サービスをサポートする別のソフトウェアモジュールを再構成する場合、このソフトウェアコンプレックスの他のすべてのコンポーネントで引き続き正常に動作することを望みますか？ そうでない場合、これは、ビジネスに害を及ぼす深刻な問題へのパスです。生産性の低下、顧客の損失、または収益です。
ビジネスサービスがますます複雑になるにつれて、サービスとインフラストラクチャの関係を理解することがますます重要になります。 この知識は、あるサーバーで実行されているアプリケーションと、別のサーバー上のデータベースへのアクセスに関するだけではありません。 現在、多くのアプリケーションが相互作用して、多数の基本的な技術要素を作成しています。 仮想化は、自律的に発生する可能性のある動的な変更に対する仮想マシンおよびその他のコンポーネントの機能により、複雑さを増します。 これらの多面的な関係を理解していない場合、変更は非常に時間がかかり、その結果が危険になります。 インフラストラクチャの変更がビジネスサービスに与える影響を理解すると、変更計画が容易になります。 たとえば、サーバーをアップグレードするには無効にする必要があることを知っているかもしれません。 この結果は既知であり、避けられません。 ただし、サポートするビジネスサービスがわからない場合は、これらの変更の技術的な期間について合意したり、計画された変更を実装する前にビジネスサービスの所有者に通知したりする機会はありません。
サービスのクラッシュを回避する
2番目は、サービスの可用性です。 事故やビジネス品質の低下によりビジネスサービスが利用できなくなった場合、あなたの仕事は、ビジネスサービスに関連付けられたデータを復元し、可能な限り迅速に実行することです。 たとえば、Delta Air Linesは、1台のデバイスの故障のために最後の5時間のダウンタイムがあり、5億ドルを失い、世界中の新聞で見出しを受け取りました。 インシデントの原因は、電源制御モジュールの故障による機器のカスケードシャットダウンであり、他の重要なインフラ施設で壊滅的な結果をもたらしました。
しかし、いつものように、物事はそれほど単純ではありません。 ITインフラストラクチャは非常にノイズが多く、毎日数千または数十万のアラートイベントを作成します。 それらの一部は単なる症状ですが、残りは既存の問題の真の原因を反映しています。 どのアラートが関連しているかを理解し、本当の理由を示すには、IT環境の腸がどのアラートを生成するかを理解する必要があります。
問題の原因を強調するには、ITインフラストラクチャがビジネスサービスを提供する方法を知る必要があります。 そうしないと、サービスが利用できなくなり、一見無関係なイベントの雪崩が発生します。各イベントは、問題の根本（真の）原因である可能性があります。 データウェアハウスの障害、ネットワークの不足、またはアプリケーションのクラッシュですか？ ビジネスサービスがどのように提供され、インフラストラクチャの各コンポーネントがこれでどのような役割を果たすかはまだわかっていませんが、問題の根本を特定することは困難です。
それ以外の場合、これらの関係を理解していれば、サービスの問題の原因の診断と除去を大幅にスピードアップできます。 実際、サービスレベルでこれを理解することが、Optanixプラットフォームが通常の条件下で30秒以内にサービスの問題の真の原因を特定できる主な理由の1つです。 1分ごとに数千ドル以上かかる場合、サービスの状態の表示は贅沢品ではなく、必需品です。
品質とサービスのコストのバランス。
3番目の理由は、サービスを最適化する可能性です。 最低限のコストで必要な品質へのコンプライアンスを確保します。 たとえば、過剰な容量のリース、ITアーキテクチャの合理化、パブリッククラウドへのITインフラストラクチャの移行などです。
繰り返しますが、これにはサービスの依存関係の可視性が必要です。 それらがどのように提供されるのか理解していない限り、災害復旧計画の一部として、バックアップデータセンターで計画する必要がある機能（ ここでは、明らかに、機能とリソースのセットとしての機能の概念）を決定することはできません。 同様に、クラウドへの部分的な移行では、サービスの提供の継続性、どのコンポーネントを一緒にしか移動できないかを知る方法を保証する他の方法はありません。
また、サービスを提供するための理解の欠如は、IT環境から最大の価値を得るためのリスクの低い機会の欠如を意味します。 これは、インフラストラクチャのボトルネックを検索して削除するか、価格を下げるために品質を損なうことなくビジネスサービスを再設計することで実現できます。
まとめましょう
多くのIT組織は、ビジネスサービスではなく、インフラストラクチャの管理を続けています。 過去に機能していたインフラストラクチャアプローチを使用しても、今日のビジネスサービスの複雑さを増すことはできなくなりました。 ビジネスサービスがITインフラストラクチャとどのように関連しているかを理解していないと、サービスの品質がより頻繁に低下し、サービスの復旧期間が長くなります。 そのため、インフラストラクチャの断片化を解消し、サービスのエンドツーエンドの可視性を提供するIT管理ソリューションを探すことが非常に重要です。 そうしないと、ビジネス全体が危険にさらされます。 Optanixが重要なビジネスサービスの管理にどのように役立つかについては、本日お問い合わせください（ そして再び広告 ）。
今日は以上です。 ご清聴ありがとうございました。 フィードバックをお寄せください。