上周在硅谷举行 的 IEEE DevOps Unleashed 研讨会 承诺“专家建议如何通过加速整个企业的软件交付来更快地创新”。它几乎交付了，对企业中 DevOps 的理论和实践有很多深刻的见解。但对于许多与会者来说，亮点是 Jez Humble 的 企业 DevOps 演讲 ，他是 Chef 的副总裁和两本关于该主题的书籍的合著者， 精益企业：高性能组织如何大规模创新 和 持续交付：可靠的软件发布通过构建、测试和部署自动化 。
Jez 很有魅力，知识渊博，风趣幽默，数百名开发人员、运维人员和商业领袖的听众全神贯注。他谈到了许多关键主题，您可以 在此处查看他的幻灯片 ，但是这 10 个观察应该让您了解他的观点，以及一些有价值的最佳实践：
1、DevOps不是一个目标，而是一个永无止境的持续改进的过程。
这个想法是创造一种每个人都希望不断变得更好的文化。
2. IT 绩效指标与 IT 绩效预测指标不同。
Jez 说，根据 2014 年 Puppet Labs State of DevOps 报告 ，这些是 IT 性能的四大指标：
- 更改的准备时间
- 发布频率
- 恢复服务时间
- 改变失败率
根据这些指标，这些是 IT 性能的前五个 预测因素 ：
- 同行评审的变更批准流程
- 版本控制一切
- 主动监控
- 高度信任的组织文化
- 开发和运营之间的双赢关系
Jez Humble，主厨副总裁
3. 指标必须不断发展。
Jez 说，DevOps 商店应该避免一直使用相同的指标。 “你必须改进你的衡量标准，”他解释说，因为“每次你衡量某件事时，它都会改变行为。”他补充说，同样重要的是，被衡量的人必须接受这些指标，否则他们会想出一种方法来玩弄这个系统。很多时候，管理层将指标用作攻击性武器，而“这永远行不通”。人们会照他们说的去做，但他们会找到一种方法让他们的指标看起来不错，无论他们是否真的帮助组织实现了目标。
另请参阅： 仔细研究软件开发中的数据文化 [调查报告]
4. 您不必为了稳定性而牺牲吞吐量。
Jez 指出， 2014 年 Puppet Labs DevOps 状态报告 将 IT 质量的关键指标分为两类：吞吐量（包括更改的提前期和发布频率）和稳定性（包括恢复服务的时间和更改失败率）。
根据 Jez 的说法，这不是零和游戏，您必须用吞吐量来换取稳定性。 “如果你做对了，”他说，“情况恰恰相反。”事实上，高绩效 IT 组织在吞吐量和稳定性方面都做得更好，而低绩效企业在这两个方面都做得更差。
5. 外部变更审批流程不起作用。
Jez 将外部变更批准流程描述为“风险管理剧院”。由于外部代码审阅者不了解代码库，因此此类审阅会降低吞吐量并且无助于稳定性。 Jez 询问如何期望外部审阅者审阅数百名程序员的数千行代码并预测其对生产环境的影响。 “它不可能起作用，这就是它不起作用的原因，”他说。
然而，同行评审过程可以加快吞吐量并且不会损害稳定性，Jez 说，因为开发人员在代码库上工作并且了解它的内在和外在。
6. 拥有紧急变更流程是个糟糕的主意。
通常，紧急变更流程会省略测试。杰兹说，这是个糟糕的主意。您已经遇到问题，或者您不会调用紧急流程来修复它，但是在没有测试的情况下进行更改可能会使事情变得更糟而不是更好。 “你想在紧急情况下使用正常的变更流程，”Jez 说。 “这就是你知道你做对了的方式。”
7. 持续交付要求开发人员每天将他们的代码检查到主干中。
“DevOps 是一种实践，而不是一种工具，”Jez 说。持续交付的关键在于为其进行架构设计。所有代码都必须可以独立部署，并且应该在提交到主干之前进行测试，而不是提交到一些极其复杂/昂贵的集成环境。 “这不需要工具，”他说，“只需要软件始终处于工作状态的心态。”对于开发人员来说，将大功能分解为小的、增量的更改也没有什么坏处。
另一方面，如果每个人都在功能分支上工作，他们不仅要将它们与主干集成，还要将它们彼此集成。 这 需要非常复杂的测试自动化。
8. 将损坏的代码留在后备箱是自私的。
如果你不能在几分钟内让它工作，Jez 说，取消更改。任何更改都需要在版本控制中进行，如果出现问题，开发人员需要立即修复问题并测试新代码。
9. 软件测试人员不对质量负责。
每个人都对软件质量负责，Jez 说。测试人员在那里使质量显而易见，以便可以继续进行，而不是为项目增加质量。这意味着测试不是开发完成后要做的事情，而是开发过程的核心部分——始终在每个阶段。请记住，这些测试旨在仅证明代码 不可 部署，而不是准备就绪。 “如果它通过了所有这些测试，而你仍然对部署感到有点紧张，”Jez 说，“这意味着你的测试还不够好。”
10、少即是多，或多或少。
研究 表明，即使是为改进关键指标而开发的设计和执行良好的项目也只有大约三分之一的时间成功。另外三分之一的时间他们没有显着帮助，剩下的三分之一时间他们实际上让事情变得更糟！对于 Jez 来说，该指标表明“少做事”通常是最好的策略，尤其是在企业中实施 DevOps 时。
“用户不知道他们想要什么。一旦你为他们构建了它，用户就会知道他们 不 想要什么。”业务目标就是客户的需求。
奖励点：
双模式 IT 是一种大规模的还原论过度简化。
Jez 说，IT 应该根据自己的特点来对待每个项目或流程。 DevOps 可以帮助您做到这一点。