私の推定によると、世界には100から2つの監視システムが存在する可能性があります（より正確な理由のある数字があれば、コメントしてください）。 これらは、クラウドシステム、オンプレミス、商用、無料、ネットワーク、インフラストラクチャなど、あらゆる面で使用できます。 その中には、サービスリソースモデルの作成をサポートするものがあります。 これらは、そのようなツリーのようなものであり、Webサーバー、データベース、アプリケーションサーバー、スイッチ、その他多くの怖い言葉など、ビジネスシステムの要素がノードに接続されています。 各子は親に影響します。 たとえば、一部のサーバーでRAM使用率のしきい値を超えると、イベントが生成され（たとえば、重大度が赤）、サービス構造の上位のオブジェクトに影響します。
多くの組織は、ビジネスシステムの可用性をビジネスプロセスの可用性に結び付けています。 SLAをカウントすると、ITシステムの可用性がゼロに低下し（一部のサーバーのメモリしきい値を超えたとき）、ビジネスプロセスが停止したことがわかりました。 しかし、これはそうではありません！？ ツリーの一番下には、クラスタがあるか、一般に、目玉にメモリが詰まっている場合があります-通常のシステム操作。 要するに、タスクは次のように聞こえます。ビジネスプロセスの可用性を正しく計算し、ビジネスシステムのコンポーネントからの重要でないイベントを振り返らないようにする方法ですか。 分析します。
ビジネスとITの間の通信では、何らかの方法でサービスとビジネスプロセスの可用性を評価する必要があります。 非常に簡単な方法があります：インシデントがビジネスから到着した-アクセス不能をカウントし始めます。 終了した作業-カウンターを停止します。 そして、これは正しい計算方法です。 しかし、もっと欲しい。 少し想像してください：
携帯通信会社とコンテンツ販売プラットフォームを紹介します。 ユーザーは、オペレーターからのバランスでSMSにつまずいたアルファ男性です。 メッセージの最後に、彼は1日にたった99.99ルーブルで「デート」サービスを使用するというオファーを見ました。 合格したテストステロンラッシュでは、短い番号をダイヤルしました。サービスに接続しました。 もちろん、口座からのお金はすぐに引き落とされました。 30分、1時間が経過し、すべてがうまく行かないことを知るために申し出ます。 衝動は終わり、損失の規模は大きくなく、ユーザーはそれを採点します。 今、彼はそのようなサービスを使用するとお金の損失につながることに気付きました。 オペレーターは収益を失っています。
物語は素晴らしいものでしたが、状況の概念そのものが非常に現実的です。 このような損失を減らし、ITのことわざに積極性を持たせるために、ビジネスプロセスの可用性/パフォーマンスをビジネス側だけでなく、他の側からも確認することが望まれます。
ユーザーは、サービスを初めて使用する場合、サービスの動作不能についてプロバイダーに通知することに常に関心があるわけではありません。
ビジネスプロセスを監視する最初のアイデアは、関連するビジネスシステムを制御し、イベントがシステムに与える影響を評価することです。 実際、一般的な場合、各ビジネスプロセスは複数のビジネスシステムに依存しています。 プロセスが長い場合、システムの1つのセットがその部分に影響を与え、別のシステムのセットが他の部分に影響を与える可能性があります。 したがって、プロセスの考えられる状態の範囲は、入力が機能し、出力が停止している状況に拡大します。 たとえば、銀行は融資申し込みを作成できますが、融資を発行することはできません。 そして、そのような状況でプロセスのステータスを判断する方法は？ 動作するかどうか？
2番目のアイデアはより複雑です。 プロセスとシステムという2つのエンティティを互いに分離する方法をすぐには理解しませんでした。 影響係数を追加し、システムとのプロセス接続の重みを調整し、さらにいくつかのトリックを試みました。 その結果、ビジネスプロセスのステータスを評価するために、そこにあるプロセッサの負荷を考慮する必要はまったくないと確信しましたが、まったく異なるメトリックセットが必要です。
ビジネスプロセス作業の実際の状況は、ビジネスプロセスの段階の成功とアクセシビリティを特徴付けるメトリックによってのみ与えられます。 その結果、独自のイベントと可用性を備えた2つの分離されたシステムができます。 しかし、単一のインターフェースで、これが主な洞察です。 ビジネスプロセスのステップの1つが正常に機能していないことがわかった場合、これは関連するITシステムを調査する機会です。 プロセスへのシステムの影響は信頼できないと考えていますが、デューティシフトまたはプロセス/システムの所有者のために、診断のためにこの接続を表示する機会を残しました。 「ハエとカツレツの分離」アプローチの最もレーズンは、インフラストラクチャ上のイベントのためにビジネスに負担がかからないことです。 ダッシュボードは非常に重大な状況でのみ赤く光り、技術スタッフはその場合、どこを掘るかを知っています。 そして、オオカミはいっぱいで、羊はいっぱいです。
接続されていない2つの監視ループ、ビジネスプロセスとビジネスシステムを作成します。 ただし、ビジネスプロセスの責任者は、プロセスに関連付けられたシステムを確認できる必要があります。
そして今、私はそのようなアルゴリズムを実装するための一般的な場合に必要なものを教えてくれます：
●会社のプロセスの構成を決定する（正確に何を制御したいのか）。
●これらのプロセスに対する主要なITメトリックの影響を決定します（たとえば、ビジネスの50％が機能せず、小売ディレクターが電話をかけないチャネルの可用性）。
●個々のシステムへの影響、およびそれらのインフラストラクチャなどへの影響を分解します。
●示された2回路モデルを実装します-ビジネスプロセスと主要なトランザクションイベントの制御、さらにITシステムとインフラストラクチャからの診断情報。
ITで同様の作業スキームを作成できた場合は、ビジネスとのコンタクトを微調整するための最初のステップを踏んだことを考慮してください。 そうでない場合は、説明したアプローチを実装するのにかかる時間のほとんどがビジネスプロセス分析にかかることに注意してください。 次回はこのパートでの経験についてお話します。
記事の著者： Anton KASIMOV 、 Technoserv社の監視システムのアーキテクト。