在最近的多次客户交流中，我反复强调以下运维思维：“三点线下，七点线上；三点运维平台，七点-点技术框架”。运维需要“从线下走向线上，从线下走向线上”。简而言之，就是一种O2O运营思维。如何理解具体的O2O思路？（文末摘录了O2O的四象限能力） 1。O2O中的线下思考 这是运维平台的第三部分，即线下内容。运维平台的建设要抓住主线，以CMDB平台为核心，在其之上分为两部分。一是持续交付平台，也就是所谓的自动化，用来提高交付的效率和质量，同时减少对人的依赖；另一块是数据平台，包括端到端的监控系统和数据分析系统。 最近思考最多的就是运维自动化平台到底该不该叫自动化？后来我的想法是把这个运维自动化从我们平台上去掉，不叫自动化了。仔细看了很多产品，包括传统企业的自动化解决方案，比如bmc的自动化，还不错，因为本质上就是流程引擎加执行器，能力上没有区别。那么互联网运维自动化与传统运维自动化有什么不同呢？我的答案是交付能力。交付是一个动词，它可以连接很多对象，比如交付价值、交付服务、交付资源、交付能力、交付配置、交付应用，不是吗？其实自动化只是对交付能力的要求，最重要的是交付质量，交付效率。我们需要具备持续交付的整体思维能力，根据角色、场景、IT成熟度构建不同的交付能力，让产品真正带来价值。 前不久看到一个金融应用发布流程，涉及到几十个环节。不少人看到后都惊呆了。我说这个过程暴露了一个问题。很多内部平台服务能力不足。例如，人为地将一次机器获取分成多个过程，而不是一次完整的资源交付。但是我去要设备的时候，得弄一台物理机，然后根据KS文件安装操作系统，激活防火墙。其实应该把这些打包（package）成送机服务！ 这两个平台最终都是基于CMDB的业务信息化管理，可以实现平台闭环和互通。监控平台可以利用工具平台的能力，提高自动处理故障的能力；数据分析平台的数据分析结果和模式发现可以作为持续交付耦合平台调度决策的输入。 2。O2O中的在线思维 这是七点技术架构的一部分，即在线内容。我觉得运维质量/效率的提升和成本的降低，都深深依赖于这个在线技术架构的可服务性。但是当我们绞尽脑汁考虑如何提升持续交付的自动化能力，降低应用发布的复杂度时，却从来没有考虑过上线工作。应用规范开启流程，减少对cmdb自动发现的依赖；服务关系调用的上报可以减少对日志监控的依赖；自动封装F5和DNS能力，减少对人为改动的依赖；一旦服务调用通过了防火墙或者F5，你的服务调度就??不再简单了。 我为什么要和大家聊精益运维？要知道日本人对生产线的要求非常严格。一旦发现生产线出现质量问题，必须终止所有生产活动。精益的观点就是以批判的态度去面对运维！ 3。O2O 中的OO互操作思想没有很好的平台支持，线上能力无法进一步加强；没有线上能力的配合，线下平台就不够简单。它们相互补充，相互促进。 不要在错误的道路上越走越远！离线和在线连接始终是必经之路。以我们自己的创业项目为例。我们从一开始就对在线能力提出了很高的要求。他把可操作性作为一个严格的标准（可能跟我们运维的背景有关系吧！CTO就是设计和实现了腾讯的“织云”）。我们可以接入统一调度，使用名称服务，自动化测试；我们还使用统一的接口规范，方便接口描述文档的自动生成和可测试性；统一包装，更换方便。随着这些能力的实现，我们减少了对人工操作和维护的依赖。如果以后需要对某个节点进行扩容，只需要告诉客户加入一个节点就可以了，不需要写复杂的文档。 4。O2O中的持续运营思维 与客户沟通时，客户难免会说，你提出的很多想法很好，但我们很难改变。其实我也知道改变是很难的。我说我们可以尝试一些操作思路。我之前不是跟你说过，运维其实就是IT运维吗？ 首先要有灰度思维。关系好的研发到关系一般的研发，从技术热情高的研发到技术热情一般的研发。你必须掌握这条路。你不能一开始就包罗万象，让所有的人、所有的企业都跟着你的想法走，那必然会失败。 其次，你必须能够系统地描述你的想法和实现的好处。很多运维只是三言两语描述自己的想法和解决方案，这是很糟糕的。我们需要这样一种系统化的语言来与开发/测试，甚至业务部门沟通，来传达这种可操作性方案的好处。每个月做一个PPT，交流一下。在UC九游，他们有一个策划沟通会。该部门花了几天时间将相关各方召集在一起。大家依次说说自己的打算，效果很好。事实上，研发和运维之间没有一堵墙。人多了就会被墙！ ***，你必须有一个平台来承载和可视化你的想法。即使在没有业务接入的情况下，你仍然需要一个可视化的平台来展示你的Idea，让对方看到效果，这往往是最打动人心的。人是理性的、视觉的，没有理由拒绝视觉呈现带来的直观好处。 接下来就是确定运维目标，开始工作了。万事开头难。当您接入第一笔业务后，其他业务的进度将大大提高。我一直认为研发不是运维的敌人。事实上，他们更看重自己开发的应用程序或程序，希望它们有更高的可用性，但往往苦于时间和缺乏运维思路。但是一定要注意，这一招千万别玩坏了，也就是说，第一枪一定要成功！ 5.O2O 中的“补贴”思维其实可见一斑。开发拒绝运维需求。这只是一些技巧。最大的招数：用了你的方案，性能会下降，需要更多第二招：如果这段时间有线上运维的需求，会影响产品上线的进度。对付***点很简单，给他们补贴一些资源。之前UC推广MySQL高可用方案时，采用的就是这种策略；建双中心的时候说需要两倍的机器。但是第二点，我觉得破局的策略是，运维要走出去，走到研发这边，走到研发流程的前端，研发阶段-“设计阶段-”需求阶段，多做时间补贴，持续宣传。 O2O的思路是让运维意识到自己不应该太执着于平台的能力。工具就是工具，永远超越不了技术架构设计思想背后的能量。O2O思维也是一种DevOps思维。O需要懂运维和研发，没有研发的运维不是好的运维。我今天也想强调一下，不懂运维的研发，我觉得不是好的研发。O2O思维更多的是一种运营思维。不不断迭代优化，运维就无法走出困境。附录参考：运维O2O四象限总结如下：
