在最近的多次客户交流中，我反复强调运维要有以下思维：“三分线下，七分线上；三分运维平台，七分技术架构”。运维需要“从线下走到线上，从离线走向在线”，简而言之就是一种O2O的运营思维。具体的O2O思维如何理解?(文末有O2O的四象限能力提取)

1.O2O中的Offline思维

这是三分运维平台的部分，也就是线下的内容。运维平台的建设要把握主线，以CMDB平台为核心，在之上分为两块，一块是持续交付平台，大家说的自动化，用来提升交付的效率和质量，同时降低对人的依赖；另外一块是数据化平台，里面涵盖端到端的监控体系和数据分析体系。

最近，我思考最多的是运维自动化平台该不该称之为自动化?后来我的思考是把这个运维自动化从我们的平台中去掉了，不叫自动化了。我仔细看了很多产品，包括传统企业的自动化方案，比如说bmc的自动化，做得都不差，因为本质上就是一个流程引擎加执行器，体现不出能力差异。那到底是什么让互联网运维自动化和传统有所不同，我的答案是在交付能力。交付是一个动词，后面可以连接很多宾语，交付价值，交付服务，交付资源，交付能力，交付配置，交付应用都可以，不是么?其实自动化是交付能力的一个要求而已，最重要的交付的质量，交付的效率。我们需要有持续交付的全局思考能力，把交付能力按照角色，按照场景，按照IT成熟度来构造不同的交付能力，这样产品才能真正的带来价值。

在前不久看过一个金融的应用发布流程，里面涉及到几十个环节，很多人一看惊呆了，我说恰恰这个流程暴露出一个问题，内部很多平台的服务化能力不足。比如人为的把一个机器获取分成了多个过程，而不是一次完整的资源交付。但我去要一个设备的时候，我要拿到一个物理机，然后自己去根据KS文件装操作系统，开通防火墙，其实这些都应该被打包（package）到一个交付机器的服务里面呀！

这两大平台，最终基于CMDB的业务信息管理，可以实现平台闭环和互通。工具平台的能力，可以被监控平台使用，提高故障自动处理的能力；数据分析平台的数据分析结果和模式发现，可以作为持续交付耦平台的调度决策的输入。

2.O2O中的Online思维

这是七分技术架构的部分，也就是线上的内容。我觉得运维质量/效率的提升，成本的降低，深度依赖这个线上的技术架构服务化能力。但我们绞尽脑汁考虑如何提高持续交付的自动化能力，降低应用发布的复杂度的时候，从来没有考虑过对线上下点功夫。一个应用的规范打包过程，可以降低对cmdb自动发现的依赖；一次服务关系调用的上报，可以降低对日志监控的依赖；对F5和DNS能力的自动化封装，可以降低对人为变更的依赖；一旦服务调用经过防火墙或者F5，你的服务调度就不再单纯了。

我为什么和大家讲精益运维，要知道日本人对生产线的苛刻要求是，一旦发现生产线质量问题，要终止所有的生产活动。精益的观点，就是带着吹毛求疵的态度来面对运维！

3.O2O中的OO互通思维

没有一个很好的平台支撑，线上的能力也没法进一步加强；没有线上能力的配合，线下的平台也没法足够简单，两者相辅相成，互相促进。

一定不要在错误的道路上越走越远！把线下和线上打通，方得始终。就拿我们自身现在的创业项目来说，我们从一开始就对线上的能力设定了很高的要求，他把可运维性作为一个严格的标准(可能跟我们是运维出身有关系吧！CTO是设计和实现腾讯“织云”的)。我们接入了统一调度，使用了名字服务，借助了自动化测试；还使用了统一接口规范，方便自动生成接口说明文档，也方便可测试；统一打包，方便变更。实现了这些能力，我们就减少了对人肉运维的依赖，我们未来某个节点需要扩容，直接告诉客户加入一个节点就好了，不需要写复杂的文档了。

4.O2O中的持续运营思维

在客户交流时，客户难免会说，你提的很多想法都非常好，但是在我们这边改变很难，其实我也知道改变很难。我说可以尝试一些运营的思路，之前一直不是和大家说运维其实是IT运营么?

首先，我们需要有灰度的思维，灰度的过程是从非核心业务到核心业务，从关系好的研发到关系一般的研发，从技术热情高的研发到技术热情一般的研发。你必须掌握这个路径，你不能一开始就Cover所有，让所有的人和业务都按照你的思路来，必然失败。

其次，你必须能够系统化描述你的思路和达到的收益。很多运维都只是只言片语的描述自己的思路和方案，这一点非常不好。我们需要这样一个成体系的语言来和开发/测试进行沟通，甚至是业务部门，沟通这个可运维性方案带来的好处。做成一个PPT，每个月沟通，在UC九游，他们有个规划沟通会，部门花费几天，把干系方拉到一起，大家依次讲自己的方案，效果非常好。其实研发和运维之间本没有墙，人多了便有了墙！

最后，你必须要有一个平台来承载和可视化你的想法。甚至在你没有业务接入的时候，你也需要有一个可视化的平台来呈现你的Idea，让对方看到效果，往往这个是最能打动人心的。人是理性的，也是视觉的，直接看到视觉呈现后带来的直观收益，没有理由拒绝的。

剩下的就是运维认定目标，开始干活了。万事开头难，当你接入了第一个业务之后，其他的业务的进展会大大提升。我一直认为研发不是运维的敌人，其实他们对待自己开发的应用或者程序更认真，更希望他们可用性更高，只是很多时候也苦于时间和无运维思路罢了。但一定要注意，这招别玩坏喽，就是说一出手必须要成功！

5.O2O中的“补贴”思维

其实都能看得到，开发拒绝运维需求就是那么几招，第一招：如果上了你们的方案，性能下降，会需要更多的机器；第二招：如果这期上线运维的需求，产品上线的进度会有影响。对付第一点，特别简单，补贴他们一些资源。之前在UC推MySQL高可用方案的时候，就是采用的这个策略；做双中心的时候，说需要一倍的机器，我说能带来双中心的运维突破，给机器好了。但第二点，我觉得破局的策略就是运维需要走出去，往研发侧走，往研发流程前面走，研发阶段-》设计阶段-》需求阶段，多做时间上的补贴，不断的宣导。

O2O的思维是让运维意识到不要太迷恋平台的能力，工具就是工具，永远不能超越技术架构设计思想背后所蕴藏的能量。O2O思维也是一种DevOps思维，O要懂运维和研发，不懂研发的运维不是好运维。今天也要强调，不懂运维的研发，我觉得也不是一个好的研发。O2O思维更是一种运营的思维，不想着持续迭代和优化，运维是走不出困境的。

附录参考：

运维的O2O四象限总结如下：