DevOps究竟要解决什么问题？
石雪峰
讲述：初明明大小：4.20M时长：04:35
近些年来，DevOps 在我们身边出现的频率越来越高了，它似乎无处不在，但对于 DevOps 的定义却好像没人能说清楚。近日，极客时间专栏《DevOps 实战笔记》的作者石雪峰在其专栏中通过软件工程的三个重要发展阶段解释了 DevOps 的“定义”以及 DevOps 要解决的问题。石雪峰称 DevOps 的秘密就来源于它的名字所代表的两种角色——开发和运维。以下为原文中的重点内容。
第一阶段：瀑布式开发模式
瀑布式开发模式将软件交付过程划分成几个阶段，从需求到开发、测试和运维，它的理念是软件开发的规模越来越大，必须以一种工程管理的方式来定义每个阶段，以及相应的交付产物和交付标准，以期通过一种重流程，重管控，按照计划一步步推进整个项目的交付过程。
可是，随着市场环境和用户需求变化的不断加速，这种按部就班的方式有一个严重的潜在问题。
软件开发活动需要在项目一开始就确定项目目标、范围以及实现方式，而这个时间点往往是我们对用户和市场环境信息了解最少的时候，这样做出来的决策往往带有很大的不确定性，很容易导致项目范围不断变更，计划不断延期，交付上线时间不断推后，最后的结果是，即便我们投入了大量资源，却难以达到预期的效果。
第二阶段：敏捷式开发模式
基于第一阶段的问题，敏捷的思潮开始盛行。它的核心理念是，既然我们无法充分了解用户的真实需求，那不如将一个大目标不断拆解，变成一个个可交付的小目标，然后通过不断迭代，以小步快跑的方式持续开发。
与此同时，将测试工作从研发末端的一个独立环节注入整个开发活动中，对开发交付的内容进行持续验证，保证每次可交付的都是一个可用的功能集合，并且由于质量内建在研发环节中，交付功能的质量也是有保障的。
敏捷的持续迭代和验证节省了研发人员大量不必要的浪费和返工，同时，使得开发和测试团队抱团取暖。可是问题又来了，开发和测试团队发现，不管研发的速度变得多快、开发了多少天才的功能，如果没有经过运维环节的部署上线，并最终发布给真实用户，那么这些功能其实并没有什么用。
第三阶段：DevOps 模式
于是，运维团队成了被拉拢的对象。这些在软件交付最末端的团队始终处于一种“背锅”的状态，他们也有改变的意愿，所以 DevOps 应运而生，也就是说，DevOps 最开始想要打破的就是开发和运维之间的对立和隔阂。
随着开发和运维协作开始，团队慢慢发现，其实在整个软件交付过程中，不仅只有开发和运维，业务也是重要的一环。
比方说，如果业务制定了一个不靠谱的需求，那么无论开发和运维怎样协作，得到的终究是一个不靠谱的结果，以及对人力的浪费。可是业务并不清楚用户的真实情况，于是运维团队慢慢转向运营团队，他们需要持续不断地把线上的真实数据和用户行为及时地反馈给需求团队，来帮助需求团队客观评估需求的价值，并及时作出有利于产品发展的调整，这样一来，业务也被引入到了 DevOps 之中，甚至诞生了 BizDevOps 这样一个专门的词汇。
那么，既然沟通协作放之四海皆准，安全也开始积极地参与进来。安全不再是系统上线发布之后的“定时炸弹”，而是介入到整个软件开发过程中，在每个过程中注入安全反馈机制，来帮助团队在第一时间应对安全风险，那么，对于安全团队来说，DevSecOps 就成了他们眼中的 DevOps。
这样的例子比比皆是，包括职能部门、战略部门等，都纷纷加入其中，使得 DevOps 由最开始的点，扩展为线，再到面，不断发展壮大。每个人都参与其中，这使得 DevOps 成了每一个 IT 从业人员都需要学习和了解的知识和技能体系。
说到最后，我还是希望基于我对 DevOps 的理解，给出一个我自己的“定义”：
DevOps 是通过平台（Platform）、流程（Process）和人（People）的有机整合，以 CALMS 文化为指引，即协作、自动化、精益、度量、共享，旨在建立一种可以快速交付价值并且具有持续改进能力的现代化 IT 组织。
以上就是今天的内容，希望你能通过本文建立起你自己对于 DevOps 的独特认知。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(1)
- 最新
- 精选
jian瀑布模型拆解+测试贯穿全过程=敏捷模型 敏捷模型+运营+运维+安全=devops5
收起评论