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

03 | DevOps的实施:到底是工具先行还是文化先行?

石雪峰 2019-10-12
你好,我是石雪峰。
当一家企业好不容易接纳了 DevOps 的思想,并下定决心开始实施的时候,总会面临这样一个两难的选择:工具和文化,到底应该哪个先行?
的确,在 DevOps 的理论体系之中,工具和文化分别占据了半壁江山。在跟别人讨论这个话题的时候,我们往往会划分为两个不同的“阵营”,争论不休,每一方都有自己的道理,难以说服彼此。在 DevOps 的世界中,工具和文化哪个先行的问题,就好比豆浆应该是甜的还是咸的一样,一直没有一个定论。
可是,对于很多刚刚接触 DevOps 的人来说,如果不把这个问题弄清楚,后续的 DevOps 实践之路难免会跑偏。所以无论如何,这碗豆浆我先干为敬,今天我们就先来聊聊这个话题。

DevOps 工具

随着 DevOps 理念的深入人心,各种以 DevOps 命名的工具如雨后春笋般出现在我们身边,甚至有很多老牌工具,为了顺应 DevOps 时代的发展,主动将产品名称改为 DevOps。最具代表性的,就是去年 9 月份微软研发协作平台 VSTS(Visual Studio Team Services)正式更名为 Azure DevOps,这也进一步地印证,DevOps 已经成为了各类工具平台建设的核心理念。
在上一讲中,我提到高效率和高质量是 DevOps 的核心价值,而工具和自动化就是提升效率最直接的手段,让一切都自动化可以说是 DevOps 的行为准则。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《DevOps实战笔记》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(15)

  • 铭熙 置顶
    雪峰帅哥,既然你说人加流程等于文化,展开下说如何从人和流程下手,有什么变化?

    作者回复: 铭熙帅哥,特别好的问题,由于专栏篇幅限制,很多内容不好展开,正好在留言区大家一起讨论。
    DevOps倡导职责共担的文化,但实际情况是,如果你的绩效目标跟我的半毛钱关系没有,我凭什么跟你共担责任呢?
    人固然有自身的问题,到我觉得更多的还是流程和机制的设计和导向问题。
    举个实际的例子,比如在梳理发布流程的时候,发现测试回归周期长,完整一次回归要两天时间,请问怎么办?
    第一种就是给测试团队加人,这显然不够DevOps。
    第二种就是做回归测试的自动化,这能解决一些问题,但是自动化成本,技术成熟度,自动化结果的可信度都需要时间,更何况如果自动化出了问题,责任还是人的,那么人的意愿肯定会打折扣。
    第三种,就要多问几个为什么,原来回归周期长的原因是研发没有给出准确的修改范围,因为当前的流程研发提交完代码,连测试包都是测试人员自己来打,服务意识固然不错,但是问题就是你压根不知道改了啥,会影响啥,结果就是全跑一遍,因为即便出了问题,也要各种甩锅,测试责任怎么也跑不开。
    所以缺陷问题只有流程上约定由研发测试一起承担,同时加入测试辅助的研发自测,将测试能力通过平台化赋能,再加上各种DevOps中的自动化手段打通变更信息,进行变更影响分析,这才能根本上解决测试和开发之间的问题。

    2019-10-12
    15
  • 李金洋
    石老师好, 我们是运维团队,如果从运维团队去主导这种devop的推进,有什么好的思路?因为毕竟和开发是两个团队,所以我们之间的工作职能和理念其实不一样,如何能够统一两者,如何能在运维的角度,去让devops能够在所有团队推进起来?

    作者回复: 你好,DevOps倡导开发和运维的沟通和协作,但这并不是一句空话,原因不仅在于部门职责划分的问题,还在于技术能力的不对等。我一直信奉一个选择,想要拯救别人,就先要拯救自己,所以运维内部过的怎么样,是否还有大量的手工操作和线上问题,这些首先是要解决的。
    接下来的核心就是通过平台能力赋能研发团队,转变运维工作的重心向平台化自动化智能化发展。
    简单罗列几个常见的手段供你参考: 1. 将运维的能力通过自动化运维平台开放出来 2. 建立部署流水线 3. 在开发环境打通持续集成和部署过程 4. 将相同的过程先其他环境延伸 5. 根据业务需求共建监控系统,收集埋点数据 ,支持AB测试等6. 简化环境申请流程和初始化成本 7. 试点云容器技术,并和开发团队一起试点 8. 定义标准化环境配置

    2019-10-15
    6
  • 牧野静风
    石老师好,我是一个运维,公司开发部门还是比较传统的方式,推动DevOps是否一定需要CTO级别的人来推动

    作者回复: 你好,这也要看公司的规模,我只能说,管理层的支持至关重要,否则你能影响的范围有限,尤其对于大公司来说,至少是一把手工程。但是管理层的支持仅仅是条件之一,具体怎么实施,试点,给予管理层反馈和数据量化,证明这个事情的价值和可行性,这些都是我们要做的事情哈。

    2019-10-12
    3
  • 老王的老李头
    老板对这事儿还没有一个直观的考量,虽说有老板的加持,但他们总觉得现在这种传统手工作业的形式还挺好。所以我需要系统的知识进行引导,很荣幸遇到您。

    作者回复: 你好,其实大多数老板,如果你说他能听得懂的语言,他是能听得进去的,但是,老板需要看得见摸得着的效果,这也是很多改进项目能否持续下去的重要因素。
    关于这一点,我的建议还是需要有量化指标来展现,比如你们公司目前的研发效率有哪些指标,具体的数值又是怎样的,只要能把这一点说清楚,后面的事情会容易很多。
    至于选择哪些指标,我在后面会专门来分享,简单来说,至少参考业界公认的DevOps四个结果指标,是不会错的,只不过还要结合公司实际,细化指标定义哈。

    2019-10-12
    2
  • Geek_599062
    标准化都还没做好,路太长。对于如何推动公司技术栈的标准化,石总有何高见?

    作者回复: 你好,坦率的说,技术栈的标准化是公司CTO要解决的问题,我关心的是,现在因为不标准带来的问题是什么呢?
    其实DevOps搞了这么多年,各种平台技术栈或多或少都有涉及过,不知道你怎么看哈。

    2019-10-14
    1
  • 陈斯佳
    我们公司现在就在做DevOps的转型,我个人感觉到最大的阻碍,不是流程,而是人。一些老的员工不愿学习新的流程和工具,让转型变得很困难。我自己的实践方法就是,在各个部门中(开发/测试/运维/DBA)找到那个最积极、最愿意改善的人,然后推进新流程和新工具的落地,等有了实际案例流程打通之后,再去和其他人推广。真心感觉人的积极主动才是一切变革的核心和内在驱动力

    作者回复: 看来你很有新得呀,有没有一个案例可以跟我们分享呢,我在计划整理优秀用户留言,让学习和分享成为同学之间的事情,期待👍

    2019-10-14
    2
    1
  • 流浪地球
    老师您好,这句话不是很理解,平台的一些基础设施比如服务器,使用方增多了自然会增值,如何理解不线性增长呢?
    规模效应:平台的成本不会随着使用方的扩展而线性增加,能够实现规模化


    作者回复: 你好,我是这么理解这个问题的。作为一个平台,不应该随着接入的服务方的增加,建设成本也随之增加。那最简单的构建打包这个事情来说,如果每接入一个新的应用,都要定制化的开发页面,数据结构,那就不能叫做一个平台。平台的做法是,通过高度的能力抽象,可以通过简单的配置就能实现业务的扩展。不仅如此,平台的服务成本也是一个道理,如果接入一个用户就要投一个人支持,这就是线性增长的,应该努力避免,这一点我会在平台设计的章节展开来说。

    2019-10-12
    1
  • 鲍建飞
    看了有段时间devops,但感觉一直在门外转来转去,文化工具都有了解,可能还是实践差了一些

    作者回复: 那就找一个力所能及的领域,脚踏实地开始实践吧👊

    2019-10-12
    1
  • 雷霹雳的爸爸
    按照老师文章的定义,流程之下的人形成自身的行为准则,而准则的集合体构成文化;这么看起来,我们公司也没什么流程,我们的准则看起来就是别搞得太难看,谁都别太过分,那么我们形成的文化就是互相尊重,允许自由发挥,崇尚自我约束,就是自律啊...这么看起来我们的文化很高级啊,应该能让我们有了一个宽松的空间来实施devOps啊

    作者回复: 互相尊重,自由发挥,自我约束,请问你是哪家公司的,能做到这种程度,还不出问题并且非常高效,我觉得可以出来分享分享是怎么做到的了😝

    2019-10-29
  • 熊斌
    喜欢那句 “真正的高手,比拼的不是武功,而是思想”,如果想法不对,手里攥一堆工具也是白搭。
    总结起来就是 对的人+对的流程+对的平台

    作者回复: 没错,再好的工具也要有人来使用哈

    2019-10-28
  • 九脉一谷
    这两年来一直在推动内部研发体系的建设,平台从无到有,自主投入研发。但是在平台推广过程中遇到了很多问题,总结一下几点感受:
    1、首先需要有一个认可的部门大领导支持,而且一定是要当成一项重点工作来推进;
    2、平台开发团队的成员也需要形成统一的认识,是为整个公司研发体系服务,是先行者,改革者,同时我们也是平台用户,要坚信通过平台化、自动化、标准化是能够改善现状,提高效率,提升软件质量的;
    3、要长期给项目业务线的核心骨干人员“洗脑”,宣传devops的理念,培训平台的功能点,指导依赖工具的使用,主动帮助梳理他们现有不合理的流程,尽量通过平台来帮助改造;
    平台的建设推广,无论是领导,还是平台开发者,项项目业务线人员,更多的是人的认知的改变。

    作者回复: 我觉得你说的特别好,感同身受,赞一个,如果编辑看到的话,请帮忙置顶,谢谢!
    关于你提出的3点内容,稍微补充一些我的想法:
    1. 大领导的支持不是长期的,无限的,领导也需要及时的反馈,尤其是看得见的数据和成果,以证明这个事情是正确的,有效的,这点非常重要。
    2. 对于平台开发成员来说,如果只是一个纯开发的想法,是很难做好这个事情的,要具有业务思维,努力了解业务现状,并且有独立创新的想法,才能激发内部的创造力,当然认可效率工作的重要性也不容忽视。
    3. 业务线的重心毕竟还在业务上,同时他们也不是工程效率方面的专家,如果期望他们给出解决方案,那显然没有理解这个工作的含义,所以正确的方式的确是识别痛点,给出解决方案,达成一致,快速试点,反馈和推进。

    2019-10-19
  • kalid
    DevOps 由人+流程+平台工具构成一个有机整体,其中最主要的还是人。推动需要一个说得上话的人,推进需要一群志同道合的人,实现则是服务一帮人。把人搞定了,什么都好搞了😄

    作者回复: 哈哈,精妙啊精妙,说的太好啦!话说回来,啥事不是人的问题呢?

    2019-10-15
  • Jxin
    看完老师文章,自己总结下。

    1.人的主观意愿 + 制度 = 文化
    2.流程的抽象 + 平台的落地 = 工具
    3.人的诉求 + 平台的推广 = 培训

    平台的定义:
    1.可扩展,纵向扩展或横向扩展(不一定必须要很自由)
    2.横向扩展,聚合多个工具或服务,助力某一大类工作的所有工作诉求,解决一个更大问题域的问题。
    3.纵向扩展,从单体工具或服务,往多租户的工具或服务演变,提供配置化的定制能力。

    作者回复: 很棒的扩展理解,我应该把这段加到文稿中😄
    其实平台是随着场景的拓展而拓展的,所以需要把人还原到具体的场景之中,思考人和事之间的关系是怎样的,服务化就是一种最好的诠释。

    2019-10-14
  • caozhao
    石老师好,
    devops 看起来虽好,可以提高开发效率,目前又有Aiops出现,如果需要转化到Aiops,devops文化会不会阻碍呢,devops是否有灵活性,可以转化或者可以添加其他技术 丰富devops平台。

    回答问题:
    我们公司 在很多最新的技术方面 比如devops 基本上一张白纸,所以有很大的上升空间,所以我们个人机会也很多,

    作者回复: 你好,AIOps更多的还是Ops领域的一种探索,解决的还是Ops所面对的问题,而DevOps已经突破了单一领域,成为软件交付整体的方法论。
    其实,无论是AIOps,还是DevOps,其实就是个热门词汇,技术进步终将不断革新,所以有人问工程效率和DevOps有什么区别。我的理解是,效率这件事是永恒的,而DevOps可能会被一种新的技术和方法所取代。

    2019-10-14
  • leslie
    谈不上吸引吧:部门文化比较自由,不违法公司规定的事情基本不管-适合自己完成当下并做些技术钻研和探索;本地其它企业都会管理的偏严而忽视了效率。
            学习是为了自己的未来去探索和实践:明白怎么做了当机会来临时把握了就好。就像二叉树视频中鸟哥所说:“机会来临前你已做好了准备,机会来临时抓住就好”😀

    作者回复: 哈哈,罗胖也说过类似的话,这一波机会没赶上怎么办,做好准备,争取赶上下一波呗😄
    我之前所在的公司风格也比较自由,但我现在看来,这还不够,公司有没有一种渠道,让局部创新全局化,说白了如果一个团队一个人摸索出来的新方法很有效,能不能发挥规模效应,让更多人受益,这种激励机制非常重要,否则你做了很多创新,很多想法,但没有用武之地,这对自由来说也是一种打击吧,不知道你怎么看这个问题?

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