不要为KPI而活着。KPI只是一堆数字。偏执于KPI会死的很难看。

臭名昭著的”毒奶粉“事件（三聚氰胺）是一个KPI失败的例子。质检总局们关注蛋白质含量等KPI，但是却忽视了其它有毒物质的检测方面，而实际上保证无害、健康才是最重要的检测目标 - business objective。搞得各家奶业公司竞相降价逐利，丧心病狂地掺杂三聚氰胺这样的”毒药“来提高蛋白质含量的KPI。 这样的KPI完成地再好，最终也落得个丢了乌纱帽、千夫所指的下场。

在企业中做IT也是这样同样的道理。

通常，各个IT部门都会有各自的一些KPI，这些指标有的是传统留下来的，大家都用的，比方说电路和设备的可用率等。也有为了反映当年的策略目标制定的。有的是自上而下的，有的是部门报上来的，经常一次几次的评审，最终确定为当年的KPI。KPI不可能很全，也不可能很多，另外，在一年之初也不可能全部预计到后面的发展。这些都注定KPI不是运行的全部目标，也不是保护伞。

举个例子说，在Helpdesk中有个常用的KPI是”响应时间”， 即在接到用户的求助后，多长时间内和用户联系。记住这里是“响应”时间，通常运行部门或服务商会因为不能预期每个服务请求的解决时间，而拒绝把“解决时间”当作KPI。而当一段时间运行下来后，总结会议上，运行部门和服务商拿出一份dashboard report说我们的KPI很棒，响应时间是如何如何短，全部达到了要求，用户部门代表或者某位领导很不满地提到某位某位用户等了很长时间问题没有得到解决，已经投诉到了CIO那里什么的，大家想像一下这时的会议该会怎么进展呢？

所以，KPI是表面的，背后的业务目标才是真正的目标。在Helpdesk的例子中，设置“响应时间”作为KPI或许没有错，但是用户问题的及时解决和用户满意度更重要，如果有服务请求长时间没有解决，那么Helpdesk应该把背后的问题，也许是二线、三线的问题，去推动解决。

回到信息网络安全的运营上。信息网络安全覆盖面特别宽，几乎涉及到所有的部门，所有的用户。这种情况的安全度量指标如何制定，KPI如何设置的确成为一个挑战。昨天，偶尔又翻了一遍Gary Hinson的“Seven Myths About Information Security Metrics”。Gary提到几个观点很有意思。例如，指标不一定非要客观的（objective）、可触摸的（tangible），为什么不采用一些主观一些但是却能反映安全本质的东西，比方说“安全意识”（security awareness）。这是一个公认的信息安全的关键要素。因为不好客观度量，通常安全部门考核指标是“安全培训课程”的次数和参加人数、参加率等。但是，这些的确和最终的业务目标“安全意识”有相当距离。Gary的建议是“为什么不设置一个1到10的相对分数让用户都来自己评价一下呢”。

我们领导经常使用“擦桌子理论” - 作为一个管理者，如果像保洁工那样每个桌子、椅子都擦一遍，然后不停的重复，那么他就基本上没有价值，或者说没有起到管理者的价值。管理者需要能够从重复的擦桌子工作中发现潜在的关键问题，发现新的业务需求，或者引入新的工作方式。基于这个思路，如果在汇报中国时，按照既定的工作任务或者KPI从头到尾过一遍，”我们的运行达到了99.99%，KPI都是绿的，blah blah”, 肯定不会得到好反馈。通常你会碰到这些问题：
“这些数字都说明了什么问题？”
“从中你们发现了什么可以改进的地方？”，
“你们的分析是什么”，
“行动计划是什么”

我们在KPI的颜色之外，也应该经常先向自己提问一下这些问题。

It’s very exciting to get the login page of https://imo.im. It’s amazing. It’s a web-based multi-client instant messager. At this moment, it can support MSN, Yahoo, AIM / ICQ, Google Talk, MySpace, and Skype. Yes, and Skype.

I used my MSN account to do the first ride. It has multiple crisp and slim windows embeded in the webpage, one small window for a session. The login and chatting are very responsive.  It support Chinese (double byte characters) very well.

Then I began to test Skype. The Skype login is quite fast. It works! I am wondering how these guys simulate a Skype client to login. You know two years ago it became top news when somebody re-engineered the Skype protocol and developed their own Skype-compatible client.

I know imo.im is using SSL. However, before users are rushing to transfer to imo.im, they must solve security concerns. That’s far away to convince users at its security. For example, how they handle the user data, including the account information, password, and chat history.  Actually when I recommend imo.im to one of my friends, I was told that he did not want to test this because he didn’t want to exposure his account information.

All in all, this is my first ride with imo.im. Its user experience is by far better than previous web IMs. In addition, it supports Skype. It’s great plus. However, there is a long way for them before users are convinced to drop their trational GUI IM clients.

在Andrew的《安全度量》一书中，提到了一个关于反病毒系统的指标。 Dan Geer提到他的一位CSO朋友说：“去年他们阻止了70000个病毒进入内部网络，但是更为自豪的是阻止了500个病毒流向外网。”， 内外网的病毒比是140：1。 于是我也查了一下我们的数字，我们一个月阻止了12000个病毒进入内网，却有300个病毒流向外网，这样我们内外网的病毒比是40：1。按照Andrew的说法，似乎我们的内部网没有那位华尔街投资银行的网络干净。但是，为了比较这个指标，我们还需要另外一个数字，就是进入内部网络的邮件总数，流向外网的邮件总数，有了这两个数字后，其实我们就可以比较两个比例：

进入内网病毒率= 检测到的进入内部网络病毒数量 / 进入内部网络邮件总数
流向外网病毒率= 检测到的流向外网病毒数量 / 流向外网邮件总数

将上下两个病毒率进行比较，或许更有趣一些。大家可能会认为，一般企业两个出、入两个方向的邮件总数应该差不多。一般“入”方向肯定会大很多，因为至少有大量的垃圾邮件存在。垃圾邮件百分比现在居高不下，一般可能在40%-70%之间，甚至更高。

关于服务器的病毒感染率，尤其是邮件服务器和文件服务器、FTP服务器等，每日都有大量的文件交互，普通用户的文件染毒就会直接影响服务器染毒的指标。这个染毒不是系统级染毒。如何处理这个指标呢？与系统管理员的绩效联系起来，似乎有些还有些距离。

大家在安全运营工作中是如何处理各种各样的安全指标的，都来分享一下吧。

It’s exciting to fing more and more nice and elegant themes released. I just changed my blog theme to ElegantBox. Just as its name reflects, it’s very elegant. Meanwhile, it support Postviews and Tags just out of box.

I don’t have time to read the change log of Wordpress 2.6.2. It might be a quick fixing update. Any way, I downloaded and installed it. Hope everything going well.

著名安全专家Bruce Schneier在CSO杂志上发表他关于安全投入回报的一个篇文章。我想这也就是Andrew在安全度量中提到的观点。读过这篇文章，事实上，Bruce并没有完全反对安全投入回报分析。他只是提醒安全经理小心使用安全厂商们的回报模型和数字，因为其中可能有很多水分，并不可靠。

Bruce也举了若干个例子来说明一般的财务ROI分析模型以及ALE（就是CISSP培训中的那个术语annualized loss expectancy ）不适用于小概率、巨损失的情形。而很多安全风险和投入就属于这一类。

Bruce的例子很有趣。ROI模型在小概率、大损失的场合不太适合使用，因为没有足够多的样本和数据可以用来统计。大家来看一下Bruce的例子。机场的安全检查新措施大概给每位旅客增加了半个小时的等待时间，按照统计数字，2007年美国一共有7.6亿人次旅客登机，这样总共的等待时间达到了惊人的43000年，假设人均寿命是70岁，就相当于这种安全检查每年杀死大概620个人。很令人吃惊吧！如果考虑到消耗的时间全部是清醒的时间、登机旅客的经济工作能力等，这个人数可能要达到上千人。好了，现在的问题来了 - 这样的安全检查措施值得吗？ROI分析需要证明如果不要安全检查的话，恐怖主义至少会杀死更多的人。

坦白说，这样的判断并不难做，911事件改变了很多人的看法。但是在互联网和IT系统中，这个判断和分析就不那么容易了。