02 | DevOps的价值：数字化转型时代，DevOps是必选项？
讲述：石雪峰
时长11:27大小10.49M
你好，我是石雪峰。今天我们来聊聊 DevOps 的价值。
前段时间，因为工作的缘故，我参访了一家在国内数一数二的金融企业。在跟他们科技处的同事交流的过程中，有一件事情让我非常吃惊，想跟大家分享一下。
虽然在一般人眼中，这家企业是典型的传统企业，但他们的绩效目标采用的却是OKR 模式。
我简单介绍一下 OKR。OKR 也就是目标与关键成果法，是在硅谷互联网公司很流行的绩效制定方法。简单来说，O 代表目标，也就是我们要做什么，KR 代表关键结果，用于验证我们是否已经达到了目标。
这家金融企业的大老板，也就是科技处的老大，给全体员工制定的众多 OKR 中，有且只有一条属于愿景指标。说出来你可能不相信，这个愿景指标就是，到今年年底，让 DevOps 在全行的三个试点项目中成功落地。
而且，这并不是简单的说说而已，如果最终达成了这个愿景指标，所有员工的年终奖将在原有的基础上上浮 10%～20%。由此可见，关于实施 DevOps，他们是在玩真的了。
全行的核心系统改造都没能成为愿景指标，那为啥 DevOps 会有如此大的魔力，让大老板都为之着迷，并且成为愿望清单列表中的第一名呢？这就是我今天要跟大家讨论的话题：DevOps 的价值以及它对现代企业的意义。
如果要选一个近年来在各大企业战略中曝光率最高的关键词，数字化转型绝对是排名最高的，没有之一。
比如，传统汽车巨头大众公司今年宣布启动全面数字化转型，计划到 2023 年年底投资约 40 亿美元，实现管理和生产的数字化。而且，预计到 2025 年，大众集团的软件研发的比例将从目前的不到 10% 增长到 60%。
为什么软件如此重要？
对于软件从业人员来说，这绝对是令人欢欣鼓舞的事情。同时，这也再一次印证了那句流传已久的名言，每一家公司都将成为软件公司。那么问题来了，在数字化转型时代，为什么软件会如此重要呢？
互联网的普及和移动通讯技术的发展所带来的移动互动网的兴起，深刻地影响了我们每个人的生活方式。
举个最简单的例子，几年前如果我们要办理银行业务，我们首先要找到附近的营业厅，抽空跑过去排号，经过很长时间的等待，才能坐到柜台前，同银行的柜员面对面地完成业务办理。当然这还是在顺利的情况下，如果忘记带证件或者排队人太多，可能还要再跑一次，办事成本相当高。
现在呢，大多数情况下，我们只要掏出手机，打开银行的 APP，点击几下屏幕，业务就办好了，完全不用受时间和空间的限制。用户对银行服务的体验直接来源于手机应用本身。如果哪家银行的应用界面很丑，操作还总是出现各种问题，就会直接影响用户对这家银行的印象，甚至会在潜意识里觉得这家银行不靠谱。显然，没有任何一家银行愿意给人留下这样的印象。
所以，软件慢慢从企业内部的支撑系统和成本中心，变成了企业服务的直接载体和利润中心。企业通过软件降低运营成本，提升服务水平，而用户在获得便利的同时，也加强了同企业之间的联系。
这本是一件双赢的事情，可问题是，我们所身处的是一个VUCA的时代，VUCA 是指易变性（Volatility）、不确定性（Uncertainty）、复杂性（Complexity）和模糊性（Ambiguity），它代表了这个时代的典型特征。比如共享单车这个行业从冉冉兴起炙手可热，到逐渐归于平静，前后不过短短几年的时间。
企业能快速满足用户的需求，在行业大势之下灵活转身，在跨界打击越发普遍的情况下脱颖而出，已经不仅仅是 good to have 的能力，而是 must have 的能力。
可以说，软件交付的效率和质量成了当今企业的核心价值和核心竞争力，所以，任何一家企业，无论是行业巨头还是初创公司，无论是互联网行业还是传统行业，无论是领先者还是颠覆者，都有强烈的意愿去改善自身的软件交付能力，而这恰恰和 DevOps 的理念和诞生背景不谋而合。这么看来，DevOps 能够成为企业愿望清单中的第一名也就不足为奇了吧。
可是，即便软件如此重要，却依然有很多公司在用一种手工作坊的方式开发软件，引用国家智库的某位领导的话来说，“工业革命消灭了绝大多数的手工业群体，却催生了程序员这个现存最大的手工业群体”。这句话看似危言耸听，但这种开发软件的方式的确存在，其中伴随着大量的效率浪费。企业内部的软件开发交付效率已经成了一座值得探索挖掘的金矿，效率经济可能成为新的业绩增长点。
DevOps 的价值
那么，实施 DevOps 带给企业的价值究竟是什么呢？要回答这个问题，我们就不得不提到 DevOps 业内非常著名的现状调查报告了。
高效的软件交付方式
从 2014 年至今，这个报告每年都会发布一份，由业内大咖和行业领袖基于科学的分析方法，通过大量的数据分析得出，可以说是业内最具权威性的报告，其中的很多数据和理念都被广为传播。我发现，在这洋洋洒洒大几十页的报告中，被引用频率或者说出镜率最高的，就是 DevOps 的 4 个结果指标。
- 部署频率：指应用和服务向生产环境部署代码的频率。
- 变更前置时间：指代码从提交到成功运行在生产环境的时长。
- 服务恢复时间：指线上应用和服务出现故障到恢复运行的时长。
- 变更失败率：指应用和服务在生产环境部署失败或者部署后导致服务降级的比例。
每年，这个报告都会基于这 4 个核心指标统计行业内高效能团队和低效能团队之间的差距。从去年的数据来看，与低效能团队相比，高效能团队的部署频率高了 46 倍，变更前置时间快了 2500 多倍，服务恢复时间也快了 2600 多倍，失败率低了 7 倍。
我们先不管这份数据是怎么计算出来的，当你第一次看到这个数据的时候，它带给你的冲击是不是很强大呢？用具体的数字形式来呈现企业之间效率的差距，是很有震撼力的。
而世界上最令人“绝望”的事情，就是那些比你优秀的人，实际上比你还要更加努力。当你仔细查看这份报告的时候，你会发现，那些常年被人提及的明星公司，很多都在践行 DevOps，甚至很多来源于这些公司的实践案例，都成为了 DevOps 行业的经典案例。
另一方面，DevOps 状态报告中提到的四项结果指标，分别代表了软件交付的两个最重要的方面，也就是交付效率和交付质量。而且，从数据结果中，我们还能得到一个惊人的发现，那就是高效能的组织不仅做到了高效率，还实现了高质量，由此可见，鱼与熊掌可以兼得。
可是，这就颠覆了很多人心目中的“慢工出细活”的传统软件开发理念。因为按照传统软件开发的 V 模式来说，软件开发完成后，需要经过单元测试、集成测试、系统测试和验收测试等层层关卡，以此来保证软件的质量符合预期。但是，对于现代软件开发而言，如此重的流程和管控显然有点跟不上时代的节奏。
我们在不断提高软件交付效率时，往往是以牺牲质量为代价的，结果做得越多，错得越多，从而陷入进退两难的境地。
DevOps 却反其道而行之，它试图通过体系化的研发实践导入、软件架构的整体革新、组织管理理念的不断升级和企业文化的影响塑造，来帮助企业改善整个软件交付过程，在实现高吞吐量的同时保证服务的总体稳定性，从而真正实现又快又好的软件交付目标。
激发团队的创造力
我们刚刚谈到的这些内容，当然是 DevOps 带给企业的重要价值，但并非全部。在专栏中，我不仅希望能跟你分享知识，还希望能跟你分享一些不同的观点，我们一起思考和讨论，获取灵感和新知。
之前，我在跟 Jenkins 创始人 KK 聊天的时候，他提出过这样一个问题：熟悉云计算的同学可能或多或少地了解过容器编排领域的事实标准 Kubernetes 以及它背后的 CNCF 基金会，那么，企业为什么热衷于加入这样的基金会呢？即使要付出一笔不菲的费用也在所不惜，企业这么做的收益究竟是什么？
不可否认，CNCF 是一个非常成功的运营案例，成为会员还能享受白纸黑字上的福利，但是，对于很多中小企业而言，他们的诉求可能不止如此。
很多时候，企业加入这样的组织，也是为了向内部员工表态，我们正和世界上最著名的公司站在同一条起跑线上，关注着同样的问题。这对他们的员工来说，既能起到激励作用，也能增强对企业自身的信心。
对于 DevOps 而言，道理也是同样的，因为说到底，企业的问题都是人的问题，最核心的价值最终都会归结到人身上，所以，单纯关注软件交付的能力而忽视人的感受，结果往往都是片面的。
在企业内部建设 DevOps 工具平台的时候，我也经常在思考这个问题，我们费尽心思通过平台能力建设提升了 5% 的交付效率，即便节省下来的时间只是让员工多休息了一会儿，也是非常有意义的事情。因为DevOps 本身也包含了改善软件从业人员的生存状态，提升他们的幸福水平的理念。
这么看来，实施 DevOps，一方面可以通过种种流程优化和自动化能力，改善软件开发团队的工作节奏，另一方面，也可以让大家关注同一个目标，彼此信任，高效协作，调动员工的积极性和创新能力，从而让整个团队进入一种积极创造价值的状态，而这所带来的影响远非建设一两个工具平台可比拟的。
总结
DevOps 作为软件工程的第三次革命，在数字化转型的大潮之下，几乎成了所有通过交付软件来提供服务的企业的必选项。因为，DevOps 不仅可以改善企业的软件交付过程，实现高质量和高效率兼得，同时也可以持续改善企业内部的工程师文化，提升员工信心，激发员工的活力和价值创造，从而帮助企业在 VUCA 时代占得先机，获得更大的成功。如果一家企业真的可以通过 DevOps 落地达到以上目标，而只需要多付出 10%～20% 的年终奖，岂不是大大赚到了吗？
思考题
最后，给你留一个思考题：如果你觉得 DevOps 可以解决公司现有的问题，想要跟领导申请立项的话，你会如何说明 DevOps 的价值呢？
欢迎在留言区写下你的思考和答案，我们一起讨论，共同进步。如果你觉得这篇文章对你有所帮助，欢迎你把文章分享给你的朋友。
精选留言(23)
linda.zx 置顶2019-10-10老师，请问关于DevOps现状报告哪里可以看到完整版呢？作者回复: 你好，我整理了历年的报告分享给你哈，链接:https://pan.baidu.com/s/1W7-_et-wulD7AueBU2KTow 密码:mgl1
6
砖瓦工2019-10-10老师，“DevOps 作为软件工程的第三次革命”的出处是哪里？前两次革命是什么？作者回复: 你好，主要指的是软件开发模式的三次变迁，也就是从瀑布模式，到敏捷模式，再到DevOps模式，具体可以参考第一讲的内容哈
1 11
leslie2019-10-10老师在课程中提到的4个指标：我觉得其实更多的是对当期时代的Ops的要求吧，记得Google SRE提出过其实现代的Ops已经需要解决更多的问题，就像现在有AI Ops；做为从业多年的Ops其实一直在思考，传统Ops持续之路在何处？
这两年听到越来越多的Ops是最便宜最好找的甚至我觉得很多时候快接近90年代和20世纪初的网管了，可是Ops所承担的压力以及工作似乎完全不符；DevOps和AI Ops其实算是Ops的转型/升级吧？毕竟软件已经从过去的单机、发展到CS/BS模式、现在的分布式，Ops所承担工作已经完全不一样了。DevOps只是作为企业内部的一部分是不是有点弱化了价值？SRE中曾经提及其实其实DevOps其实还是一个Team存在：其实很多时候是OpsDev与DevOps组合值班，去解决问题；其实我觉得这是一种很好的探索吧。其实我现在是DBAOPS，不过由于Dev环节还是有些问题-在强化自己的Dev的基本能力，这样基本能完全把握问题在哪儿吧。
单纯的DevOps有些统称了：其实Ops不理解Dev是做不好Ops的；申请项目谈不上：设计项目和组织结构倒是在考虑，或许将来规模够大可以用，暂时只能一肩挑了。展开作者回复: 其实不知道你发现没有，这些指标并没有绑定到具体的角色，而是通用的结果指标，也就是通过这个指标度量的是整个交付团队的能力，而并非其中的某一个具体角色，比如举个例子，MTTR平均故障修复时长，拆解开来其实包含了MTT，MTTK，MTTF，MTTV，也就是识别，定位，修复和验证四个部分，这既包含了传统运维的监控能力，线上故障定位能力，通过异常诊断定位代码的能力，研发快速修复活回滚的能力，以及整条交付流水线的能力，快速发布上线的能力，所以是个全局考查的指标，每一个环节的实践都有可能会影响这个结果哈。
至于运维无用论，我觉得都不需要讨论了，我建议你看下萧帮主的文章哈😄 2 6
阿西吧2019-10-10DevOps 有什么致命的缺点吗？毕竟没有银弹啊展开作者回复: 致命的问题就是难以真正落地呀，需要长期的团队磨合和能力建设。我见过一些公司希望在三个月内实现DevOps，这显然是不太现实的。
其实不说DevOps了，就连持续集成能真正做到位都不容易，更不要说文化的建设啦。 5
Wesley2019-10-10《软件观念革命—交互设计精髓》，该书提到软件开发领域的三次革命：
1. 高级语言 20世纪50年代，使软件开发从机器语言的束缚中解放出来。
2. 软件工程 20世纪70年代，使软件开发的注意力从语言拓展到开发过程。
3. 人机交互 20世纪90年代，人机交互理论改变了一般商用软件的设计开发流程和方式展开作者回复: 很赞，又帮助大家拓展了知识面👍
5
delly2019-10-10我所在的运维团队把自己一整套运维流程做成了DevOps：通过配置管理工具（chef）把需要手工配置的项目代码化，然后通过gitlab管理代码项目，jenkins实现持续集成持续部署，几乎所有以前需要手工配置的东西都变成了几行代码。同时也为app部署提供了更快捷的通道。配合三活的基础架构，部署以及变更也可以做到随叫随做，至少头天要求第二天做。
对团队整体来说算是极大地解放了双手和工作效率，对个人来说喜忧参半。。。因为我们这种大厂的运维团队，职能分的很细，有一部分人是负责客户沟通和应用的（现在都去开发配置代码了，开发完无论是一台server还是一万台都可以随时部署），另一部分负责具体干活的（部署，照手册配置），那目前的状况对第二部分人来说就比较惨了，无事可做，就必须要找到其他出路。人家说的DevOps干掉运维干掉的就是我们的这一部分人。展开作者回复: 你的回复让我感受特别深，单个个体在大的浪潮之下真的是势单力薄，所以有种说法是浪费创造价值，因为如果真的按照效率最优化的方式进行，那么将有大量现有的工种被淘汰。但是换个角度，几年前做配置管理的同学也在焦虑，现在软件开发越来越轻量级，工具平台越来越成熟，那么是不是配管的工作都可以被一个按钮取代呢，所以当时大家也在探讨转型道路。几年后的今天，我发现其实很多配管都转型做了DevOps或者产品经理，一方面是时代变革会带来新的岗位和机遇，另外一方面个人能力的持续积累也将这种抵抗变化的能力不断加强。所以，核心四个字，找准方向，先干再说！
4
Bryan Bai2019-10-10我的经验DevOps要走草根线路，从小组的单一功能的试运行，创造明星团队，逐步获得其他部门和老板信任，增加更多功能，并加入更多团队。由各个部门分摊成本。作者回复: 老板的信任很重要，其实对于老板来说，他也希望自己的团队能够更加高效，但是老板能做的就是认可和提供资源，真正做出成绩还得靠你所说的试点团队，当在局部产生效果后，老板也会更加有信心追加投入嘛。
3
Joseph.Kim2019-10-11你好，这个devops报告是哪个报告展开作者回复: 你好，我收集的历年报告分享给你哈
链接:https://pan.baidu.com/s/1W7-_et-wulD7AueBU2KTow 密码:mgl1 2
牧野静风2019-10-10希望老师后续重点讲下如何落地DevOps展开作者回复: 你好，感谢你的留言。
第一部分重点还是理论基础，建立对于DevOps的明确认识，这一部分尽量精简，重点会放在第二部分落地实践里面。
当然，各个企业所面对的业务形态都不尽相同，也欢迎你提出关心的问题，我们共同讨论。 2- kirajun2019-10-12老师好，如何说服公司经营层推行 DevOps 呢？如果只是 DevOps 的 4 个结果指标，在经营层面似乎不太关心，研发内部的质量和效率改进，如何更好的有外部价值体现？
作者回复: 你这句话说的太深刻啦，也抓住了核心，思考到位，给你点赞👍
回到问题本身，研发效率质量指标和经营业务指标的关联，从而证明效率提升有助于业务提升，这是一个巨大的难题。现在更多的还是说交付需求变快啦，吞吐率提升了，业务方更加满意了，但是，这个需求交付了，对公司的业绩有什么影响，这更多的是业务分析的事情。
我们公司最近也在摸索这个事情，也建立了一些模型，理论上来说，随着大数据，线上追踪，加上各类埋点监控等的成熟，以及综合用户反馈用户性能等多个指标，是有条件追溯全链路的业务价值的，但是说实话比较难。
你的这个问题，我作为遗留事项，最近也跟更多的行业公司交流探讨，希望在度量实践的章节给出一个比较好的实施方法来！ 1 1 
老王的老李头2019-10-12我会把老师的专栏背熟，让后直接去说服他。展开作者回复: 哈，那不如不经意间地分享给他😄
1
iiiqueena2019-10-11归根结底还是提高“人效”。从人、流程、工具出发实现这个目标，落地过程中由文化引导，的确是很困难的事情。尤其是人的本性是安于现状或恐惧改变带来的不利因素，但当他们看到改变带来的好处时，应该也是忧喜参半（喜的是效率提高，忧的是多出来的劳动力应该转向哪里？）。如果再往前想一些，当技术可以极大地提高生产力时，那核心是不是就是业务能力？展开作者回复: 非常精妙的留言，必须赞一个👍
我很认同人，流程，平台三位一体的改进，才能有效，否则你能改变的将非常有限，尤其是人的思路，如果拒绝变化，即便是自动化到了部门边界就没有然后啦，这一点看到的例子太多了，尤其是开发环境，以及生产环境的职责分离，导致前端敏捷后端瀑布的模式，很难达到理想的DevOps状态。
另外，喜忧参半我也非常认同，有时候思考的出发点是部门的利益，而不是整体的效率，如果效率最优化，那么必然很多浪费的资源无处安放。
最后业务敏捷的能力是关键，我在后面的专栏也会说到这点。
期待你的更多回复！ 1
陈文涛2019-10-11这个“课后作业”可是个难题，最近也在思考这个问题，devops的好处显而易见，但毕竟请的起咨询公司还是少数，所以我觉得这个实施devops与实施敏捷其实套路差不多，首先要大家达成一致的认识，试点团队，打造明星团队，成果宣传推广。
devops是一套体系，如何体现出来他的价值，由众多流程环节进行保证，比如你的自动化测试、代码静态检查、自动化部署、自动编译打包，总之第一点要解放双手，从研发工具上入手，这第一点是从无到有的过程，建立起来并不难，然后才是进一步的推进。
而对于2b的行业devops的理念可能与2c行业也有不同吧，因为毕竟部署环节其实是割裂开的，这也是想请教老师的问题。
总之，我觉得如果还不是敏捷的研发模式首先要敏捷起来，而devops感觉就是敏捷思想的进一步的延续，就像微服务之余soa一样。展开作者回复: 你说的非常好，其实我发现很多时候我们都倾向于先挑简单的事情做，比如没有静态代码检查，就先搭个sonar然后跑着，这个从0到1的过程固然重要，但是越往后越是深水区，越不是快餐能够吃饱的，还是以静态代码检查为例，规则怎么制定合理，怎么能达成一致，怎么能做为强制质量门禁，这不仅是技术层面的事情，也是意识和共享目标的问题，否则没有人有意愿主动改进。所以如果DevOps都是微创新，在以前的老路上修修补补，那获得的结果也不会有什么大的变化。可惜的是，在很多公司都是期望不进行变革，就享受到变革的成果，这是不现实的。
1
阿硕2019-10-11企业的数字化转型有没有一个通俗易懂的解释呢？devops的实施是否就代表着实现数字化转型或者有关呢？作者回复: 你好，你的这个话题就有点大了，软件对于企业的价值不言而喻，我只能说DevOps所代表的IT变革，以及新的开发模式有助于企业的数字化转型，因为越来越多的企业通过软件即服务来创造价值。
比如电商行业在寻求新零售，无界零售，不再是单一卖货，而是寻求人，货，场之间的关系，让零售无处不在。而技术的进步，又使得数据指数级增长，传统企业互联网化和新业务形态的扩展，都共同推动了DevOps的火热哈。
至于数字化转型的定义，我理解业界也没有标准的定义吧，关于数字化方式和传统方式的对比，我引用一段描述供你参考:
传统企业和数字化企业最大的区别在于工作方式的不同。传统企业更多地在做两种模式，一种是经验式管理，另一种是以孤岛形式存在的IT管理。“传统企业的目标是通过机制的设置，达到效率的提升。但是在这样的过程里有一个问题：人没有被解放出来。人在流程里只是一个节点，就像生产线上的一个螺丝钉，围绕着流程转。”
而数字化企业的做法，一是行为在线化，企业里所有的行为，包括人的行为、组织行为是在线的；二是数据在线化，所有的人、财、物、事都被数据化，实现在线通达。这样，人就被解放出来了，不再围绕着机器工作，而是机器围绕着人来工作。“这种以人为本管理模式下所有流程都能以它最合适的方式，随时随地由人发起它的改进和优化过程。” 1
Jxin2019-10-101.数据上高效率同时高质量。devops有一定推进作用，毕竟更快部署，确实可以带来连带作用。不过，架构抽象、流程制度等等易是影响因素。
2.感觉老师这边提的devops怎么有点效能工具团队的味道呢。
3.感觉对devops的认知要在老师这里被颠覆了。我原本认为devops的突出价值，应是开发运维结合后产生的奇迹。以k8s为例子，docker公司曾经就是pass公司中一个微不足道的小公司，但当docker开源走红后，便迅速崛起，其他pass的大企业都还没开始还击就已经被按倒在地上，可谓是降纬打击。但k8s的出现却又直接把弄潮儿、不可一世的docker公司一下子打落皇座（2014年docker公司距离成功真的只有一步之遥）。那么k8s为什么能创造如此奇迹？我认为这便是devops的奇迹。k8s具备两个特性，优秀的编排能力（pass平台要干的事，要解决的问题。偏dev），优秀的架构抽象和领域设计（作为专注于面向对象的javaer，看k8s的实现，声明试api的应用，真的是震惊，惊叹，虽然它用的是所谓的面向连接的go。偏ops）。而这两个特性正是devops的组成，开发 + 运维一起实现的。而这样产生的奇迹，正是我原本认为的devops价值的可能性。展开作者回复: 你好，抱歉这么晚才回复，被你猜到了，我目前的确是在负责公司的工程效率体系建设，效率这种东西是永恒的，而DevOps是其中一种手段。
你说到DevOps的价值，其实公司里面关注的还是业务指标，成本，研发资源的有效利用，而这些只靠开发和运维的结合是远远不够的，比如测试的效率如何解决，从我的角度来看，其实运维的成熟度已经非常高了，再加上像k8s这样的工具出现，真是大大简化了很多事情，我们公司的开发都是自己部署的，而测试和业务才是瓶颈。 1- 萨瓦迪卡么么哒2019-10-10建议在试读阶段写一点技术层面的干货，很多人也提到了所谓的落地实践。否则很难判断课程的实际价值。
作者回复: 你好，感谢你的建议，由于课程会按照既定的大纲来持续迭代，你可以选择感兴趣的内容进行试读，当然更欢迎你提出所感兴趣的点和问题，我们也可以随时交流哈。
1 
Geek_5990622019-10-10可以建设工程师文化的团队，可以提升软件交付效率，可以提升软件交付质量。最重要的是，软件用户会因为交付的提升说IT 部门牛X，年底也不会那么狠砍IT预算。作者回复: 哈哈，大家好才是真的好，就像极限编程里面提到的40小时工作制的实践，如果DevOps有助于缩短996的问题也是很好的。
1 1
就不告诉你2019-10-10我的困惑是，Devops是以单项目方式推进，还是多项目共同推进？时间紧，任务急的情况下，这东西怎么去整合？常规的落地需要多久？展开作者回复: 首先DevOps的落地本来就不是一朝一夕的事情，对于很多研发实践来说也是如此，比如持续集成提出快20年了，到今天理念还是那个理念，但是真正能做好的公司其实并不多。
另外关于落地方式，我的建议是试点团队+平台团队的方式来做，试点团队验证研发模式和工具平台，平台团队沉淀标准规范和工具能力建设，二者结合跑通一个项目之后，再把经验横向来复制。如果多个项目并行，除了问题影响面太大，再加上时间紧，任务重，结果就是亚历山大哈。 1- Leiting2019-10-10你会如何说明 DevOps 的价值呢？
首先，我肯定会那各种数据来说明DevOps实施的好处。然后，就是各大知名企业的背书。比如说：京东。
但是，我的疑问是，DevOps和CI/CD又有什么区别呢？文中说：“DevOps 却反其道而行之，它试图通过体系化的研发实践导入、软件架构的整体革新、组织管理理念的不断升级和企业文化的影响塑造，来帮助企业改善整个软件交付过程，在实现高吞吐量的同时保证服务的总体稳定性，从而真正实现又快又好的软件交付目标。”
非常期待它是如何做到的？？展开作者回复: 首先不能否认CICD对于软件交付的重要价值，甚至如果说CICD没做好，那么DevOps一定做不好。只不过一般来说，DevOps涵盖的领域要比CICD来的更广，比如敏捷开发方法，应用架构，安全，业务等都涵盖在其中，是个非常大的体系。
简单来说，CICD是实现DevOps的必要条件。至于又快又好，这也是CICD的目标，其中的一个核心理念就是fail fast，通过建立一条流水线，并在每次执行过程中触发自动化的测试，将问题在初始阶段发现和解决，减少后续的修复成本，将质量内建在研发过程中。当然不仅如此，更多的实践方法，我会在第二章节详细展开，也欢迎提出你的问题哈。 1 - jay2019-10-10DevOps 却反其道而行之，它试图通过体系化的研发实践导入、软件架构的整体革新、组织管理理念的不断升级和企业文化的影响塑造，来帮助企业改善整个软件交付过程，在实现高吞吐量的同时保证服务的总体稳定性，从而真正实现又快又好的软件交付目标。针对这一段话，后续会有具体的方法论讨论DevOps的高效和高质量么？展开
作者回复: 你好，我会在第二部分落地实践篇介绍相关的具体实践，简单来说可以将精益思想和自动化能力融入软件开发过程从而实现高效，通过质量内建和低风险发布实现质量控制。
1
