01 | DevOps的“定义”：DevOps究竟要解决什么问题？
请订阅文章所属专栏。
精选留言(41)
Jxin1.与个人认知有点分歧。您对devops的描述个人认为在how的范涛，也就是怎么做。而描述一个东西，感觉用what来描述会合适点，也就是是什么，解决什么问题。
2.个人认为，devops的出现，是当下软件工程模式的痛点和互联网环境共同催生的。在敏捷开发的模式下，沟通协作成本和多工序质检成本对软件工程的阻碍性高于职责分工带来的促进性。故采用这种垂直整合的方式，虽失去了分工带来的效能提升，但减少了沟通协作和多工序质检（运维的上线标准，测试的提测标准）的成本。同时，也得幸于当下各种运维、测试技术栈层出不穷，且线上学习资料、培训机构丰富、活跃。在这个大环境下，垂直整合的技术栈成本降低到了可以接受的程度，一切才能顺水推舟。除了devops还有去qa和精准开发的产品思维，我认为这些都是当下痛点下的垂直整合的体现。作者回复: 感谢你的回复，其实对于DevOps的定义，我是加了双引号的，因为这个定义也只是一家之言。
的确，DevOps要解决的还是软件研发交付能力和业务需求快速多变之间的矛盾。职责划分是企业精细化运营的必然结果，因为每一个领域的知识厚度已经超越了以前英雄的时代，也就是一个人搞定一切，所以才有了不同的职能。现在忽然发现，职能和组织划分又产生了部门墙和沟通成本，甚至这个成本已经超出了做事本身，于是现在又开始推崇全栈工程师。
以我在企业中的观察，所谓全栈还为时尚早，更多的还是通过平台来解决只有专家才能做事的问题。顺便说一下，QA的能量依然很强大呀😄2019-10-08 8 12- Geek_5bc409瀑布模式在项目初始阶段对花费了大量的时间对业务进行梳理分析，确定了整体的架子和大概方向。敏捷并没有花费大量的时间去研究业务，从一个小系统开始不停迭代，会不会因为对业务没有分析透，出现一叶障目，方向偏离或者说系统开发到一半的时候，发现整个的总体业务架构是不合理的，需要大返工的情况
作者回复: 你好，感谢你的留言。
说说我个人的看法，首先采用敏捷开发方式，与需求是否靠谱没有直接的关联关系，比如瀑布模式下，也有大力出悲剧的案例，比如摩托罗拉的铱星计划，再比如诺基亚智能手机的案例。
其次，说句实话，即便使用敏捷模式，现在很多需求都是拍脑袋拍出来的，至于说这个需求价值到底有多少，始终缺少直接的衡量，这就导致拍的越多，成功率越高，从而产生无穷无尽的需求。
那么这也代表了，其实企业对于用户想要什么并不清楚，谁能想到电商行业两大巨头格局已定的情况下，偏偏杀出来个拼多多呢？
所以，无论是精益创业的MVP理论，还是反脆弱中的从不确定中收益的角度来说，企业以可控的成本不断试错，以博取一个无限的收益，已经成为了常态。
那么对软件开发来说，就需要有这样的能力，可以快速的把一个原型想法交付上线，并收集线上数据实时反馈给业务方，判断是否需要继续投入资源。这个过程的成本越低，企业的成长性就越好，从而不断发展下去。
至于说软件架构这个东西，我还没见过哪个架构做出来10年不变的，即便我们自己的内部平台，也是重构重构再重构，所以没必要一步到位，更多是还是演进式思路，要不然开发怎么磨砺自己的技能呢？2019-10-08 2 10 
he7yong老师是否可以把业务需求分析，架构设计DDD，这些和devops之间是否有什么关系，也讲讲？作者回复: 你好，你是指Deadline Driven Development 嘛 😆
开个玩笑，我对DDD的理解还没有那么深，所以就不胡说八道啦，推荐你参考张逸的专栏哈😄2019-10-11 1 3
leslie粗谈一下个人的理解吧：可能我个人最深的感受是OPS只会部署，调教和解决代码问题能力很差。自己是从程序员-数据库开发-数据库开发兼数据库运维然后就一直在OPS和DBA之间不断主从切换多年：运维只是运维，开发只是开发的问题碰到太多了。
最初了解这个概念是在Google的SRE一书中：近半年一直在努力强化和完善自己，课程开课之前其实就在学<全栈工程师指南>;运维其实是各个环节的中间层，尤其是现在数据库运维的概念基本被弱化或者消失相关的压力全部放到了运维身上，网络的常规又在运维身上；不是有句俗语么“万能的运维”，之前我们经常说DB是中间层；从开发角度而言数据是中间层，可是从部署角度而言运维才是中间层-连接开发和网络安全然后解决一切常规问题。
综述：个人的理解是DevOps应当具备如下技能：熟悉操作系统能完成系统部署以及精确定位问题出自哪里：系统、网络、硬件、程序、数据库大致问题在哪儿并能解决系统问题和准确定位其它方面的问题和解决基本问题。Someone Does Everything。
以上是人对此的一点薄见-希望在老师的课程以及的课程都学完时我能明了并完成自己对此的梳理和定位以及提升：谢谢老师的分享。作者回复: 果然运维都是自带万能光环出现的，而且又无处不在，我从开发的角度深刻能体会到对运维环境的未知和恐惧，只要不是代码的问题，就全部是运维的问题，这种思维定势，直接导致了很多问题直接都会丢给运维解决，这对运维团队的能力和压力都是双重考验啊。
回到全栈工程师的问题，目前看到更多的还是领域内的全栈，比如前后端开发，比如全栈测试，真正的全栈还是凤毛麟角吧。
Anyway，感谢你的留言，也期待你的更多分享。2019-10-09 3
鲍建飞设备端可以集合devops么作者回复: 你所说的设备端是指嵌入式或者智能硬件设备吗？其实这些产品同样需要提高软件交付效率和质量，我记得在DevOps实践指南里面就提到过一个POS机实践DevOps的案例，他们通过分批下发，自主部署的方式，解决了一次性部署的问题和冲突，你可以找来看看。其实在我接触过的公司，同样有类似的平台支持远程升级，核心理念还是怎样通过工程能力建设解决实际的业务问题哈。
2019-10-10 2
Oliver移动端的开发如何去实现DevOps呢，目前我们做的只是通过Jenkins来持续集成打包而已，不知道在移动端DevOps的方面还可以做哪些东西作者回复: 你好，我目前在公司就是重点负责移动端的DevOps建设，除了你提到的自动打包，其实能做的事情非常多，比如自动发布，自动多渠道管理，测试和代码质量门禁的建设，组件化的能力建设等等，相当于一整套移动端的持续交付链路能力，重点看你们当前的阶段，和急需解决的问题哈，可以提出来一起讨论。
2019-10-09 2
悟空之前看了赵成老师的运维体系管理课程，还有部分同学提到的沟通成本问题，简单说一下，当做自己的输出
1. 古老的瀑布模式存在一个问题，研发、测试、运维各自有各自的“方言”，造成没有统一的标准，当业务规模越来越大，简单的配置管理都变得异常困难，更别提怎么用自动化取代人工操作；
2. DevOps 就是大家统一搞一套标准，谁都认识谁都认可；标准统一了，事情就好办了，理清楚实际的业务场景，针对性的开发出各种工具平台来提升持续交付整个流程上的效率问题；作者回复: 嗯嗯，协作的前提是大家有相同的认知，如果你觉得重要的事情，对他来说并没有什么意义，那就没有合作的基础，所以DevOps最重要的就是让大家认同价值交付是共赢的事情，并在这个基础上先前一步吧。
2019-10-09 2
就不告诉你如果一个公司本身就是集需求开发测试运维于一体的一站式服务，那DevOps意味着什么？作者回复: 我的理解一站式服务并不能解决交付效率和质量的问题哈，当然现在基于DevOps的一体化平台无论在公司内部，还是外部，都有不错的需求，比如阿里云效，我相信基础设施云化只是一个开始，后面很多能力都会SaaS化，也包括效率建设方面的能力哈。
2019-10-09 1 2
阿硕寻找志同道合的一帮人，达成共识，实现目标，研发，测试，运维的所做所为，这很DevOps作者回复: 赞，我特别喜欢你的这个评论，希望越来越多的公司都能“很DevOps”哈！
2019-10-08 1 2
无言的约定做java后台开发的适合学习吗？作者回复: 你好，我只能说，单从软件形态上划分，基于服务端的业务相对最适合于DevOps，因为没有固定的发布周期，服务拆分治理又有相对比较成熟的框架，比如Spring Boot，各种配套的工具平台比较完善，更不要说容器应用后的高可扩展性，所以在企业里面推行DevOps，优选的还是服务端业务。
就像我在专栏中说的那样，我觉得DevOps应该是所有IT从业人员都需要了解的内容，也许不需要那么精通，但也不能完全不清楚，毕竟DevOps是大势所趋哈。2019-10-08 3 2
桃子-夏勇杰请问一下老师，如何一个公司的敏捷都没有做好，做DevOps对企业来说会有多大的收益？敏捷没做好做DevOps vs 敏捷做好了做DevOps，两者会有多大差距？作者回复: 你好，我们来假设一下，如果没有采用敏捷的方法，那么十有八九还是瀑布软件开发模式，那么发布的频率和周期是多大呢，如果几个月一个版本，那么和DevOps的快速发布本身是否就背道而驰呢？但话又说回来，很多工程实践，并不只适合DevOps，你比如持续集成，只要是软件开发都是需要的。只不过敏捷的价值不仅在于开发，而是在于如何理解需求，交付需求，我个人的看法是，如果敏捷没做好，DevOps也一定做不好。
2019-10-18 1 1
陈斯佳光看评论都能学到好多…感谢老师的认真！作者回复: 谢谢你的留言，我会认真对待每一个跟大家交流的机会哈😄
2019-10-13 1- 陈斯佳DevOps对我而言，核心是快速反馈，让团队能以最小代价最快的速度获得真实程序反馈，从而让各个部门对不确定的目标更加清晰一点。平台和流程的自动化只能能保证效率的提高，但其中推动这一反馈闭环形成的还是人，一个愿意拥抱变化，不断精进迭代的人。希望在这个平台能遇上这样的一群人
作者回复: 你好，人的问题是最复杂的问题，如果完全依靠人的境界提升，还是不太现实，我一直认为，建立有效的流程和机制是非常重要的手段，这会潜移默化的影响人的行为，行为建立习惯，习惯构建文化。
2019-10-13 1 
helloworld之前对DevOps的理解就是开发+运维的综合体，看了老师的文章后感觉整个公司的所有部门都是DevOps的一部分作者回复: 因为DevOps太火啦，所以大家都不能置身事外呀，其实沟通协作不仅仅在dev和ops两个部门之间有，在外部的安全，业务部门也同样存在，而且部门墙更加严重，比如安全要求应用上线发布前必须经过审核，每次审核要一天时间，而有时候为了早一天发布，开发测试都是通宵达旦，这要如何解决呢？还是自动化，对其目标，共享上线计划，把安全团队拉进来才行嘛。
2019-10-12 1 1
灬 黑 礼服 ~我们在践行 gitops了，，，一股劲的冲。。。总感觉没有运维什么事情了，，，，开发门槛高了，，，，运维技能要求高了，，，，全都自动化了作者回复: 赞啊，Gitops我也是前年在Jenkins X项目中开始接触的，的确非常DevOps ，欢迎分享你们的实战经验。
其实很多人在说咖啡运维，也就是喝着咖啡把运维做了，但其实都依赖于运维能力的平台化自动化输出，我相信运维会更加寻求智能化和数据运营能力的建设，期待AIOps的专栏哈2019-10-10 1
Bryan BaiDevOps 是个双核系统，技术方面的关键字是automation，自动化的是以前手动的流程。这里有个关键问题就是这个手动过程是不是正确的，如果本身是个错误的流程，或者识别错误，那么这个automation只会放大错误。文化方面的关键词是collaberation ,也就是通过文化和工具的带动，使得沟通更快速和双向。作者回复: 非常认同你的观点，其实与其说是错误的流程，不如说是陈旧僵化的流程，毕竟流程始终存在，也的确依靠流程解决了历史上的问题。但是随着标准化和自动化的演进，为流程改进带来了更多的可能性，比如以前依靠人的环节，可以被自动化辅助甚至取代，那么这就是一种进步。
2019-10-09 1
刘剑云对于企业内部的IT，总共6—7个人，传统机械制造行业，主要是crs erp plm等软件及迁移到移动端，原来瀑布方式就3—5天一个功能 多的话10天半个月，现在用敏捷也差不多，DevOps对我们有用吗？作者回复: 感谢你的问题，首先我先问的是作为企业内部IT你们的用户对软件交付现状是否满意呢，如果用DevOps的核心指标来度量，一个需求从提出到交付的时长是多少呢？是否存在积压和排队的现象呢？
另外一方面现在现在你们团队状态又如何呢，是否需要熬夜上线呢，个人发展方面有进步吗。
其还是那句话，DevOps是否有用的衡量标准就是是否能解决实际问题。
其实，回到ERP/CRM系统的问题上来，我在想这些系统的未来是哪里呢。我特意搜了下SAP公司，今年一季度的财报显示，由于创新和云服务的强力推动，整体公司业绩上涨了6.5个百分点。
所以如果未来的趋势是上云，也就是软件走服务化路线，那么慢慢和互联网软件是不是也没什么不同了呢？
所以回答你的问题，一方面看现状，一方面着眼未来，如果有可取之处，自然提早准备也是好的哈。2019-10-08 2 1
随波逐浪雪峰老师，文章内容组织的很棒，引人入胜，不知不觉就听着读着到了小结。大大的点赞
｡◕‿◕｡作者回复: 哈哈，感谢你的无条件支持😄
2019-11-21- 卡卡罗特devops其实就是一整套的工作方式，在接收需求，论证需求的讨论，再到开发测试运维测试通力协作，以推动需求的快速落地实践，而涉及的核心工作流在于持续集成和持续交付。充分交流沟通推动工作的进程是核心思想，然后通过工具进行具体的实践，automation就是实践的核心。我们公司现在在挖掘gitlab+k8s推进这项进程，最近还看了个猪齿鱼的开源项目感觉蛮有意思，老师也可以看下
作者回复: 感谢你的推荐，猪齿鱼的博客我也有关注哈，现在基于多云的一体化研发平台确实很热，其实大家的思路都大同小异，我后面也会花一讲的时间搭建一个开源的流水线平台，就是基于gitlab+k8s来做的，欢迎有问题随时留言。
2019-11-11 
雷霹雳的爸爸老实说，老师BizDevOps和DevSecOps那两段描述异常鲜活，再往后的内容让我彻底拜服，远远超出我对DevOps的预期
所以回过头来说wiki的DevOps定义也不过分，这就是一场运动，套用经典换一个词竟然也如此贴切：devOps对我们来说不是应当确立的状况，不是现实应当与之相适应的理想。我们所称为devOps的是那种消灭（产品研发交付过程中）现存状况（任何的障碍和藩篱？）的现实的运动
我忽然感觉离全面发展竟然不远了...作者回复: 哈哈，涉及到一场运动，给人的感觉不太好，我觉得渐进式的改进会更贴切一些，因为客观情况下，步子也迈不大，这也是为啥DevOps的实践需要漫长的1到2年时间才能见效的原因吧
2019-11-04