本文分为三个部分，第一部分从服务交付和服务度量两方面介绍运维可视化；第二部分介绍什么是DevOps以及它给运维带来的改变和影响；第三部分结合最新的数据资料和趋势聊一聊运维人可能面临的危机。

Part 1

   

可视化

没有比“可视化”更好的一个词能概括运维的本质，而“可视化”又应该分成两部分：可视化的服务交付和可视化的服务度量。

 

一、可视化的服务交付

早期的运维是从ITIL开始的，那个时候大家都不知道运维是什么，幸好找到了一个IT服务最佳实践——ITIL。开始了互联网运维的摸索之路，从CMDB、服务台、事件管理、变更管理、可用性管理、容量管理等逐步去了解，并同步建设对应的管理平台。但我们很快发现，这一完备的流程框架如果遇到了大规模运维的情况，就无法应对，原因在于过多的聚焦于流程以及规范，我们发现很难提升运维敏捷度和精细性，并且我们还是不知道一个完整的IT服务边界在哪儿？如何实现它？

不过在ITIL的实践过程中，其实提出了一个很好的概念——IT服务。对于运维来说，提供一种高效、一致性、透明化、面向用户的服务是运维的价值所在，这样就要求运维屏蔽其提供的服务背后的所有实现细节。

从运维具体事务或者活动的角度来说，如何对其进行一次或者多次的组合封装，把它们变成一个完整的IT运维服务，是此时的运维自动化重点方向。毕竟繁杂的运维事务不进一步封装，对个人或者团队来说，都意味着很高的学习成本和事务执行成本。在传统的IT运维组织中，我们能看到彼此事务之间的割裂非常明显，比如说网络、机房、服务器、应用部署等，都是在不同的团队完成，彼此工作独立进行。在敏捷和精益运维驱动之下，必须要求有一个集成平台来把这些事务流调度起来，否则无法提高事务执行的效率和质量，真正地把运维交付功能变成了交付服务的模式。

对于如何封装这些事务或者活动，从DevOps提倡的“自动化一切” （Auto everything)可以找到些答案，其核心的自动化主线就是面向用户的敏捷持续交付。我把持续交付又分成两类场景：一种是持续交付基础设施，一个是持续应用交付 （持续构建、持续测试、持续部署、持续反馈)，他们有点近似IAAS和PAAS的关系。

持续交付基础设施在公有云IAAS平台中得到很好的解决，利用软件定义计算、存储、网络等技术来实现对上层应用所需资源的快速交付。在私有IT环境中，当前有大量客户采用虚拟机方案或者私有云方案来解决交付难和慢的问题。最新的轻量级虚拟化技术Docker更是热点，根本的原因是把应用的交付在镜像级别完成，从而让应用交付更加快速。

持续交付软件从代码产生的那一刻就开始进行管理，到编译、到测试、到灰度环境验收再到正式环境部署，并且希望这条主线完全自动化。面向程序包的持续集成非常简单，现在有很多的开源解决方案来实现，如Jenkins、Go等，但有一种情况需要特别注意，就是程序包的配置管理问题，这个也往往是影响部署的重要因素。所以我们很多时候使用开源平台只是为了构建程序包，后续包及其其中的配置管理以及实例化部署，特别是大规模集群部署，都是由单独的持续部署平台来解决，而非之前的持续集成工具（虽然它们也支持发布），但持续部署平台需要有和持续集成平台无缝对接的能力。

基于软件包的交付解决之后，我们希望交付的粒度更大，如何实现全应用（从应用的前端接入到后端存储)的交付，此时便有了PAAS平台和基于应用架构的可视化部署服务两种方案。这两种实现思路有很大的不同，我们知道完整的PAAS平台提供了对底层公共服务的向上API统一抽象，比如说数据库服务、存储服务、Cache服务。PAAS平台最经典的实现应该是Cloud Foudry了，国内很多PAAS平台基本上都是参考CF来实现的。阿里UC也有一个类似的PAAS平台，示意图如下。

而在现实的情况中，很少公司有能力把Mysql、MC、Fastdfs封装公共服务供上层应用直接调用，意味着对研发程序有着一定的要求，是否还有一种更轻量的无约束自动化方式呢？我们可以把运维的全应用部署转变下思路，此时把应用架构中的各个部分拆解成对象组件（包含属性和状态)，比如说机房、OS、应用包等，全应用部署就是这些对象的编排，类似可视化IDE编程环境。

综上所述，运维的自动化最终要实现可视化，复杂的运维工作流必须通过可视化来表达，可视化后的自动化才能让所有人理解一致、执行一致、结果一致。

二、可视化的服务度量

“除了上帝，一切人都必须用数据说话”，这是运维人员必须恪守的信条。我写过一篇完整的数据驱动运维的文章“关于数据驱动运维的几点认识”，里面系统地介绍了数据化运维的目的、数据的来源以及如何构建数据体系，等等。

最近也在进行一个数据实践，就是建立面向应用的端到端数据分析体系，该体系对数据有个标准化的分层归类，从基础设施、上层组件、到应用服务、到接口、再到用户侧，基于应用的拓扑架构，收集各类指标，统一到一个分析平台中展现，如下图所示。

基于这套分层化的数据体系标准，我们也有对应的系统实现，如下图所示。

当形成标准的数据采集、分析和展现体系之后，可以向其他应用不断去复制这套方案，大家只需要遵循一套数据标准即可，最后数据的采集、分析、展现和告警都是标准化完成。这套数据体系建设完成之后，可以在运维的故障定位、服务优化、架构改进、运维规划等各方面找到应用场景。

此时有人会有疑问如何面向应用把这些数据整合关联起来？我们当前是基于配置文件的静态视图和基于接口调用而生成的动态视图来集成。动态调用视图生成会复杂一点，可以让线上的接口调用统一由名字服务中心来接管调度，抽样对接口调用进行染色，从而生成动态的访问关系。

以上视图能快速发现和定位规模故障，但对于单个用户的故障指标上则应对乏力。此时分布式Trace服务的作用就显现出来了，可以借鉴Twitter的Zippkin和Google的Dapper的实现思路。当前我们就结合自身的业务架构特点，实现了一个统一的服务调度框架和名字服务中心，在业务代码无侵入的情况下，可以把业务调度链的染色数据上报和关联，实现对于单个问题的快速定位。

数据的可视化能力非常重要，需要在面向整体和面向某个业务流上都有实现。它首先体现出你对运维的理解是什么样的，从可视化Dashboard上可以看到最直接的运维经验；其次基于可视化之上的数据共享，让大家对数据的理解达成一致；最后利用一致化的可视化数据发挥运维的驱动能力，驱动DevOps，数据的核心价值就在于此。

因此可视化的能力就代表了运维的能力，可视化的程度越高，运维的能力越高。那么你现在到底可视化了哪些运维服务，并能进行度量呢？

Part 2

   

DevOps，值得运维拥抱！

 

最近公司组织大家出去讨论关于协同效率问题，之前在腾讯也讨论过部门墙的问题。随着公司的日益增大，这类问题会一直存在，且一直在解决而不能彻底解决。此时，我从运维的角度来谈DevOps还是比较应景的，它恰好给这个问题提出了一个全新的解决方案。结合之前自己总结的一个DevOps PPT，在下文中，我通过我的PPT逐步来谈谈我对DevOps的理解（部分来自于自己的总结，部分来自于之前的读书笔记）：DevOps到底是什么?给运维带来了什么样的改变和影响？

一、DevOps是什么？

1、DevOps的初印象

DevOps在很多人看来就是一个代号，先不管它的到底是什么，但这个代号有一个很大的好处，统一了沟通交流术语，如同之前的敏捷。另外从字面上第一次把DevOps放在一起来看，抛弃了之前的一些概念，比如说运维，甚至更早期的D/O分离等等。

DevOps和Dev/Ops、Dev & Ops是有着一些区别。首先、Dev/Ops、Dev & Ops都强调两个独立的职能角色；其次Dev/Ops用分离的视角来看研发和运维，最典型的后果就是研发只看功能需求，不考虑可运维性，而Dev & Ops在一定程度上两个团队的合作能力是更强了(平行团队)，但是还没有做到真正的跨职能。把DevOps融入到各自的日常活动中，无论是研发、测试和运维都需要面向共同的目标、价值观、思维模式等等。

2、DevOps是一种文化（Culture）

单纯的说是一种文化，非常空洞。文化的表现必须是通过一种运动的形式来表达其内在的价值诉求，就如同文艺复兴和五四新文化运动一样。同样在DevOps领域，也是因为多种运动不断催生的产物，比如说一天10次部署运动、平台及服务运动、持续迭代运动等等，最终达到其文化价值的传递，比如说高质量、高效率的服务交付。从我的角度来说，持续集成、XX(架构、监控)及服务及运维数据化是DevOps的核心，可视化是其最终的呈现。

3、DevOps是一种价值观（ValueSet）

价值观是DevOps需要恪守的准则：

（1）持续优化。任何一个工作都不存在完美的状态，应该持续的推动他，自动化平台的建设如此，数据驱动DevOps更是如此，因时而变。

（2）合作共赢。把彼此的合作放在第一位，完成面向用户的共同价值输出，而非个人所在部门的利益达成。

（3）杜绝浪费。任何停滞都是一种浪费，不作为更是一种浪费。

（4）关注用户。用户的价值为最终的导向，并且让用户的价值反向传导到内部工作流节点上。

4、DevOps是一种思维模式（MindSet）

在早前我写过一篇文章探讨过互联网+和云+之间的关系。我也特意对两者的思维模式做了一个对比。

其实在思维角度来说，这两种思维也有很大的相近之处。互联网思维，雷军的七字诀不做过多的解释。在DevOps的思维层面上来说，我也做了一个总结，大致如下：

(1) 精益

精益思想（Lean Thinking）源于20世纪80年代日本丰田发明的精益生产（Lean Manufacturing）方式。丰田的精益制造有14项基本原则，后面有人对其的管理思想进行提炼，总结出精益思想有五项基本原则：

• 从客户的角度来定义产品价值。价值由客户定义，而非自己定义。

• 识别价值流。精益思想识别价值流的含义是在价值流中找到那些是真正增值的活动、那些是可以立即去掉的不增值活动。精益思想将所有业务过程中消耗了资源而不增值活动叫做浪费。识别价值流就是发现浪费和消灭浪费。

• 让价值流流动起来。精益将所有的停滞作为企业的浪费，因此要求创造价值的各个活动（步骤）流动起来，强调的是不间断地“流动”。

• 拉动式价值创造。按照客户的需求进行生产，设置好对应的投入和产出。

• 持续改进式到尽善尽美。“通过尽善尽美的价值创造过程为用户提供尽善尽美的价值”。

在很多管理思想上，原理是互通的，PDCA、全面质量管理、六西格玛等等，甚至是所遵循的方法论，DevOps也是如此。

(2) 价值

当互联网思维在强调他的用户口碑的时候，而我们的技术服务则强调他对用户的价值输出，从而为产品赢得口碑。价值在上面也提到是用户关注的价值，而不是我们认为的价值。高可用、稳定的服务是质量的根本，质量则是价值的一部分，而不断的满足用户需求的服务才是重中之重，这就让各自的团队有了一个共性的衡量标准。

(3) 跨界

其实互联网思维的专注是让你对事情有更深入的理解，才能做到极致。而在DevOps所倡导的思维模式，并不是让你去失去专注，而是在此基础上让你更加跨界。在强调职能分工的企业中，过多的限制在某个岗位上行驶某个职能，不利于事务的整体推动。而运维是那个全局观能力最强的人，恰恰需要这个时候从整个价值链的活动来全局观察，并提出方案。同样，研发和测试也需要不断跨出自己的职责区，去和运维一起优化产品和技术方案。

(4) 敏捷

业务要求快，技术则要求敏捷，无论是流程的敏捷，还是服务交付都需要非常敏捷。传统的敏捷观点是要技术如何更好服务业务部门的需求，是Dev和Biz的之间的合作模式，而现今的敏捷则从持续集成、持续交付、持续部署等多个层次对敏捷提出了新的要求，是Dev、Test、Ops甚至是产品部门一部协奏曲。

5、DevOps是一种工具观（ToolSet）

DevOps首先倡导的原则是自动化一切，但数据化同样重要，并且我提出要把他们都可视化呈现出来。自动化是可视化一切价值流的过程，数据化则可视化价值节点的状态。这个在之前的运维可视化部分里，有全面的阐述。

 

二、DevOps的最佳实践

Damon列举了一系列实践与举措，对于这些举措，我也用几个词做了备注。这些实践与举措在那些成功应用了DevOps的组织中已经成为它们日常工作的一部分，如下：

 

• 去除“完成”这个词，服务是永不停止的，它们一直在运行并应该得到持续

  关注【持续优化】

• 将运维需求与功能需求一样视为一等公民，使运维方能够及早发现需求影

  响【合作共赢】

• 将工作流程可视化，使所有人对全局有了解，瓶颈自然显现【可视化】

• 协同匹配价值流，这样才能理解系统全局并发现浪费【价值驱动】

• 将信息流变为产品流，以降低信息传递中的歧义并澄清人员间必须的交流【拒绝浪费】

• 将相关数据组合起来形成有意义的指标，让组织中不同利益相关者都能意识到【数据可视化】

• 通过将变更关联到相应指标并将它们图形化来提升对变更的认知【数据可视化】

• 有目的地妆点办公室墙，使每个人都感觉到自己是整个系统的一分子【工作满意度】

• 去中心化管控，让产品的开发者和运维者就责任达成一致（例如：开发者负责代码的正常运行，运维负责平台的正常运行，诸如此类）【共享责任文化】

• 举行内部小型会议，大家可以在会上就已经完成和可以完成的事项达成一致，会上也鼓励大家就变更发表自己的意见。【共同参与】

• 强制在运维的帮助下对所有开发提交的服务进行部署验证检查，以避免在运维时才出现问题【持续部署】

• 释放你的猴子，这能使你对自己的服务承诺产生巨大的自信【信任】

• 在问题发生时不仅在管内（pipeline flow）流转（要引入更多的变更和工作），而是关注在找到瓶颈发生的真正原因并加以修正【杜绝浪费】

• 保证对客户透明，在出现问题时勇于担当，在问题解决后保持警惕，客户自然有理由心满意足【关注用户】

• 在团队和日常工作流以外建立良好关系，例如通过“Guess the Admin”游戏或与公司内不同的人一起共进午餐【合作与分享】

2013年puppetLabs做了一次DevOps调查，也谈到了最佳实践，汇总如下：

三、DevOps和ITIL对比

DevOps和ITIL有着明显的不同，从这个不同的也也可以看出，DevOps代表着未来，ITIL已经不适用互联网的业务运维模式（传统企业还不敢说）。ITIL应该算是运维第一个阶段的指导思想，但在日益快速变化的互联网运维面前，它已经无法胜任。当然现在有些文章也在表达ITIL的思想和DevOps思想的相同之处，比如说也在强调服务生命周期的管理，最佳实践也是在指导系统平台的建设。但我觉得从本质上来讲，ITIL完全没法覆盖运维的活动，其次没有从价值链的传导过程设计运维实践，比如说持续集成，这些都是其致命的弱点。

四、DevOps的核心技术指标（吞吐率和延时）

从DevOps的最佳实践及自动化要求来看，DevOps本质上就是为了更好地解决组织的吞吐率（Throughout）和延时（Latency）问题！在前面也谈到过，我们可以把所有的运维活动提炼成面向用户的价值流（flow），这些流从技术层面上来说，真的有点类似于我们线上应用系统的一次请求。对于技术请求来说，对其性能的衡量就是吞吐率和延时，那么对于运维服务性能（Ops performance）来说，也可以转换成吞吐率和延时。那么这两个指标具体有代表什么呢？

1、吞吐率

(1) 持续集成性能，可以从不同的团队角色出发提炼出不同的指标。

从研发团队来说，每天触发持续构建及单元测试的数量、....；

从测试团队来说，每天回归测试的数量、每天自动化测试的数量、....；

从运维的角度来说，每天持续部署的数量、生成持续反馈报告的数量、....；

(2) 其他的变更性能

一个运维人或者团队，一定周期内的运维变更能力，比如说可以支持多少个业务多少个变更能力。不过这个变更能力取决于两个方面能力，一个是工具的自动化能力；另外一个取决于线上服务公共化的能力。前者大家很好理解，后者大家就不好理解了。举个例子，当一个被调用服务需要扩容的时候，此时这个服务被前端服务放在配置文件中还是DNS服务中，这个变更的复杂度完全是不一样的。

所以对一个运维团队来说，在构建自动化平台的同时，也别忘了和研发一起做架构上的优化，提升运维的吞吐能力。

2、延时

(1) 持续集成延时

之前提到过把能力不断前置，其实是把服务的延时不断降低，类似技术架构中的cache机制。我们都知道，为了让业务访问数据库更快，就不断的把数据推到离应用程序更近的地方；为了让用户下载更快，我们把文件通过CDN分布到离用户一公里。过往的实践告诉我们，打破原有的思维定势非常必要。在过去的观点中，运维应该是应用环境的第一负责人和执行人，但在持续部署平台完善的情况下，发布工作可以不断往前推置；DNS服务的管理也可以不断的交给应用运维自己去管理，甚至直接开放API供应用程序直接调度修改使用。这些工作都需要相关团队的彼此推进和结合，否则很难实现以上所说的角色转换。前置的最极致表现，就是用户的行为对系统产生影响的时候(高容量)，变更即刻自动化完成。

集中式也必须不断走向分散式，使用去中心化的管理模式。我们都知道中心化能带来良好的管理和控制，但是最大的影响就是效率，多对一的情况下，那个一很容易成为瓶颈。但在无平台的情况下，我不建议这种能力直接往前端推置，不同的人的管理很容易不统一，这个会给后期的统一自动化平台建设带来更大的成本，而在有平台的情况下，把相关的服务能力直接交付给前端。

(2) 故障恢复延时

故障恢复越快越好，这就意味着对用户影响更小。但为了达到这个故障恢复延时很小，则需要监控平台、数据平台强大的支持。如果把故障分解成三阶段：发现故障、定位故障、解决故障，则每个步骤依赖的能力是不同的，缩短每一个阶段的延时，是我们日常运维在故障处理这块的工作重点之一。

更高吞吐率、更低延时的运维就是更好的运维，我们须持续不断的推动及优化！

五、DevOps，运维需要做的改变

1、组织的改变

按照以前职能分工的组织结构造成隔离的责任制文化，大家都只关注自己的岗位职责，而不去care其他。但在DevOps的要求之下，运维活动需要经常的跨职能进行，这也要求部门之间需要有一个共享责任的文化氛围去更好的衔接部门之间的关系。当前在国外的一些调查报告中可以看出，已经出现了独立的DevOps部门和DevOps工程师。从组织的角度来说，需要一些DevOps培训，如同组织引入敏捷培训一样。

2、个人的改变

当前每个人要认识到，运维不再是简单的参与维护职责，而是整体事务的推动者和解决者，此时需要利用运维人的全局观去把控整体项目的影响等等。

运维人也需要不断跳出舒适区，去跨界识别风险和提供优化方案；需要让自己变成善于整合资源的人，集中各团队的优势能力，让我们的运维交付更快、服务更稳定。面向问题和面向事务的运维需要往面向用户价值的运维转变！

3、工具观的改变

以前以ITIL为中心的流程系统建设方法论，需要彻底的改变，把持续集成自动化当作第一要务。有了持续集成的平台之后，不断去解决底层（如：操作系统安装）及上层应用调度的自动化，最终形成自底向上的自动化调度平台方案。

其实DevOps不就是那个协同效率的解决方案么？

Part 3

   

运维危机，你嗅到了么？

 

运维危机是运维人的危机，你感觉到了么？

其实这个时候谈运维危机有点像在当下讨论股市危机一样，因此写这个话题时，内心很纠结，特别是这个互联网运维才产生没多少年（10年）的行业，怎么你就来谈危机了？没办法，都因技术发展太快。

首先带大家看一组数据，国外著名企业级公有云管理市场领导者rightscale每年都会发布一份云计算市场报告，rightscale应该是云管理里面的鼻祖，2013年他们平台管理的服务器达到580万台，因此他的数据报告还是有一定的权威性，从这个报告中可以让我们看到一些趋势。

一、云的使用情况

 

1、云的使用度已经达到93%的水平，而在具体的云使用策略上，可以看到未来多云（82%）和混合云（55%）是未来的趋势。

其实这两组数据给我们展现都是云的趋势越来越明显，用户的接受度越来越高。而云计算到底对运维有着什么样的颠覆力？

2、个人也对对国内的公有云使用情况做了一次调研，用户的使用水平也是相当的高（游戏领域），达到76.19%。因为样本量不大，应该会更高。

3、Rightscale报告中，也对DevOps的使用情况做了统计。用户应用DevOps的理念或者工具很广泛，达到66%的水平，相比去年有一定的增长，并且在IT更复杂、敏捷性要求更高的大企业中，DevOps的应用比例更高。在DevOps工具的使用上主要是puppet、salt、chef、docker几类。调查报告中用了“DevOps rises，Docker soars”来总结DevOps和Docker。

4、为了进一步去验证DevOps理念的应用情况，我把PuppetLabs的DevOps的报告又找出来了，总结了DevOps的核心理念及实践。报告反复强调自动化、强调DevOps文化价值、强调数据驱动等等，这些对运维又有着什么样的影响呢？

 

二、危机在哪儿？

1、云计算平台对运维的影响

我们都知道云计算平台有IAAS平台、PAAS平台、SAAS平台之分，不同的部分对运维的角色都有着不同程度的影响。

IAAS把基础架构做成一个服务，资源即需即得，这也正式创业公司都愿意使用公有云平台的一个原因。按照传统的模式，创业公司自己需要联系机房、购买服务器、电信机房放置调试服务器/网络等等一堆基础设施的工程，影响项目周期不说，还需要一定的专业技能，而IAAS把创业公司都从这些需求中解放出来。再进入到IAAS内部几大部分，软件定义计算、软件定义存储、软件定义网络，进一步降低对运维人的依赖，确保一个大资源池的整体服务能力。让软件代替人，是IAAS层基本思想，都知道对于一个海量的服务架构，同时要面向不同的业务形态，IAAS只能依赖这样的软件定义能力，靠人是跟不上的。刚刚paypal分享他们迁移到openstack经验，其中一个数据很有意思，以前paypal对服务器故障的容忍度是1%，而迁移云平台之后容忍度是3%到5%。要知道这个比率提高意味着什么，对运维的实时事务处理要求进一步降低，也就是对人的需求减少了。结论：不需要那么多基础运维人员了。

PAAS部分，进一步对服务进行抽象，变成一个公共的服务架构，研发程序只需要遵从一定的开发和配置约束，最后服务的运行、发布等都由PAAS平台统一接管，进一步释放对运维的依赖，且此时根本就没有IAAS层维护成本；结论：不需要那么多应用运维人员了。

最后到SAAS部分，这块目前在国外非常活跃，国外从运维领域的监控、自动化部署、数据分析、资源管理等领域都有多家公司在提供服务。之前依赖运维从无到有的构建，现在也不需要了。在传统的模式下，运维都是自己搭建监控平台，自己构建部署系统。当前情况下，对于小的企业来说，可以直接使用云平台自带的服务，足够应付。对于更大规模的企业环境来说，你可以选择其他云服务，只要你许可他们的agent安装在你的服务器上，采集数据/部署都可以完成。再回过头看看IAAS云中提供的RDS服务（类似SAAS服务），里面把一切对Mysql的管理都封装成webUI；对于系统中慢查询，在给出报告的同时，还能给出相应的优化建议，备份、迁移管理都一应俱全。不过幸运的是，国内目前这块的产品还不多。结论：不需要那么多应用运维人员和DBA了。

随着在云计算不同层次的云服务水平的不断提升，对传统的运维模式（流程性、功能性、技能型）逐渐形成颠覆力。可能还是会有很多人有疑问？从公有云获取到服务器资源之后，总还需要做一些一些人去做系统管理的工作吧？不需要，你是否想过未来假设有人基于puppet或者salt封装一个appstore的模式供用户使用，里面所有的SA管理方案都可以通过下载的方式应用到自己的OS环境；PAAS现在很难应用起来，部署工作总还需要运维吧？我认为即使PAAS应用不起来，通过其他的持续部署方案和更上的自动化编排方案都可以解决自动化的问题，因为本质上就是发布文件和执行命令；应用需要经常变更、扩容、故障定位总需要运维吧？我也不这么看，你所会的技能很多都隐藏在数据之中，通过容量数据可以驱动应用变更和扩容，并且容器docker的出现可以让这个工作变得更简单，关于故障定位，很多时候都是依赖一些故障定位技巧，而这些技巧都是可以通过数据来做root cause分析的，只需要把资深的一些运维人经验提炼成产品。

因此我更愿意相信在不久的将来会有一个完整的运维产品存在（类似ERP），该运维产品能够解决自动化运维的问题，能够把一切技术数据收集起来，按照运维人的经验来提炼数据的价值，应用到各个运维场景中去，比如说容量、故障定位、扩容、变更等等。

2、DevOps对运维的影响

在前面给了一些关于DevOps的数据，首先可以看出DevOps的理念已经开始逐渐被更多的企业所接受，其次DevOps关注的焦点也和过去的流程ITIL有着本质的区别，他就是需要通过自动化不断的降低浪费、驱动敏捷、打破团队边界等等。在前不久，我参加了今年puppetlabs的一个在线调查，里面可以看到国外已经有专门的DevOps部门存在，且有专门的DevOps工程师。我是如何看DevOps？就是把后端的Ops服务不断的推到前面Dev，让前面的Dev具备Ops能力，这就是DevOps。当然背后是靠平台和工具支持的，流程肯定是不行，这是传统运维急需要改变的地方。把这种对人的依赖和运维的经验都转换到平台中。在早期，所有的发布变更都依赖运维来完成，后来我们搭建发布平台，可以让测试来做发布，再往后发布平台和自动化测试平台进一步对接，这个发布工作再进一步交付给研发，运维从过去的执行者变成了审核者，自动化驱动一切，质量、敏捷驱动一切。

再去到数据化运维部分。由于研发、运维都是技术人员，所以大家很容易对技术数据达成一致的认识，甚至有时是研发会更敏感，因为他更了解自己的服务该如何衡量。过去我们都有错误的认知，把数据当着运维团队的核心资产且保密，只有运维团队使用，而其他的团队只能关注到一些运维给到的结果，其实这是违背DevOps原则的。而我的建议是，运维提供采集一切数据的能力，把上层的分析和展现能力开放给所有技术人员，运维人员只是数据使用的一个角色，可以按照自己的价值维度和场景抽象几个数据产品出来，比如说监控、容量、质量、可用性等等。研发人员也是数据使用的一个角色，它可以按照自己对服务的理解，去任意的加工数据，这个有点回归到以前BI的那套思路了。

因此运维最终要变成经验平台的建设者，而非简单的事务执行者。

3、开源技术对运维的影响

现在还有什么开源解决不了的呢？请直接搜索【开源的DevOps开发工具箱】或者关注博客【http://www.devopsbookmarks.com】。

而我想说，在运维的每个部分都有相应的开源解决方案存在，难道我们还说对运维的依赖很重么？在任何一个运维开源技术面前，运维能表现出比研发更强的把握能力么？说实话，开源技术把之前运维的技能墙打破了，都可以获取技术的能力。不过这个地方有运维的一个存在价值，也就是国外DevOps部门的存在价值，我的思考是DevOps部门提供的是运维平台统一规划和建设能力，否则对于一个企业来说，技术和目标的协调无法完成。开源技术降低了获取门槛，但也提高了被滥用的可能，而运维部门可以避免这种滥用。

一方面我们要注意到当下的云端技术变化趋势以及对运维的影响，另一方面要清楚的知道单纯的流程性/功能性/技能型运维，已不是时下需要，危机正在悄悄走进你。当前运维的存在空间，还有部分是因为开发不懂什么是运维，他们连puppet都不知道。当有一天运维也像开发、测试一样变成云端服务，运维就不需要依赖某个运维人和某个运维团队了。因此请尽快拥抱自动化运维、数据化运维，并往运维产品化、规划方向提升，一起做好运维转型准备吧。

作者介绍：王津银

• 优维科技公司创办人。

• 2007年进入腾讯公司接触运维，经历服务器从百到万的运维历程。

• 先后在YY和UC参与不同业务形态的运维，期间带过多种运维团队。

• 极力倡导互联网价值运维理念，即面向用户的价值是由自动化平台交付传递，同时由数据化来提炼和衡量。

本文来自云栖社区合作伙伴"DBAplus"，原文发布时间：2016-02-17