DevOps 实战笔记
石雪峰
京东商城工程效率专家
37393 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 41 讲
DevOps 实战笔记
15
15
1.0x
00:00/00:00
登录|注册

01 | DevOps的“定义”:DevOps究竟要解决什么问题?

职能部门加入
安全团队介入
业务参与
上线门槛
运维团队焦虑
开发堆砌新功能
运维团队改变意愿
开发和运维协作
节省浪费和返工
持续验证
质量内建
不断迭代
拆解大目标
应用系统缺陷
延期交付
不确定性
重流程、重管控
阶段划分
快速、频繁、稳定的构建、测试、发布
协作与沟通
基础设施变更
自动化软件交付流程
实践
运动
文化
对DevOps的理解和定义
定义符合预期吗?
持续改进能力
快速交付价值
C(协作)A(自动化)L(精益)M(度量)S(共享)文化
平台、流程、人的整合
DevOps模式
敏捷式开发模式
瀑布式开发模式
DevOps
思考题
定义
发展历程
定义
DevOps究竟要解决什么问题?

该思维导图由 AI 生成,仅供参考

你好,我是石雪峰。今天我们来聊一聊 DevOps 的“定义”。
近些年来,DevOps 在我们身边出现的频率越来越高了。各种大会上经常出现 DevOps 专场,行业内的公司纷纷在都招聘 DevOps 工程师,企业的 DevOps 转型看起来迫在眉睫,公司内部也要设计和开发 DevOps 平台……这么看来,DevOps 似乎无处不在。
可回过头来想想,关于 DevOps,很多问题我们真的想清楚了吗?所谓的 DevOps 平台,是否等同于自动化运维平台,或持续交付平台呢?DevOps 工程师的岗位描述中又需要写哪些技能要求呢?另外,该如何证明企业已经实现了 DevOps 转型呢?这些问题真是难倒了一众英雄好汉。说到底,听了这么久的 DevOps,它的“定义”到底是什么,好像从来没有人能说清楚。
现在,我们先来看看维基百科对 DevOps 的定义。不过,估计也没谁能看懂这到底是在说什么。
DevOps(开发 Development 与运维 Operations 的组合词)是一种文化、一场运动或实践,强调在自动化软件交付流程及基础设施变更过程中,软件开发人员与其他信息技术(IT)专业人员彼此之间的协作与沟通。它旨在建立一种文化与环境,使构建、测试、软件发布得以快速、频繁以及更加稳定地进行。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
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-08
    9
    36
  • Geek_5bc409
    瀑布模式在项目初始阶段对花费了大量的时间对业务进行梳理分析,确定了整体的架子和大概方向。敏捷并没有花费大量的时间去研究业务,从一个小系统开始不停迭代,会不会因为对业务没有分析透,出现一叶障目,方向偏离或者说系统开发到一半的时候,发现整个的总体业务架构是不合理的,需要大返工的情况

    作者回复: 你好,感谢你的留言。 说说我个人的看法,首先采用敏捷开发方式,与需求是否靠谱没有直接的关联关系,比如瀑布模式下,也有大力出悲剧的案例,比如摩托罗拉的铱星计划,再比如诺基亚智能手机的案例。 其次,说句实话,即便使用敏捷模式,现在很多需求都是拍脑袋拍出来的,至于说这个需求价值到底有多少,始终缺少直接的衡量,这就导致拍的越多,成功率越高,从而产生无穷无尽的需求。 那么这也代表了,其实企业对于用户想要什么并不清楚,谁能想到电商行业两大巨头格局已定的情况下,偏偏杀出来个拼多多呢? 所以,无论是精益创业的MVP理论,还是反脆弱中的从不确定中收益的角度来说,企业以可控的成本不断试错,以博取一个无限的收益,已经成为了常态。 那么对软件开发来说,就需要有这样的能力,可以快速的把一个原型想法交付上线,并收集线上数据实时反馈给业务方,判断是否需要继续投入资源。这个过程的成本越低,企业的成长性就越好,从而不断发展下去。 至于说软件架构这个东西,我还没见过哪个架构做出来10年不变的,即便我们自己的内部平台,也是重构重构再重构,所以没必要一步到位,更多是还是演进式思路,要不然开发怎么磨砺自己的技能呢?

    2019-10-08
    5
    25
  • 陈斯佳
    DevOps对我而言,核心是快速反馈,让团队能以最小代价最快的速度获得真实程序反馈,从而让各个部门对不确定的目标更加清晰一点。平台和流程的自动化只能能保证效率的提高,但其中推动这一反馈闭环形成的还是人,一个愿意拥抱变化,不断精进迭代的人。希望在这个平台能遇上这样的一群人

    作者回复: 你好,人的问题是最复杂的问题,如果完全依靠人的境界提升,还是不太现实,我一直认为,建立有效的流程和机制是非常重要的手段,这会潜移默化的影响人的行为,行为建立习惯,习惯构建文化。

    2019-10-13
    14
  • Goal
    之前看了赵成老师的运维体系管理课程,还有部分同学提到的沟通成本问题,简单说一下,当做自己的输出 1. 古老的瀑布模式存在一个问题,研发、测试、运维各自有各自的“方言”,造成没有统一的标准,当业务规模越来越大,简单的配置管理都变得异常困难,更别提怎么用自动化取代人工操作; 2. DevOps 就是大家统一搞一套标准,谁都认识谁都认可;标准统一了,事情就好办了,理清楚实际的业务场景,针对性的开发出各种工具平台来提升持续交付整个流程上的效率问题;

    作者回复: 嗯嗯,协作的前提是大家有相同的认知,如果你觉得重要的事情,对他来说并没有什么意义,那就没有合作的基础,所以DevOps最重要的就是让大家认同价值交付是共赢的事情,并在这个基础上先前一步吧。

    2019-10-09
    7
  • 小白
    DevOps是各团队(已不单指开发与运维)一起紧密协作工作,以更快更好的构建、测试、发布软件交付价值为目标。DevOps发展过程中渐渐形成了DevOps文化和方法论,同时各种工具平台不断发展和出现,有了方法论和工具,接下来就是实践,大家又在实践过程中不断完善发展方法论和工具。

    作者回复: 精辟的总结!如果总想着一步到位,那就失去了DevOps持续改进的精髓呀!这也是理论篇想要传递的核心思想。

    2019-10-12
    6
  • 昕宇
    老师好,请问一下devops与微服务之间是什么关系,不是很懂

    作者回复: 你好,维服务是一种应用架构的设计风格,简单来说吧,以前的应用大多是单体的,也就是所有服务都打到一个软件包里面,这样的问题就是,哪怕任何人改一点代码,整个软件包都要重新生成,重新部署,这样肯定不够灵活。 而DevOps追求的是软件的灵活快速发布,所以如果把一个大应用拆成一堆小的组件,彼此独立部署发布,那就不用大家一起齐步走了,搞得快的人可以快点跑。 所以这两者没有啥因果关系,但是微服务应用更加容易发挥DevOps的威力,再加上云和容器,就构成了现在一体化的技术变革。

    2019-10-11
    6
  • leslie
    粗谈一下个人的理解吧:可能我个人最深的感受是OPS只会部署,调教和解决代码问题能力很差。自己是从程序员-数据库开发-数据库开发兼数据库运维然后就一直在OPS和DBA之间不断主从切换多年:运维只是运维,开发只是开发的问题碰到太多了。 最初了解这个概念是在Google的SRE一书中:近半年一直在努力强化和完善自己,课程开课之前其实就在学<全栈工程师指南>;运维其实是各个环节的中间层,尤其是现在数据库运维的概念基本被弱化或者消失相关的压力全部放到了运维身上,网络的常规又在运维身上;不是有句俗语么“万能的运维”,之前我们经常说DB是中间层;从开发角度而言数据是中间层,可是从部署角度而言运维才是中间层-连接开发和网络安全然后解决一切常规问题。 综述:个人的理解是DevOps应当具备如下技能:熟悉操作系统能完成系统部署以及精确定位问题出自哪里:系统、网络、硬件、程序、数据库大致问题在哪儿并能解决系统问题和准确定位其它方面的问题和解决基本问题。Someone Does Everything。 以上是人对此的一点薄见-希望在老师的课程以及的课程都学完时我能明了并完成自己对此的梳理和定位以及提升:谢谢老师的分享。

    作者回复: 果然运维都是自带万能光环出现的,而且又无处不在,我从开发的角度深刻能体会到对运维环境的未知和恐惧,只要不是代码的问题,就全部是运维的问题,这种思维定势,直接导致了很多问题直接都会丢给运维解决,这对运维团队的能力和压力都是双重考验啊。 回到全栈工程师的问题,目前看到更多的还是领域内的全栈,比如前后端开发,比如全栈测试,真正的全栈还是凤毛麟角吧。 Anyway,感谢你的留言,也期待你的更多分享。

    2019-10-09
    6
  • 卡卡罗特
    devops其实就是一整套的工作方式,在接收需求,论证需求的讨论,再到开发测试运维测试通力协作,以推动需求的快速落地实践,而涉及的核心工作流在于持续集成和持续交付。充分交流沟通推动工作的进程是核心思想,然后通过工具进行具体的实践,automation就是实践的核心。我们公司现在在挖掘gitlab+k8s推进这项进程,最近还看了个猪齿鱼的开源项目感觉蛮有意思,老师也可以看下

    作者回复: 感谢你的推荐,猪齿鱼的博客我也有关注哈,现在基于多云的一体化研发平台确实很热,其实大家的思路都大同小异,我后面也会花一讲的时间搭建一个开源的流水线平台,就是基于gitlab+k8s来做的,欢迎有问题随时留言。

    2019-11-11
    5
  • 刘丹
    DevOps = 敏捷开发 + 持续集成 + 自动化测试 + 持续发布 ?

    作者回复: 我理解你说的这部分属于工程实践,也是工程师日常打交道最多的内容,这些固然很重要,但是比如需求拆分是否合理,应用架构是否支持独立部署,持续发布了安全风险如何管控,团队协作是否高效,这些都会影响工程实践的效果哈

    2019-10-09
    2
    5
  • he7yong
    老师是否可以把业务需求分析,架构设计DDD,这些和devops之间是否有什么关系,也讲讲?

    作者回复: 你好,你是指Deadline Driven Development 嘛 😆 开个玩笑,我对DDD的理解还没有那么深,所以就不胡说八道啦,推荐你参考张逸的专栏哈😄

    2019-10-11
    2
    4
收起评论
显示
设置
留言
63
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部