vlambda博客
学习文章列表

在上一篇文章中，我们介绍了加速IBM Z AIOps之旅的框架，以及该框架对企业数字化转型的重要性。IBM Z AIOps之旅分为疲于救火（Firefighting）、应变响应（Reactive）、主动出击（Proactive）和智能前瞻（Intelligent）四个阶段。AIOps有三个功能区域：检查（Inspect）、评估（Evaluate）和行动（Act）（见下表）。在这篇文章中，让我们一起来探讨下检查功能区域（Inspect）的最佳实践做法。

检查功能区域的目标是识别潜在问题，避免问题发生对业务造成破坏。为此，我们需要致力于这三个方面的工作：监控整个基础架构和端到端应用的性能，生成事故警报，应用分析以尽早发现异常现象。让我们来深入看下检查功能在每个阶段的情况。

处于疲于救火模式的客户主要专注于恢复服务，在问题发生时解决问题。由于发现许多问题的时间比理想情况要晚，例如，在某些情况下，终端用户首先发现问题，提出疑虑，在这种情况下，每个问题对业务的影响在很大程度上是未知的，客户也几乎没有对正在解决的问题按照优先级进行排序。他们也有可能把IBM Z 单独进行管理，其运行与公司其他部件的运行几乎没有共通之处。这个阶段的反面模式（anti-pattern）包括：

• 监控解决方案没有覆盖目前的全栈技术，存在盲区。其组织和使用的工具也彼此孤立，导致缺乏对子系统的所有权。

  
  

• 未设置阈值，或者设置后从未更改，导致很多阈值没有发挥作用，生成的警报太少或太多。

  
  

• 操作员花费大量时间查看监视器，查找问题，而不是收到警报提醒他们需要注意某个问题。

要摆脱这种模式，这些公司应该考虑采用下一章节介绍的实践做法。

从疲于救火阶段转向应变响应阶段的组织对实践做法、技能和工具进行了投资，他们能够以更结构化的方式识别问题，更早发现问题。对流程改进进行投资，可以提高运行效率，提高永续能力，改善服务级别协议。应变响应阶段的实践做法包括：

• 确保监控解决方案覆盖范围合理，避免出现漏洞，导致一个区域的某个问题未被检测到，进一步扩散并对核心业务应用产生系统性影响。这需要对中间件、API、JVM、操作系统、硬件、存储和网络进行全栈监控。

  
  

• 改善监控解决方案中对阈值和基于规则的警报的使用，这样操作员就不用一直盯着监视器，并且可以更早地收到关于问题的通知，在解决这些问题对终端用户和服务级别协议影响更小时解决这些问题。

  
  

• IBM Z上运行着大量负载，事件的数量也非常庞大。因此，我们建议您将通知用于非关键事件，将警报用于关键事件。操作员和SME可以订阅合适级别的事件。例如，SME可以订阅通知，利用通知来分析问题发生的根本原因，以进一步自动优化阈值调整。

  
  

• 为了有效管理所有关键警报，需要根据必要信息在企业范围内的支持系统中手动创建事故单。这可以帮助您确保所有关键警报得到处理。

  
  

• 为了避免已知缺陷对您系统的永续能力造成重大影响，您应该进行预防性维护。我们建议每年至少进行两到四次预防性维护。此外，我们建议更频繁地安装潜在影响较大的修补程序，如HIPER，PE补丁程序（PE Fix），安全性/完整性和普遍PTF（Pervasive PTF），更多信息，请点击阅读原文查看。

  
  

从应变响应阶段转向主动出击阶段的组织采用了一些实践做法，能在问题对业务产生负面影响之前及早发现问题。他们也不断完善其最佳实践做法以应对混合应用的复杂情况。让我们一起来看看，在组织处于AIOps这一阶段时，有哪些最佳实践做法。

• 自动创建事故单，使用一致性描述，例如，事故单中包含的信息级别，从而进一步确保所有关键警报都得到处理，并且评估迅速。

  
  

• 持续创建新阈值和基于规则的警报，避免手动检测漏掉一些事故。

  
  

• 定期进行强化监控（如，进行z/OS运行健康状况检查），并在自动化系统中设置补救措施，通过事故管理进行通知。如果检测到不健康的状况，则采取适当的补救措施，例如，增加自动化以降低对业务造成任何不利影响的风险。

  
  

• 使用应用性能管理软件在混合云上对业务应用进行端到端的监控，该软件可以对从移动设备到所有平台和子系统的交易进行跟踪。这可以极大减少您在作战室的时间，因为您可以立即了解到应用运行缓慢的原因，这样就可以联系合适的SME分析根本原因，解决问题。

  
  

• 通过单窗格实施跨混合云基础架构的监控解决方案。这样，您对整个混合云基础架构的状态具有一致和可共享的理解。由于基础架构的强大程度取决于最薄弱的环节，因此，这有助于您快速解决问题，不论问题发生在哪里。

  
  

• 使用关键性能指标（KPI）如流量、延迟、饱和度、错误来监控对系统和应用运行状况的检查，以快速识别问题。操作员会更清楚系统的状况，而且随着KPI逐渐成为行业标准，这也保持了与其他平台一致。

  
  

• KPI的任何变化，无论是信息性变化、警报还是关键性变化，都会自动生成事件，发送到中央事件管理系统，进行统计分析。

  
  

• 重视监控工具，意识到其对业务至关重要，从不关闭，并设置了冗余，以避免在故障期间停机。

  
  

在智能前瞻阶段，重点是持续改进。这个阶段将继续把检查、评估和行动的实践做法和管理环境整合到一个集成方案中。虽然在前一阶段智能和机器学习可能已经运用到某些适用范围狭窄的应用中，但是本阶段对机器学习的运用更为普遍。您可以通过建立基线、查找异常、发现趋势、预测问题来了解系统的正常情况，从而在问题造成服务中断之前进行补救。以上所有这些结合在一起可以帮助您快速应对越来越多的问题，以免对您的业务造成影响。

• 动态和智能阈值由AI代理自动设置，并了解应用的周期性和重要性，用于识别问题和异常。这可以极大改善警报质量，包括减少警报噪音，避免引发不必要的警报，同时减少出现应该发出警报而没有发出警报的情况。

  
  

• 通过诸如分页响应等机制跟踪对警报的响应能力。您可以优化使用的流程，包括调用职责，以确保响应能力不断提高，并且在服务级别协议范围内。

  
  

• 利用机器学习来了解您组织的正常情况。可实现KPI实时评分和日志分析，在异常现象对业务造成破坏前发现它们。这些异常现象有关联警报，操作员和SME可以收到任何日志或指标表现异常的警报。

  
  

• 持续不断地识别问题签名，可及早识别特定关键问题。训练机器学习算法来获取新的问题签名，并将异常行为与相应的问题签名关联起来。操作员不仅能收到异常现象的警报，还能预测可能突破阈值的时间，理解可能的根本原因，并根据指导解决问题。

  
  

AIOps之旅激动人心。在评估中，我们发现大多数公司处于应变响应阶段，有些公司处于主动出击阶段。我们还看到一些较为领先的公司正积极朝智能前瞻阶段迈进。每个阶段的实践做法都有明确的定义。这段旅程仍然需要一些时间，但是进行投资的公司进展迅速。

敬请期待下一篇文章，下篇文章我们将介绍评估功能区域，祝您AIOps之旅愉快！

      * 替换AT为@

内容声明：本文仅代表作者的个人观点，与IBM立场、策略和观点无关。文中专业名词因翻译原因，表述中难免存在差异。如有疑惑，请以英文为准。同时数据来源于实验室环境，仅供参考。如果您对我们的话题感兴趣，请给我们留言。