CIO：微软是如何推进云计算实践的？

　　Tony：现在对于云计算的定义非常多，我定义的云计算，其特点第一是资源池；第二是资源的产品化，即它能够扩展到你需要的地方；第三是宽带接入；第四是服务的能力可计算，现在很多云服务的提供是随需的、自助式的服务，而不是传统的可以预测或定期、定量提供的服务。

　　早些时候我老板问我，什么时候能够把IT的这些业务应用直接放在云上？收到这个问题之后，微软IT部门对现在所有IT支持的业务应用进行了分析，看目前哪些应用已经就绪，可以放到云上。团队中有工程师说，我们可以提供25个不同的衡量标准，去衡量哪些是直接可以放到云里去，哪些还不能。

　　我觉得这个衡量过程太复杂，应该用对大家来说更加简易的方法来分类这些应用，所以我们就从业务因素和技术因素两方面，把所有的应用分成基本的、中等的和先进的三个类别，类似于小、中、大这样的3个类别。我们认为，在业务因素和技术因素这两方面都属于基本类型的应用，应该是在早期就可以被移植到云上的。当微软在云计算方面的经验更加成熟一些时，再把类别被界定为中等的应用放到云上去，依此类推。

　    微软做的第一期的云应用，是基于一项公益项目。每年的10月都是微软的社会公益月，微软会有很多员工为公益项目发起一些捐赠，在微软内部组织项目拍卖，拍卖所得收益捐赠给社会公益事业，整个拍卖叫价的时间长度是一个月，所有拍卖项目的开始时间是10月1日，终止时间是10月末最后一天。我刚加入微软时，当时用的拍卖工具是由一个微软程序员自愿免费开发的，说是放在一个专门的服务器上，其实就是在某一个员工的台式机上去托管。

　　整个拍卖周期有一个月长，月底是最后叫价的机会，所以到月底那个应用尽管没有被宕机，但是响应的速度已经非常慢了。因为我是搞IT的，看到这个觉得非常丢脸，所以接下来就决定我们要把这个应用做的更好，后来就移到云上。

　　把这个应用移到云上有两点好处，第一技术上没有复杂性，第二对于业务不会造成任何风险损失。现在这个拍卖应用已经放在云上了，每年在10月应用一次，在其他的11个月不用的时候，不会占用服务器的空间，等到应用的时候，把USB存储插上就可以了，而且可以迅速的扩展，微软将近10万名员工都可以用，而且速度非常快，我们把这个应用放在云上以后，筹集的善款比以前增加了10倍。

　    现在微软官方网站microsoft.com也被挪到云上了，微软官网社交体验平台部分，以前没有移到云上时，成本是每个月1.5万美元，可用性是99.1%，如果修改一个应用，需要2-3周时间；迁移到云上以后，成本变成每个月882美元，可用性提高到99.996%，当资源配置发生变化做应用修改的时候，只需要30分钟就可以完成。

　　CIO：微软官网的社交体验平台每个月成本从15000美元降到882美元，成本节省在什么地方？

　　Tony：成本节省在硬件方面的服务器成本及支持人力成本等。举例来说，亚马逊要提供云服务，它自己要买服务器，所以它要均摊硬件服务器成本，所以要比较成本的话，应该长期的比较，不能够短期内比较。原来我在迪士尼工作时，当时为了做一部大电影，迪士尼购买了皮克斯很多高性能服务器，当这部电影完成之后，CTO说这些服务器不要了，因为服务器的成本是一次性的，已经进入电影制作的总成本了。根据摩尔定律，每18个月新的服务器的速度性能会翻倍，拍新电影时还不如买新的。这就是一种对于成本的不同观点。

　　我在迪士尼得到的另一个经验就是，技术发展到现在，如果一个服务器是3年均摊的成本，每一年服务器成本是要低于服务器那一年电耗的成本，所以现在买服务器的时候，看的不单纯是CPU的速度，还要看它的能耗。现在对于网络公司来说，要衡量的成本是什么？是叫做每一次点击的总拥有成本。如果做电子商务网站，还可以做一个叫做每一次点击的成本率，通过一个算法算出每一笔成交额的总成本。

　  CIO：云计算未来的发展有多快？

　　Tony：现在发展云计算有两个驱动因素，一个是日本的这种现象，在自然灾害多发地区，自然灾害的频繁迫使人们去选择云计算。另外一种云计算的推动力更有意思，在一些新兴的国家市场，如西欧一些新的经济增长很快的国家，还有前苏联解体分裂出来的一些国家，这些国家都有一些成长非常快的公司，他们想要直接应用云服务，为什么他们会这么要求呢？因为他们要求对业务的响应速度非常快，而所处国家的经济在发展初期，没有那么多条条框框，没有非常成熟的监管机制，没有那么多的要求，所谓“初生牛犊不怕虎”，就直接应用云了。

　　反而在那些成熟市场的国家，大型公司在IT上已经有非常成熟的架构，他们面对云的时候，就选择要速度慢，甚至选择不做。微软发展云服务的时候，很多的要求来自于巴西这样的一些发展中国家的市场，而不是成熟的市场。

　　云的好处在于，在技术资源上可以获得无穷的供给，可能作为一个人，想象力是有限的，或者其他方面是有限的，但技术绝对不会成为进一步发展的瓶颈。我在一家专治癌症的医院的一个研究部门担任董事会成员，抗癌药物还有治疗方案的研究是一个需要大量计算的工作，原来唯一的问题就是计算资源不够，现在有了云，就可以解决这个问题，因此我认为在有生之年应该可以看到人类攻克癌症。

　　至于云在未来的发展，要分不同的应用来看，电子邮件作为一个云服务，现在已经做的很成熟并且基本普及了，再一个就是CRM，今年、明年很快也会普及开来，至于其他的这样的一些应用，可能在云上的发展比较稳定。

　  CIO：您如何跟CEO讨论IT成本的问题？

　　Tony：我拒绝和CEO讨论IT成本的问题，IT不应该谈论成本，而是应该谈论IT提供服务的价值，哪些IT的工作是高价值的，哪些是低价值。可以讨论哪些是低附加值的IT工作所投入的成本，但千万不要说给IT部门设立一个成本的上限，如果设了上限，就会总是去做那些IT附加值低的项目，从而降低整体IT价值。因为一旦谈到成本，通常大家都会找捷径和最容易实现的目标，而忘记长线目标。

　　比如我要求应用开发人员把应用开发成本降低10%，肯定很容易做到，但是现在节约了10%的成本，但是没准到明年或后年，10%成本的节约就实现不了了，或者这10%的节约没用到点子上。但如果换一个说法，要求削减应用总数的10%，把那些重复的应用删掉。而且通常如果删除掉10%的应用，节约的成本远远大于总成本的10%。总之千万不要把成本作为一个目标，我就是经常用这种工作方法。

　　看生产流程输入，通过加工流程，输出的如果是以成本为目标的话，大家着重改变的是成本，前面的收入大家都不愿意去考虑。打个比方，要减肥的话，衣服穿小一尺码的，是不能改变肥胖的。预算应该属于成本，应该是输出时的部分，而不是一开始去做的部分，当然，我们做IT的都了解这个，但是对CEO、CFO可能就解释不清楚，这个就是工作的难度所在。

　  CIO：微软如何量化IT的价值？

　　Tony：有没有KPI指标可以用来衡量IT所创造的价值？当然有，一个是软指标，一是硬指标。比如要把IT软件升级到最新版本，如何去表现IT这个工作的绩效？很简单，例如需要打补丁的次数少了等等，这方面可以用专门的工具去计算节约的成本，类似于在生产制造企业中降低了多少残损率的指标。

　　软指标也很容易，比如做IT这个项目，能节约多少的人力，多少的时间，如果这个资源利用情况改进后，能够用在其他业务性的工作上去创造价值，这个是属于软性指标。但是当我们在解释的时候，通常都是既有硬性的成果效用，也有软性的，这两个方面都要说。我在做一个IT项目时，如果只找到其中一个方面的衡量（当然大部分是以硬性指标为基础，也有一些软性的指标），而如果硬性指标一点都没有的话，这个项目基本上不能成为一个成功的业务案例，所以我不做这种项目。

　  CIO：在满足业务部门需求、为业务部门提供适当的IT支持方面，微软IT部门有何经验？

　　Tony：我从最简单的说起，第一个叫“满意度条款”，这其实是借用了销售的理念，就是跟内部客户即业务部门的关键大老板，进行服务沟通，也可以说是“讨价还价”，先签合同，形成一个类似契约关系的东西，这个“条款”指的是为满足业务部门这一年达到业务目标，IT要做哪些东西，业务部门对IT做的这些东西的满意度等等。

　　第二个工具是以成本作为落脚点，起初业务部门的战略目标是什么，业务部门用精准的语言描述出这个部门的战略方向，业务部门到底要做什么。比如这一年业务部门的成本要从多少降到多少，比如财务的比例、现金流要增加多少，业务部门的目的是增加新的收入或进入新的市场，或拜访更多客户等，描述出种种业务需求。

　　第三个工具就是我们的多年发展路线图，通常我们选择制定3年的规划，第一年的目标非常明确，我们要加什么软件，它的功能是什么。第二年我们要做的这个东西可能稍微模糊一点，没有那么清晰，到了第三年就只是更加方向性的描述。也就是长期目标和短期目标，长期目标是站在战略层面，短期目标会更加具体。

　   最后一个工具比较复杂，它借用了财务的概念，叫做“书面发票”。“书面发票”包括几个内容，第一是成本类的，成本类又分成两大类，第一大类叫均摊成本，第二类是直接成本。

　　均摊成本主要是两种类型的IT服务成本，要么是很难往某一个具体的业务部门用户上靠，要么是成本太大。比如SAP的CRM或ERP，这个初始的投入成本很高，所以就简单的把它作一个平均化，基于微软总体员工数，把均摊到每个人头上的成本算出来，还有网络带宽这样的成本都用这个方法算出来。把这一年的“书面发票”这部分数据展示出来，向用户展示在带宽使用的优化方面，成本节约了多少等等，这个是可以量化的数据，把绩效体现出来。

　　直接成本是可以具体到某一个业务部门，比如这个业务部门为实现某个业务目标，IT为这个部门专门编制了一个业务流程，提供IT服务支持、建立IT应用，这个成本是可以直接分配给具体的业务部门的。

　　真正神奇的地方在于，当业务部门的负责人找到我，提出给他们开发一个新的应用，以前IT部门会说，开发新的应用业务部门要给IT多少钱，现在不这么说，因为有了“书面发票”，均摊成本是多少，直接成本是多少就非常明了，而且直接成本里有很清楚的明细，比如给业务部门提供了多少IT支持的服务，给业务某个新应用进行开发的时间等等，这些都可以展示出来，告诉他，这些钱全都是已经花了的，如果要开发这个新应用，按照既有方式要花这些钱，但是如果用新的做法，你不需要付均摊成本，省下的那些钱可以用于新的应用和开发去。

　　这样就换了一个方式，以前业务的人说IT花了太多钱，现在我把这个产品单列出来，让他选择，这时业务部门会很高兴，他觉得IT部门帮了他，而且完全是帮他省钱。有这样的“发票机制”，两个成本明晰的单子，就很好的转化了和业务部门的沟通交流方式。