DevOps实战笔记
石雪峰
京东商城工程效率专家
立即订阅
3611 人已学习
课程目录
已完结 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实战笔记
登录|注册

特别放送(五)| 关于DevOps组织和文化的那些趣事儿

石雪峰 2019-12-24
你好,我是石雪峰,今天又到了特别放送环节。写到这儿,专栏已经接近尾声了,我想再跟你聊聊 DevOps 的组织和文化。
DevOps 文化好像是一个矛盾结合体:一方面,文化这种东西似乎只可意会不可言传;另一方面,文化对 DevOps 实践的重要性又是毋庸置疑的。
在各种行业大会上,关于文化的议题总是屈指可数。原因也很简单,关于文化,一般都说不明白,即便能说明白,也改变不了什么。因为文化的改变可不是像引入一个工具那么简单,很多时候都需要思想上的转变。
谈到 DevOps 文化,我想到去年我和几个朋友一起组织《DevOps 实践指南》的拆书帮活动。这个活动就是,通过连续几周的线上分享,我们帮助大家总结提炼书中的核心知识。
在分享的过程中,有这样一件事,我印象特别深刻。事情的起源是原书的第 14 章中有这样一段描述:
团队在客户面前没有任何需要隐藏的,对自己也同样如此。与其把影响线上系统的问题视为一种秘密,不如尽可能地将它透明化,主动将内部的问题广而告之给外部用户。
某大型公司的 IT 负责人刚好负责分享这个章节,他表示,为了尊重原文,他保留了这段描述,但是在国内的环境下,这并不现实。即便是他自己,一个坚定的 DevOps 实践者,也很难做到这种程度。因为如果把公司内部的问题通通开放给客户,那估计转天就可以收拾东西回家了。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《DevOps实战笔记》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(3)

  • 陈斯佳
    老师,突然有个问题好奇的问一下,你们公司的开发和测试环境,与生产环境是同一个组负责的吗?我们公司有专门的Unix团队和OPS团队负责生产环境上的发布,我们这个部门专门负责开发和测试环境的自动化,我们的工作就是给生产发布提供测试过的包。说实话我还是很喜欢我现在这个岗位的职责,因为不是生产环境,所以不需要值夜班。好奇这样的岗位会不会普遍?你们公司是不是也有这样的岗位?

    作者回复: 恩,你说的这种情况还是非常普遍的,无论是部门职能划分的缘故,还是类似金融保险的监管要求。对于互联网公司来说,其实没有这么清晰的边界,像我们这边首先无论你是什么环境,部署的平台和工具都是同一套,当然自建的集群除外。然后无论是部署测试,预发,生产都是研发自己来做,运维不负责应用的发布工作,上线有一定的流程要求,所以这块并没有实现完全的自动化。不过运维该值班还是要的哈,纯无人值守还是有点理想。

    2019-12-24
    2
  • leslie
    提到删库且注意到没备份的事情其实不只老师所说的有,我同样听过类似的案例。相关信息不能透露不过确实真实发生过,不过可能由于DBA确实是业界的资深人士且及时处理后果被控制到最小化且几乎没啥影响。
         案例简述:某天1测试数据库被删,同行反馈;该公司DBA立刻检查,不过排查过程中发现不仅权限不对且之前生产做的备份报警策略未生效,不仅测试数据库被删且多日数据库其实一直备份失败;立刻权利回收且修改备份报警策略。究其问题其实是开发和运维同时犯错了,所幸DBA够资深且检查够细致避免了可能的灾难性事故的发生。由于各方都有责任,内部相互预警处理的。
           国内外的文化差异就是:问题是否直接公开,其实gitlab的处理方式应当算是一次极其成功的危机公关。前段时间ES被爆出安全漏洞就没有这种魄力去处理危机,采取了和国内类似的藏。问题并不可怕,可怕的如何合理处理好问题,这其实涉及到的属于PM的课程。
            DevOps所要求的能力其实不是表面上的:真实想做好确实需要很全面的软件层能力和处理事情的能力,老师分享的同时算是补了个国内的案例。谢谢老师今天的分享,这事儿真正做好不容易。

    作者回复: 悄悄的说,这种事情我在国内某大行也遇到过,幸好是发现了这个问题,没有导致严重的问题,但是这也给我们提了个醒,越是觉得没有问题的地方,就越应该花时间精力去看。所以最近我们也在安排年末的演练,这次的不同之出在于,不仅仅是安排一个任务下去,有人执行并给出执行结果,而是要把恢复过程内部直播,并让更多的人来挑战你,这样才能把事情做到位哈!

    2019-12-24
    2
  • sugar
    案例很有启发,细节公开,处理步骤都公开确实不好做到,但是这种方式对公司对个人的成长有极其重要的推动。

    作者回复: 其实就像当你知道你的代码会被人Review的时候,你自然会多想想怎么能写的好一些一样,很多时候不公开不透明,就是因为做的烂,真有多少技术含量倒也未必。

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