如今，很多人都在尝试为 DevOps 的成功构建模型。 Xavier Amatriain 在硅谷举行的 IEEE DevOps Unleashed 研讨会上介绍了我见过的最有趣的方法之一。
Amatriain 在 Netflix 和 Telefonica 工作了很长时间后最近成为 Quora 的工程副总裁，他开发了他称之为 DevOps 的 CASSSH 模型，并补充了在多个 DevOps 实施过程中学到的真实经验。他的演讲 ——精益 DevOps：从创新驱动型公司中吸取的教训 ——重点关注如何提高创新速度：
CASSSH = 成本 、 可用性 、 可 扩展性、 速度 、 安全 性、DevOps H appiness
Amatriain 的 CASSSH 模型将 DevOps 归结为一个简单的首字母缩写词。让我们详细看看每个组件：
成本： Amatriain 说，在 DevOps 的世界里，优化成本并不是那么微不足道。您必须考虑短期成本与长期成本、内部支出与外包支出之间的差异，以及投资额外的服务器或可以充分利用这些资源的精益 DevOps 流程是否更有意义。
可用性： 当谈到可用性时，Amatriain 说，问题是，您需要多少个“九”的可靠性，以及您愿意为额外的九个支付多少钱？他引用了平安夜范例，指出当 AWS 在 2012 年平安夜关闭 Netflix 时，相对较短的中断对可用性产生了巨大影响。你可以工作一整年来达到 99.99% 的可用性，他说，但如果你的网站在错误的时间出现故障，那么一切都会在短短几个小时内付诸东流。
可扩展性： “你准备好做大了吗？”阿玛特里亚恩问道。如果是这样，发生这种情况的可能性有多大？这种增长的成本是多少？现在为可扩展性花钱是否有意义，或者您是否应该将这种可能性外包给云，这样您就不必担心直到它发生？
安全： Amatriain 说，安全总比后悔好，但安全也有其自身的成本。你能负担得起多少安全保障？
DevOps 快乐： 最后但同样重要的是，Amatriain 指出，为了优化创新和生产力，您需要一个乐于工作的团队。他还指出，DevOps 幸福感与半夜被问题吵醒的概率呈负相关。
解决 DevOps 困境的技巧
当你把它们放在一起时，Amatriain 说，与其说 CASSSH 是一个模型，不如说它是一个困境。您如何优化或权衡所有这些维度以找到理想的操作点？
幸运的是，Amatriain 还分享了一些有用的经验教训：
- 解决特定的成本变量很容易。 但更有效的方法是找到成本的根源，并尝试在那个层面上解决问题。
- 质量不负有心人……最终 。一开始您可能需要在代码质量上投入一些，但从长远来看它可以节省资金。如果您想编写一次性原型，那么为什么要关心代码质量？但是对于大多数生产项目，您需要计算投资于质量的初始成本何时会超过不得不清理因快速而肮脏的事情而造成的技术债务的延迟成本。
- 可以测试所有 CASSSH 维度。 这可能看起来并不明显，但测试实际上可以让你行动得更快。 Amatriain 建议将员工测试人员插入小型开发团队，在那里他们可以成为测试和代码质量的传播者。他承认，这会给测试人员带来压力，但“总比和 50 名其他测试人员一起做同样的事情要好”。
- 结对编程代码审查岩石。 “没有什么比坐在某人旁边并就每一行代码提出问题更好的了，”Amatriain 说。让一个程序员对另一个程序员说，“让我相信你所做的是正确的事情”比来自外部的相同问题更有分量。
- 当事情破裂时，你对它们所做的事情会产生巨大的影响。 请务必记住，通知不是警报。警报是您可以采取行动的东西，而不仅仅是“很高兴知道”的东西。如果您不能对其采取行动，它只是一个通知。
- 指标，指标，指标。 Amatriain 说，你需要能够衡量正确的事情，这意味着你需要了解什么是正确的事情。
- 一切都是生产，或者“生产就是新的开发”。 Amatriain 说，如果人们在测试环境中没有像对待生产功能一样关注质量，那么当一个最初只是实验的功能突然进入生产并开始积累技术债务时，可能会造成麻烦，因为它之前没有经过全面测试。
- Amatriain 说 ，团队针对竞争维度进行优化是灾难的根源 。例如，如果一个团队针对成本进行优化，而另一个团队针对速度进行优化，那么您就会遇到大问题。解决方案是确保跨维度共享目标，以便成本团队对可接受的速度有一定的了解（反之亦然）。这个想法是，在特定的成本范围内，你可以做任何你想做的事。但如果你超出这个范围，你就会遭到成本团队的反对。
DevOps 团队和整个公司都从精益中受益，Amatriain 总结道，但精益也会增加不稳定性和风险。但是，通过利用 CASSSH 模型改进流程可以帮助鼓励创新并提高创新速度，同时还可以降低风险。