绩效管理（PM）包括四个基本的ITIL定义进程，彼此建立。事件管理是基础，可用性管理以上，然后将容量管理和服务级别管理定位为最复杂的“Capstone”。以下是这些构建块在数据网络上下文中包含的内容。事件管理事件是指影响性能的计划外服务中断或服务质量下降。其他ITIL流程(如事件管理)可以提供出现事件的早期证据，然而，大多数事件对性能管理无关紧要，通常通过策略、阈值或相关性分析自动从考虑中删除。
当自动事件处理表明降级或用户开始抱怨时，事件管理就开始发挥作用。它一般涉及网络运营中心和服务台的工作人员，通常使用的是一种常见的故障单系统。事件管理从良好的检测开始，然后处理事件，如SNMP提要、探测报告、ping和陷阱。支持事件管理的系统将事件转化为具有良好诊断信息的可操作警报。事件管理的目标是尽快恢复服务操作或质量，从而最大限度地减少业务中断。
如果您只能实现一个性能管理构建块，那么应该选择这个。所有的系统都有事件，因此一个覆盖基础设施和业务服务关键部分的良好的事件管理系统是必不可少的
可用性管理
有几条路径“可用性意识”。您可以在服务设计阶段主动实施可用性计划。您可以反应地监控您的事件管理系统以识别可能表示可用性问题的长期事件。或者您可以反应地监控客户的抱怨有关可用性。
无论你采取什么方法，可用性都很难量化。它并不是百分之百地减少停机时间。如果你认为系统在工作的整个时间里，所有的系统组件确实都在运行并提供服务，那么情况就会是这样——但生活并没有那么简单。
可用性管理包括仔细定义和严格度量可用性，并使用历史数据确定可用性趋势。可用性度量必须转换为能够阐明基础设施和服务运行状况的报告。报告可能显示资源在没有报告任何服务中断事件的情况下运行的时间百分比。更严格的方法可能是使用合成代理从关键用户位置周期性地测试系统。你不可能在任何地方都进行测试，因为你会使被测系统过载，所以你必须做出深思熟虑的权衡。
容量管理下一个构建块通常被视为可用性问题的长期解决方案。我们经常听到这样的话:“如果我们有足够的容量，那么事故问题就会消失，可用性就会很好。”我们害怕。是的，容量管理是有价值的，但不，它并没有消除对前两个构建模块的需要——实际上是依赖于它们。
容量管理应在业务，服务和组件的水平。业务容量管理包括与业务经理一起工作，以了解将影响系统负载的不断变化的业务条件。服务容量管理量化用户和应用需求，以适当地调整服务的大小。和成分每个设备的容量管理措施和跟踪利用率（例如，缓冲区，内存，CPU，带宽）。
许多组织都有很好的组成水平容量规划，但发现难以到达服务和业务水平的难度。它们测量随时间的利用率，并检查趋势，以确定利用率是否在高端或低端上的“超出范围”。通过使用退役和补充过度利用的资源，可以与业务需求保持一致的成本。容量管理使组织能够创建“如果”计划计划预期的业务需求。
服务级别管理服务水平管理涉及到识别、持续监控和审查服务，并与商定的服务目标进行比较。服务水平目标必须根据业务需求进行调整。评估系统变化对服务质量和满足服务水平目标的能力的影响是关键。服务水平管理还包括确定是否在指定的时间和地点交付商定的服务水平。有效的服务水平管理不是孤立的。它协调事件管理、可用性管理和容量管理，以确保达到所需的服务水平。
服务水平管理能力应该是全面的，并提供充分的系统性能信息以实现服务水平协议。SLA是一个必须仔细协商的复杂协议。在以后的文章中会有更多的内容。