DevOps 实战笔记
石雪峰
京东商城工程效率专家
37393 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 41 讲
DevOps 实战笔记
15
15
1.0x
00:00/00:00
登录|注册

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

这些文化对于DevOps的实施又有哪些帮助呢?
哪些文化是非常吸引你的?
对人的培训至关重要,让工具平台发挥最大的效用
平台是组织内部的能力集合体
平台具备基础通用共享能力,能够快速搭建新的业务实现
平台的最大意义,就是承载企业内部的标准化流程
平台是标准化流程的载体
责任共担和质量导向的文化
可以定义期望文化下的行为表现,并通过流程的改进来改变大家的行为
正向的文化可以弥合流程和平台方面的缺失
思考题
平台 + 人 = 培训赋能
流程 + 平台 = 工具
人 + 流程 = 文化
DevOps的实施:到底是工具先行还是文化先行?

该思维导图由 AI 生成,仅供参考

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

DevOps 工具

随着 DevOps 理念的深入人心,各种以 DevOps 命名的工具如雨后春笋般出现在我们身边,甚至有很多老牌工具,为了顺应 DevOps 时代的发展,主动将产品名称改为 DevOps。最具代表性的,就是去年 9 月份微软研发协作平台 VSTS(Visual Studio Team Services)正式更名为 Azure DevOps,这也进一步地印证,DevOps 已经成为了各类工具平台建设的核心理念。
在上一讲中,我提到高效率和高质量是 DevOps 的核心价值,而工具和自动化就是提升效率最直接的手段,让一切都自动化可以说是 DevOps 的行为准则。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

DevOps实施中的工具和文化一直备受争议。本文深入探讨了这一话题,强调了自动化和工具平台的重要性,同时指出盲目引入工具可能导致资源浪费。良好的文化对流程和工具发挥作用的重要性也得到了强调。文章提出了DevOps的三个支柱:人、流程和平台,强调了它们之间的相互关联和重要性。通过深入浅出的方式,全面阐述了DevOps实施中工具和文化的重要性,为读者提供了全面的认知和指导。文章还分享了美国第一资本的例子,展示了DevOps实施的成功案例。整体而言,本文为读者提供了对DevOps实施中工具和文化的深入理解,以及对组织流程、平台和人的关注。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《DevOps 实战笔记》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(30)

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

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

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

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

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

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

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

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

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

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

    2019-10-12
    2
    4
  • 柯基道格
    文化VS工具。这个问题在很尖锐,个人认为文化和工具需要齐头并进,而且两者的推广并不冲突,但我认为工具可以先行。因为,文化是潜意识,工具是表意识,文化并不能马上让人接受,人对新文化的接受是慢慢才能接受,有时可能不达到触及某个痛点,可能永远都不接受,但工具不一样,工具是看得到摸得着的,接受起来比虚拟的文化更容易让人接受,就好比让父母用手机支付,如果只是空谈无币文化,而没有真实给他们买上一部手机和装上支付宝,是永远不会接受这个新鲜事务的。 说下我们公司一直存在的问题,我们是国企体制内的公司,想推广文化可比一般的互联网企业难太多了,国企的中上层,可能都不是技术出身(列如部门老大,没写过代码,没做过测试,没干过运维,只是在外包的协助下干过需求),对于技术文化的理解并没有技术人员那么透彻,对于国企管理者来说,只在乎结果完成,怎么过程并不重视。虽然随着DEVOPS的盛行,国企领导也听入其中,但是还是将其视为可以更快的出结果,而不是部门融合的文化。众所周知,国企类公司拥有难以打破的部门壁垒,部门与部门之间就如同次元壁一样难以打破。在这种情况,文件难以推广的情况下,我只能以工具效能的方式去推进,不知这算是无奈,还是这种模式只能如此。

    作者回复: 冰冻三尺非一日之寒,我觉得还是得要借力外部,领导也需要业绩,找个合适的机会让老板也了解下业界同类企业的方向,这种侧向压力可能来的更加直接,其实对于研发效能的提升是个长期的事情,我也见过很多国企老板借这类项目在职位上更近一步的,还是多多参与业界活动,或者找一些咨询的机会哈,事在人为嘛。

    2020-02-15
    2
    3
  • Jxin
    看完老师文章,自己总结下。 1.人的主观意愿 + 制度 = 文化 2.流程的抽象 + 平台的落地 = 工具 3.人的诉求 + 平台的推广 = 培训 平台的定义: 1.可扩展,纵向扩展或横向扩展(不一定必须要很自由) 2.横向扩展,聚合多个工具或服务,助力某一大类工作的所有工作诉求,解决一个更大问题域的问题。 3.纵向扩展,从单体工具或服务,往多租户的工具或服务演变,提供配置化的定制能力。

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

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

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

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

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

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

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

    2019-10-14
    1
收起评论
显示
设置
留言
30
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部