运维人，你应该具有的五大O2O思维

《运维人，你应该具有的五大O2O思维》要点：
本文介绍了运维人，你应该具有的五大O2O思维，希望对您有用。如果有疑问，可以联系我们。

在最近的多次客户交流中,我反复强调运维要有以下思维：“三分线下,七分线上；三分运维平台,七分技术架构”.运维需要“从线下走到线上,从离线走向在线”,简而言之就是一种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四象限总结如下：

文章来源：微信公众号——互联网运维杂谈

转载请注明本页网址：
http://www.vephp.com/jiaocheng/4558.html