DevOps实战笔记
石雪峰
京东商城工程效率专家
立即订阅
3511 人已学习
课程目录
已更新 34 讲 / 共 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体系和持续改进的意义
平台工具篇 (8讲)
21 | 开源还是自研:企业DevOps平台建设的三个阶段
22 | 产品设计之道:DevOps产品设计的五个层次
23 | 持续交付平台:现代流水线必备的十大特征(上)
24 | 持续交付平台:现代流水线必备的十大特征(下)
25 | 让数据说话:如何建设企业级数据度量平台?
26 | 平台产品研发:三个月完成千人规模的产品要怎么做?
27 | 巨人的肩膀:那些你不能忽视的开源工具
28 | 迈向云端:云原生应用时代的平台思考
特别放送 (4讲)
特别放送:成为DevOps工程师的必备技能(上)
特别放送:成为DevOps工程师的必备技能(下)
特别放送:学习DevOps不得不了解的经典资料
特别放送:Jenkins产品经理是如何设计产品的?
总结答疑 (1讲)
期中总结:3个典型问题答疑及如何高效学习
DevOps实战笔记
登录|注册

20 | 持续改进:PDCA体系和持续改进的意义

石雪峰 2019-11-26
你好,我是石雪峰。
今天是“工程实践篇”的最后一节课,如果你现在问我,在这么多的工程实践中,什么能力是团队在推行 DevOps 时最应该具备的?我会毫不犹豫地告诉你,那就是持续改进
很多同学在留言区问我:“雪峰老师,我们公司已经搭建了 Gitlab,也跟 Jenkins 实现了打通,做到了自动化的编译打包和发布工作。可是接下来,我们还有啥可以做的呢?我感到很迷茫啊。”
所以,这就引申出来一个问题:“一个团队做到什么程度,才算是达到了 DevOps 呢?”
每每遇到这样的问题,我就会回想起,几年前我去国内一家知名公司的杭州总部交流的经历。
当时,负责跟我们对接的是这家公司 DevOps 的主要推动人,可以说,他见证了这家巨头公司的 DevOps 转型全过程。在交流时,我问了他一个问题,他的回答让我印象特别深刻。
我问他:“你觉得,你们公司是在什么时候实现 DevOps 转型的呢?”他想了想,说:“现在,我们公司已经没有专职的测试和专职的运维了,基础架构也早就容器化了。这些事情,都是业务发展到一定阶段之后自然而然发生的,只不过,DevOps 火起来以后,我们才发现,原来我们一直在做的就是 DevOps。所以,很难说在哪个时间点完成了 DevOps 转型。对我们来说,最重要的就是团队具备了一种能力,就是始终能够找到新的突破,持续追求更好的状态。”
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《DevOps实战笔记》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(3)

  • iiiqueena
    回顾会挺好用的😁

    作者回复: 重在坚持,以前华为定期有民主生活会,想想其实也是类似的活动哈

    2019-11-27
  • Tom
    这家杭州公司的测试和运维都转去做什么了?

    作者回复: 不再有专门的测试和运维部分,而是打散到业务线里面了,并不是说测试和运维都消失了哈。

    2019-11-27
    2
  • leslie
    关于"故障回溯"其实在金融系统的运维中广泛使用:尤其是故障率/事故率极低的技术部门,只不过这种工作需要一个强硬的leader或者说追求稳定性和持续改进的leader。
        Plan-Do-Check-Act:这个循环看似简单:可是当它深入你的思维理念的时候许多问题就已经解决了不少,可是这个东西如何良好的不断循环和持续让它不断实现确实并不容易。
        老师课程中所说的潜移默化的做出来的DevOps:其看清了问题的本质然后执行了,看到了效果且认可这件事的代价然后去持续跟进、改进且做好。
        问题和效率不是出了一大堆才去解决的:PDCA其实CAPD同样可以,就看什么阶段去开始而已;开始的阶段不同其实这个顺序会有调整,不过最终都是解决了问题。

    作者回复: CAPD的思路很有意思哈,也给我一些启发,既然是循环,那么从任何节点都可以切入,都可以成为一套自己的方法论,用于指导具体实践和规则,赞!

    2019-11-26
收起评论
3
返回
顶部