允许企业评估的经过测试的框架开发操作在他们的组织中，以及如何改进，CALMS模型仍然特别有用。

CALMS代表协作、自动化、精益、测量和共享，它特别有助于分析组织的DevOps结构，并最终分析其在任何组织中的效用。CALMS框架涵盖DevOps中的所有利益相关者，包括业务、IT运营、QA、InfoSec和开发团队，以及他们如何共同交付、部署和集成具有商业意义的自动化流程。

“DevOps作为一种技术正在缓慢但稳步成熟，因此很高兴看到CALMS模型等通用评估方法，”霍尔格·米勒，的分析师星座研究，说。“CALMS模型为比较DevOps团队的成熟度提供了一个很好的参考框架，因此，它对于评估团队的状态，以应对随之而来的转型变化是非常宝贵的。”

应用CALMS

以下是CALMS应用于企业DevOps的几种方法，可以考虑转换为DevOps结构，也可以寻求对现有部署进行改进。

长期以来，采用技术必须是为了满足业务需求，而不是为了技术本身而投资技术。这种思维方式的转变适用于CALMS的“文化”部分如何支持与自动化流程相关的预测ROI必须在整个DevOps团队中得到支持。穆勒说，这种心态对于让非技术业务团队参与进来尤其重要。

他说：“DevOps必须得到业务主管的支持。这是文化方面的一个关键因素。”。“软件团队可以做的一件事是使用成功的软件部署，帮助说服DevOps的业务主管进行投资。这是每个DevOps组织都需要的部落活动。”

网飞公司众所周知，它是DevOps自动化的典型案例研究。除此之外，它可以在几分钟内跨整个庞大的基础设施部署代码和软件更新，一天中多次部署。但米勒表示，Netflix的自动化示例并没有考虑到那些希望效仿Netflix自动化软件部署和更新的公司可能出现的问题。

米勒说：“风险总是部署得太快，最终会部署出错误的代码。”。“当然，自动化需要考虑到这一点并进行补偿。但不是每个人都能做到这一点。”

完成后，通过消除资源来记录成本节约相对容易。米勒说，在CALMS框架内，DevOps中相应的“精益”组件相对容易评估。

米勒说，DevOps的好处是，公司可以提前就他们认为的精益运营达成共识。

然而，他补充道，“总是有过于苗条的风险，以至于你开始在QA方面犯错。”

一旦完成，软件部署的成功相对容易衡量。然而，尝试将未来部署作为预测模型的一部分进行测量当然更具挑战性。

穆勒说：“提前衡量DevOps的好坏可能会非常棘手。”。“因此，测量应允许在部署后阶段快速定位错误，以便在需要时快速修复代码。”

分享在许多方面与文化重叠。这是评估DevOps中所有不同团队是否在一起工作和沟通的地方。

米勒说：“多亏了DevOps，独立开发者的日子早已过去。但分享并不总是那么容易。”。“即使在单独的团队中，也很容易陷入这样一个陷阱：不必尽可能多地考虑团队，就想完成自己的工作。”

最终结果

穆勒说，虽然应用CALMS评估DevOps不会有什么坏处，但该框架仍然不如DevOps的主要目标之一重要，即使用技术使组织的运营更加灵活，并对客户需求做出反应。

他说：“归根结底，像CALMS这样的评估方法是很好的，但它们从来没有像专注于实现下一代应用程序那样重要。”。