做者 ：陈正玮，来自台湾。目前是台湾 DevOps 社区组织者，也是《Effective DevOps》繁体中文版的译者，以及《DevOsp 三十六计》繁体中文版的审校者。 本文摘选于陈正玮于 3 月 13 日在 CodeHub#1 线上直播分享《DevOps 前世此生》，但愿借助这场分享可以带来一些 DevOps 的基本介绍、科普知识。git
直播回顾地址 ：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 的过程当中，你实践了哪些方法？又是如何实践的？oop
狭义的来看 DevOps，它彷佛只是为了解决研发和运维之间的冲突与协做问题，但若是咱们提高至广义的角度来看，广义的 DevOps 是将整个组织都包含在内，整个组织都应该共同为了“交付价值”而“持续改进”。
毕竟一间组织，不应如上图左侧这样一层压榨下一层部门，而应该是右侧的金字塔同样，每一个部门都同等重要，缺了一角这个金字塔的结构都有可能所以崩溃。
“DevOps is a human problem.”，DevOps 包含“人／文化”、“流程”及“技术／工具”三个层面，这些都一再提醒咱们除了关注企业内的“技术债”，也别忘了处理“文化债”。
要知道“人们并不抵制改变，他们抵制的是被改变。” 惟有形塑出良好的文化，才能为企业带来长远深邃的改变，才能让企业长久拥抱“持续改进”，持续地向用户“交付价值”。
最后的最后，再说一次别忘了“消除浪费，交付价值”，一块儿迈向这趟 DevOps 旅程吧！性能
号外：台湾 DevOps 社区将于今年 10 月举办 DevOpsDays Taipei 2019，目前正在征求讲师与议题，欢迎感兴趣的朋友投稿：devopsdays.tw/cfs 3d
| mPaaS 第一期线下沙龙 CodeDay#1 开放报名中： 版本控制
活动主题 ：移动端高性能架构演进与跨平台开发实践日志
本期邀请支付宝移动端技术专家，与你们面对面一同探讨在跨平台开发下的高可用、高性能架构演进与跨平台开发、动态化更新实践。
报名方式 ：点击「阅读原文」进入活动页进行报名；没法到现场的同窗可经过钉钉搜索群号“23124039”当即加入技术交流群，届时获取直播地址，并有机会与讲师在群内深度交流。
期待你的参与。
