近日, IT Revolution 发布了一份有声读物,内容是 Gene Kim 和 John Willis 之间将近八个小时的对话、后凤凰项目时代:DevOps 的起源和演变。
《凤凰项目》是一本关于IT、DevOps 及助力企业成功的小说,发表于2013 年,由Gene Kim、George Spafford 和Kevin Behr 合著。这本书致敬了《目标》,那是一本有关生产制造的小说,作者是 Eliyahu Goldratt ,发表于 1984 年。另外,2003 年,Goldratt 还接续《目标》发表了一份有声读物《超越目标:埃利亚胡·高尔德拉特论约束理论》。
Kim 和 Willis 的有声读物收集了他们在践行 DevOps 时的个人观察和思考,他们在对话中通过 9 个单元探讨了使 DevOps 成为今天这个样子的影响因素和思维方式。Kim 阐明了 DevOps 长期存在的核心冲突:
为了让技术能够帮助组织在市场竞争中胜出,我们必须响应紧急的业务需求。那就是说,我们需要能够更加快速地实现变更,但是,我们也需要保持世界级的可靠性、安全性和稳定性。但是,那意味着我们永远不能做变更。两个都是正当的业务目标。你必须响应紧急的业务需求,但也要保持安全性和稳定性。截然不同的行为——更频繁更迅速地变更 vs. 不经常更谨慎的变更。在某种程度上,那是 Dev 的真正体现:交付、交付、交付。Ops 全是关于保持稳定性,那意味着从此不再交付新东西。
Willis 和 Kim 介绍了录制这份有声读物的目的:
自“凤凰项目”至今,我们已经学到了许多东西,甚至在我们开始写作和完成“DevOps 手册”之前。我们把那些东西放到一部著作中,扩展人们的知识面,帮助企业成为高效的组织。我们记录下了所有这些不同的知识体系,展示它们如何汇在一起让 DevOps 成为可能;这是这些原则第一次在工业规模上推广。
第一个单元聚焦于《凤凰项目》本身,第二部分关于 Goldratt,第三部分关于 Deming 。第四到六单元阐述了精益理论和实践、安全文化和学习型组织,最后三个单元更为详细地介绍了一些专家经验(其中包括由Kim 主持 Stephen Spear 、 Sidney Dekker 和 Richard Cook 参加的座谈会记录)、案例(诺德斯特姆公司、Target、迪斯尼、Marks&Spencer、CSG、微软、哥伦比亚运动服饰,沃尔玛、耐克和宝洁),并得出了一些结论。
在整个有声读物中,Kim 和 Willis 提到了许多著作,他们承认,自己也是“站在巨人的肩上”,如 Goldratt、 Deming、Spear、 Mary Poppendieck 、 Ben Rockwood 、 Mike Rother 、 Mark Burgess 、 Peter Senge 、 Simon Sinek 、 Eric Ries 、 Sidney Dekker 、 Dr. Carlota Perez 、 Donald Reinertsen 和 L. David Marquet 。他们探讨了许多原则和实践,其中包括心智模型、“混沌类人猿大军(chaos simian army)”、 COSO 立方、“限制驱导式排程法(drum-buffer-rope)”、“现状树(current reality trees)”、决定论、假设驱动开发、 ETTO 、坏苹果理论以及 Westrum 的组织文化类型学。
Willis 和 Kim 都回忆说,书中的人物和叙事经常引起《凤凰项目》的读者共鸣:
我们听到类似这样的说法:“我知道那个角色。Gene 就像是在写《凤凰项目》时偷偷溜进了我们的大楼”,“我的天啊,Parts Unlimited 遇到的事情就是我们遇到的!”“凤凰项目”带来的其中一个惊喜是,Brent 这个角色引发了 DevOps 社区的强烈共鸣,因为我们都知道那样的人,或者更可能的是,我们都是那样的人。
Kim 介绍了《凤凰项目》的设计目标:
是为了在用于生产制造的精益原则和用于整个技术价值流的精益原则之间建立起同构映射。我们希望,在“凤凰项目”中,我们可以同样清晰地描述技术价值流中的每一个筒仓也面临的每一类问题。
Willis 和 Kim 探讨了让人们和参与者推动 DevOps 向前发展的重要性,Kim 说:
我似乎是顿悟,推出一种很棒的理论是一回事,但是,如果没有一个活跃的社区真正地把它推广到行业中去,那么它就真得变成了更需要智力的学术工作……我曾没见过一个社区会如此贪婪如此渴望地借用其他领域的理念,并把它们纳入我们的工作方式。那就是我为什么对于 DevOps 和 DevOps 社区持有这样的乐观态度。
在这份有声读物中,Willis 和 Kim 详细讨论了 DevOps 的基本原则“三方法(The Three Ways)”,他们经常提到 Kim 的其中一位导师 Steven Spear 博士,他精通丰田生产系统,主张把问题视为学习机会。Kim 把三方法总结为:
这种文化可以培养冒险精神,那样,我们就可以从成功和失败中学习。它是说,重复是精通的前提条件。但是,它还说,那是关于创建一种不断试验和学习的文化。也有学派认为,高绩效企业在市场中胜出是因为他们学得比竞争对手快。 Andrew Shafer 说:“你要么是一个学习型组织,要么就输给一个学习型组织。”
在第七章的座谈会中,Spear 博士从心理安全的角度构建 DevOps 文化的特征:
恐惧并不一定会导致畏缩。畏缩只会发生在大脑几乎短路进入 DO 循环时,“我该做什么?我该做什么?我不知道。我只是坐在地上,一把椅子后面,希望问题自己消失。”但是,那不是我们要讨论的。我们讨论的是,用我们的自制力、谨慎、精力、热情和乐观精神,分辨出我们不知道应该干什么的时刻以及我们应该怎么做,并说,“是这样,但我知道如何解决,因为我接受过训练,并且是问题解决行业的实践者,”因此,那不一定会导致瘫痪。
Sidney Dekker 把这两种思想整合在了一起:
我认为, Allspaw 说的就很好,事件是一种计划外投资,作为一名领导者,如果你不那么看,那么你就无法在已经做的投资上取得回报。
Kim 解释了 DevOps 模型中自动化的目的:
我们希望尽可能多地实现自动化,不能自动化的地方,我们也希望可以减少人为参与,那样,我们就能尽可能接近单件流。在理想情况下,我们会把所有的时间都安全、安心、可靠地配置到单件流中。
Willis 从另一个层面探讨了自动化的重要性:
奇迹的发生不只是因为自动化,还因为从浪费的角度分析了价值流,更重要的是,从全局优化的角度出发察看瓶颈的能力。
Kim 和 Willis 经常考虑使用这些 DevOps 原则理解和改进科技行业工作的价值成果以及技术团队与组织其他部门密切合作的重要性。Kim 注意到:
有趣的是瓶颈最终出现在哪里。我第一次听到这个说法是从来自 Netflix 的 Adrian Cockcroft 那里,还有同样来自 Netflix 的 Roy Rappaport 那里。Adrian 说:“然后,最终限制我们的是产品经理以及我们能够提出多少想法。”换句话说,有多少不错的想法真得值得我们用真正的客户进行测试?他说,瓶颈不应该是 Dev、QA、Ops 或安全。我们不想那些地方有瓶颈。而且,我认为,那与 Eric Ries 和 Steve Blank 的理论很相配:瓶颈应该能产生好的想法。
Kim 和 Willis 认为,科技行业的工作性质通常具有挑战性,因为软件往往是看不见的,系统的复杂性和技术债务的重负让它们变得脆弱、不可靠,而且难于理解。Willis 表示:
Deming 的思想把我们带入了一个别无选择的境地,只能应对不确定性,我的理论为我们创建了一个路径,使我们可以更好地掌握不确定性。因此,失败和效率的融合——这就是我们在 DevOps 中经常谈到的,关于更快推进与更具弹性的反直觉性。
Kim 和 Willis 还较为详细地探讨了弹性和网站可靠性工程,并以误差预算为例说明了如何平衡速度和可靠性。Kim 说:
误差预算结构是自平衡系统其中一个最好的例子。如果开发人员希望速度快,就可以速度快,直到碰壁,然后失速。另一方面,把事情做对的人就可以得到回报,他们可以像他们说的那么快,只要他们没有失去对服务水平目标的控制。
在 Stephen Spear、Richard Cook 和 Sidney Dekker 举行的座谈会里,Cook 从社区知识分享、学习和专业知识几个方面进行了观察:
DevOps 不只是修复问题或获得速度的实践。DevOps 还是建立 DevOps 践行者社区的实践。我认为,和你周围的人分享专业知识是一种道义责任,你帮助他们更好地做准备,应对他们将要处理的那些问题,即使你没有陪在他们身边。我认为,责任需要成为 DevOps 的一部分。我认为,DevOps 需要超出工具链和库的范畴,成为一种涉及人的实践。John 将其称之为“线上(above the line)”。要做到这一点,可能需要我们把自己视为 DevOps 的践行者,而不是某个公司的职员。就是说,对于一名 DevOps 践行者,DevOps 实践实际上是一种专业、一种技能、一种存在于你目前正在从事的具体岗位之外的专业知识。
Kim 和 Willis 总结道,他们观察到的利用 DevOps 原则和实践的高效组织可以描述为“动态学习组织”,而 DevOps 可能是未来生产力激增的一个关键部分。
感兴趣的读者可以从这里下载完整的《后凤凰项目时代》有声读物或者从这里下载完整的对话记录。
查看英文原文: From Darwin to DevOps: John Willis and Gene Kim Talk About Life After The Phoenix Project
评论