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实战笔记
登录|注册

06 | 转型之路:企业实施DevOps的常见路径和问题

石雪峰 2019-10-24
你好,我是石雪峰。今天我来跟你聊聊企业实施 DevOps 的常见路径和问题。
由于种种原因,我曾直接或者间接地参与过一些企业的 DevOps 转型过程,也跟很多企业的 DevOps 负责人聊过他们的转型故事。这些企业的转型过程并不是一帆风顺的,在最开始引入 DevOps 的时候,他们也面临很多普遍的问题,比如企业业务都忙不过来了,根本没有时间和精力投入转型工作之中,或者是企业内部的系统在经历几代建设之后变得非常庞大,以至于谁都不敢轻易改变。
但是,即便存在着种种问题,我也始终认为,DevOps 转型之路应该是有迹可循的。很多企业所面临的问题并不是独一无二的,甚至可以说,很多公司都是这样一步步走过来的。所以,在转型之初,如果能够参考借鉴一条常见的路径,并且对可能遇到的问题事先做好准备,企业的转型过程会顺利很多。

两种轨迹

其实,对于企业的转型来说,DevOps 也并没有什么特别之处,跟更早之前的敏捷转型一样,如果想在企业内部推行一种新的模式,无外乎有两种可行的轨迹:一种是自底向上,一种是自顶向下。

自底向上

在这种模式下,企业内部的 DevOps 引入和实践源自于一个小部门或者小团队,他们可能是 DevOps 的早期倡导者和实践者,为了解决自身团队内部,以及上下游团队交互过程中的问题,开始尝试使用 DevOps 模式。由于团队比较小,而且内部的相关资源调动起来相对简单,所以这种模式比较容易在局部获得效果。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《DevOps实战笔记》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(12)

  • iiiqueena
    老师,在J型曲线里为什么会有”自动化导致人工处理的测试增加",自动化的进程中不是也增加了自动化测试么?测试的压力从手工转到编写自动化测试脚本,人工处理的测试增加时怎么回事呢?

    作者回复: 是这样子,由于开发辅助工具以及需求拆分导致开发完成的需求加速,流转到测试团队就对测试团队带来的更大的压力,如果测试团队的自动化能力没有跟上,那么就会产生瓶颈,比如给你举个例子,对于一个移动App来说,开发一个功能可能一天就完成了,但是全量回归测试就要两天,那么开发再怎么快,测试也快不了,这就要求测试能力的提升了,你可能会说,开发只改了一个功能,那么只测一个地方不就行了吗?事实上,并非这么简单,一来害怕出错,二来依赖关系变更影响分析没有做到位,你怎么敢就事论事呢?

    2019-10-28
    1
    2
  • 书剑
    我们去年7月成立devops小组,先通过jenkins实现了. net应用测试环境构建,paas实现了java应用的平台化构建,目前已通过二开paas平台实现了开发,测试,预发布环境的java应用部署,正在将正式java应用的部署从早期jenkins迁往paas。
    途中有两个问题想请教下老师
    1.虽然将应用迁移至部署平台,但感觉称不上cicd,请问老师cicd成功实践的判断标准是什么?
    2.就是实践devops时,小组成员手上有很多遗留下来的本职工作,以及随着公司发展穿插进来的新工作,导致先前计划的devops相关工作无法按计划进行,这种矛盾该如何处理?

    作者回复: 你好,关于第一个问题,我给你提供一个最简单的指标,那就是如果只修改一行代码,从研发提交到上线发布给用户需要多长时间?你可以尝试基于现有的CICD流程来看看,我可以告诉你的是,从业界调查报告来看,这个时间不超过一天,精英公司不超过一个小时。
    关于第二个问题,我是觉得从来没有准备就绪的时候,并行工作难以避免,如果想保障DevOps的工作推进,就要在流程上约定,比如每个迭代周期,有百分之多少的工作预留给DevOps,如果没有这个底线,那只能说明DevOps的工作优先级不够高。

    2019-10-25
    3
    2
  • sugar
    老师提出的“羽化原则”比较适合我们当前的现状,从底层开始做起,需要一个可以统领的“大脑”,前端时间申请新服务器,整个流程走了一个多月,本来是准备11.11之前切换的,结果服务器下来之后由于网络配置,走流程开通权限啥的浪费了不少时间(主要就在审批),然后管理啊系统封版,只能等到11.11后,反正目前问题还是比较多

    作者回复: 你好,像你说的这种申请资源慢,在很多公司我看都是通病,而且靠一个部门也很难解决,人家不听你的啊,所以这种时候就需要DevOps这类专项来改进,甚至需要借助外部力量,明确指出这个地方有问题,其实很多时候聘用外部专家,核心就是透过他的嘴来说出内部不方面说出的问题哈😄

    2019-10-25
    2
  • 陈斯佳
    向上沟通真是很重要的能力,上级是我们能利用到的最好的资源

    作者回复: 没错,但是很多人都不会利用这个资源,我想这跟组织的文化关系很大,我在最早上班的时候是一家日企,第一天就给我们培训的菠菜文化,也就是报告,联络和相谈这三个词的缩写,有进展及时报告,有问题风险及时联络,有创意和想法及时相谈,这三点对我受益匪浅,推荐给你。

    2019-10-30
    1
  • maomaostyle
    当devops转型工作与本职工作并行时,可否采用kanban方法对工作进行优先级和阈值设定,并通过沟通协商来制定针对触发阈值的决策

    作者回复: 你好,其实DevOps转型工作和本质工作,都是需求,只不过我们人为的区分了业务需求,技术需求,持续改进需求等多种类型而已,实际上对于优秀的DevOps来说,持续改进类需求和技术需求会占据固定的比例,而不是业务需求的牺牲品。比如像谷歌的工程师,每周有20%的时间是自由的,就是公司鼓励创新的一种途径。
    关于看板的使用方法,欢迎继续往后听,我会通过两讲来进行详细的介绍。

    2019-10-28
    1
  • Oliver
    我是负责移动端的devops建设,目前devops团队就我一人,现在的自动化就部署了jenkins去自动化编译,打包,测试 ,发布到应用市场这样一套流程。 后续的工作就不知道怎么去开展和推进了,有点迷茫。

    作者回复: 你好,我现在也是在负责移动端的项目,我觉得根据项目规模不一样,痛点也不一样,比如我们之前的发版动作比较复杂,还必须专人负责,这就可以优化为一键发版,任何人都能操作,减少人与人之间的依赖。再比如,安全扫描的环节手动执行,这就可以把这个环节串联在流水线中也让他自动化,减少部门与部门之间的依赖。还有,测试安装调试包很复杂,需要自行下载连接手机安装,那么就可以通过二维码,发送链接,手机访问网页等方式一键推送和下载,减少人和机器之间的依赖。所以你看,在主流程跑通之后,其实有大量的可操作空间,这就要站在全局视角观察整个流程的瓶颈点,看看有哪些是自己能做的,也就是持续改进的过程。

    2019-11-13
  • Jxin
    1.move fast and break things
    2.我感觉我在看的不是devops,而是实施敏捷开发,精益开发,增长理念落地,和分工协作,群策群力。总之,好泛。

    作者回复: 呵呵,好经典的一句话,只不过我总觉得break既可以翻译成打破常规,也可以翻译成把系统搞挂,要选哪个就看DevOps的了😄

    2019-11-08
  • 雷霹雳的爸爸
    要说问题,可能在于整个组织把这个工作当成负责devOps工具平台搭建实施的那些人事情了,而这些人自己甚至也认为devOps的相关工作比业务相关的优先级要低,往后排,长此以往,也就没有以后了的感觉

    要说解决,估计还得各种吹风儿,尤其给领导的吹边风儿,争取更多的授权,然后再借一些业务开发问题引入一些具体实践措施,也算瞒天过海,用心良苦了吧

    作者回复: 精辟!我就在做给最大的领导吹风的事情,但是要把这个事情提升到战略高度,让老板理解的前提下认为这件事情跟业务同等重要,我只想说,不容易,这就要用到一些整理信息的技巧了,比如“推拉镜头”,从小点着手,不断变焦到全局,最终达到目标,我下周试验一把,回头给你反馈😝

    2019-11-08
  • 陈文涛
    军工企业一年两个版本 就不需要、无法应用 devops么?表示存疑

    作者回复: 你好,我忘记有没有说了,今年再碰到这个朋友,他们对DevOps的模型框架非常感兴趣,只能说不是不适合,只是时候未到吧,不知道你有什么观点呢?

    2019-11-06
  • 熊斌
    每学一篇,老师文中描述的问题我们项目都有。

    作者回复: 不仅仅是你们团队,我见过的绝大多数公司问题都有类似,还是组织问题没有解决,期待你的更多思考和解决方案,一起来做实践者,加油

    2019-10-28
  • 信鸽
    地区和文化限制 IT的前沿技术在我们这里至少延后3年 学着以免日后被淘汰

    作者回复: 技术不分国界,地区,我见过有些公司的程序员就是在家里办公,网络已经大大加速了信息流动效率,参与关注一些开源项目,是很好的选择哈,一样,你能找到一个领域,并成为专家,加油。

    2019-10-24
  • leslie
    打卡学习,积累知识和经验待以后自己使用😀

    作者回复: 加油哈

    2019-10-24
收起评论
12
返回
顶部