01 | DevOps的“定义”：DevOps究竟要解决什么问题？
该思维导图由 AI 生成，仅供参考
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
DevOps：软件开发的第三次革命 DevOps是一场软件工程的革命，旨在通过自动化软件交付流程和基础设施变更过程中，促进软件开发人员与其他信息技术专业人员之间的协作与沟通。文章从瀑布式开发模式和敏捷式开发模式出发，探讨了软件开发中存在的问题，以及DevOps作为解决方案的意义。传统模式下，开发和运维之间的对立和隔阂导致软件交付的困境，而DevOps的出现旨在打破这种局面，促进协作与沟通。除了开发和运维，业务、安全等部门也逐渐融入DevOps，使其成为整个软件开发过程中的重要组成部分。DevOps不仅仅是一种文化、运动或实践，更是通过平台、流程和人的有机整合，以协作、自动化、精益、度量和共享文化为指引，建立一种可以快速交付价值并具有持续改进能力的现代化IT组织。文章最后呼吁读者建立自己对DevOps的独特认知，并提出思考题，引发读者对DevOps的理解和定义的思考和讨论。 DevOps的发展历程和软件开发模式的变迁，使其成为软件工程的第三次革命，对整个行业产生深远影响。它的开放性使每个从业人员都需要学习和了解，建立正确的认知是体系化学习的第一步。通过本文，读者能够快速了解DevOps的发展历程和意义，建立对DevOps的独特认知，引发对DevOps的理解和定义的思考和讨论。
《DevOps 实战笔记》，新⼈⾸单¥59
全部留言(63)
- 最新
- 精选
Jxin
1.与个人认知有点分歧。您对devops的描述个人认为在how的范涛，也就是怎么做。而描述一个东西，感觉用what来描述会合适点，也就是是什么，解决什么问题。 2.个人认为，devops的出现，是当下软件工程模式的痛点和互联网环境共同催生的。在敏捷开发的模式下，沟通协作成本和多工序质检成本对软件工程的阻碍性高于职责分工带来的促进性。故采用这种垂直整合的方式，虽失去了分工带来的效能提升，但减少了沟通协作和多工序质检（运维的上线标准，测试的提测标准）的成本。同时，也得幸于当下各种运维、测试技术栈层出不穷，且线上学习资料、培训机构丰富、活跃。在这个大环境下，垂直整合的技术栈成本降低到了可以接受的程度，一切才能顺水推舟。除了devops还有去qa和精准开发的产品思维，我认为这些都是当下痛点下的垂直整合的体现。作者回复: 感谢你的回复，其实对于DevOps的定义，我是加了双引号的，因为这个定义也只是一家之言。 的确，DevOps要解决的还是软件研发交付能力和业务需求快速多变之间的矛盾。职责划分是企业精细化运营的必然结果，因为每一个领域的知识厚度已经超越了以前英雄的时代，也就是一个人搞定一切，所以才有了不同的职能。现在忽然发现，职能和组织划分又产生了部门墙和沟通成本，甚至这个成本已经超出了做事本身，于是现在又开始推崇全栈工程师。 以我在企业中的观察，所谓全栈还为时尚早，更多的还是通过平台来解决只有专家才能做事的问题。顺便说一下，QA的能量依然很强大呀😄
2019-10-08936- Geek_5bc409瀑布模式在项目初始阶段对花费了大量的时间对业务进行梳理分析，确定了整体的架子和大概方向。敏捷并没有花费大量的时间去研究业务，从一个小系统开始不停迭代，会不会因为对业务没有分析透，出现一叶障目，方向偏离或者说系统开发到一半的时候，发现整个的总体业务架构是不合理的，需要大返工的情况
作者回复: 你好，感谢你的留言。 说说我个人的看法，首先采用敏捷开发方式，与需求是否靠谱没有直接的关联关系，比如瀑布模式下，也有大力出悲剧的案例，比如摩托罗拉的铱星计划，再比如诺基亚智能手机的案例。 其次，说句实话，即便使用敏捷模式，现在很多需求都是拍脑袋拍出来的，至于说这个需求价值到底有多少，始终缺少直接的衡量，这就导致拍的越多，成功率越高，从而产生无穷无尽的需求。 那么这也代表了，其实企业对于用户想要什么并不清楚，谁能想到电商行业两大巨头格局已定的情况下，偏偏杀出来个拼多多呢？ 所以，无论是精益创业的MVP理论，还是反脆弱中的从不确定中收益的角度来说，企业以可控的成本不断试错，以博取一个无限的收益，已经成为了常态。 那么对软件开发来说，就需要有这样的能力，可以快速的把一个原型想法交付上线，并收集线上数据实时反馈给业务方，判断是否需要继续投入资源。这个过程的成本越低，企业的成长性就越好，从而不断发展下去。 至于说软件架构这个东西，我还没见过哪个架构做出来10年不变的，即便我们自己的内部平台，也是重构重构再重构，所以没必要一步到位，更多是还是演进式思路，要不然开发怎么磨砺自己的技能呢？
2019-10-08525 
陈斯佳DevOps对我而言，核心是快速反馈，让团队能以最小代价最快的速度获得真实程序反馈，从而让各个部门对不确定的目标更加清晰一点。平台和流程的自动化只能能保证效率的提高，但其中推动这一反馈闭环形成的还是人，一个愿意拥抱变化，不断精进迭代的人。希望在这个平台能遇上这样的一群人作者回复: 你好，人的问题是最复杂的问题，如果完全依靠人的境界提升，还是不太现实，我一直认为，建立有效的流程和机制是非常重要的手段，这会潜移默化的影响人的行为，行为建立习惯，习惯构建文化。
2019-10-1314
Goal之前看了赵成老师的运维体系管理课程，还有部分同学提到的沟通成本问题，简单说一下，当做自己的输出 1. 古老的瀑布模式存在一个问题，研发、测试、运维各自有各自的“方言”，造成没有统一的标准，当业务规模越来越大，简单的配置管理都变得异常困难，更别提怎么用自动化取代人工操作； 2. DevOps 就是大家统一搞一套标准，谁都认识谁都认可；标准统一了，事情就好办了，理清楚实际的业务场景，针对性的开发出各种工具平台来提升持续交付整个流程上的效率问题；作者回复: 嗯嗯，协作的前提是大家有相同的认知，如果你觉得重要的事情，对他来说并没有什么意义，那就没有合作的基础，所以DevOps最重要的就是让大家认同价值交付是共赢的事情，并在这个基础上先前一步吧。
2019-10-097
小白DevOps是各团队(已不单指开发与运维)一起紧密协作工作，以更快更好的构建、测试、发布软件交付价值为目标。DevOps发展过程中渐渐形成了DevOps文化和方法论，同时各种工具平台不断发展和出现，有了方法论和工具，接下来就是实践，大家又在实践过程中不断完善发展方法论和工具。作者回复: 精辟的总结！如果总想着一步到位，那就失去了DevOps持续改进的精髓呀！这也是理论篇想要传递的核心思想。
2019-10-126
昕宇老师好，请问一下devops与微服务之间是什么关系，不是很懂作者回复: 你好，维服务是一种应用架构的设计风格，简单来说吧，以前的应用大多是单体的，也就是所有服务都打到一个软件包里面，这样的问题就是，哪怕任何人改一点代码，整个软件包都要重新生成，重新部署，这样肯定不够灵活。 而DevOps追求的是软件的灵活快速发布，所以如果把一个大应用拆成一堆小的组件，彼此独立部署发布，那就不用大家一起齐步走了，搞得快的人可以快点跑。 所以这两者没有啥因果关系，但是微服务应用更加容易发挥DevOps的威力，再加上云和容器，就构成了现在一体化的技术变革。
2019-10-116
leslie粗谈一下个人的理解吧：可能我个人最深的感受是OPS只会部署，调教和解决代码问题能力很差。自己是从程序员-数据库开发-数据库开发兼数据库运维然后就一直在OPS和DBA之间不断主从切换多年：运维只是运维，开发只是开发的问题碰到太多了。 最初了解这个概念是在Google的SRE一书中：近半年一直在努力强化和完善自己，课程开课之前其实就在学<全栈工程师指南>;运维其实是各个环节的中间层，尤其是现在数据库运维的概念基本被弱化或者消失相关的压力全部放到了运维身上，网络的常规又在运维身上；不是有句俗语么“万能的运维”，之前我们经常说DB是中间层；从开发角度而言数据是中间层，可是从部署角度而言运维才是中间层-连接开发和网络安全然后解决一切常规问题。 综述：个人的理解是DevOps应当具备如下技能：熟悉操作系统能完成系统部署以及精确定位问题出自哪里：系统、网络、硬件、程序、数据库大致问题在哪儿并能解决系统问题和准确定位其它方面的问题和解决基本问题。Someone Does Everything。 以上是人对此的一点薄见-希望在老师的课程以及的课程都学完时我能明了并完成自己对此的梳理和定位以及提升：谢谢老师的分享。作者回复: 果然运维都是自带万能光环出现的，而且又无处不在，我从开发的角度深刻能体会到对运维环境的未知和恐惧，只要不是代码的问题，就全部是运维的问题，这种思维定势，直接导致了很多问题直接都会丢给运维解决，这对运维团队的能力和压力都是双重考验啊。 回到全栈工程师的问题，目前看到更多的还是领域内的全栈，比如前后端开发，比如全栈测试，真正的全栈还是凤毛麟角吧。 Anyway，感谢你的留言，也期待你的更多分享。
2019-10-096- 卡卡罗特devops其实就是一整套的工作方式，在接收需求，论证需求的讨论，再到开发测试运维测试通力协作，以推动需求的快速落地实践，而涉及的核心工作流在于持续集成和持续交付。充分交流沟通推动工作的进程是核心思想，然后通过工具进行具体的实践，automation就是实践的核心。我们公司现在在挖掘gitlab+k8s推进这项进程，最近还看了个猪齿鱼的开源项目感觉蛮有意思，老师也可以看下
作者回复: 感谢你的推荐，猪齿鱼的博客我也有关注哈，现在基于多云的一体化研发平台确实很热，其实大家的思路都大同小异，我后面也会花一讲的时间搭建一个开源的流水线平台，就是基于gitlab+k8s来做的，欢迎有问题随时留言。
2019-11-115 
刘丹DevOps = 敏捷开发 + 持续集成 + 自动化测试 + 持续发布 ？作者回复: 我理解你说的这部分属于工程实践，也是工程师日常打交道最多的内容，这些固然很重要，但是比如需求拆分是否合理，应用架构是否支持独立部署，持续发布了安全风险如何管控，团队协作是否高效，这些都会影响工程实践的效果哈
2019-10-0925
he7yong老师是否可以把业务需求分析，架构设计DDD，这些和devops之间是否有什么关系，也讲讲？作者回复: 你好，你是指Deadline Driven Development 嘛 😆 开个玩笑，我对DDD的理解还没有那么深，所以就不胡说八道啦，推荐你参考张逸的专栏哈😄
2019-10-1124
