02 | DevOps的价值：数字化转型时代，DevOps是必选项？
该思维导图由 AI 生成，仅供参考
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
数字化转型时代，DevOps成为企业必选项。文章首先介绍了一家金融企业将DevOps作为愿景指标，并以此激励员工的案例。随后，文章探讨了数字化转型对企业的重要性，强调了软件在企业中的关键地位。随着VUCA时代的到来，软件交付的效率和质量成为企业核心竞争力。因此，实施DevOps能够提升软件交付能力，成为企业愿望清单中的首选。最后，文章提到了DevOps的价值，指出实施DevOps能够提高软件开发交付效率，成为企业的新的业绩增长点。文章通过实例和分析，阐述了数字化转型时代下，DevOps对企业的重要性和价值。文章还掏出了高效的软件交付方式和激发团队创造力的内容，强调了DevOps对软件交付效率和质量的重要性，以及对员工激励和团队创造力的促进作用。文章最后提出了一个思考题，引导读者思考如何向领导申请立项，突出了实践性和思考性。
《DevOps 实战笔记》，新⼈⾸单¥59
全部留言(41)
- 最新
- 精选
linda.zx置顶老师，请问关于DevOps现状报告哪里可以看到完整版呢？作者回复: 你好，我整理了历年的报告分享给你哈，链接:https://pan.baidu.com/s/1W7-_et-wulD7AueBU2KTow 密码:mgl1
2019-10-10339
陈斯佳我会直接和老板说：“现在的测试发布每一次需要一个小时左右。如果DevOps实行后，预计只需要10分钟，节省了50分钟。这50分钟乘以运维组、测试组和开发组的20个人，省下的工作时间就是1000分钟。再乘以他们每分钟平均薪酬，大概1元钱（按照月薪8000算）。也就是每次测试环境发布就能节省1000块钱。每天预计需要平均5-6次测试发布，那么每天就能省5000-6000块。每个月（按照20天）就能省100000-120000。如果效率再高点，还能省更多。老板，您觉得如何？”作者回复: 哈哈，我在公司里面见过很多这样的算术题，你猜怎么样，老板基本没啥感觉，因为什么？计算公式看起来都对，但是没法证明。 所以效率这个事情不像成本，砍掉一半服务器节省3000万，简单直接。其实如果老板不认为效率是竞争力，想要说服他，很难。一个小建议是，从业务方的交付来说明，因为业务方经常会吐槽交付不给力，那么提升效率解决他们的问题，老板感受会更深刻。 所以，核心是，如果你想向谁证明一件事，那么最好的方法就是让他关注的人来替你证明这件事。
2019-10-13957- delly我所在的运维团队把自己一整套运维流程做成了DevOps：通过配置管理工具（chef）把需要手工配置的项目代码化，然后通过gitlab管理代码项目，jenkins实现持续集成持续部署，几乎所有以前需要手工配置的东西都变成了几行代码。同时也为app部署提供了更快捷的通道。配合三活的基础架构，部署以及变更也可以做到随叫随做，至少头天要求第二天做。 对团队整体来说算是极大地解放了双手和工作效率，对个人来说喜忧参半。。。因为我们这种大厂的运维团队，职能分的很细，有一部分人是负责客户沟通和应用的（现在都去开发配置代码了，开发完无论是一台server还是一万台都可以随时部署），另一部分负责具体干活的（部署，照手册配置），那目前的状况对第二部分人来说就比较惨了，无事可做，就必须要找到其他出路。人家说的DevOps干掉运维干掉的就是我们的这一部分人。
作者回复: 你的回复让我感受特别深，单个个体在大的浪潮之下真的是势单力薄，所以有种说法是浪费创造价值，因为如果真的按照效率最优化的方式进行，那么将有大量现有的工种被淘汰。但是换个角度，几年前做配置管理的同学也在焦虑，现在软件开发越来越轻量级，工具平台越来越成熟，那么是不是配管的工作都可以被一个按钮取代呢，所以当时大家也在探讨转型道路。几年后的今天，我发现其实很多配管都转型做了DevOps或者产品经理，一方面是时代变革会带来新的岗位和机遇，另外一方面个人能力的持续积累也将这种抵抗变化的能力不断加强。所以，核心四个字，找准方向，先干再说！
2019-10-10417 
iiiqueena归根结底还是提高“人效”。从人、流程、工具出发实现这个目标，落地过程中由文化引导，的确是很困难的事情。尤其是人的本性是安于现状或恐惧改变带来的不利因素，但当他们看到改变带来的好处时，应该也是忧喜参半（喜的是效率提高，忧的是多出来的劳动力应该转向哪里？）。如果再往前想一些，当技术可以极大地提高生产力时，那核心是不是就是业务能力？作者回复: 非常精妙的留言，必须赞一个👍 我很认同人，流程，平台三位一体的改进，才能有效，否则你能改变的将非常有限，尤其是人的思路，如果拒绝变化，即便是自动化到了部门边界就没有然后啦，这一点看到的例子太多了，尤其是开发环境，以及生产环境的职责分离，导致前端敏捷后端瀑布的模式，很难达到理想的DevOps状态。 另外，喜忧参半我也非常认同，有时候思考的出发点是部门的利益，而不是整体的效率，如果效率最优化，那么必然很多浪费的资源无处安放。 最后业务敏捷的能力是关键，我在后面的专栏也会说到这点。 期待你的更多回复！
2019-10-1115
砖瓦工老师，“DevOps 作为软件工程的第三次革命”的出处是哪里？前两次革命是什么？作者回复: 你好，主要指的是软件开发模式的三次变迁，也就是从瀑布模式，到敏捷模式，再到DevOps模式，具体可以参考第一讲的内容哈
2019-10-10315
阿卡牛DevOps 有什么致命的缺点吗？毕竟没有银弹啊作者回复: 致命的问题就是难以真正落地呀，需要长期的团队磨合和能力建设。我见过一些公司希望在三个月内实现DevOps，这显然是不太现实的。 其实不说DevOps了，就连持续集成能真正做到位都不容易，更不要说文化的建设啦。
2019-10-10213
Wesley《软件观念革命—交互设计精髓》，该书提到软件开发领域的三次革命： 1. 高级语言 20世纪50年代，使软件开发从机器语言的束缚中解放出来。 2. 软件工程 20世纪70年代，使软件开发的注意力从语言拓展到开发过程。 3. 人机交互 20世纪90年代，人机交互理论改变了一般商用软件的设计开发流程和方式作者回复: 很赞，又帮助大家拓展了知识面👍
2019-10-1029
leslie老师在课程中提到的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，也就是识别，定位，修复和验证四个部分，这既包含了传统运维的监控能力，线上故障定位能力，通过异常诊断定位代码的能力，研发快速修复活回滚的能力，以及整条交付流水线的能力，快速发布上线的能力，所以是个全局考查的指标，每一个环节的实践都有可能会影响这个结果哈。 至于运维无用论，我觉得都不需要讨论了，我建议你看下萧帮主的文章哈😄
2019-10-1037
陈文涛这个“课后作业”可是个难题，最近也在思考这个问题，devops的好处显而易见，但毕竟请的起咨询公司还是少数，所以我觉得这个实施devops与实施敏捷其实套路差不多，首先要大家达成一致的认识，试点团队，打造明星团队，成果宣传推广。 devops是一套体系，如何体现出来他的价值，由众多流程环节进行保证，比如你的自动化测试、代码静态检查、自动化部署、自动编译打包，总之第一点要解放双手，从研发工具上入手，这第一点是从无到有的过程，建立起来并不难，然后才是进一步的推进。 而对于2b的行业devops的理念可能与2c行业也有不同吧，因为毕竟部署环节其实是割裂开的，这也是想请教老师的问题。 总之，我觉得如果还不是敏捷的研发模式首先要敏捷起来，而devops感觉就是敏捷思想的进一步的延续，就像微服务之余soa一样。作者回复: 你说的非常好，其实我发现很多时候我们都倾向于先挑简单的事情做，比如没有静态代码检查，就先搭个sonar然后跑着，这个从0到1的过程固然重要，但是越往后越是深水区，越不是快餐能够吃饱的，还是以静态代码检查为例，规则怎么制定合理，怎么能达成一致，怎么能做为强制质量门禁，这不仅是技术层面的事情，也是意识和共享目标的问题，否则没有人有意愿主动改进。所以如果DevOps都是微创新，在以前的老路上修修补补，那获得的结果也不会有什么大的变化。可惜的是，在很多公司都是期望不进行变革，就享受到变革的成果，这是不现实的。
2019-10-1126- Bryan_7171老师，请问Agile Coach和DevOps master一起进入项目，进行Scrum培训和DevOps培训，怎么分配比较好呢，有些工作看起来有重复，并且有不同的地方，项目组的人员会感觉矛盾的，怎么才能合理地将Agile和DevOps一起融入到项目中呢？
作者回复: 你好，我的一个小建议是，可以按照他们各自擅长的领域划分，比如管理实践和工程实践，敏捷教练侧重于管理实践，帮助团队熟悉敏捷开发流程，保证需求清晰拆分合理的进入迭代开发过程中，而DevOps可以偏向于具体工程实践的引入，包括一些工具平台能力的建设，核心研发实践比如持续集成，自动化测试能力的建设，研发过程的数据收集和度量等。另外一个思路就是一个敏捷从前向后，DevOps从后向前，也就是敏捷围绕从需求提出到需求就绪这个过程，DevOps从运维环节向前倒退到开发环节，从而覆盖完整流程的优化哈。
2019-11-054
