ITIL实践解读:端到端APM应用性能的管理观(1)(4)

四、作为流程的 APM

与事件和问题管理类似，APM 本身能够被作为一种流程来考虑，因此也适合持续改进。在 六西格玛 DMAIC 定义、测量、分析、改进和控制）模式下，既可考虑用于实施 APM 解决方案，又能够考虑作为一种解决问题的一致方法。

定义Define）：首先而且最重要的是，您必须界定问题。对于 APM 解决方案的设计来说，这一定义始于业务需求，而且是经常能够被扩展。然而，对于响应问题来说，这一步则反其道而行之，将问题的定义严格限定于它最简单的核心因素。

测量Measure）：这一步专注于收集相关的诊断信息，忽略不相关的或分散的数据。与 EUE 测量的相关性，对于实现确定的故障域隔离和最终根源分析的主要目标来说至关重要。可重现的问题允许更好的相关性。

分 析Analyze）：该流程的核心步骤包括解释数据。通常，APM 解决问题流程的目标是对一个问题进行“选疗”triage）——识别故障域并对该结论提供支持性证据。这一步实现了持续的服务改进；相关的故障能够被用 于改进阈值设置，并作为修正系统设计的输入数据。

改进Improve）：领域专家——与更大的团队合作——确定改进选项来 解决事件或问题。这一流程应该分开。当然，主要的业务目标是解决问题以重新恢复服务，但是从持续服务改进的角度来看，改进 APM 解决方案也很重要。APM 工程师应该评估正确的指标是不是正在被监测到，这些指标是不是相关、能够提供正确的故障域信息。

控 制Control）：最后一步是最容易被忽视掉的；可是没有它，您将会发现，有时候对于同一个问题，您一直在重复着前面的4个步骤。从业务角度来说，这 是系统结构发生变化的地方——增加资源或对项目逻辑作出改变以避免对限制的敏感，这些限制导致了问题的产生——应该被考虑到。从 APM 的角度来说，考虑调整警报阈值和规则，从而提供一个对将来问题的提前警报，这样就能在业务受到影响之前采取相应的行动。