每当我们谈到传统的IT运维或IT服务管理，第一时间会让大家想到的是要遵循IT服务管理最佳实践ITIL的流程去指导日常运维。我们的IT服务管理就是通过ITIL的流程管控来实现标准的运维操作。ITIL作为由英国政府商务办公室（OGC）所主导的IT服务管理最佳实践，目前已经成为很多国家和企业用来指导IT运维的方法论。在过去的20年里，包括国有五大银行、中国移动和中国电信等国内IT服务管理做得比较好的公司，无疑不是ITIL流程落地的忠实粉丝。

   我们且看ITIL的流程落地给使用ITIL的企业或组织带来什么样的好处？ITIL强调通过服务台实现事件单和服务请求单的统一接入和转派，并设置合理的工单优先级，以急业务之所急的方式通过服务台工作人员对每个工单的全链路跟踪和督办,最终实现工单处理流程的闭环。另外，我们都知道业务应用和IT基础设施的日常运维都担心会不时的引入可能的风险，风险有可能是由于不善的变更和发布导致，或由于新代码的缺陷引入的风险等。所以ITIL强调严格的变更和发布审批，并设置变更咨询委员会（CAB）的职能通过CAB会议来履行该职责。通过设置变更/发布窗口的固定时间段来尽可能降低或规避不必要的风险。规范的变更和发布管理是在企业内部做好IT服务配置管理的前提，最根本和直接的做法是对生产环境的相关配置项（如服务器或存储设备）进行变更后，需要做到及时的对配置管理数据库也就是我们经常提及的CMDB中的内容进行同步更新。如果做不到这一点，久而久之CMDB的内容和生产环境就不一致。再久而久之，CMDB就失去了在日常运维过程中判断异常事件的影响级别、系统监控和业务影响分析的辅助能力。所以，看一个企业的运维管理成熟度如何，我们基本可以通过配置管理的成熟度就可以做出初步判断。配置管理是很多运维管理流程和实践的基础，比如很多公司的统一监控平台就是建立在配置管理之上的。利用统一的监控大屏(ECC)来实现业务应用和IT基础设施的全链路的指标监控和故障定位。通过数量庞大的IT技术运维团队提供7x24小时的故障处理和业务保证。定期执行全网的安全扫描和跨数据中心级的容灾切换，确保IT治理能力的最终实现。以上所有流程实践都会有相应的指标，比如银行在主数据中心出现整体不可用的情况，要确保在8个小时内把所有的业务应用在其灾备中心启用，实现业务级的灾备。这个8小时的时间承诺就是我们常说的目标回滚时间（RTO，Recovery Time Objective）。RTO是一个典型的服务级别指标，通常会被纳入服务级别协议（SLA）中去监督和管理，确保其能有效达成。

  通过以上的IT运维流程的综合布局，最终实现了以ITIL理论为指导的IT服务管理体系。那么在云时代下，相对于传统的以流程管控为抓手的运维会有哪些变化呢？我们且从如下几点来区分其不同。

   1、监控系统的实现机理不同

   传统的监控系统是以独立的第三方商业软件作为输出的。比如IBM的Tivoli Monitor或HP的OpenView。监控系统是以外挂的方式来采集被监控的软件产品的日志并做到集中的ECC大屏呈现。在云计算的世界里，每个云产品，比如ECS云服务器，其作为可以独立输出的产品服务单元，云产品自身已经带有完备的监控功能。换句话说：云产品的配置管理已经落到了每个云产品的内部，云产品的监控能力与产品的配置项是紧耦合的关系。云厂商需要做的是设置一个统一的监控平台界面（Uni-Manager），把各个云产品的监控能力加以封装，以客户比较熟悉的ECC的形式输出。

   2、风险的控制机理不同

  传统运维的风险预防主要集中在执行严格的变更和发布管控和审批流程，以及针对风险的治理能力。风险的发现主要来自监控的指标体系的设置，以及事件的定级和指标触发的应急响应。故障恢复也有赖于频繁的应急演练，这里包括特定故障的应急演练和整个数据中心级的切换演练。

   有别于传统运维严把变更和发布审批，云计算的运维更加强调通过白屏化的操作和脚本化的驱动来降低和规避风险。基本实现全局故障1分钟发现，5分钟定位和10分钟解决。云环境下的风险管理也会包括诸如风险预防、风险发现、故障定位、故障恢复和故障复盘的全流程，只是云环境更加强调自动化脚本或平台的作用，把变更或发布脚本在云计算的产研侧写完，这样就可以做到可重复执行和受故障影响的业务自动恢复。通过平台的管控和脚本的触发实现变更或发布的可灰度、可监控（白屏化）和可回滚。可灰度即对应DevOps提到的金丝雀发布，可回滚即对应DevOps的蓝绿部署。故而云环境的风险控制是依赖DevOps全自动化的部署流水线来实现的。

   3、自动化成熟度不同

   云计算的资源虚拟化和资源池化的特性本身为自动化运维提供了很好的技术保障。在云环境下遇到网络DDOS（拒绝服务）安全攻击或重大故障时，自动化的业务限流或业务流量的自主切换变得非常容易实现。甚至为了确保业务全链路的安全，可以采取部分业务功能自动降级的处理，比如某券商软件可以把已引入故障的查客户积分的功能暂时跳过，确保主业务链路的证券产品买卖服务功能的可用。除此之外，云环境还可以如DevOps所提倡的不时人为注入故障(Chaos Monkey)的操作,验证在重大故障来临可以以自动化方式恢复业务的能力，充分体现云环境的产品鲁棒性。

总之，云环境下的运维更加强调白屏化和脚本驱动，以DevOps部署流水线的方式来规避或降低变更或发布的风险。ITIL 4的部署管理实践可以通过DevOps部署流水线的方式来落地，故而企业的IT服务管理在未来的指导原则是不断打造基于云计算的产品能力来实现业务的持续交付和自动化运维的能力。