DevOps实战笔记
石雪峰
京东商城工程效率专家
立即订阅
3436 人已学习
课程目录
已更新 30 讲 / 共 35 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 从默默无闻到风靡全球,DevOps究竟有什么魔力?
免费
基础理论篇 (4讲)
01 | DevOps的“定义”:DevOps究竟要解决什么问题?
02 | DevOps的价值:数字化转型时代,DevOps是必选项?
03 | DevOps的实施:到底是工具先行还是文化先行?
04 | DevOps的衡量:你是否找到了DevOps的实施路线图?
落地实践篇 (16讲)
05 | 价值流分析:关于DevOps转型,我们应该从何处入手?
06 | 转型之路:企业实施DevOps的常见路径和问题
07 | 业务敏捷:帮助DevOps快速落地的源动力
08 | 精益看板(上):精益驱动的敏捷开发方法
09 | 精益看板(下):精益驱动的敏捷开发方法
10 | 配置管理:最容易被忽视的DevOps工程实践基础
11 | 分支策略:让研发高效协作的关键要素
12 | 持续集成:你说的CI和我说的CI是一回事吗?
13 | 自动化测试:DevOps的阿克琉斯之踵
14 | 内建质量:丰田和亚马逊给我们的启示
15 | 技术债务:那些不可忽视的潜在问题
16 | 环境管理:一切皆代码是一种什么样的体验?
17 | 部署管理:低风险的部署发布策略
18 | 混沌工程:软件领域的反脆弱
19 | 正向度量:如何建立完整的DevOps度量体系?
20 | 持续改进:PDCA体系和持续改进的意义
平台工具篇 (4讲)
21 | 开源还是自研:企业DevOps平台建设的三个阶段
22 | 产品设计之道:DevOps产品设计的五个层次
23 | 持续交付平台:现代流水线必备的十大特征(上)
24 | 持续交付平台:现代流水线必备的十大特征(下)
特别放送 (4讲)
特别放送:成为DevOps工程师的必备技能(上)
特别放送:成为DevOps工程师的必备技能(下)
特别放送:学习DevOps不得不了解的经典资料
特别放送:Jenkins产品经理是如何设计产品的?
总结答疑 (1讲)
期中总结:3个典型问题答疑及如何高效学习
DevOps实战笔记
登录|注册

02 | DevOps的价值:数字化转型时代,DevOps是必选项?

石雪峰 2019-10-10
你好,我是石雪峰。今天我们来聊聊 DevOps 的价值。
前段时间,因为工作的缘故,我参访了一家在国内数一数二的金融企业。在跟他们科技处的同事交流的过程中,有一件事情让我非常吃惊,想跟大家分享一下。
虽然在一般人眼中,这家企业是典型的传统企业,但他们的绩效目标采用的却是 OKR 模式
我简单介绍一下 OKR。OKR 也就是目标与关键成果法,是在硅谷互联网公司很流行的绩效制定方法。简单来说,O 代表目标,也就是我们要做什么,KR 代表关键结果,用于验证我们是否已经达到了目标。
这家金融企业的大老板,也就是科技处的老大,给全体员工制定的众多 OKR 中,有且只有一条属于愿景指标。说出来你可能不相信,这个愿景指标就是,到今年年底,让 DevOps 在全行的三个试点项目中成功落地。
而且,这并不是简单的说说而已,如果最终达成了这个愿景指标,所有员工的年终奖将在原有的基础上上浮 10%~20%。由此可见,关于实施 DevOps,他们是在玩真的了。
全行的核心系统改造都没能成为愿景指标,那为啥 DevOps 会有如此大的魔力,让大老板都为之着迷,并且成为愿望清单列表中的第一名呢?这就是我今天要跟大家讨论的话题:DevOps 的价值以及它对现代企业的意义。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《DevOps实战笔记》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(30)

  • linda.zx 置顶
    老师,请问关于DevOps现状报告哪里可以看到完整版呢?

    作者回复: 你好,我整理了历年的报告分享给你哈,链接:https://pan.baidu.com/s/1W7-_et-wulD7AueBU2KTow 密码:mgl1

    2019-10-10
    18
  • 陈斯佳
    我会直接和老板说:“现在的测试发布每一次需要一个小时左右。如果DevOps实行后,预计只需要10分钟,节省了50分钟。这50分钟乘以运维组、测试组和开发组的20个人,省下的工作时间就是1000分钟。再乘以他们每分钟平均薪酬,大概1元钱(按照月薪8000算)。也就是每次测试环境发布就能节省1000块钱。每天预计需要平均5-6次测试发布,那么每天就能省5000-6000块。每个月(按照20天)就能省100000-120000。如果效率再高点,还能省更多。老板,您觉得如何?”

    作者回复: 哈哈,我在公司里面见过很多这样的算术题,你猜怎么样,老板基本没啥感觉,因为什么?计算公式看起来都对,但是没法证明。
    所以效率这个事情不像成本,砍掉一半服务器节省3000万,简单直接。其实如果老板不认为效率是竞争力,想要说服他,很难。一个小建议是,从业务方的交付来说明,因为业务方经常会吐槽交付不给力,那么提升效率解决他们的问题,老板感受会更深刻。
    所以,核心是,如果你想向谁证明一件事,那么最好的方法就是让他关注的人来替你证明这件事。

    2019-10-13
    2
    16
  • 砖瓦工
    老师,“DevOps 作为软件工程的第三次革命”的出处是哪里?前两次革命是什么?

    作者回复: 你好,主要指的是软件开发模式的三次变迁,也就是从瀑布模式,到敏捷模式,再到DevOps模式,具体可以参考第一讲的内容哈

    2019-10-10
    1
    12
  • delly
    我所在的运维团队把自己一整套运维流程做成了DevOps:通过配置管理工具(chef)把需要手工配置的项目代码化,然后通过gitlab管理代码项目,jenkins实现持续集成持续部署,几乎所有以前需要手工配置的东西都变成了几行代码。同时也为app部署提供了更快捷的通道。配合三活的基础架构,部署以及变更也可以做到随叫随做,至少头天要求第二天做。

    对团队整体来说算是极大地解放了双手和工作效率,对个人来说喜忧参半。。。因为我们这种大厂的运维团队,职能分的很细,有一部分人是负责客户沟通和应用的(现在都去开发配置代码了,开发完无论是一台server还是一万台都可以随时部署),另一部分负责具体干活的(部署,照手册配置),那目前的状况对第二部分人来说就比较惨了,无事可做,就必须要找到其他出路。人家说的DevOps干掉运维干掉的就是我们的这一部分人。

    作者回复: 你的回复让我感受特别深,单个个体在大的浪潮之下真的是势单力薄,所以有种说法是浪费创造价值,因为如果真的按照效率最优化的方式进行,那么将有大量现有的工种被淘汰。但是换个角度,几年前做配置管理的同学也在焦虑,现在软件开发越来越轻量级,工具平台越来越成熟,那么是不是配管的工作都可以被一个按钮取代呢,所以当时大家也在探讨转型道路。几年后的今天,我发现其实很多配管都转型做了DevOps或者产品经理,一方面是时代变革会带来新的岗位和机遇,另外一方面个人能力的持续积累也将这种抵抗变化的能力不断加强。所以,核心四个字,找准方向,先干再说!

    2019-10-10
    7
  • 阿卡牛
    DevOps 有什么致命的缺点吗?毕竟没有银弹啊

    作者回复: 致命的问题就是难以真正落地呀,需要长期的团队磨合和能力建设。我见过一些公司希望在三个月内实现DevOps,这显然是不太现实的。
    其实不说DevOps了,就连持续集成能真正做到位都不容易,更不要说文化的建设啦。

    2019-10-10
    7
  • leslie
    老师在课程中提到的4个指标:我觉得其实更多的是对当期时代的Ops的要求吧,记得Google SRE提出过其实现代的Ops已经需要解决更多的问题,就像现在有AI Ops;做为从业多年的Ops其实一直在思考,传统Ops持续之路在何处?
         这两年听到越来越多的Ops是最便宜最好找的甚至我觉得很多时候快接近90年代和20世纪初的网管了,可是Ops所承担的压力以及工作似乎完全不符;DevOps和AI Ops其实算是Ops的转型/升级吧?毕竟软件已经从过去的单机、发展到CS/BS模式、现在的分布式,Ops所承担工作已经完全不一样了。DevOps只是作为企业内部的一部分是不是有点弱化了价值?SRE中曾经提及其实其实DevOps其实还是一个Team存在:其实很多时候是OpsDev与DevOps组合值班,去解决问题;其实我觉得这是一种很好的探索吧。其实我现在是DBAOPS,不过由于Dev环节还是有些问题-在强化自己的Dev的基本能力,这样基本能完全把握问题在哪儿吧。
          单纯的DevOps有些统称了:其实Ops不理解Dev是做不好Ops的;申请项目谈不上:设计项目和组织结构倒是在考虑,或许将来规模够大可以用,暂时只能一肩挑了。

    作者回复: 其实不知道你发现没有,这些指标并没有绑定到具体的角色,而是通用的结果指标,也就是通过这个指标度量的是整个交付团队的能力,而并非其中的某一个具体角色,比如举个例子,MTTR平均故障修复时长,拆解开来其实包含了MTT,MTTK,MTTF,MTTV,也就是识别,定位,修复和验证四个部分,这既包含了传统运维的监控能力,线上故障定位能力,通过异常诊断定位代码的能力,研发快速修复活回滚的能力,以及整条交付流水线的能力,快速发布上线的能力,所以是个全局考查的指标,每一个环节的实践都有可能会影响这个结果哈。
    至于运维无用论,我觉得都不需要讨论了,我建议你看下萧帮主的文章哈😄

    2019-10-10
    2
    6
  • Wesley
    《软件观念革命—交互设计精髓》,该书提到软件开发领域的三次革命:
    1. 高级语言 20世纪50年代,使软件开发从机器语言的束缚中解放出来。
    2. 软件工程 20世纪70年代,使软件开发的注意力从语言拓展到开发过程。
    3. 人机交互 20世纪90年代,人机交互理论改变了一般商用软件的设计开发流程和方式

    作者回复: 很赞,又帮助大家拓展了知识面👍

    2019-10-10
    6
  • iiiqueena
    归根结底还是提高“人效”。从人、流程、工具出发实现这个目标,落地过程中由文化引导,的确是很困难的事情。尤其是人的本性是安于现状或恐惧改变带来的不利因素,但当他们看到改变带来的好处时,应该也是忧喜参半(喜的是效率提高,忧的是多出来的劳动力应该转向哪里?)。如果再往前想一些,当技术可以极大地提高生产力时,那核心是不是就是业务能力?

    作者回复: 非常精妙的留言,必须赞一个👍
    我很认同人,流程,平台三位一体的改进,才能有效,否则你能改变的将非常有限,尤其是人的思路,如果拒绝变化,即便是自动化到了部门边界就没有然后啦,这一点看到的例子太多了,尤其是开发环境,以及生产环境的职责分离,导致前端敏捷后端瀑布的模式,很难达到理想的DevOps状态。
    另外,喜忧参半我也非常认同,有时候思考的出发点是部门的利益,而不是整体的效率,如果效率最优化,那么必然很多浪费的资源无处安放。
    最后业务敏捷的能力是关键,我在后面的专栏也会说到这点。
    期待你的更多回复!

    2019-10-11
    4
  • 陈文涛
    这个“课后作业”可是个难题,最近也在思考这个问题,devops的好处显而易见,但毕竟请的起咨询公司还是少数,所以我觉得这个实施devops与实施敏捷其实套路差不多,首先要大家达成一致的认识,试点团队,打造明星团队,成果宣传推广。
    devops是一套体系,如何体现出来他的价值,由众多流程环节进行保证,比如你的自动化测试、代码静态检查、自动化部署、自动编译打包,总之第一点要解放双手,从研发工具上入手,这第一点是从无到有的过程,建立起来并不难,然后才是进一步的推进。
    而对于2b的行业devops的理念可能与2c行业也有不同吧,因为毕竟部署环节其实是割裂开的,这也是想请教老师的问题。
    总之,我觉得如果还不是敏捷的研发模式首先要敏捷起来,而devops感觉就是敏捷思想的进一步的延续,就像微服务之余soa一样。

    作者回复: 你说的非常好,其实我发现很多时候我们都倾向于先挑简单的事情做,比如没有静态代码检查,就先搭个sonar然后跑着,这个从0到1的过程固然重要,但是越往后越是深水区,越不是快餐能够吃饱的,还是以静态代码检查为例,规则怎么制定合理,怎么能达成一致,怎么能做为强制质量门禁,这不仅是技术层面的事情,也是意识和共享目标的问题,否则没有人有意愿主动改进。所以如果DevOps都是微创新,在以前的老路上修修补补,那获得的结果也不会有什么大的变化。可惜的是,在很多公司都是期望不进行变革,就享受到变革的成果,这是不现实的。

    2019-10-11
    1
    3
  • Bryan Bai
    我的经验DevOps要走草根线路,从小组的单一功能的试运行,创造明星团队,逐步获得其他部门和老板信任,增加更多功能,并加入更多团队。由各个部门分摊成本。

    作者回复: 老板的信任很重要,其实对于老板来说,他也希望自己的团队能够更加高效,但是老板能做的就是认可和提供资源,真正做出成绩还得靠你所说的试点团队,当在局部产生效果后,老板也会更加有信心追加投入嘛。

    2019-10-10
    3
  • helloworld
    说白了实施好DevOps关键还是靠人的觉悟程度!人的觉悟提高了,从被动工作到主动工作,自然而然就DevOps了

    作者回复: 呵呵,这个说法好,可问题是,人的觉悟咋提高呢?我觉得如果期待自然进步,那是很难的,人都有惯性,都有习惯,所以还是要建立机制,比如激励考核机制,说白了被动的工作既不会出错,也不费脑子,让干啥就干啥多省心,主动工作有什么好处呢?

    2019-10-12
    2
  • Joseph.Kim
    你好,这个devops报告是哪个报告

    作者回复: 你好,我收集的历年报告分享给你哈

    链接:https://pan.baidu.com/s/1W7-_et-wulD7AueBU2KTow 密码:mgl1

    2019-10-11
    2
  • 牧野静风
    希望老师后续重点讲下如何落地DevOps

    作者回复: 你好,感谢你的留言。

    第一部分重点还是理论基础,建立对于DevOps的明确认识,这一部分尽量精简,重点会放在第二部分落地实践里面。

    当然,各个企业所面对的业务形态都不尽相同,也欢迎你提出关心的问题,我们共同讨论。

    2019-10-10
    2
  • kirajun
    老师好,如何说服公司经营层推行 DevOps 呢?如果只是 DevOps 的 4 个结果指标,在经营层面似乎不太关心,研发内部的质量和效率改进,如何更好的有外部价值体现?

    作者回复: 你这句话说的太深刻啦,也抓住了核心,思考到位,给你点赞👍
    回到问题本身,研发效率质量指标和经营业务指标的关联,从而证明效率提升有助于业务提升,这是一个巨大的难题。现在更多的还是说交付需求变快啦,吞吐率提升了,业务方更加满意了,但是,这个需求交付了,对公司的业绩有什么影响,这更多的是业务分析的事情。
    我们公司最近也在摸索这个事情,也建立了一些模型,理论上来说,随着大数据,线上追踪,加上各类埋点监控等的成熟,以及综合用户反馈用户性能等多个指标,是有条件追溯全链路的业务价值的,但是说实话比较难。
    你的这个问题,我作为遗留事项,最近也跟更多的行业公司交流探讨,希望在度量实践的章节给出一个比较好的实施方法来!

    2019-10-12
    1
    1
  • 老王的老李头
    我会把老师的专栏背熟,让后直接去说服他。

    作者回复: 哈,那不如不经意间地分享给他😄

    2019-10-12
    1
    1
  • 阿硕
    企业的数字化转型有没有一个通俗易懂的解释呢?devops的实施是否就代表着实现数字化转型或者有关呢?

    作者回复: 你好,你的这个话题就有点大了,软件对于企业的价值不言而喻,我只能说DevOps所代表的IT变革,以及新的开发模式有助于企业的数字化转型,因为越来越多的企业通过软件即服务来创造价值。
    比如电商行业在寻求新零售,无界零售,不再是单一卖货,而是寻求人,货,场之间的关系,让零售无处不在。而技术的进步,又使得数据指数级增长,传统企业互联网化和新业务形态的扩展,都共同推动了DevOps的火热哈。
    至于数字化转型的定义,我理解业界也没有标准的定义吧,关于数字化方式和传统方式的对比,我引用一段描述供你参考:
    传统企业和数字化企业最大的区别在于工作方式的不同。传统企业更多地在做两种模式,一种是经验式管理,另一种是以孤岛形式存在的IT管理。“传统企业的目标是通过机制的设置,达到效率的提升。但是在这样的过程里有一个问题:人没有被解放出来。人在流程里只是一个节点,就像生产线上的一个螺丝钉,围绕着流程转。”
    而数字化企业的做法,一是行为在线化,企业里所有的行为,包括人的行为、组织行为是在线的;二是数据在线化,所有的人、财、物、事都被数据化,实现在线通达。这样,人就被解放出来了,不再围绕着机器工作,而是机器围绕着人来工作。“这种以人为本管理模式下所有流程都能以它最合适的方式,随时随地由人发起它的改进和优化过程。”

    2019-10-11
    1
    1
  • Jxin
    1.数据上高效率同时高质量。devops有一定推进作用,毕竟更快部署,确实可以带来连带作用。不过,架构抽象、流程制度等等易是影响因素。
    2.感觉老师这边提的devops怎么有点效能工具团队的味道呢。
    3.感觉对devops的认知要在老师这里被颠覆了。我原本认为devops的突出价值,应是开发运维结合后产生的奇迹。以k8s为例子,docker公司曾经就是pass公司中一个微不足道的小公司,但当docker开源走红后,便迅速崛起,其他pass的大企业都还没开始还击就已经被按倒在地上,可谓是降纬打击。但k8s的出现却又直接把弄潮儿、不可一世的docker公司一下子打落皇座(2014年docker公司距离成功真的只有一步之遥)。那么k8s为什么能创造如此奇迹?我认为这便是devops的奇迹。k8s具备两个特性,优秀的编排能力(pass平台要干的事,要解决的问题。偏dev),优秀的架构抽象和领域设计(作为专注于面向对象的javaer,看k8s的实现,声明试api的应用,真的是震惊,惊叹,虽然它用的是所谓的面向连接的go。偏ops)。而这两个特性正是devops的组成,开发 + 运维一起实现的。而这样产生的奇迹,正是我原本认为的devops价值的可能性。

    作者回复: 你好,抱歉这么晚才回复,被你猜到了,我目前的确是在负责公司的工程效率体系建设,效率这种东西是永恒的,而DevOps是其中一种手段。
    你说到DevOps的价值,其实公司里面关注的还是业务指标,成本,研发资源的有效利用,而这些只靠开发和运维的结合是远远不够的,比如测试的效率如何解决,从我的角度来看,其实运维的成熟度已经非常高了,再加上像k8s这样的工具出现,真是大大简化了很多事情,我们公司的开发都是自己部署的,而测试和业务才是瓶颈。

    2019-10-10
    1
  • 萨瓦迪卡么么哒
    建议在试读阶段写一点技术层面的干货,很多人也提到了所谓的落地实践。否则很难判断课程的实际价值。

    作者回复: 你好,感谢你的建议,由于课程会按照既定的大纲来持续迭代,你可以选择感兴趣的内容进行试读,当然更欢迎你提出所感兴趣的点和问题,我们也可以随时交流哈。

    2019-10-10
    1
  • Geek_599062
    可以建设工程师文化的团队,可以提升软件交付效率,可以提升软件交付质量。最重要的是,软件用户会因为交付的提升说IT 部门牛X,年底也不会那么狠砍IT预算。

    作者回复: 哈哈,大家好才是真的好,就像极限编程里面提到的40小时工作制的实践,如果DevOps有助于缩短996的问题也是很好的。

    2019-10-10
    1
    1
  • 就不告诉你
    我的困惑是,Devops是以单项目方式推进,还是多项目共同推进?时间紧,任务急的情况下,这东西怎么去整合?常规的落地需要多久?

    作者回复: 首先DevOps的落地本来就不是一朝一夕的事情,对于很多研发实践来说也是如此,比如持续集成提出快20年了,到今天理念还是那个理念,但是真正能做好的公司其实并不多。
    另外关于落地方式,我的建议是试点团队+平台团队的方式来做,试点团队验证研发模式和工具平台,平台团队沉淀标准规范和工具能力建设,二者结合跑通一个项目之后,再把经验横向来复制。如果多个项目并行,除了问题影响面太大,再加上时间紧,任务重,结果就是亚历山大哈。

    2019-10-10
    1
收起评论
30
返回
顶部