在openstack云环境下都是软件定义的场景，和传统的有所区别，如何设置kpi？

我们不胡乱回答，首先，kpi我认为是对人和部门设立的，所以，数据中心是以一个部门为单位，衡量kpi的。 但openstack是个软件，所以，你的问题应该转为，在使用openstack下如何衡量数据中心的价值，更合适。所以，其实就是openstack的计费功能。

OpenStack 前期在计量方面走了些弯路，现在 ceilometer ， gnocchi ， aodh ， panko 项目的稳步并进，总算峰回路转。 OpenStack 的计费项目 Cloudkitty 并未完善。

可以去了解一下这个项目，有了完善的计费，那么机房对业务的支撑就可以量化了。

业界大体上是按照项目管理上的质量、安全、效率、成本几个方面来定KPI的。
1、质量
这其实是相当大的一个概念了。可用率，影响范围/时间等等，容灾的粒度、恢复时长，甚至监控的覆盖度，及时性，告警的准确性、收敛等等都勉强可以算到这里面。
质量这方面的要细说起来太多了。简单来说还就是那几个，可用率，影响时长等等。如果对事故有分级的话，就给各种等级的事故数定个量吧。

2、安全
安全一般不会定死KPI。可能每年会定一些安全方面的项目，考察项目的完全情况吧。比如假设今年定了个root账号清理的项目，那就看完成情况就好了。当然，日常工作中，如果出现安全事件，也会视情况对考核产生影响。

3、成本
对于大互联网公司来说，成本绝对是个要年年提的KPI，小公司在这方面的投入不多，可能不太care，或者即使想care，也不知道怎么入手。

首先要订成本的KPI，你要有一套可行可信的成本计算的方式。我们采用的是容量模型。简单来说，容量模型就是指单位资源可以支撑多少用户规模，或者单位用户规模需要多少资源。比如我现在有个业务，每一万活跃用户总共需要A类机器2台，B类机器2台，C类机器4台，带宽20M(这个模型是一般是基于业务的当前情况算出来的，是否合理还要经过一番认证跟PK)。然后结合这个模型，我们做预算，一看到年底，卧槽，当我们用户数翻两番的时候，这块的成本太高了，老板说，不行，预算得砍掉一半。

好了，这个预算就算是成本的KPI了(当然，业务的实际用户数波动，这个预算也可以跟着波动)。然后接下来的一年可能就要为这个东西忙乎很长时间了。
顺便展开说一下怎么节省成本了，大体上就是两种方式：
一、管理手段。比如怎样优化流程缩短交付时间，减少资源池buffer，怎样压榨业务不要私设小金库，怎样协调资源的共用与复用等等；
二、技术手段。比如优化算法，优化用户体验，错峰复用，就近部署等等。

最后，考核。先看看当前的用户规模按照当时定的容量模型需要多少资源，核算一下实际用了多少资源。多用了资源，那就得解释清楚为什么多了(比如业务复杂底高了啊，新增加了业务啊等等)。少用了资源，那就看看是不是真的优化了，如果真的优化了，好，奖励，大大的奖励，省下来的钱来1%出来就够大家吃香喝辣的了。

4、效率
这个要结合itil、自动化运维、SLA之类的系统和规范来看吧。大体上我们会这样来考核：
一、列出服务目录，制定SLA；
二、服务尽量做成系统，用itil之类的工具、规范来管理。方便跟踪这些工作的完成时长，及时情况，超时情况等等。
比如业务部门说帮忙装个xx软件，原始的方式是对方口头(im/电话/邮件)说，然后运维找个合适的时间做，什么时候做没个准，甚至有时还会忙忘了。这种状态下当然不大好考核，只能靠口碑来考核了。但如果有个服务台(提单系统)，业务部门什么时候提的单记录下来了，运维什么时候接单，什么时候完成的，都记录下来了，那就好考核了。
三、运维的很多工作其实可以自动化完成。像上面这个例子，如果去年我们关于效率这方面考核的是运维的接单、完成的及时情况，那今年可能就是要考核的是效率的提升了。比如去年装软件这个服务的平均完成时间是3个小时(提单后，运维手工去操作的，平均3小时已经很快了)