运维数据的采集、处理和分析 ——运维管理杂谈之七

就爱抬杠

要讨论运维服务水平协议问题，前提是能够对信息系统的运维过程实施全面的监控和管理，也就是要实施全面运维管理。一般的信息系统，是对业务数据进行采集、处理和分析。信息系统运维管理就是对信息系统自身各个部分的运行数据进行采集、处理和分析。
6 k8 f9 M- \+ {4 j% }
按照信息系统不同部分的不同特点，大概可以分为应用系统、主机和存储设备、桌面设备、安全设备、网络以及机房环境等六大部分。这六大部分的监控和管理系统，也可以称为运维管理基础设施。

' d, X3 e% [: O0 X' J2 K& h" e9 W' {, [2 ~运维管理基础设施的目的在于采集数据，以及设定和提取各个子系统的KPI（关键性能指标）。各个子系统都有自己的KPI。例如主机的内存、CPU指标等，都是KPI。

( |- I1 S' G5 e2 C在通过运维管理基础设施采集运维数据，得出KPI指标后，还要根据KPI与需求部门协商，得出双方都能接受的关键服务性能指标KQI。在设定KQI时，应当做到KQI对于IT来说可以用KPI计算（否则无法定量评估），对于需求部门来说可以理解（否则需求部门无法接受）；最后，根据双方协商的KQI指标签订相应的服务水平协议SLA。
% N/ o, F% Y( r& K/ f
) K( e' U- z$ c这里需要解释的是，需求部门和IT协商的应该是KQI包括哪些指标以及指标的定义，至于指标需要满足的具体数值，最终应该由需求部门决定。IT的任务是根据相应的KQI标准推算出相应的KPI指标，并据此最终计算出相应的费用。如果用函数关系来解释，我们可以认为KPI是资金投入的函数，KQI是KPI的函数，SLA是KQI的函数，最终我们可以得出SLA和资金投入的函数关系，也就是需求部门需要的服务水平和IT需要的资金投入之间的关系。
  I: U, P' @# w+ k/ J* {2 C
需求部门关心的KQI其实就是ITIL的服务交付功能，也就是可用性管理、容量管理和持续性管理。对需求部门来说，系统开发完成后，实现需求部门要求的功能已经不是问题。此时，需求部门就会关心系统用起来速度怎么样，响应时间是多少；系统的持续性怎么样，一年内正常运行时间占所有工作时间的百分比；系统的容量性怎么样，如果系统用户大量增加，是否需
7 G3 d8 g; ~+ X9 W- X; S+ o8 [要另起炉灶重新开发，升级的成本是多少等等问题。
3 \) |! F+ |0 o0 M9 j% P
这里也可以看出，KQI是和系统的各个部分都密切相关的。系统性能达不到要求，主机、网络、数据库等都可能成为瓶颈，应用开发的水平也可能成为瓶颈。业务的可持续性也会和机房环境甚至桌面设备的KPI相关。需求部门并不关心具体某个部分的性能，这些应该是IT的责任。这就要求IT在考虑分析问题的时候，应当建立整个业务的量化拓扑模型，这也就是KPI-〉KQI的过程。