上周，以“互联网企业的运维进化论”为题，UCLOUD与三位资深运维人为华南运维圈带来了一场深度运维分享会，认认真真地做了两件事，分享，交流。
本篇文章，我们老王在现场分享的内容【我的互联网运维理论与实践】。老王绝对是对听众负责的，认认真真准备了150页的PPT，终于在分享前精简到了105页，赶紧来看看他的理论实践。
隔(U)壁(C)的老王
老王的运维理论的整体思路如下：
1.运维的美丽新世界。从行业和自身的运维工作角度分析，呈现给大家一片运维的广阔天地，目的是让大家认识到运维的方向以及在自己的运维岗位上，运维到底能做什么。
2.运维的实践。最终还是要落地，分解了多个主题，每个主题部分都有阐述思路、建设经验和系统呈现，最后给了一个经验总结。
老王说，云对运维的革命要两看，自我革命是智慧，被别人革命是落后的。运维的本质是可视化，有十六个字要诀——价值导向，平台支撑、服务透明、数据驱动，要经历三部曲——标准化、服务话和无状态服务。再论何为运维的正确姿势——敏感(对业务)、去权威、觉知力、想象力和不操蛋。
运维阶段发展论
图：运维的进化论
运维的发展是有阶段的，每一个阶段是和运维的认识有很大的关系。
- 职能化，就是维护的代名词;
- 服务化，这是ITIL下的产物;
- 价值化，是运维把能力逐渐转向面向用户;
- 产品化，已经是在行业级别上进一步抽象，特别是带着互联网行业的最佳实践开始做产品化的抽象，它是运维的终极蜕变。
“在这个里面没有提智能化运维和云运维，我自己还没有深刻的想清楚他们的产品形态到底是什么样的，如果是SAAS化算是云运维的一种形态的话，云运维我便可以接受些。但是对于智能化运维，我始终不知道他的内涵是什么，想不出它的内在实质，也便没有存在的意义。”老王解释道。
运维识别的机会
运维风口已经打开了，从IT到”I”T。前面的I是指Information，后面的I代表Internet。
危机驱动下的运维机会。一则是我们的危机，另外是别人的危机。我们的危机是让我们不断做得比别人更好，别人的危机更多是目前互联网倒逼传统企业，给他们带来的危机，难道这不是我们的机会么?
成本驱动下的运维机会。企业的人力成本越来越高，此时更需要运维的产品化，更需要技术全栈的运维解决方案等等。
转型驱动下的运维机会。互联网+驱动下的企业升级，[云+技术]的需求会越来越明显。运维可以带着对技术的全栈理解而来，优势很大。
细分驱动下的运维机会。在不同的技术价值链条上，未来垂直化的服务分工会越来越明显，这有点和语言的发展阶段相似，早期的编译，后面的过程，再到后面的面向对象，越来越接近人的理解，而非机器。而老王认为，未来的垂直服务提供越来越接近业务的理解。
#p#
运维16字诀
价值导向，首先肯定是秉承自己的价值，否则就会觉得做这个事情的确挺苦的，我们每天都是处理问题、处理需求、处理故障，感觉像救火队。
平台支撑，其实有两类，可以把它分成运维内部和运维外部的。像这种平台，有一部分是运维内部平台建设的，比如说自动化平台和监控平台。还有一部分是架构和服务的PaaS平台部分，其实是对线上服务的平台支撑。
服务透明，也有两种服务透明。第一种服务透明是运维提供服务给研发部门的时候，服务能不能做到透明性;第二种服务透明是线上的服务、底层的公共组件的服务提供给研发的时候，他能不能保证透明性。
数据驱动，所有做的工作，到底它目前的状态是什么样子的，通过数据来驱动。
运维三部曲
运维三部曲，一体两翼，第一个做标准化，第二个做服务化，第三个做无状态化。两翼，一个是工具化，一个是数据化平台。因为运维的工作一直是通过手工的方式，一定要通过工具化来提升效率，另外通过数据化来衡量剖析自己的价值，甚至说驱动。用流行一点的观点就是说数据化怎么去驱动DevOps，这是数据化运营里的重点描述。
运维的本质——可视化
其实当你所有业务的架构或者是服务的架构，甚至你内部的运维过程都一览无余在你的控制之下的时候，你会觉得这个东西就是可控的，你的质量会变得可控。比如我说所有的架构图不要靠人工去维护，因为我们都知道互联网的业务变化是非常快的，我们最后是用自动化的方法去发现业务拓扑，也不需要人工去维护。
论运维的五大正确姿势
- 敏感，让运维人员不要长期对着电脑，更多的去了解你的业务，和别人做的有什么不同，内在的规则有什么;
- 去权威，互联网的今天本来就没有中心节点，没有权威，只有好的经验学习，在结合自己业务的过程中，需要调整和改变;
- 觉知力，觉察和知道，感受你每天的变化，觉知身边他人的变化，不断的思考和总结，为明天的自己做好一切准备;
- 想象力，运维是个苦闷的工作，不和业务直接接触，丧失了对业务的敏感度，如果再不给自己加点想象力的话，到最后只能和机器作伴了;
- 不作，所有的不合作，不拒绝，不积极都是一种操蛋行为，浪费自己的时间，浪费他人的时间，大可不必。做点有意义的事情，多好，是吧。
#p#
DevOps的技术本质论
过去讲企业的三要素：人、流程、系统。我把它拓展和具体了。系统里面我就分了自动化+数据化以及线上的架构服务化;同时派生了一个组织和文化，我觉得这点非常重要，避免谈组织和文化，真的不是一个合格的DevOps组织。其实，DevOps最终要解决的目标是吞吐率和延时问题：内部服务的吞吐率和延时，线上服务的吞吐率和延时等等。
运维标准化
标准化和规范都是为了让人和系统更有效率和效力的做事。效率是速度、效力是结果。很多时候不做规范，开始做运维平台建设，到最后会失控，或者就变成了ssh的可视化封装。看似非常灵活，其实这种自由带来的结果就是行为不可控。老王也对标准化提炼了一些观点：
- 标准化没有边界。在你看到有问题的地方，都可以设定规范和标准化，但是要考虑在平台中如何实现，同时要权衡成本。
- 标准化以可运维性为目标。我们做这么多的标准化，不就是为了让大家一眼就能看得明白，基于它们构造的运维能力，人人可以对接。
- 标准化以简化运维平台建设为度量。除了早期的一些流程，对线上的所有标准化，都可以理解成是为了简化运维平台建设，这些规范必须沉淀到平台中，才能真正做到方便运维。
- 标准化是有层次的。硬件、OS、应用、协议…..
- 标准化意味着运维理解的精确度。可以自己体会一下，你不会觉得运维无事可做，或者就是提供服务器的。
公共化服务的目标
公共化服务的目标，可运维性到底是什么?分解成三个维度：
服务透明，这个与位置无关，保证API对外提供服务等，服务管理甚至是有统一的运维管理平台的维护的。
可管理性，一定要有一个可视化的管理职能、管理能力，确保一切都是可配置、场景化的。
自服务，不一定要限制这个平台构建后是服务于运维的，如持续性的平台，有时候甚至就可以交给研发用。这是自服务的能力，其实也是产品文化的要求。
总结：
我们应该在苦逼中寻求美感。体验改变之美，我们一直在做改变的事情，改变别人的事情，改变自己的事情。技术之美，我们有对各种技术的理解，全面去看运维，不一定要局限在某个点上，想象力、极致之美、全局之美……
