DevOps随便谈谈

这是去年应一个同事随手写的，记在这边吧。有些考虑不是很成熟，不过就当是过去的笔记吧。

缘起：

最近好像经常遇到人问我，希望让我给推荐一个DevOps平台，这个问题很不好回答，这跟你选一个开发语言或者开发框架有很大的不同。但是为什么大家会有这种需求呢？这就要从DevOps是什么开始说起。

什么是DevOps？

Wiki上的定义：DevOps（Development和Operations的组合词）是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。
DevOps的核心思想
DevOps的核心思想被实例化为CALMS，即：文化Culture,自动化 Automation,精益 Lean，度量Metrics, 分享Sharing。而谈到DevOps就不得不提到一本著名的小说《凤凰项目》，真是的是小说，以及从《凤凰项目》里脱颖而出的著名的三步工作法The Three Ways 。

CALMS:

• Culture – 文化：公司各个角色一起担当业务变化，实现有效协作和沟通；
• Automation – 自动化：在价值链中尽量除去手工步骤；
• Lean – 精益：运用精益原则更频繁地交付价值；
• Metrics – 度量：度量并使用数据来优化交付周期；
• Sharing – 分享：分享成功和失败的经验来相互学习。

The Three Ways:

• The First Way： System Thinking （系统思考：强调全局优化，避免局部优化）；
• The Second Way： Amplify Feedback Loops （经过放大的反馈回路：创建从开发过程下游至上游的反馈环）；
• The Third Way： Culture of Continual Experimentation And Learning（持续做试验和学习的文化：持续做试验，承担风险、从失败中学习；通过反复实践来达到精通。

为什么会有DevOps呢？

先讲一个小故事，之前和一个朋友聊关于DevOps的课程应该怎么设计和讲解，提到了一个问题，教DevOps应该从何入手，学生来听课学完之后应该学会什么？近期国内的DevOps培训、活动、技术大会、沙龙如雨后春笋般遍地开花、也是随着容器技术的飞速发展，瞬间DevOps成了炙手可热的东西，好像全世界都突然DevOps起来了，而我的朋友却提出了一个观点，说根本没有什么开发和运维，这一切都是开发，或者说不存在Dev和Ops，只有Dev，刚开始我听到这个说法的时候也是觉得非常奇怪么，甚至提出了直接的有力反驳证据，存储工程师肯定不是开发吧？但是他解释给我说，我当然知道运维的存在，知识这一切在我看来，本来就是一体的。原来，他在软件行业发展的初期就进入了这个行业，一个人从事了大量的独立项目，也就是在每个项目里都是一个人完成所有角色的工作，所以在他看来我们谈到的Dev和Ops的工作都是后期人为分开的，也就是从来不存在什么Dev和Ops，只有Dev，只是有些Dev的工作因为分工的关系逐步划分出去了，这些工作现在被我们称之为Ops。其实我之前也从事过一些比较小规模的现场开发工作，发布周期很快，从新需求收集到功能上线平均在1周内半完成。在这个过程中所有的工作都是由开发人员完成的，没有任何其他运维人员参与，因此这个项目中的开发人员完全了解关于本项目中所有的实施过程，也就不需要再去找相关的运维人员核实部署环境的操作系统、数据库、网络、存储、中间件等各方面的问题，所有遇到的各类问题都由开发人员独立解决，跟我们现在玩DevOps提到的谁开发谁负责安全部署上线一样。如果我们基于开发人员对所有事情负责的假设，那真的自然就没有DevOps什么事了。
那么现在大家关注的DevOps问题又是什么呢？和我上面的故事有什么关联和区别呢？下面我们来仔细探讨一下。也希望通过下面的分析来呈现出DevOps文化的整个全景给大家。
首先希望澄清一个问题，DevOps是一个文化或运动，DevOps就不是一个固定的答案用来回答固定问题，它是一种潮流或趋势，也就是说不能说我要DevOps你给我来一套。就好像企业文化，他不是别人能强加给你或者直接指导给你学习的，虽然不同的企业都有一些好的企业文化、以及推行企业文化的最佳实践，但是这都无法成为你自己的企业文化，就算你全盘借鉴回来也会有不适的问题、都要本地化，经过借鉴学习改良、或者完全脱生于内部形成自己的文化。

如何落地DevOps

那么DevOps该如何实施呢？毕竟它不是云上的彩虹，肯定是可以落地来做点什么的。从概念定义的角度来看，它应该是沟通合作、透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快速、频繁和可靠。也就是说以快速、频密、可靠交付为目标的一种改进过程的文化。仅从这个角度来看，就不能把自己限定到别人的DevOps实践、平台的流程里思考问题，而是要站在自己的泥坑里，看看怎样才能快速、频繁和可靠的交付服务或产品。既然目标有了那么就可以开始分析问题了，在今年沈阳园区举办过一次；DevOps沙龙活动，当时我给大家提出了一个问题，我觉得很适合对于所有希望进行DevOps学习和改善的团队思考

你的项目修改一行代码、到完成交付需要多久？

简单解释一下就是目前的一个新需求只需要你的项目修改一行代码，那从得到新需求到新需求上线需要多久的时间呢？我们可以结合自己的项目具体的一个环节一个环节的分析一下。这个问题的答案往往就反映出你DevOps的程度。如果你只需要几分钟甚至几秒钟，那么恭喜你，但是如果你需要几天几十天，甚至按月来计算的话，那很好，你真的需要了解一下DevOps，并逐步实践一下。

这也就是为什么这篇文章我不会去谈DevOps流行的各类技术，DevOps工具链、DevOps最佳实践等问题，那些都是我们现在流行讲的道法术器势中的术和器，即实现目标的具体措施和工具。而我们面临的问题不是工具可以解决的，需要先从上而下的分析、了解，知其然，还要知其所以然。也就是当我们真正的找到自己的问题，产生问题的原因之后，从改变人们的思维着手，而不是上来就先抛出微服务这种大杀器，直接说用了微服务你就是DevOps的。还是前面的问题，分析从需求到发布这个整个过程每个环节发生了什么，有哪些过程、人或事、做了哪些实施、开发或具体步骤，最终得到了一个结果，反应你当前的实际情况，然后再开始考虑每个环节可以优化么，优化会变的快么，如果快了如何保证可靠呢？这个过程可以自动化么？直到分析完每一个步骤和过程再实际进行改善优化、在这个过程中你开始发现需要引入新的技术或工具，开始比较不同的工具、技术的优势劣势、局限性、主要缺点、明显优势，等细节，比对分析，选择合适的一款引入进来，解决一个问题，然后进行下一个，逐步迭代。那我们的终点在哪里呢？

改善：持续改善，也许这就是答案。