devops学习心得总结 第1篇

过去普遍采用的软件交付基础模型，就是“瀑布（Waterfall）模型”。瀑布模型，基本特征，就是等一个阶段所有工作完成之后，再进入下一个阶段。适合条件比较理想化（用户需求非常明确、开发时间非常充足）的项目。大家按部就班，轮流执行自己的职责即可。

但是互联网软件项目，甲方客户的需求往往并不是固定且明确，会根据实际情况调整部分开发内容。同时用户给的开发时间周期却越来越少。在这个情况下，大家发现，笨重迟缓的瀑布式开发模型已经不合时宜了。

于是，软件开发团队引入了国外一个新的概念，那就是大名鼎鼎的——“敏捷开发”有两个词经常会伴随着DevOps出现，那就是CI和CD。CI是Continuous Integration（持续集成），而CD对应两个英文，Continuous Delivery（持续交付）或Continuous Deployment（持续部署）。

画个图说明可能更明白一点：

敏捷开发大幅提高了开发团队的工作效率，让版本的更新速度变得更快。

很多人可能会觉得，“更新版本的速度快了，风险不是更大了吗？”

其实，事实并非如此。

敏捷开发可以帮助更快地发现问题，产品被更快地交付到用户手中，团队可以更快地得到用户的反馈，从而进行更快地响应。而且，DevOps小步快跑的形式带来的版本变化是比较小的，风险会更小（如下图所示）。即使出现问题，修复起来也会相对容易一些。

这样最大限度的解决了用户需求描述和产品功能之间的信息不对称问题。众所周知的产品生命周期包括从产品需求确立到产品设计，开发，生产及售后。在传统模式下直到产品生产完成后，我们才能确认产品提供的服务或应用是否能真正的满足用户的需求，但是由于各种无法克服的原因，信息在传递的过程中会不断的被扭曲，被误解，导致最终产品和用户的期望总会有比较大的出入，如果需要重新改正的话，成本往往过于巨大导致用户不得不长时间忍受着不符合自己期望的产品。

在新的（Agile/DevOps）迭代开发持续交付的模式下，用户可以很早的就得到最终产品或服务的一部分进行实际体验，从而可以尽快的把发聩传递回需求管理团队和产品研发团队，这些极具价值的反馈信息将会成为随后产品交付功能的重要参考。随着一次又一次的不断迭代开发和交付，最终产品的将会变得越来越完美。【3】

为了更好的体现持续交付以及即时用户反馈两个重要的过程，我们可以用下面这张图来具体表现：

devops学习心得总结 第2篇

DevOps这个词，其实就是Development和Operations两个词的组合。

DevOps这个词来源于2009年在比利时根特市举办的首届DevOpsDays大会，为了在Twitter上更方便的传播，由DevOpsDays缩写为DevOps。

DevOps是一组过程、方法与系统的统称，用于促进开发、技术运营（运维）和质量保障（测试）部门之间的沟通、协作与整合。让团队从业务需求出发，向着同一个目标前进。

这个定位稍微有点抽象，但是并不难理解。反正它不是某一个特定软件、工具或平台的名字。

Agile/DevOps比较特别的地方是它是组织文化，流程以及工具的结合体。

想要将DevOps真正落地，首先第一点，是思维转变，DevOps并不仅仅是组织架构变革，更是企业文化和思想观念的变革。

除了_之外，就是根据DevOps思想重新梳理全流程的规范和标准。

在思维和流程改变的同时，想要充分落地DevOps，当然离不开软件和平台的支持。

既然如此我们就需要把这三个要素一起标注出来，如下图所示：

目前支持DevOps的软件实在是太多了。限于篇幅，这里就不一一介绍了。话说回来，现在DevOps之所以被吹得天花乱坠，也有这些软件和平台的功劳，可以趁机好卖钱啊。

上述这些关键要素里面，技术（工具和平台）是最容易实现的，流程次之，思维转变反而最困难。

换言之，DevOps考验的不仅是一家企业的技术，更是管理水平和企业团队文化。

对比前面所说的瀑布式开发和敏捷开发，我们可以明显看出，DevOps贯穿了软件全生命周期。

结合下面这张图，更明显地说明了DevOps所处的位置，还有它的价值：

devops学习心得总结 第3篇

一般而言，当企业希望将原本笨重的开发与运营之间的工作移交过程变得流畅无碍，他们通常会遇到以下三类问题：

发布管理问题：很多企业有发布管理问题。他们需要更好的发布计划方法，而不止是一份共享的电子数据表。他们需要清晰了解发布的风险、依赖、各阶段的入口条件，并确保各个角色遵守既定流程行事。

发布/部署协调问题：有发布/部署协调问题的团队需要关注发布/部署过程中的执行。他们需要更好地跟踪发布状态、更快地将问题上升、严格执行流程控制和细粒度的报表。

发布/部署自动化问题：这些企业通常有一些自动化工具，但他们还需要以更灵活的方式来管理和驱动自动化工作──不必要将所有手工操作都在命令行中加以自动化。理想情况下，自动化工具应该能够在非生产环境下由非运营人员使用。

要开始优化发布流程，可以从问题识别开始，看看上面提到的哪种问题在你的团队中具有最高的优先级。基于公司实际情况，制定阶段性目标，一步一步实现。

坚持持续改进，推行精益管理，不断优化开发，业务流程，打造创新，高效，负责，协作的企业文化。推行DevOps是所有竞争性公司的必由之路，是一个长期的过程，靡不有初，鲜克有终，只有不忘初心，方得始终。  

devops学习心得总结 第4篇

       Developments：更多的对软件进行更新；

       QA：对代码进行测试；

       Operations：部署上线的项目更加稳定。

        DevOps并不是一个技术，其强调高效组织团队之间如何通过自动化的工具协作和沟通完整软件的生命周期，从而更快、更频繁稳定的完成软件的交付，实现更稳定的更新。

        DevOps本意是鼓励不同的软件开发部门共同协作，个体和互动 高于 流程和工具。开发、测试、运维三个部门不同系统合并成为一个，会带来减少维护成本的长期利益。DevOps另一个核心目标是自动化和持续交付。

        DevOps转化必须要快，高层次上，考虑抢占市场；低层次上，紧盯任务。

        透过自动化和“软件交付”和“架构变更“”的流程，来使得构建、测试、发布软件能够使更加地快捷频繁和可靠。

确保流水线更好的运行：一定要做自动化构建；

                                        一定要做自动化测试；

                                        持续集成。

— — — — — —后期还会不断地补充— — — — — —

devops学习心得总结 第5篇

微服务架构下，不同的工程师可以对各自负责的模块进行处理，例如开发、测试、部署、迭代。

而虚拟化，其实就是将一个硬件加软件构成的整体系统“划分”为多个子系统，系统之间相互隔离，为微服务提供便利。

容器就更彻底了，不是划分为不同的操作系统，而是在操作系统上划分为不同的“运行环境”（容器），占用资源更少，部署速度更快。

参考资料：

3．为什么DevOps很好，但却很难落地，大家对DevOps是怎么理解的？（2）

devops学习心得总结 第6篇

大多数的 IT 团队寻求改革并非来源于部门内部的自我革新，而是来源于业务部门的服务压力。正如同当年企业寻找 ERP，今天的企业将目光投向了 DevOps。但是 DevOps 并非像 ERP 那样可以直接部署的东西，而是一种由主流互联网巨头们所总结出来的的研发管理理念，是 Google、Netflix 等大型互联网公司实现快速迭代的秘诀。

深入理解了 DevOps 之后，你会发现：为了帮助研发团队在保持质量的前提下提高交付效率的方法都隶属于 DevOps 的范畴。

国内企业在实践 DevOps 过程中，普遍碰到了比较大的困难。主要是以下两个原因：

对于许多仍然在使用中心化的研发组织形式的团队来说，DevOps 的尝试无法立即获得肉眼可见的增长数据，思索与尝试带来的对团队的训练可能会是第一份收获。

参考Agile/DevOps成熟度指标模型图示，可以参考到国外企业的敏捷开发实践经验，同样是把转型的关键落实在以下四个方面。【3】

仅仅依托于工具恐怕无法保证DevOps的实施。我们推崇的是从流程，工具和组织文化以及人员素质四个方面整体考虑。【3】

DevOps对非互联网传统领域的企业而言是一件重要不紧急的事。

实践 DevOps 的原则中很重要的一点就是对工具的运用及依赖工具搭建合适企业自己独特性要求的自动化流程。但是目前市面上缺乏成熟的 DevOps 工具链，各个服务商的细分工具层出不穷，企业为了搭建整套 DevOps 流程，需要研究几十种工具，并选取其中的 6-8 种进行落地实践。非常依赖于管理者的项目经验，没有 DevOps 经验的团队起步将会比较困难。