コンテナアプリケーションの動作環境の雲、マイクロサービスのITインフラのシステムアーキテクチャでは、ますます多くの企業がに、運用・保守要員のより多くの複雑なプロセスをより多くのツールを導入していますITシステム管理の細かさを向上させるが、新たな問題が巻き起こっています。
バタフライ効果のように、そのような複雑な環境では、データは密接にリンクされている間、インジケータの変化は、アラームが連鎖反応のシリーズをトリガすることができます。赤はタイトな神経運用・保守要員を保持し、異なる監視プラットフォーム、電子メールやSMSアラートの流入を識別し、細心の管理の警告が不可欠です。
挑戦運用保守アラーム管理
アラーム嵐をいかに抑制しますか？どのように失う漏れない重要な警告を保護するには？どのくらいの速スクリーニング根本原因アラーム？降水アラームの経験を処分するには？すぐに業務を復元する方法？これらは、職場での各操作および保守チームが直面する最も困難な問題です。最後に、それの複雑さのような高い程度を持参するので、頻繁にアラーム嵐、アラーム管理の原因は何ですか？
アプリケーション・システム間で互いに近接して
、多くの場合、複数のアプリケーションシステム間でビジネスニーズを完了させるために、リンクのアプリケーションが呼び出す各質問のIT単位は、事業の失敗につながる可能性があります。任意の警報システム、監視オブジェクトは、すべてのアラームの90％は、アラームの原因に帰することができることを意味し、アラームを90％と高い大規模な相関の警告を他の関連するポリシーの数をトリガすることができます。
アラームバランス点を見つけることは困難ポリシー設定
高アラームしきい値を、システムが動作不良を欠場することは容易であり、低アラームしきい値は、無効なアラームの多数を持って運用および保守チームの効率に影響を与えます。また、サイクルの長さをチェックするためのアラームを設定し、同様の問題があります。運用保守チームが多いアラーム脱落しないためには、アラームの感度を上げることがあったが、このアラームの繰り返し率は、60％の高さであってもよいです。
適時のに応じて、厳戒態勢ではありません
、現在2-3、9-10などから人に至るまで、モードに運用・保守チームの大半を働いているアラームの同じタイプの処理に関与する複数の人、同じ警告が複数の交通機関にプッシュされます保守要員の手インチ しかし、いくつかの特別な期間で通常は1アテンダントは、他のチームメンバーが住んに大きな障害をもたらしたアラームを、処理する責任があります。遅延の原因とアラームの嵐を引き起こし、ある程度の取り扱い警報を逃しただろう繰り返し無効な情報が多数結合し、効率的な派遣やスケジュール管理システム、の欠如のため。
「アラーム管理能力成熟度モデル」はほぼ確実
運転・保守管理の問題を最小限に抑え、ITの運用保守管理システムの効率を高めるために、AIOps技術開発が不可避な選択となっています。次の監視ツールには、ITILプロセスと自動化プラットフォーム、中央ネクサスに全体の動作および保守監視システム下AIOpsの重要な一部としてアラーム管理、。ハイとローのアラーム管理機能は、IT運用保守SLA（サービスレベル契約、サービスレベル契約）であるキー制約となっています。
現在のアラーム管理、アラーム管理プラットフォーム明確な目標と進化のパスの企業は、より定量的な評価を支援するために、我々は、管理機能を警告する各レベルの管理に基づいて、5つの段階、「アラーム管理能力成熟度モデル」の統合に分かれていますプログレッシブ方法を示す能力の程度を変化させる、ハイレベルのコンテンツは、低レベルのコンテンツを含みます。
レベル1、アラーム分散管理
当社の運用保守チームできるだけITシステムのあらゆる側面を包括的にカバーのために、より多くの監視ツールを導入している、さまざまな監視ツールは、数十アラームの何千ものが生成されます、アラームが分析する必要があり、優先順位のスクリーニング、および実行計画の操作。時間が経つにつれて、おそらく数十万人は、アラームイベントの何百万人を心配する必要があります。
集中管理と非効率的処理及びアラーム応答をもたらす操作及び保守要員障害における異なるオブジェクト間の警報、警報情報転送の割り当ての欠如のためです。厳密に言えば、このレベルはまだ遠い満期管理からです。
レベル2、統一されたアラーム管理
より多くの運用チームは、高い管理コストおよびトラブルシューティングの低効率によって引き起こされる障害を認識していました。統計によると、会社自体のまたはサードパーティのプラットフォームの運用・保守チームを使用してアラームの一元管理に20％以上。
警報システムは、統一された管理プラットフォームに異なる監視ツールやアクセスを生成し、アラームは一定のルール、フィルタ、および圧縮に基づいて重複排除することができます。こうしたネイルなど、より効率的なコラボレーションツールと組み合わせ労働のビジネスやITインフラ部門、アラームカテゴリ、に従ってのように、機能的な運用、保守チームに基づく分業の視点をサービスやシーンに監視ツールの境界を破る管理能力成熟度のこのレベル釘、マイクロチャネルビジネス、スラックなど、ある程度、トラブルシューティングの効率を高めます。
レベル3、インテリジェントなアラーム管理
业务在变，监控需求也在变，因为告警去重规则的死板而带来的问题不言而喻。通过大量的数据统计分析，只有不到40%的告警能够通过规则进行压缩。
随着人工智能技术的不断发展，特别是NLP（Natural Language Processing，自然语言处理）技术的成熟，针对告警这类文本数据的分类、聚类、模式发现算法，成为了有效抑制告警风暴，提升告警有效性的主要手段。可以通过时间相关性、文本相似度、故障溯因图、CMDB（Configuration Management Database，配置管理数据库）等手段，对海量数据中相似、相关的告警进行聚合。针对告警中的异常、新奇等重要信息，通过时间熵和内容熵进行标识，越是不频发、无规律、严重度高的告警越需要被重视，熵值越大信息越重要。告警智能管理将极大减少告警处理量，提升告警故障分析效率。
Level 4，根因告警定位
根因定位一直是告警管理皇冠上的那颗明珠。由于告警的传递性和多面性，要在众多错综复杂的信息中迅速定位根因对所有运维团队来说都是巨大的挑战。
关于根因定位的探索大致可以分为以下三个方向，一是基于动态获取的系统调用链路和承载关系，并结合时间相关性开展根因分析；二是基于CMDB构建一个实时反映系统环境的配置项和关系二元组群，通过告警在其中的投射关系进行根因定位；三是建立全面覆盖IT运维管理全域的实体、属性、关系三要素库，再运用知识图谱算法获得根因告警。当然不论是哪一种方案，都需要建立在对IT系统架构的深度学习和理解基础之上，才能真正做到明辨真伪，洞悉根因。
Level 5，告警自愈
アラームは、完全な失敗の自己修復の自動化プロセスで、監視ツール、警報プラットフォーム、タスクスケジューリングプラットフォーム、CMDB、ITILや他の関連するシステムを開き、アラームから受信し、根本的な原因は、ルールのマッチング、スクリプトの実行、障害回復を見つけますマニュアルの確認、そして最終的に警報、実際のアラームのライフサイクル管理を復元します。
アラームは別のキーポイントがあり、全体のアラーム治癒過程を技術的な問題を見つける原因に加えて日常の運用・保守業務経験の蓄積と降水量である障害アラームのルートレベル4、の知識ベースを確立することですが、また、回復プログラムの基礎。しかし、これは、より多くの日常のトラブルシューティングや障害を回復するために、個人の能力に依存しているどのような当社の企業の弱点の多くは、障害に対処する上で多くの経験が彼らの脳内に運転・保守要員に存在し、正確です。また、プロセスを繰り返す障害はまた、再分析する必要があります最も貴重な資産の損失になります運用・保守要員の流れと、不必要に回復時間を長くします。
アラーム操作やメンテナンスチームは、簡単な修正を達成するために失敗し、問題の原因を特定するための最初の時間を癒すことができます。業務を支援しながらチームは、土砂処分の経験の問題は、潜在的なリスクを防止し、そして最終的に閉ループ管理システムの運用・保守を形成します。
現在では、より多くの企業には、アラーム管理の分野での探査を開始し、そして嵐のアラーム抑制におけるいくつかの成功を達成しています。クラウドインテリジェントアラームプラットフォームのようなルイも集中警報管理とインテリジェントの問題を解決するための運用および保守チームの異なるセクターを支援します。操作と道路の維持管理は、長いとハード、継続的な改善のアラームは、我々は技術の経験と開発の蓄積と、アラーム管理が飛躍的に夏の到来を告げることを信じて、一晩行うことはできません。また、この究極の目標の一般的な無人運転・保守に私たちをリードし、アラーム管理機能のための議論と実践我々の成熟度モデルによることを願っています。