研究洞见：构建 DevOps 文化没有银弹

InfoQ 在 2015 年第四季度做了一项调查，调查 哪种 DevOps 实践最有益于一个健康的 DevOps 文化，同时跟进了“ DevOps 文化模式”系列文章（电子杂志同样可用）。其目标是通过社区投票选出优秀的实践。

尽管广泛的结论不能从 72 名参与者的投票（截止 2015 年 12 月 30 日）中推断出来，但是也有一些结果需要引起我们的关注。

最明显的结果是没有一个实践在参与者之间达成共识。实际上，甚至没有一个实践达到总选票的 10%：排名第一的“在 Sprint/Backlog 中包含运营需求”只有总选票的 9%。但是，所有的实践都至少得到了 2 名参与者的投票（投票最少的“基础设施代码评审”有 7 票）。

考虑到对 DevOps 并没有标准的定义，和 / 或者没有标准的实践清单，因此这种结果并不奇怪。结果指出为了实现 DevOps 文化每个组织可能需要一组不同的实践，除其它特定情境因素外，还取决于他们目前的文化、体制和变革的阻力。

如果我们关注排名前 5 的实践（占总投票的 40%），我们会发现开发和运营保持一致以及促进共享的工作流程和目标的重要性：

• 在 Sprint/Backlog 中包含运营需求

• 在开发 / 产品团队中加入运营工程师

• 为关键指标共享目标和责任

前 5 中的 2 个与自动化相关的实践从根本上来讲是为了推进快速交付和反馈，因此没有太多的惊喜：

• 自动化机器配置

• 基础设施即代码

有趣的是，排名第 6（“开发监控应用性能”）和第 7（“开发负责应用的部署”）专注将传统运营职责分派到开发团队。除了让人们更接近应用代码和架构，以便执行任务（从而减少开发与运营之间的交接开销——有时是责备），这些实践同时还有其它作用，或许解释了为什么它们排名这么高：

• 开发团队能更好地理解在生产环境中非功能性地运行他们应用的影响，从而增加对运营团队的同理心（可能有助于实践 1）。

• 运行团队从每日的部署和监控中解放出来，从而为自动化基础设施和工具释放了时间，而这反过来又促进了这些任务。

• 不需要正式交接和详细 / 脆弱的文档，因为自动化成为常态，而异常由开发团队直接处理。

同样这些实践意味着至少有一个明确的打破开发与运营以及相关的 标签文化之间的“混乱之墙”的意图。

需要注意的是实践清单特意包含了“冲突”实践，其中一个实践声明开发应该负责部署，而另一个实践则规定应该由一个专门的团队负责部署。结果很明显，大家比较赞成前者，因为前者获得的选票是后者的3 倍多。

另一个有趣的现象是，尽管“开发随叫随到”和“开发拥有生产系统的根访问权限”经常被引用作为 DevOps 的需求，但是它们的排名都很靠后。在现实中，这两个实践有意义与否取决于组织文化。投票结果表明这两个实践都不是构建一个健康的 DevOps 文化的基本原则。在高度监管的环境中，它们甚至可能不合理。

最后，因为本次调查与我们“ DevOps 文化模式”系列是并行运行的，有趣的是我们注意到，系列中没有哪一个实践在结果中排名非常靠前，“无可指责的事后检讨”获得总投票的5%，“指导其他团队成员”达到3%。

你希望 InfoQ 更加详细地介绍哪种实践？请在下面评论让我们知道。

查看英文原文： Research Insights:No Silver Bullets for DevOps Culture

感谢陆志伟对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们，并与我们的编辑和其他读者朋友交流（欢迎加入 InfoQ 读者交流群（已满），InfoQ 读者交流群（#2））。