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

10 | 配置管理:最容易被忽视的DevOps工程实践基础

石雪峰 2019-11-02
你好,我是石雪峰。从今天开始,专栏正式进入了工程实践的部分。在 DevOps 的体系中,工程实践所占的比重非常大,而且和我们的日常工作息息相关。正因为如此,DevOps 包含了大量的工程实践,很多我们都耳熟能详,比如持续集成、自动化测试、自动化部署等等,这些基本上是实践 DevOps 的必选项。
可是,还有一些实践常常被人们所忽视,但这并不代表它们已经被淘汰或者是不那么重要了。恰恰相反,它们同样是 DevOps 能够发挥价值的根基,配置管理(Configuration Management)就是其中之一。它的理念在软件开发过程中无处不在,可以说是整个 DevOps 工程实践的基础。所以今天我们就来聊一聊配置管理。
说了这么多,那软件配置管理到底是个啥呢?
熟悉运维的同学可能会说,不就是类似 Ansible、Saltstack 的环境配置管理工具吗?还有人会说,CMDB 配置管理数据库也是配置管理吧?这些说法都没错。配置管理这个概念在软件开发领域应用得非常普遍,几乎可以说无处不在,但是刚刚提到的这些概念,都是细分领域内的局部定义。
我今天要讲到的配置管理,是一个宏观的概念,是站在软件交付全生命周期的视角,对整个开发过程进行规范管理,控制变更过程,让协作更加顺畅,确保整个交付过程的完整、一致和可追溯。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《DevOps实战笔记》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(14)

  • Robert小七
    老师是否有落地的方案呢?这篇专栏都是讲的概念,在devops研发运营一体化中都有相应的介绍!但是对于如何落地,我觉得这个才是重点

    作者回复: 你好,每个企业面临的实际问题都不相同,很难给出一个通用的落地方案,但从配置管理的角度来说,最重要的就是识别和管理配置项,也就是将一切纳入版本控制,并且是要遵循规则纳入管理的,我的建议是你把软件交付过程中涉及的这些配置项通盘梳理一下,看看是否都满足这个要求。纳入管理之后,就要建立流程方面的上下游关联和联动,比如开始可以从需求和代码的关联做起,再逐步扩展到其他配置项内容。当然,也欢迎你提出你的实际问题来,这样可能会更加聚焦一些,谢谢。

    2019-11-02
    1
    4
  • holen
    老师讲的都是概念,能不能结合老师公司的实践讲一下贵公司是怎么做的吗? 虽然 每个企业面临的实际问题都不相同,方案也不一样, 但是 我们可以从案例中 得到一些思路或者启发, 而不是这样听一些概念,然后还是不知道从何入手!

    作者回复: 嗯,可以简单给你介绍下我们的一些过程吧,其实最早也是没有专职的配置管理职能的,软件的发布和集成都是研发团队自行管理。推动这个事情的契机是公司决定加快版本发布节奏,从三周一个版本推进到两周一个版本,看起来缩短了一周时间,但就像之前演示的部署引力图一样,方方面面的影响都在阻碍这个目标。
    所以,我们决定引入配置管理智能,初期就做两件事,一个是重新定义分支策略,从长分支改为了短分支加特性分支的模式,第二个是管理集成权限,从任何时间都有人能集成,到按照版本周期管控。在这个过程中,梳理了代码仓库的目录结构,存储方式,并基于流程建立了在线提测平台实现研发过程的线上化。
    接下来配置管理结合平台和流程先前先后开始延展,向前管理需求代码关联,事中将构建测试等过程工具以及环境配置纳入统一管控,向后定义了版本发布和上线规则。在团队走上正轨有序开发之后,逐步加强平台和自动化能力的建设,比如代码提交失控,那么就做集成线上化,测试验收通过之后自动合并代码,比如环境差异大,就通过容器化和服务端配置管理工具,实现统一的初始化。构建速度慢,就通过网络改造和增量编译提升构建速度。从而最终使得版本发布这件事情变成一键式的操作。
    我想说的是,实践有很多,但是哪些可以用于解决实际问题,还要把握原则,如果你不知道该从何入手,不妨看看现在的软件交付流程,是否是由配置管理来驱动的,是否还有一些数据是失控和混乱的状态,是否版本的信息还无法完整回溯。对于配置管理来说,标准化,自动化,服务化是一条通用的路径,以上供你参考。

    2019-11-06
    3
  • albertz
    提交记录那部分让我想到这一点:Code Review的起始点应该是commit message,从这里可以看出一个开发人员对自己的工作成果是否有信心和责任心,以及表达能力。也是一种综合素质的体现。我们就是做软件配置管理的,没天看到的无数提交记录,真的是千奇百怪,良莠不齐,有的干脆是不知所云,或者就是写一串无意义的字符。现在我们通过工具强制填写JIRA号和任务信息,算是略有改善。所以我想说,对自己的代码负责,想让人刮目相看,从写好commit message做起。

    作者回复: 没错,每个人写下的每一行代码和提交注释都是自身credit的体现,良好的习惯也要通过流程来培养,为了加速这个习惯的养成,适当的规则建立也是很有必要的。

    2019-11-02
    2
  • 陈斯佳
    老师,问一个和文章无关的问题。就是我自己打算每年考一个证,通过考证来督促自己学习。您觉得想要作为一个合格devopa工程师,哪一本证最值得考呢?AWS的SysOps Admin Associate含金量如何呢?谢谢

    作者回复: 你好,坦率的说,我个人对于考证不是特别热衷,当然不是质疑认证本身的价值哈,对于咱们这行来说,单纯的输入式学习,效果不见得好,我觉得还得要看跟你当前工作或者未来发展方向相关的认证,就像你说的以考试来督促学习,但是也更建议通过输出来督促学习。就好比我在写这个专栏的过程中,有很多东西也不完全清楚,没有深究,但是为了体系化输出,就必须有针对性的补充相关的知识图谱哈。可以给自己定一个小目标,在团队内分享一个系列课程,说不定在交流中,会有新的收获哈。

    2019-11-05
    1
  • 悟空
    和前面同学一样的问题,老师讲的都是普适性的道理,但是否在实际操作中,接触devops比较少的话,听的感觉很爽,实际操作仍然感到不知从何入手呢?
    极客时间,有不少专栏都是讲类似"devops"思维的课程的,内容都很精辟。希望可以搞一个入门级的"devops实践",不需要结合学员们各种各样的场景。只是假设一个场景,走一遍流程,这样是否可以给读者一个更全面的认识呢

    作者回复: 你好,感谢你的留言,的确以DevOps的广度而言,其实每一讲的内容都可以独立展开为一篇专栏。为了帮助大家更好理解和上手,我也在准备一个完整的端到端流水线的实例,通过一次代码提交到上线的完整过程,来理解贯穿前面所讲过的这些实践理念,大约会在专栏靠后的部分上线哈。

    2019-11-05
    1
  • 工画师
    这次课程真的可以收藏了。我们公司现在就在做DevOps,通过访谈梳理出来的痛点,核心问题都集中在这次课程中提到的问题了,这四点是一切的源头。此外,我们还有一个问题是配置管理是从局部向上设计的,有些过度,把自己提升到管理和审批的角色,制定了复杂的流程、规范和交付物……所以我觉得这次课程再谈一下配置管理“度”和边界问题就完美了。配置管理会涉及变更管理和缺陷管理等,但相关联是否到了项目管理的控制程度,这个问题不能模糊,否则会阻碍自动化流程的效率。

    作者回复: 你好,我的理解配置管理和项目管理是不同的思路,配置管理虽然也会涉及到流程的梳理和定义,但这些都是为了更好的配合配置管理的理念而存在的手段,而项目管理是为了在资源、时间、范围的约束下达成目标,一个偏落地执行,一个偏优化改进,虽然实际工作中,这两拨人经常会打交道,但我看到的是冲突大于合作。。。

    2019-11-04
    1
  • 阿硕
    石老师,您好,请教下什么样的角色适合担当起配置管理呢?考核是统一管理还是各自独立呢?

    作者回复: 你好,在以往公司内部都有专职的配置管理员,不过近些年来这个岗位本身有些模糊,在互联网公司随着流程和工具平台的成熟度提升,慢慢都会转到工程效率,版本团队来兼任,这个还是要看你们公司的业务形态,一般组织级会统一建设配置管理能力和规则。

    2019-11-03
    1
  • zy86
    其实软件的版本管理好做。但是现在我感觉我们公司最难做的是数据库表结构变化的管理。我们是java开发。当然我们可以使用flyway这样的组件来做。但是又对这种自动的数据库脚本执行插件感到害怕。怕上线以后如果谁写了删库代码。那就尴尬了

    作者回复: 嗯,工具还好,类似Inception之类的工具都比较成熟,关于数据库变更脚本,还是要有Review过程以及自动风险分析的,如果有危险操作不会通过自动化检查。

    2019-12-03
  • sugar
    全流程版本控制带来的好处,三年前因为一次事情自行做了版本控制,当然仅限于系统和数据库方面,但是节省了不少的排错时间,出现问题后,分析配置管理带来的可能影响,真是分分钟的事。

    作者回复: 赞,统一变更控制是核心能力,即便哪天不流行DevOps了,这个也不会过时的。

    2019-11-08
  • 天天向上
    为啥叫配置管理 这个名字很容易让人想偏
    版本管理 变更管理 追溯管理 感觉都比配置管理好理解

    作者回复: 的确像你说的,给一个人解释清楚配置管理是什么并不是一件简单的事情,就跟用一句话说明白DevOps是干啥的一样。不过,我倒觉得版本,变更,追溯都是配置管理的领域范畴,也是配置管理的目标,如果说做到全流程可追溯,大家可能理解起来会更直观一些,anyway,我觉得核心还是要把这些思想落在日常流程定义,工具平台开发里面才能发挥真正作用哈。

    2019-11-07
  • 高山上的鱼
    老师好,听了好长时间课程,第一次留言。从2012年至今一直在做配置管理相关工作,正如副标题所言确实是被忽略的工作。大家耳熟能详的都是开发、测试、运维等等,每次别人问我做啥的,我说配置管理,他们的表情都是一脸茫然。当接触到devops后,深深感觉到配置管理和devops的联系,配置管理其实是整个软件研发过程中的基础工作,项目之所以版本管理混乱也是没有配置管理意识,记得《配置管理最佳实践》中开篇强调,不懂配置管理的项目经理肯定不是一个好项目经理。这么多年的配置管理工作让我更加确定devops是未来我的方向。也专门学习过python开发、docker、k8s,并将java和php项目在k8s中实现,初步实现了开发提交代码到配置库,触发k8s平台创建jenkins master pod,然后触发创建jenkins slave pod进行持续集成,调用harbor仓库拉取基础镜像(tomcat,mysql等)进行部署,中间过程通过pipeline实现。但是在工作中领导更注重理论,不太关心实践,请教老师我怎么去开展工作比较有效。或者我需要具备哪些能力才能加入您所在的团队。

    作者回复: 你好,抱歉最近双11比较忙,才有时间统一回复大家的留言。
    首先,我想说的是,配管并没有没落只不过是换了一种新的形态,更加关注于工程效率领域,比如效能产品,效能平台,效能落地项目等,我个人认为这个方向是很有前景的,也一直在这个方向摸索,所以,加油哈!
    至于领导注重理论,我觉得也不是什么坏事,如果领导连理论都不懂,那就更是费劲了,当然我也相信领导更加关注结果,结果来源于实践,所以这个并不冲突。
    关于你说的最后一个问题,我的建议是私聊哈,你可以加我微信:cendrier 😝

    2019-11-07
  • 陈斯佳
    真是见Commit Message即见人品。是得好好学习如何写注释了,为了他人,也为了将来的自己…

    作者回复: 嗯,把每一次提交都当做自己的名片来对待,加油哈。

    2019-11-05
  • leslie
    其实“版本变更标准化"和"全流程可追溯"是一个典型问题:都是靠人的大致记忆或者去搜,很多会去抱怨干嘛写那么多/详细的注释;领导不强行推或者说各自一个标准,其实这是后面出现问题排错的一个巨坑。
          "单一可信数据源"其实还好控制:测试测完了才能放上去,让软件测试去把关;彻底没有问题的才能放上去,这样就能避免不少问题。开发不写注释或者注释的问题确实很难强行去规范,除非不达标就不让上线。
          

    作者回复: 可能随着企业规模的扩大,单一可信数据源的问题会越来越明显吧,至少在我所在的公司,这就是一个非常大的通病,各个系统之间难以有一套标准的语言来实现打通。

    2019-11-02
  • 熊斌
    四大理念里面,对于我们公司而言,最难的是第一条—版本变更标准化。

    问题在于有了标准之后刚开始一段时间大家按部就班得按标准化流程去执行,后期处于疲态后完全忽视标准的存在,仅仅将成果物做了版本管理而已。主要原因我觉得是领导也睁一只眼闭一只眼

    作者回复: 是的,如果标准不能固化在工具平台之中,的确容易流于形式,标准能够被绕过,说明还是没有重视这块的价值吧,这么细节的内容,可能领导也的确关注不到。

    2019-11-02
收起评论
14
返回
顶部