[转载] 运维的美丽新世界

在7.25号广州威斯汀酒店举行的一场DevOps运维交流分享会，从上午9点30开始，一直到下午5点30结束。期间给大家带来了三个分享主题，分别是腾讯T4级的数据库专家Robin(tencentdba.com）的【仓管员团队的发展自白】、KVM虚拟化的专家肖力（微信号：kvm_virt）【虚拟化运维项目实践】，还有一个就是老王【我的互联网运维理论与实践】，每个主题都1.5个小时，从来没见过这么长的，觉得很爽。在此也非常感谢Ucloud的精心组织和安排~超级感谢来参加分享会的300多名听众们，谢谢，辛苦了！

有人问我这次你的演讲PPT为什么这么长？105页。我说我真的是认真的，否则对不起大家；另外我这次分享就是想带大家看一下运维全貌，运维能做什么，能做成什么样，不谈如何做【很多在我微信号里面提到了】。其实我开始设定的主题叫【我来UC做运维干的8件事】，写着写着，发现有很多东西可以总结，等150多页写完，把自己也感动了。而接下来带给自己的也是痛苦，后面好不容易缩减到100页。

首先分享下我本次PPT的整体思路：

• 【运维的美丽新世界】。从行业和自身的运维工作角度分析，呈现给大家一片运维的广阔天地，目的是让大家认识到运维的方向以及在自己的运维岗位上，运维到底能做什么。

• 【运维的实践***】。最终还是要落地，因此我给分解了多个主题，每个主题部分都有阐述思路、建设经验、系统呈现、最后给了一个经验总结。

很多人都在讲革运维的命，其实我想说，自己革自己的命，是勇气是智慧；别人来革我们的命，说明我们落后。而我一直在思考，如何不让别人革我的命，所以一直带着危机感在工作。也一直给自己内心一个声音“今天的我和昨天的我有什么不同，我到底做了什么让自己不同”，一直到现在。在这个不断思考的过程中，呈现这些PPT内容便是自然。在此我把其中一些重要的观点拿出来，再次和大家分享一下。

备注：运维的发展是有阶段的，每一个阶段是和运维的认识有很大的关系。职能化的阶段，基本上就是维护的代名词。服务化是ITIL下的产物；价值化，是运维把自己的能力逐渐转向，面向用户；产品化，已经是在行业级别上进一步抽象，特别是带着互联网行业的最佳实践开始做产品化的抽象，它是运维的终极蜕变。在这个里面没有提智能化运维和云运维，我自己还没有深刻的想清楚他们的产品形态到底是什么样的，如果是SAAS化算是云运维的一种形态的话，云运维我便可以接受些。但是对于智能化运维，我始终不知道他的内涵是什么，想不出它的内在实质，也便没有存在的意义。

备注：运维是可以从多个角度来解读的，ITIL可以说是传统的一种经典解读。基于ITIL的ITSM理念，诞生了很多产品，比如说IBM、BMC、CA等等。然后从国内的实践来说，成功着很少，核心的原因是因为ITIL基于流程化的IT服务交付，在互联网业务敏捷要求的今天，流程只是给了一个规范指导，而没法完成快速交付。建议阅读【IT服务管理--基于ITIL的全球最佳实践】

观点：现在DevOps大行其道，火得不行。不过我想说的是，大家首先要意识到DevOps不是一个技术的问题，因此不要具象，它是一个文化、价值观、思维和平台组成的体系。这个体系需要研发、测试、运维和产品等多个团队的融合，而不是运维来独自构建的。所谓不要具象，千万别以为puppet、salt或者持续集成就是DevOps，他们只不过表现出技术的驱动力，更是要看到这些工具实施成功的背后影响因素。推荐大家阅读【持续集成--降低软件的风险之道】【持续交付--发布可靠软件的系统方法】。

备注：基于IT技术运营的运维理解，可以看到运维体系就更大了，里面涉及到ITIL，也涉及到DevOps，也涉及到APM。大家可以根据这个目录不断的去索引，比如说【IT service view CMDB】，看看这个产品到底背后的理念是什么，和我们平时理解的CMDB有什么不同，这个是打开运维思路的绝佳方法，同时你再也不会觉得运维要做的事情很少。这个也是运维和研发价值差别最大的地方，你可以找到很多的运维方向点。真正的ITOM，是覆盖了传统的ITSM理解（必须产品化），同时要结合ITOAutomation（DevOps）和ITOAnalytics（运维分析）等等。

备注：真正的运维是要往产品化的方向去走。我们自己研发的运维平台中，他的产品化的能力到底怎么样？独立部署的能力如何？能满足的是一个运维团队的需求还是多个？是否考虑到多个角色在平台中的场景？等等。这种产品化可以不断思考，从运维、公司直到行业的角度去看自己做的东西。行业的角度怎么看？多用google搜索一下别人怎么做的，多看点国外的书？做持续集成，不看刚刚提到的两本书，我觉得最终呈现出来的产品形态就是一个工具。

备注：运维风口已经打开了，从IT到"I"T。前面的I是指Information，后面的I代表Internet。

• 危机驱动下的运维机会，一则是我们的危机，另外是别人的危机。我们的危机是让我们不断做得比别人更好，别人的危机更多是目前互联网倒逼传统企业，给他们带来的危机，难道这不是我们的机会么？

• 成本驱动下的运维机会。企业的人力成本越来越高，此时更需要运维的产品化，更需要技术全栈的运维解决方案等等。

• 转型驱动下的运维机会。互联网+驱动下的企业升级，云+技术的需求会越来越明显。运维可以带着对技术的全栈理解而来，优势很大。

• 细分驱动下的运维机会。在不同的技术价值链条上，未来垂直化的服务分工会越来越明显，这有点和语言的发展阶段相似，早期的编译，后面的过程，再到后面的面向对象，越来越接近人的理解，而非机器。而我认为，未来的垂直服务提供越来越接近业务的理解。

备注：

• 敏感，让运维人员不要长期对着电脑，更多的去了解你的业务，和别人做的有什么不同，内在的规则有什么；

• 去权威，互联网的今天本来就没有中心节点，没有权威，只有好的经验学习，在结合自己业务的过程中，需要调整和改变；

• 觉知力，觉察和知道，感受你每天的变化，觉知身边他人的变化，不断的思考和总结，为明天的自己做好一切准备；

• 想象力，运维是个苦闷的工作，不和业务直接接触，丧失了对业务的敏感度，如果再不给自己加点想象力的话，到最后只能和机器作伴了；

• 不操蛋，所有的不合作，不拒绝，不积极都是一种操蛋行为，浪费自己的时间，浪费他人的时间，大可不必。做点有意义的事情，多好，是吧。

备注：强调过很多次了，再强调一下吧，天天对开发讲“运维友好”，运维也要讲“开发友好”，作用力要相互起来。这样才能达成真正的DevOps，不要搞得到最后感觉大家要对你运维服务似的。

备注：这个PPT是纠正一个观点，过去讲企业的三要素：人、流程、系统。我把它拓展和具体了。系统里面我就分了自动化+数据化以及线上的架构服务化；同时派生了一个组织和文化，我觉得这点非常重要，避免谈组织和文化，真的不是一个合格的DevOps组织。DevOps最终要解决的目标是吞吐率和延时问题：内部服务的吞吐率和延时，线上服务的吞吐率和延时等等。

备注：这个很好理解，互联网业务的通用技术架构大部分都是这样。

备注：在上面的架构图中，在每一块的服务选型都容易造成失控，这种失控带来就是运维失控（运维苦逼的一个主要原因）。失控的主要原因，开发组的任意选型，没有在小组之间共享架构能力。多组件的选型，让运维能力没法及时跟上，因此就有很多潜在的风险，甚至是出问题没法及时解决（故障延时增大）。

备注：从统计学的角度，进一步阐释架构失控带来的可用性下降。其实这个只是告诉大家【服务公共化】多么的重要。

我还是想强调，我们运维人一定要有一个【完整的运维图景】植入在我们的心中，矢志不改的为之努力，让我们用自己的勇气和智慧来革自己的命，而不是别人！

点击【阅读原文】可以下载我这次分享的PPT，供大家交流使用！更多内容，请大家等组织方Ucloud的整理，后面我再转发给大家。

对于PPT中的一些观点，我后续有机会会独立成篇和大家深入探讨。另外欢迎广深地区有运维研发经验的同学联系我哈，【我在阿里UC和**，你在哪儿】。