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