作者：陈正玮，来自台湾。目前是台湾 DevOps 社区组织者，也是《Effective DevOps》繁体中文版的译者，以及《DevOsp 三十六计》繁体中文版的审校者。本文摘选于陈正玮于 3 月 13 日在 CodeHub#1 线上直播分享《DevOps 前世今生》，希望借助这场分享能够带来一些 DevOps 的基本介绍、科普知识。

直播回顾地址：http://t.cn/ExdGwn6

曾经有人说过这样的一句话，“IT Doesn't Matter.”，IT 似乎和水、电力一样变成一种基础设施、一种成本中心，除了提供基础资源之外，IT 似乎不再重要，不需再被人们特别拿来一提。但真的是如此吗？

事实上 IT 变得越来越重要，大家应该也听过这句话，软件正吃掉世界。这句话其实有更新版，软件正“持续地”吃掉世界！现在各式各样的企业，都正在转变成为一间软件公司、IT 公司。IT 及软件依然“持续地”在各个行业发挥它的影响力。

既然各个企业都在转变为软件公司，那就让我们从软件开发涉及的组织部门、团队来看一看。首先，你一定会有一个开发/研发部门，但只有研发部门是不够的，往前会有业务部门，再往前则是客户；往后会有运维部门，运维部门负责运维工作，让客户能顺畅地使用服务。

不过我们都知道，研发一个软件、产品，想要一帆风顺，一次就打中客户的心是很难的。毕竟，现在是一个高度竞争的时代，我们唯一确定的事情就是，市场总是充满着不确定性与变化的。

从客户这边，我们可以得知市场是快速变化的。这也会反映到业务本身，产品与业务需求同样快速变化。而常见的一个状况是“业务与研发”之间经常具有沟通、合作上的问题。

于是，敏捷（Agile）出现了，敏捷宣称能帮助研发“快速响应变化”，敏捷也帮助业务与研发之间，能拥有更良好的沟通协作。

当研发端敏捷之后，研发和运维之间又有另一个冲突发生。研发想要快速地响应变化，但对运维来说，他们会觉得每次发布新版本总是有一堆问题需要收拾善后，所以最好没事不要发布新版本，能够一直维持在一个安全且稳定的状态。

于是 DevOps 出现了，DevOps 解决了研发与运维之间的冲突，帮助企业解决了研发和运维之间的沟通与协作问题。

让我们换个方式说明，如果我们用软件开发流程来看，研发和运维只有在软件 release 的时候双方才会有互动与交集。

但真实状况却是这样的，两方其实根本是沟通互动不良的，就像中间有一道墙。而这道墙的产生，可能是因为组织规模日渐扩大、专业能力的分工、或前面提过的成本中心的观念等等造成的。

因此当研发这一端已经开始敏捷，能够迅速响应变化。

我们不禁想问两个问题，首先是“运维，有可能也敏捷起来吗？”

以及，阻碍了研发和运维的这道墙壁，是不是有可能打破它？

因为这面看不见的墙，就会发生这张图的状况：研发将软件交付之后就弃之不顾，但运维那边服务已经火烧起来了，房子都快烧光了，但是研发却说这和他们没关系，你们运维自己要处理好。

所以我们一定要想办法打破这道墙！而 DevOps 的出现，也正是告诉我们，这道ƒ墙必须被打破！

既然 DevOps 宣称能解决这两个问题，那么它究竟是何时出现的？关于 DevOps 的诞生，我们可以从几个历史事件来谈。首先是 2008 年的“Agile 2008 Conference”，在当时目前被人称为 DevOps 之父的 Patrick，在当年想要找人讨论“Agile Infrastructure”。这个历史事件的重大意义在于，这代表了在 2008 年，已经开始有人们关注我们前面提及的这两个问题“如何打破研发与运维的那道墙”和“如何让运维敏捷”。

接着的重要事件则是隔年 2009 O'Reilly Velocity 技术大会上，Flickr 发表了一个演讲，说明他们是如何做到一天部署 10 次。当然在 10 年后的现在，一天部署十次可能不是什么新鲜事，但在 2009 年，肯定是一件创举。而这场演讲现在也被人们公认为是世界首件 DevOps 成功案例。

由于前两个事件的缘故，DevOps 之父 Patrick 决定要举办一场名为 DevOpsDays 的活动，让大家一起好好的聊一聊这些话题。当然这场活动举办完毕之后，在互联网上的讨论也随之火热起来，人们开始在 Twitter 上讨论这场活动及相关的主题。然因为 Twitter 有字数限制，为了节省字数，他们就将 DevOpsDays 缩写为 DevOps，于是 DevOps 这个字正式出现在这个世界上。

除此之外，后续也陆续有更多人响应，持续地讨论 DevOps 相关主题，并且陆续有相关的书籍出版上市，像是大家都知道的《持续交付》与《凤凰项目》。

所以由历史来看，DevOps 确实是一场 IT、软件研发行业的转型运动，而且是一场由社区自主发起的运动。

但除了前面的这些历史事件之外，其实 DevOps 能火热起来，还有着更多原因。我个人认为这场运动的火热，它更像是一场天时、地利、人和的结果，它是由更多的东西累积而来的，不然不可能因为一场 DevOpsDays 就让全世界都跟着火热讨论。如我们回顾更多的历史，不可讳言的，随着敏捷开发诞生的各种重要观念、方法，推了 DevOps 一把。当然，各种优良的软件工程观念与方法，也推了 DevOps 一把，像是持续集成、持续交付…… 除了敏捷之外，看板方法、精益（Lean）对于 DevOps 也是非常重要的。甚至你可以从精益再往前追溯到 TOC 限制理论或 PDCA 戴明环。除了这些观念与实践方法之外，技术与工具的发展也同样重要。版本控制系统（例如：git）、虚拟化技术、容器化技术、组态配置管理工具、云端服务，这些技术也都同样推了 DevOps 一把。

所以真要说为何 DevOps 能够火热，其实是因为在 2009 年，已经有这么多历史宝藏的累积，这才令DevOps 能从 2009 年开始一飞冲天，火热起来！

前面说了这么多，我们中场休息一下，来个段子。我们说在一千个读者眼中，就有一千个哈姆雷特；同样地，如果你询问一千位 DevOps 专家，你可能会得到一千零一种相似但有些微差异的 DevOps 定义。

所以到底什么是 DevOps？它其实就是互联网上的一个标签，当年它只是人们为了在互联网上能够讨论 DevOpsDays 相关的内容，而透过 #devops 这个标签，将人与人、将研发和运维的两派人马串连再一起。但随着 DevOps 在互联网上越来越火热，于是各方人马，为了自己的目的（例如：做产品的想卖产品，社区的人想要更广大的推广它），于是大家开始为它添加了更多的定义。

既然 DevOps 难有一个标准的定义，因此这里我觉得，我们不妨换一个角度来谈一谈 DevOps 的内涵。让我们一起思考一个问题“一间企业要如何才能生存下去？”

这里提供一个答案，企业能否存活的关键在于“企业能为你的顾客及用户带来什么价值？”唯有能够持续地将价值交付给用户的企业，才能赢得市场，企业才能持续生存下去。按这个思路，我们很容易地能够理解，为何不论是研发或运维，企业的每个部门都必须具备能够响应变化的能力，这都是为了满足一个目标“交付价值”！

所以“价值”是非常重要的东西，那什么是价值呢？简单来说，就是我们想要的东西。价值可能是企业关注的“商业价值”与“用户价值”，亦可能是实际的资金、可能是市场占有率。对用户而言可能是你这个软件好不好用，操作起来用户体验好不好。价值可能是很多不同的东西，涉及不同的层面，但用简单一句话来说价值就是“我们想要的东西”。

因此我们可以说 DevOps 为我们解决了前述的两个问题，它帮助企业让研发和运维能成为一个高效率的团队，帮助企业能够交付价值给用户。也正是如此，我们即能理解为何谈到 DevOps，很多人在讨论的内容其实是敏捷、精益，因为敏捷与精益背后的价值观、精神，也正与“交付价值”息息相关。

故此，我们可以说“顺畅和高品质地交付有用的价值”，即“消除浪费”、“使价值交付最大化”，即是藏在 DevOps 背后最重要的一项价值观。这也就是为何在讨论 DevOps 时，不只谈论技术工具，也会谈到文化层面的议题；人们不只会谈论该使用哪种工具来达成持续集成，更会谈到何为良好的团队文化，如何让团队能拥有良好的协作能力与沟通能力。因为，似乎只要是能够帮助企业“顺畅和高品质地交付有用的价值”的任何主题，都可以被包含在 DevOps 之内。

谈完了 DevOps 的过去，接着让我们快速地看一下 DevOps 的现在，看看现在大家在谈到 DevOps 时，都在讨论什么。如果你随意的百度搜寻 DevOps 相关的图片，那么你很可能会搜寻到的是各式各样的“智能运维平台”、“自动化运维平台”这一类的内容。确实这些“平台”对于 DevOps 是重要的，而且当你彻底的解决研发和运维之间的协作问题、流程问题时，往往其中一项成果即是这一类的平台。

提到了流程，有些人在讨论 DevOps 时，会从组织工作流程的持续改进的角度切入。例如在《凤凰项目》和《DevOps 实践指南》中提到的三步工作法。这里就不详述三步工作法的内容，有兴趣的同学可以直接看看这两本经典好书。

另外，有些人会谈 CALMS（Culture、Automation、Lean、Measure 及 Sharing），或者更精简一点，只谈“文化”、“自动化”和“信息透明度”，在《Effective DevOps》这本书则是从“协作”、“亲和力”（Affinity）、“工具”及“扩展”（Scaling）切入讨论。

时间有限，这里我也用“自动化”、“信息透明度”和“文化”来介绍 DevOps。首先说明的是 Automation 自动化。

自动化，以结果而论，可以说就是让软件研发至运维流程中的各个环节能够“又短又快”，并为企业带来一些实质的益处，像是提升可靠性、减少人为错误、提升生产力、减少浪费……而在这背后，你会发现跟精益的精神是密切相关的。

谈到“自动化”，多半会提到另外三个词，分别是“持续集成”、“持续交付”和“持续部署”，但需要注意的是这三个词并非仅仅只包含着技术和工具，它们更是一种实践方法，也就是说并非架设了 Jenkins 就代表你已经导入或实践了“持续集成”或“持续交付”，更重要的是研发团队在工作的方法及流程，甚至在价值观上是否拥抱这些实践方法所包含的关键思维。

接着是“透明度”，或者应该说是“信息透明度”。包含 Monitor、Metrics、Analytics。

其实也可以换句话说，即是让数据（信息）说话。

以软件研发至运维整个流程来看，每一个环节都有许多值得被可视化、度量，提升其透明度的数据，DevOps 意味着我们要让这些数据（信息）说话，成为企业持续改进的依据。

因此透明度，包含许许多多层面，不仅是与用户相关的需求反馈、项目管理的状态、运维的各种数据及日志，甚至是每位员工拥有的专业知识都需要提升透明度，避免人员成为组织其中一项单点故障的原因。（如只有某位员工拥有某些特定的技能与知识，一旦该员工出了状况，也可能会造成组织无法顺利运作。）

最后，DevOps 是一种文化，DevOps 与文化很有关联。

文化，是由人与人所形成的。而 DevOps 之父同样也曾说过“DevOps is a human problem.”

因此我们不仅是要打破研发和运维之间的那道墙，我们更要让整个企业都拥抱一种名为 DevOps 的良好文化。

就如我们在前面 DevOps 历史提到的，在 2009 年 Flickr 即能做到一天部署十次，我们除了赞赏这件事之外，别忘了仔细看一下他们演讲的副标题“Dev and Ops Cooperation”。 “一天能够部署十次”是他们的成果，但要达成这件事的关键在于“让研发与运维能够协同合作”。由此看来，DevOps 确实是“human problem”，DevOps 确实和组织文化息息相关。

文化的形成需要组织从上到下的支持、由下到上共同的努力。DevOps 拥抱多种优良的文化，像是“鼓励创新”、“容许犯错”、“持续改善”、“接纳多元观点”、“当责”、“不究责”（对事不对人）……等。

如果你拥有一些企业经营管理的背景，那么你可能会发现，DevOps 拥抱的这些优良文化，并非是首次被提倡于企业界。其实在企管、企业经理人、航空或医疗行业中，他们亦早已提出类似的观点。所以这些优良文化，并非是一些空穴来风的东西，而是不同行业的专家们共同的看法与见解。

谈了这么多 DevOps 的内容，我们可以发现当人们在讨论 DevOps 时，其实包含了多种层面，我们可以从价值观、原则、方法、实践、工具、历史或运动各种层面来讨论 DevOps。

让我们再举一个范例，这张图是由 Gartner 提出的 DevOps Model。（这已经是旧版了，Gartner 有提出更新版本）你可以看见，Gartner 眼中的 DevOps 包含 Culture、Process、People 及 Technology 四个部分。这四个部分彼此相关联。

说明到此，相信各位都能理解到一件事，即是现今人们口中的 DevOps 其实是一个包含“人／文化”、“流程”及“技术／工具”的巨大议题！

最后，针对“工具”，特别要介绍一个不一样的观点，即是“工具是文化的加速器”。

DevOps 必然包含了技术与工具层面的议题，像是常见的 CI / CD 工具的技术选型，或 Monitor 工具的技术选型……等。但除了探讨工具实际运用的细节之外，我们别忘了“工具”是为谁提供“服务”、是谁在使用这些“工具”。因此，选用什么工具、工具该如何操作并不是工具最重要的关键重点，真正的重点在于“工具之于人们的价值”。如果你今天导入了 Jenkins，但团队内却没有人去使用它，那它便毫无价值，同理 Jenkins 可以替换成任何其他的工具、技术，甚至是实践方法，像是看板、Agile、GitLab、Jira、容器……，无论替换成什么，务必都要思考这一件事“工具之于人们的价值”。

别忘了，其实“工具与文化息息相关”！试着去思考一下康威定律与逆康威定律吧！

最后一个部分，我们来聊一聊 DevOps 的未来。

首先，SRE 将会是许多企业拥抱 DevOps 的一种实践方向。毕竟这可是有谷歌挂保证的，谷歌在《SRE》书中提到了 SRE 是他们实践 DevOps 的具体实践。这其中包含了技术及文化层面的实践。并且当企业持续改善，最终拥抱了 AIOps、自动化运维时，终究会遇到谷歌曾经面临的困境，于是很自然的企业亦会向着 SRE 的方向前进。

DevOps 的另一项未来发展，即是成为一种人人只要付费就能拥有的平台或服务，而目前各大云端供应商也都已经推出自家的 DevOps as a Service。如果花一点小钱就能迅速搭建好一个环境，帮助企业解决研发和运维之间协作流程的诸多问题，相信对于尚未开始导入 DevOps 的企业而言，应该是一个可以考虑的选项。当然，还是要再次提醒，你并不会因为导入了一套工具、平台或 DevOps as a Service 就能声称企业已经成功导入 DevOps，工具的架设与导入只是开始。

DevOps 将会成为一种“认证”与“标准”。对于期望拥抱 DevOps 的企业而言，认证与标准可以成为一项助力，因为在面对 DevOps 所涉及的如此广大范围的内容，我们很容易因此迷失方向。但认证与标准，则能为我们提供一份指南，成为我们的道标，让你有迹可循开始你的 DevOps 旅程。但同样的亦要提醒，“What you measure is what you get.”，认证与标准应该要成为你的助力，而不要倒果为因，为了认证而去认证，为了标准而去迎合标准。

最后，DevOps 恐怕将会消失，或同化在每个企业的基因当中。就像先前一项研究调查，现今国外的软件研发公司绝大多数皆已经拥抱敏捷（Agile），敏捷似乎已经逐渐成为一种习以为常的标准作法。同样的，DevOps 亦有往此发展的趋势，已有越来越多的企业主动拥抱 DevOps。

今晚谈了非常多的内容，最后快速做个回顾。

如前面的段子，一千个 DevOps 专家，会有一千零一种 DevOps 定义，如今 DevOps 的标准定义已经不是人们讨论的重点了。

现在大家在谈的都是实战经验，到底在提升企业的生产力、打造高效企业、提升企业交付价值的能力上，你做了些什么？在你宣称导入 DevOps 的过程中，你实践了哪些方法？又是如何实践的？

狭义的来看 DevOps，它似乎只是为了解决研发和运维之间的冲突与协作问题，但如果我们提升至广义的角度来看，广义的 DevOps 是将整个组织都包含在内，整个组织都应该共同为了“交付价值”而“持续改进”。

毕竟一间组织，不该如上图左侧这样一层压榨下一层部门，而应该是右侧的金字塔一样，每个部门都同等重要，缺了一角这个金字塔的结构都有可能因此崩溃。

“DevOps is a human problem.”，DevOps 包含“人／文化”、“流程”及“技术／工具”三个层面，这些都一再提醒我们除了关注企业内的“技术债”，也别忘了处理“文化债”。

要知道“人们并不抵制改变，他们抵制的是被改变。” 唯有形塑出良好的文化，才能为企业带来长远深邃的改变，才能让企业长久拥抱“持续改进”，持续地向用户“交付价值”。

最后的最后，再说一次别忘了“消除浪费，交付价值”，一起迈向这趟 DevOps 旅程吧！

号外：台湾 DevOps 社区将于今年 10 月举办 DevOpsDays Taipei 2019，目前正在征求讲师与议题，欢迎感兴趣的朋友投稿：https://devopsdays.tw/cfs

| mPaaS 第一期线下沙龙 CodeDay#1 开放报名中：

活动主题：移动端高性能架构演进与跨平台开发实践

本期邀请支付宝移动端技术专家，与大家面对面一同探讨在跨平台开发下的高可用、高性能架构演进与跨平台开发、动态化更新实践。
报名方式：点击「阅读原文」进入活动页进行报名；无法到现场的同学可通过钉钉搜索群号“23124039”立即加入技术交流群，届时获取直播地址，并有机会与讲师在群内深度交流。

期待你的参与。