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

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

开源为先的共享精神
自由发挥自我价值的空间
心理安全的文化氛围
错误的态度
502页面的利用
透明、公开和坦诚相待
处理方式
事件经过
与DevOps文化相关的故事
对内容的印象
改变企业文化的重要性
DevOps文化的知名内容
Netflix招聘成年人的故事
Etsy三只袖子毛衣的故事
GitLab删库的故事
《DevOps实践指南》的拆书帮活动
文化的重要性
思考题
总结
DevOps组织和文化
特别放送:关于DevOps组织和文化的那些趣事儿
文章

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

你好,我是石雪峰,今天又到了特别放送环节。写到这儿,专栏已经接近尾声了,我想再跟你聊聊 DevOps 的组织和文化。
DevOps 文化好像是一个矛盾结合体:一方面,文化这种东西似乎只可意会不可言传;另一方面,文化对 DevOps 实践的重要性又是毋庸置疑的。
在各种行业大会上,关于文化的议题总是屈指可数。原因也很简单,关于文化,一般都说不明白,即便能说明白,也改变不了什么。因为文化的改变可不是像引入一个工具那么简单,很多时候都需要思想上的转变。
谈到 DevOps 文化,我想到去年我和几个朋友一起组织《DevOps 实践指南》的拆书帮活动。这个活动就是,通过连续几周的线上分享,我们帮助大家总结提炼书中的核心知识。
在分享的过程中,有这样一件事,我印象特别深刻。事情的起源是原书的第 14 章中有这样一段描述:
团队在客户面前没有任何需要隐藏的,对自己也同样如此。与其把影响线上系统的问题视为一种秘密,不如尽可能地将它透明化,主动将内部的问题广而告之给外部用户。
某大型公司的 IT 负责人刚好负责分享这个章节,他表示,为了尊重原文,他保留了这段描述,但是在国内的环境下,这并不现实。即便是他自己,一个坚定的 DevOps 实践者,也很难做到这种程度。因为如果把公司内部的问题通通开放给客户,那估计转天就可以收拾东西回家了。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文通过分享GitLab和Etsy的故事,探讨了在面对问题时,公司如何实践DevOps文化,并思考了这些做法的优势。文章强调了DevOps文化的关键词:协作、分享共担、无指责文化、在错误中学习,以及在实际问题中如何以这些文化为准则来指导行为模式。GitLab在面对数据库停机事故时,选择了公开透明,将事件细节和分析过程记录在公开文档中,并通过YouTube直播和Twitter更新问题状态,赢得了用户的信任和认可。而Etsy则通过“三只袖子的毛衣”奖项,表达了对错误的包容和对文化的偏好,建立了心理安全、快速变化、及时反馈、鼓励创新的文化。这些故事展示了DevOps文化的重要性,以及在实践中的优势和价值。 Netflix作为硅谷精英中的精英之一,通过开放透明、免责文化和心理安全的氛围,建立了自由发挥的工作环境,并以开源为先的共享精神推动了171个项目和插件的开源。这种文化使得员工能够真正发挥自己的价值,为公司创造更大的价值。 总结来看,本文强调了DevOps文化中的几个关键点:建立免责的文化并在错误中学习,通过对外开放透明建立信任促进协作,打造心理安全的氛围鼓励创新,以及开源为先的共享精神。这些都是企业文化转变中至关重要的因素,需要管理层的认同和导向。最后,文章鼓励读者从自身做起,审视团队内部的文化建设,鼓励分享和创新,减少重复建设,从而共同学习进步。 这篇文章通过分享实际案例和企业文化的思考,为读者展示了DevOps文化的重要性和实践价值,对于关注企业文化和技术发展的读者具有一定的启发意义。

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

全部留言(4)

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

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

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

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

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

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

    2019-12-24
    1
  • 棒棒
    文化宏观看是一家公司的格局、胸襟和气魄,微观看是每行 code 的底层实现
    2022-02-08
收起评论
显示
设置
留言
4
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部