在最近的多次客户交流中，我反复强调运维要有以下思维：“三分线下，七分线上；三分运维平台，七分技术架构”运维需要“从线下走到线上，从离线走向在线”，简而言之就是一种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思维更是一种运营的思维，不想着持续迭代和优化，运维是走不出困境的