イベントの一元管理について知りたいことがあるはず(2)

この記事の内容の一部は、Qingchuang Technology の上級製品専門家、Bu 博士によるものです。

こんにちは～またお会いしましょう～前回はイベントとイベント運営についてお話しましたが、前回の楽しい内容の続きはこちら：イベントの一元管理について、きっと知りたいことがあるはずです（１）

この号では、主に次の 2 つの側面を含む、イベント管理が実際の生活にどのように適用されるかを説明します ( *注意: この共有には多くの内容が含まれており、長いので、興味のある友人は後で読むことができます。紛失に注意してください) ):

1. イベント管理の応用シナリオ

2. イベントを一元管理する方法

1. イベント管理の応用シナリオ

1. インテリジェントな運用および保守 AIOps

インテリジェントなイベント管理は、IT 監視ツールのアラーム情報を統合し、アラームノイズをインテリジェントに 95% 削減し、イベント管理プロセスを自動化し、チームのコラボレーションを強化し、障害の特定と修復を加速し、ビジネスへの影響を最小限に抑えます。

2. セキュリティ情報イベント管理 SIEM

企業の内部および外部のセキュリティイベントを収集し、ルールエンジンとイベントフロー処理エンジンを通じてセキュリティリスクに関するリアルタイムの洞察を取得し、柔軟なイベント処理プロセスを使用してチームがセキュリティインシデントに積極的に対応できるようにします。

3. モノのインターネット

スマートデバイスとセンサーのイベント情報は、モノのインターネットのエッジノードとコアノードでリアルタイムに集約および処理され、イベントストリーム処理を通じて新しいデータモデルがキャプチャおよび発見され、より価値の高いアプリケーションシナリオが実現されます。探検した。

4. 事業分析

ビジネス運営と IT サポートの間のデータ境界を突破し、システムからより多くのビジネスデータをリアルタイムで取得し、ビジネスに影響を与えるイベントにチームが迅速かつ正確に対応できるようにします。危機の時には、混乱を乗り越えてください。

上記のシナリオから、統合イベント管理のアプリケーションの普遍性を見つけるのは難しくありません。統合イベント管理は日常のシナリオにどのように適用されますか? スケールの異なる次の 3 つのケースを通して説明します。

ケース 1: シングルユーザーサービスイベント

銀行のプライベートバンキングセンターのマネージャーである Zhang は、自分に割り当てられた顧客リストに最近の訪問の手配があるかどうかを確認するために、銀行のプライベートバンキングシステムにログインしようとしています。しかし、アクセスが認証されず、パスワードをリセットしようとしてもログインできなかったため、IT ヘルプデスクに連絡しました。

IT サービスデスクマネージャーの Xiao Wang は、Zhang マネージャーの詳細情報を入手し、彼が銀行のプライベートバンキングセンターのマネージャーであるかどうかを確認します。認証に合格した後、Xiao Wang はプライベートバンキングシステムの管理者モジュールにログインし、Zhang マネージャーの個人情報と関連設定を確認します。転勤により、個人データの一部の変更が正しく実装されず、エラーが発生したことが判明しました。

Xiao Wang がこれらの変更をトリガーし、再実行しました。その後、Zhang マネージャーは再度ログインを試み、システムへのログインに成功しました。Xiao Wang がワークベンチ上のイベントレコードを閉じると、システムは満足度調査を Zhang マネージャーに送信します。張マネージャーは非常に満足し、Xiao Wang に 5 つ星を与えました。

Xiao Wang はプライベートバンキングシステムに関連する変更を引き続きチェックしており、他の人の変更はすでに正常に実行されています。Xiao Wang氏は「作業指示書を作成する必要はない」と認めた。

ケース 2: マルチユーザーサービスイベント

IT サービスデスクのマネージャー Li は、最近電話データが増加していることに気づきました。基本的にすべてのサービスデスクが同じインシデントを受け取りました。携帯電話の転送が長期間応答しませんでした。同時に、警報操作窓口の当直責任者は、ある業務システムでデータベース障害が発生していることを知り、そのメッセージへの対応を行っていた。

マネージャのリーは、これは重要なサービスインシデントであると判断し、すぐに ITSM システムにログインして携帯電話転送の問題に関するアナウンスを出し、すぐにインシデントチケットを作成してチームに問題に関連する情報の収集を要求しました。 IT サービスデスクと統合イベント管理プラットフォームのアラームワークベンチ) を関連付けることで、個別の処理に冗長なリソースを無駄にすることなく集中管理を実現します。

10分後、リー管理者はIT管理者からシステムが復旧したという最新情報を受け取り、ITサービスデスクの数人のスタッフにモバイル送金業務の確認を再度依頼し、復旧したことを確認した。通常に戻り、チケットを閉じました。

最後に、ITSM システムの速報の内容を再更新しました。

ケース 3: 重大な IT サービスインシデント

「それは良くない！」当直の NOC エンジニアであるシャオ・リーは叫んだ。

統合イベント管理プラットフォームのアラームワークベンチがアラームストームを検出し、新しいアラームが画面に表示され続けました。多数の仮想マシンがダウンしました。これは、コアスイッチの障害またはハイパーバイザーの問題を意味します。

Joe はイベントを ITSM システムに記録し、それをメジャーイベントとして定義します。彼はクラウド管理者とネットワーク管理者に連絡し、会議を設定しました。

パブリッククラウドサービスプロバイダーとして、広報マネージャーも関与する必要があります。広報マネージャーは、インシデントの状況、重大度、範囲をリアルタイムで理解し、起こり得る世論に対処するために顧客に時間内に通知する必要があるからです。事件によるプレッシャー。

クラウド管理者は、これがハイパーバイザーのバグによって引き起こされたものであることをすぐに発見しました。彼らはすぐにハイパーバイザーのベンダーに電話しました。同時に、クラウド管理者はイベントの優先度を最高に調整します。

ダウンする仮想マシンが増えるにつれ、コールセンターには電話が殺到し、CEO が自ら介入して、影響を受けた大口顧客に電話をかけるようになった。この時点でサプライヤーはインシデントにできるだけ早く対応しませんでしたが、CTO が緊急対応を開始し、インシデントは 2 時間以内に解決されました。

その後、CTO はインシデントの根本原因を突き止めるためにインシデントのレビューを組織し、サプライヤーもそれに参加しました。インシデントレポートが作成され、そのようなインシデントが二度と起こらないように、レポートの内容について一連の研究開発、テスト、および変更計画が開始されます。

2. イベントを一元管理する方法

規模の異なる 3 つの例から、インシデントまたは緊急対応のプロセスにおいて、顧客のサービスニーズを満たすために、IT チームは次のベストプラクティスプロセスに従ってさまざまな活動を実行することがわかります。主に次のようなものがあります。

1. イベントの検出

イベント検出には通常、次の 3 つの方法が含まれます。

ユーザーが問題を報告すると、サービスデスクのオンコール担当者がそれがインシデントであるかどうかを確認します。
緊急度は、顧客の SLA に対するコミットメント、つまりサービスを復元できる速度によって異なります。
優先順位。さまざまなビジネスまたは顧客への影響に対して、どれを最初に対処する必要があります。

2. イベントをログに記録する

一般に、イベントの記録は、次のような履歴イベントを管理、要約、分析する機能を提供するシステムを通じて行われます。

コールセンターシステム: 外部の顧客は通常、電話でコールセンターシステムに連絡します。カスタマーサービス担当者は、ここで顧客の問題を記録する責任があります。
IT ワークベンチ: 内部ユーザーは通常、問題を報告するときに IT ワークベンチにアクセスします。
監視システム: システム内の潜在的な問題を自動的に監視して発見するために、サービスおよび関連するサービスコンポーネントを監視して異常を検出します。
統合イベント管理プラットフォーム：異なる監視システムで発生した異常を一元的に収集し、コールセンターシステムの利用者や顧客向けの統合イベント管理プラットフォームやITワークベンチに障害をタイムリーかつ同期的に報告し、一元監視管理します。
ITSM システム: イベントが重大なイベントであることが確認され、保存する必要がある場合は、後で監査のために ITSM システムにイベントシートを作成する必要があります。

3. イベントの分類

イベント分類フェーズでは、主に次に従ってイベントが分類されます。

どのタイプ: ハードウェア障害、ソフトウェア障害、ネットワーク障害など。
影響の程度と範囲: たとえば、どの企業や顧客が影響を受けているか。
緊急度: 顧客の SLA に対するコミットメント、つまりサービスを復元できる速度によって異なります。
優先順位: さまざまなビジネスまたは顧客への影響を考慮して、どれを優先する必要があります。

分類は次のことに役立ちます。

インシデントの特定と処理の効率を加速し、インシデントの責任者を効果的に特定し、インシデント処理コストを削減します。

4. 診断イベント

インシデント診断の核心は、何が問題になったのかを特定し、その問題に対して通常のサービスを復元する最速の方法を決定することです。

イベントが以前に発生し、イベントモデルに影響を与えた場合は、最前線の担当者が直接診断できます。ただし、より複雑なインシデントやこれまでに発生したことのないインシデントの場合は、部門を超えたチームまたは第二線の専門家による共同調査が必要になります。

5. インシデントの解決

インシデントの解決とは、一時的な修正ソリューションと永続的な修正ソリューションを含む、診断完了後のインシデントの解決策を指します。通常、緊急事態や事故対応の過程では恒久的な修理は行われませんが、一連の作業を最短時間で行い、できるだけ早く生産を再開できることが望まれます。主な操作には次のようなものがあります。

自動実装：一般に、事前に定義された既知のイベントモデルに基づいて、イベントの自動解決と自動回復が完了し、手動による診断と治療は不要で、すべてが自動的に完了します。
運用保守技術者が自ら解決できるように記録します。通常、イベントモデルやシステム分析結果に応じて廃棄提案が出され、運用保守技術者が判断し、最終的に手動操作で復旧プロセスを完了します。。一部の複雑なシナリオでは、サポートチームまたはサプライヤーに対応するソリューションの提供を依頼することもでき、運用およびメンテナンスエンジニアが運用プロセスを実行します。

6. イベントを閉じる

インシデントが解決したら、インシデントを正式に終了する必要があります。閉じるには次のアクションが必要です。

ビジネスサービスが通常に戻ったことをユーザー、顧客、その他の経営陣や関係者に伝えます。
業務復旧のためのデータベースクラスタのサイズを増やすなど、必要に応じてCMDBの構成情報を更新します。
社内外の人員の投入、新しいサーバーの追加など、請求の更新。

7. 事後レビュー

イベント後のレビューは多くの組織で軽視されがちですが、知識の要約、最適化された監視、最適化されたイベント処理、最適化された既存のイベントとアプリケーションプロセスにとって不可欠かつ重要なリンクです。

イベントのレビューは通常、イベント発生後 5 営業日以内に完了します。このリンクには、イベント処理に関する運用保守エンジニアの概要レポートを詳細にレビューするためのレビュー投稿が設定されている必要があります。レポートの主な内容含む：

報告日
報告責任者
インシデントの概要: 1 つまたは 2 つの短い文で、根本原因、発生時間、影響とともにインシデントを簡単に説明します。たとえば、2023 年 8 月 5 日の午前 9 時 25 分にデータベース障害が発生したため、障害期間中のトランザクションの約 20% で応答時間が長くなり、ユーザーエクスペリエンスに影響を及ぼしました。所要時間は約 15 分で、重大度レベルは「重大」でした。

出来事の詳細: ①何が起こったのか詳しく説明してください。②この問題の根本原因は何ですか？③この問題の一時的な解決策（できるだけ早くビジネスを回復するための迅速な回復解決策）? ④ 問題に対する恒久的な解決策。

影響: ビジネス、顧客、トランザクションなどへの影響、重大度レベル。

タイムライン：SLAを保証するためには、主に企業内の対応する評価基準を参考に、発見時間、担当者への通知時間、対応時間、解決時間、終了時間などを詳細に記録する必要があります。そしてエンドユーザーへのコミットメント基準。

参加者 (緊急事態やイベントのシナリオによって参加者は異なります): ① 事件指揮官。②レコーダー。③連絡担当者。④その他の参加者：異分野の専門家、開発やテストなど。

このインシデントに私たちはどのように対応したか: ①私たちがうまくいったこと: たとえば、以前の緊急事態およびインシデント対応プロセスでは、インシデント対応の適時性を大幅に向上させるプロセス、方法、テクノロジーなどを使用したことはありません。② 不十分な対応: たとえば、対応プロセス中に、既存のプロセスまたは方法が特定のリンクに対する抵抗を引き起こす可能性があり、改善する必要があることがわかりました。

フォローアップ行動計画

今後同様の問題が再発するのを防ぐために、必要な修正を完了してください。のように：

①特定の指標の監視が敏感すぎるため、監視ソースでいくつかの調整を行う必要がある;プログラムのバグのため、バグ修正計画はエンジニアリング研究開発チームと策定され、スケジュールに組み込まれる

②恒久的に修復できない場合、同様のインシデントが再び発生した場合に自動化された手段で迅速に修復できますか。たとえば、特定のアラームに対してルールや自動修復スクリプトを設定でき、再度アラームが発生した場合には、手動介入なしで自動的に修復できます。

③既存プロセスを最適化し、対応効率を向上

さて、上記がこの共有の全内容です。統合イベント管理について質問がある場合は、コメント欄にメッセージを残して議論してください~

Qingchuang Technology は、Gartner によって継続的に推奨されている AIOps 分野のベンチマークサプライヤーです。同社は、企業顧客が運用および保守データに対する洞察を向上させ、運用および保守の効率を最適化し、テクノロジーの運用および保守が事業運営に与える影響を完全に反映できるよう支援することに尽力しています。

業界をリードする顧客の共通の選択

乾物品の運用とメンテナンス、および技術共有について詳しく見る

右上隅をワンクリックでフォローできます

当社は10年近くにわたり、インテリジェントな運用と保守の分野に深く関わってきました。

Gartner が連続して推奨する AIOps ベンチマークサプライヤー

次回会いましょう~