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