DevOps实战笔记
石雪峰
京东商城工程效率专家
立即订阅
3605 人已学习
课程目录
已完结 39 讲
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 | 迈向云端:云原生应用时代的平台思考
转型案例篇 (2讲)
29 | 向前一步:万人规模企业的DevOps实战转型案例(上)
30 | 向前一步:万人规模企业的DevOps实战转型案例(下)
特别放送 (5讲)
特别放送(一)| 成为DevOps工程师的必备技能(上)
特别放送(二)| 成为DevOps工程师的必备技能(下)
特别放送(三)| 学习DevOps不得不了解的经典资料
特别放送(四)| Jenkins产品经理是如何设计产品的?
特别放送(五)| 关于DevOps组织和文化的那些趣事儿
总结答疑篇 (2讲)
期中总结 | 3个典型问题答疑及如何高效学习
期末总结 | 在云时代,如何选择一款合适的流水线工具?
结束语 (1讲)
结束语 | 持续改进,成就非凡!
DevOps实战笔记
登录|注册

29 | 向前一步:万人规模企业的DevOps实战转型案例(上)

石雪峰 2019-12-26
你好,我是石雪峰。
“向前一步”这个名字,来源于 Facebook 的首席运营官谢丽尔·桑德伯格的一本书《向前一步:女性,工作及领导意志》。她在书中鼓励女性在职场中向前一步,勇于面对挑战,追求自己的人生目标。
我之所以选择用这个名字作为案例的标题,是因为在企业中,DevOps 转型并不是一件容易的事情,我们也需要有勇气向前迈出一小步,去承担这个使命。哪怕只是改变了一个小问题,也是转型过程中不可忽视的力量源泉。
在专栏最后的案例环节,我会用两讲给你介绍下微软这些年的 DevOps 转型故事,以及我在国内企业中的实践总结和经验。
今天,我们先从管理实践文化层面入手,来看看这家传统的软件巨头是如何在经历了移动互联网时代的迷失之后,在容器云和 AI 时代再一次独占鳌头的。
微软的 DevOps 转型并不是一个突然的决定,随着云服务的兴起,用户需求激增,对发布节奏的要求越来越高。这些通过需求的数量就能体现出来。2016 年的用户需求数量比过去 4 年的总量还要多,到了 2017 年,需求数量达到了 2016 年的 2 倍,这就要求团队能够以更快的速度完成交付。
要知道,如果你期望的优化水平是提升 10% 的交付能力,那在原有的组织架构、流程规则下做局部优化就有可能实现。但是,如果要达到 200% 的优化效果,就需要做出巨大的改变了。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《DevOps实战笔记》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(3)

  • leslie
    最近一直在整理笔记,然后整理的过程中发现了自己的问题以及后续应当去做的努力。报了几门程序开发的课程-强化一下自己的代码功力。
         老师现在一篇文章从看完到简单梳理差不多要1小时左右。今天的课程非微软的部分案例场景在上次大会听过-填鸭似的听了2天,真心觉得比上班还累啊。大企业的转变在某些方面都有些类似的,还是对于今天的课程做点补充吧。
        1.建立面向交付的特性团队:这个循序渐进的过程,不过有个核心的前提-领导必须有强大的前瞻性和做事情的魄力,否则这件事情真实落地确实很难;
        2.自组织敏捷团队-保证团队目标的一致性和互相的配合度:需要相当严格和规范的制度与监控配合;
        3.团队转型从中型团队入手-其中包含两种形式:第一种中型企业的核心小型团队,第二大型企业的中型团队;两种方式都能去找到问题且较小的代价一步步去做一些事情。
         以上是对于今天课程的理解和总结:案例挺好挺有代表性的,幸好我今年学的课程够多,不然要开始听不懂了。谢谢今天的分享,期待后续的分享。

    作者回复: 我也补充一点,面向特性的交付团队,这个跟软件架构也有关联,很多公司不是不想按特性交付,而是软件架构决定的交付的节奏一定快不了,这也是为什么很多人在讲微服务的原因,当然拆服务不是个盲目的事情,我只想说康威定律真的是在很多地方都有印证,而逆康威定律也一样有效。

    2019-12-26
    3
  • 陈斯佳
    efficiency不等于effective。快,不一定对,方向很重要。有一个对方向不断矫正的反馈机制更重要。

    作者回复: 有一本书叫做《Effective DevOps》,不是一般想象中的那种DevOps书籍,而更多的把视角落在的组织和人的层面上。在公司时间久了,就会发生一家公司能不能实现DevOps,跟工具的关系是最小的,人和流程,以及思维定式才是最大的问题。就好比两个老板要约一个会议,都是跟自己手下人说,你去找那边的老板约时间,那边的老板时间不妥当,也会让他的手下同步回来。其实想想,为啥两个老板不直接聊下呢,是因为没有工具吗,微信可方便的很呀,而这就是很多问题的根源所在吧。

    2019-12-26
    1
  • maomaostyle
    老师可否解释下具体什么叫特性?这个概念如何定义?谢谢
    2019-12-30
收起评论
3
返回
顶部