半年没更新了，贴一篇上周BMC在上海开云计算大会时我的演讲记录充充数。
——————————————————————————————————————–
其实相对于自服务门户或者监控工具来说，自动化在云计算里面是比较吃亏的，因为自动化技术是隐含在云计算平台后面，对客户来讲即看不到自服务的界面，运维人员也无法看到非常漂亮的监控界面。但就像大家选车一样，车的引擎好坏往往决定了这部车的价值。自动化之于云计算，正如车的引擎。接下来的时间里，我将就云计算里面，BMC是怎么通过自动化解决方案为客户提供完整的云计算服务进行介绍。
首先请大家看两组图，左上角是邮局，在过去没有自动邮件分捡机时需要花大量人力做这样的分类，这样在一个地区里面可能有几十甚至上百个人专门做邮件的分类，但当90年代引入了这种邮件自动分捡机以后整个效率大大提高了，这是自动化的好处。第二组图是80年代电话程控交换机引入前，我们打电话需要有专门的人员进行接线，一个人员只能处理十几条线路；但有了电话程控交换机，今天一个通信管理人员已经能够负责上万家用户线路。所以我们可以发现，即使是在传统行业，采用了自动化以后，首先是整体成本下降了，因为人力减少。第二，效率提升了。现在邮件传达的速度，甚至我们打电话的速度，跟原来是不可同日而语的。除此之外，对于我们作为用户来讲是一个服务体验的改变及服务质量的提升。这两个是非常好的例子，告诉我们说，即使没有IT，没有云计算，传统行业也是需要有自动化技术。
今天我们讲云计算，对于一个企业来讲，我们认为其实是一条曲折的道路，这里面会经历以下四个阶段，我们称之为云所需具备的能力。第一，具备单点设备的能力。首先我需要一个基础的架构，在这个基础架构上面搭建一个虚拟化环境。第二，在此基础架构上需要具备自动化能力，能够通过自动化的方式对相关设备进行驱动，这个设备有可能是虚拟化平台，甚至有可能是虚拟化平台里面的数据库或者是中间件这样的组件级对象。第三是整合管理能力，我们所需要的不仅是单点设备处理能力，更希望云平台提供端到端的管理能力。最终我们要站在服务的角度去进行用户需求的捕捉，其目的是能够让IT资源以可以让用户理解的方式直接提供给最终用户。这四个能力无论是私有云，混合云还是公共云来讲，都是需要的。
在08年云计算刚开始在业界出现时，BMC发现所谓的云计算思路跟BSM的概念基本是吻合的，因为云计算相当于是BSM(业务服务管理)的一个最佳实践。在这个最佳实践当中，自动化是非常重要的一个组成部分，从应用自动化，数据库自动化，服务器自动化，网络自动化都是属于这种关键的能力，也是云计算所需要的能力。可能有人要问，为什么我们需要IT的自动化，今天管理IT，如果不需要自动化也可以管理得蛮好，用了IT自动化以后可能成本还会增加。我们从以下四个方面解释为什么需要IT的自动化。首先从成本考虑，一个服务器管理成本基本等于你去购买一台全新的物理服务器成本的三倍。今天我们还要在物理服务器上虚拟多个服务器，因此其实我们所面向的管理对象比原来更多，那么管理成本的剧增是毫无疑问的。第二，质量。根据每三方机构的调查，在所有IT故障当中，有80%是因为不恰当的变更配置造成的。在这种情况下，我们引用IT自动化手段可以把配置步骤流程化和合理化，尽量减少人为失误。第三，90%的问题是已知和可避免的，在IT自动化范畴里面我们需要做一些合规检查，能够在问题还没有发生之前，通过合规检查的手段及早发现存在的一些技术风险和漏洞。第四，应用发布速度的问题。今天不管是哪个行业，企业的业务系统越来越复杂，涉及的逻辑组件和相关部件会越来越多，对于企业来说应用发布所需要的环节复杂化了，通常应用发布所需要时间比预期超出60%。如果没有自动化软件的协助，这些时间是无法缩短的。
根据我们BMC在许多自动化项目的经验，我们总结出一个企业在迈向自动化运维过程当中，可能会有四个阶段，分别为标准化，脚本化，产品化和服务化。标准化的意思是说，在这个阶段，企业可能意识到我需要有一些IT操作的流程，虽然我没有一些自动化的工具，但是我可以通过人，通过文档的方式把IT日程的操作固化下来形成一个标准。这样以后涉及到相同类似操作的时候我们沿用这个标准来进行操作的执行。第二个阶段是脚本化，当我有了标准化以后，之前所设定的一些简单标准化IT操作流程可以通过脚本实现，这种情况下可以让内部的IT人员写一些脚本，再派人定期去运行一些脚本，或者利用crontab自动运行脚本。进入第三个阶段，当脚本使用越来越多的时候，企业会考虑到我要引用一些产品进来，可能是针对服务器的自动化，可能是针对桌面机，可能是针对网络的自动化。第四个阶段是服务化。服务化更多是指云计算当中的自动化概念，在这个阶段自动化不仅仅面向IT运维的部门，而是通过自动化把IT资源便利地交付给最终用户，这个我们称之为服务化的概念。对于大部分企业来讲，不一定一定会经过这四个阶段，但是基本上会经历这些事情，有可能是三个阶段有可能是两个阶段，但是你该做的这些事还是需要去做的。
第一个阶段我们称之为标准化阶段，哪一些东西我们可以把它标准化流程化呢？我们在银行的客户比较常见，就是每天做巡检。早上来了以后要安排一个人员登入到每一台服务器上面去，敲一个指令或者多个指令查看系统的状态，或者有时候没办法做正常监控的时候，可能要看一下应用系统配置文件的情况是怎么样的，这些都属于日常的操作。另外还有一个例子，我们经常会有一些业务系统的升级，一般来讲，一套固定的业务系统，我升级步骤基本是固定的，从做数据库的字段表修改，到应用的文件分发，或者文件的解压等等这些都是标准化流程。企业会把这些东西作为IT的流程固化形成一个文档，交给下面的人去做。首先在不考虑其他情况下，不考虑人力成本，不考虑出错的情况下，我们认为这已经比完全没有流程要好。但我们可以算一下工作量。比如今天有200台服务器可能是一个中型企业需要管理的，以我们做日常巡检为例子，一个人需要登入一台服务器查看配置文件，登入一台机器需要花两分钟时间，200台服务器共花6.7个小时，如果每天都安排一个人去做这样的事情，每周需要耗时33.5人时，或3.5人天，每年需要182.5人天。这还仅仅是一项检查，而我们常常可以看到，客户的这种巡检列表往往长达上百个。当巡检范围更多的情况下，我们耗的人天会更加大。
所以在第二个阶段，我们可以看看刚才的问题有没有可能通过脚本来实现。这里是一个很基本的脚本代码，把这个脚本到那台机器上运行之后去采集一个数据，接下来对检查结果进行输出，貌似用脚本的方式可以把时间成本降低了，因为我只要把这个脚本发下去，最后回收上来一个反馈值，我就可以完成工作了，大不了我把这个值再拿一个表记下来。但是使用脚本会有什么问题呢？第一，脚本应该怎么样进行定向发布，刚才我讲的只是一个通用脚本，但是很多时候，我们的服务器组是按照我业务系统类型进行划分的，我需要去检查的这些项并不是保证我每一台服务器都是一样。第二个问题，这个检查要求变了怎么办，我们还需要派人专门去修改特定的脚本。所以我们使用脚本程序存在三大问题，第一类是不安全性。脚本是以明文出现的，包括你需要登入的话要有用户名/密码，另外会掺杂其它访问信息。第二是难维护，当你进行修改的时候，你怎么来维护脚本。第三部分是难管理。
在第三阶段，企业考虑我能不能引用一些业界成熟的产品。这个图上我们以应用发布为例，基本来讲，我们会涉及到四个团队，首先业务系统会有应用开发的小组进行一个应用系统的打包，打完包在真正把的业务包部署到生产环境之前需要做一些验证，这是由我们测试或QA部门来完成的，接下来当这些包已经发下去以后，运维团队要进行维护，这个维护除了要维护业务系统以外，还要保证你现有服务器系统本身上面操作系统版本是能够按照你的应用系统要求进行升级的。第四部分安全的管理团队可能也需要定期做检查。通常来说，如果是一些产品化的话，我们会引用不同产品。但BMC我们提供的是一整套的自动化管理的平台，它能够把我刚才讲的这几个方面，从OS到数据库到中间件到应用，从发布到控制等的所有环节在一个平台上完整的去实践它。
自动化层面上我们会涉及包括从底层网络设备自动化；第二，服务器自动化，无论是物理的服务器，或者虚拟化平台；第三是数据库的自动化；另外是中间件自动化以及应用自动化。接下来再做一个对比，我们做一个业务系统上线，下面是传统用手工的方式去做的，上面是通过BMC自动化软件去完成的。首先可以看到，在手工阶段，可能是由一个业务系统的用户提出这么一个变更要求，一个新的业务系统上线我们需要去购买服务器，即使今天不去购买物理的服务器也需要去部署一个虚拟的服务器，这样我就需要有专门人去做。接下来交给网管，按照企业本身的要求，把指定的IP绑定，把我的服务器接入到网络当中去。接下来服务器要放到生产环境去，需要打补丁，需要有专门的技术人员做服务器的加固。前面三部分完成之后才是业务系统的部署，专门一个人来做业务系统应用的部署。最后企业考虑到，可能这个系统面向的用户量比较大，还需要增加一个Load balance。在真实的企业环境中，当然不是每个环境同一个人，也许是同一个人做不同的事，但是整个过程耗时是比较长的，需要从底层基础到应用。通过BMC自动化，我们可以实现：首先用户提出这么一个变更要求，自动化管理软件可以通过操作流程的逻辑调度把它串联起来，当这个步骤失败的话，应该怎么处理，通过这样一整套平台让业务系统能够快速上线。当然讲到这里，其实我们还没有到云，这是在自动化管理的阶段。
第四个阶段，也就是云计算的阶段，我们称之为服务化，自动化是面向服务的。自动化管理所对应的是资源管理，首先资源管理主要分为几大块，一个是服务器和应用自动化，另外网络上面我们可以直接对物理的网络设备做配置。再一个是数据库的自动化，在云环境当中部署相应数据库的软件。包括对于存储，可以直接到存储物理的层面上对它进行空间划分。BMC的Cloud Lifecycle Management能够支持业界主流的平台和系统，如VMWare、XEN等主流的虚拟化平台。对于网络这块我们开箱支持思科网络设备。在存储方面我们支持Netapp等。这些都是对于现有主流产品的支持。将来怎么办呢？我们可以看到在资源管理这里我们有供应者API，这个API是BMC留给将来更多厂商的一个接口。如果对于客户新增加的设备，可以利用API来对它进行支持，通过API你可以调用第三方设备的专业管理平台来进行统一管理。第二，云平台管理员服务蓝图，这是把服务的定义转化为真正的IT部署。在部署当中，我可以部署在单台的VM或者两台的VM，除了在VM里面安装操作系统外，接下来VM是要接入到网络层面去，我们会在网络层面上通过虚拟的网卡进行配置，这里面做的事情远远不像我们看到的那么简单，它在底下做了很多自动化的操作配置。第三，端到端的自动化的部署。在我们方案里面，我们进行操作系统部署和应用部署，并且提供操作系统的加固。什么是加固呢？当你完成这些应用部署以后，你需要去做一些合规检查，这些都是在部署过程当中完成的，所以我们称之为端到端，而不是仅仅停留在某一个层面上。第四个特性我们可以按照服务等级进行资源配置。比如在一个制造行业，今天要用云计算，我可能要把两个业务系统放到云计算里面来，一个是OA系统，一个是面向外面用户的网站。我们的策略引擎是通过标签的技术，当业务系统部署前要选择一个服务的级别，它会根据服务级别的判断该业务系统应该放在哪一个预先定义好服务级别的资源池，然后调用资源管理模块完成真正的部署。
我们网络自动化的配置可以根据多租户进行划分，在网络部署上会做Vlan的自动划分，保证不同租户的数据流在不同的Vlan中。另外，CLM自动化网络部署的时候，不光配置路由器交换机，同时也支持像防火墙、负载均衡这一类设备。这个我们称之为在物理层面上保证多租户用户数据的安全。第二个跟安全相关的是，当我的业务系统进入到云平台以后，其实它是需要定期做合规检查的，一个是本身系统级别补丁的合规，另外业务系统本身由于公司制度所要求也需要有一个合规的检查。这时候对云管理平台的自动化要求就不仅仅是软件或操作系统部署，而具有合规检查的能力。所以，从这两个方面保证了用户云计算平台的安全。一个是应用层面一个是网络物理层面。
接下来介绍两个案例，第一个案例是服务自动化的案例，客户是摩根士丹利。在业务需求方面，由于摩根史丹利有两个服务中心，他们发现在业务系统的升级过程中，首先，需要花人工去做的时间比较长，没办法保证业务的连续性；第二，人工去做有时候会有一些失误造成计划外宕机。所以在这种情况下，他们经过了多方比较，最后选择了BMC的Bladelogic解决方案，通过Bladelogic帮助他们提高了员工效率，估计每年节省27万美元。第二个案例是公共云的案例，客户是澳洲电信，使用CLM后，澳洲电信日常操作和安装任务所花的时间从天降到分钟级。
每个企业的IT愿景是不同的，在座各位无论你们目前是处于自动化的第一阶段还是第二阶段，或者希望往第三阶段，第四阶段迈进。BMC作为业界自动化领先的厂商，我们希望通过丰富的解决方案和项目当中大量丰富的经验，能够给大家提供更多的支持，能够为大家实现IT管理目标作出我们最大的努力，谢谢。
