评估您的能力并评估DevOps的工作进度。
CALMS是一个框架，用于评估公司采用DevOps流程的能力，以及衡量DevOps转换过程中成功与否的方法。该缩写词由“ The DevOps Handbook”的合著者Jez Humble创造，代表文化，自动化，精益，度量和共享。
文化
DevOps不仅仅是一个过程，或者是不同的开发方法，它是一种文化变革。而且，DevOps文化的主要部分是协作。
除非开发人员和IT / Ops专业人员一起工作，否则世界上所有的工具和自动化都是无用的。因为DevOps不能解决工具问题。它解决了人类的问题。
将DevOps视为敏捷团队的发展-不同之处在于，默认情况下现在包括操作。组建面向产品的团队以取代基于职能的团队是朝正确方向迈出的一步。包括开发，质量保证，产品管理，设计，运营， 项目管理，以及长期运行的产品所需的任何其他技能。拥有一个可以无缝协作的基于产品的团队，比让一个团队做所有事情或雇用“ DevOps专业人员”更为重要。
很少有什么事情可以促进协作，例如共享一个共同的目标并制定实现该目标的计划。在某些公司中，突然转向基于产品的团队实在太多，太早了。因此，请采取较小的步骤。开发团队可以并且应该邀请运营团队的适当成员参加sprint计划会议，每日站起来和sprint演示。运营团队可以邀请主要开发人员参加会议。这是一种敏捷而有机的方式，可以让彼此的工作，思想和斗争获得动力。
挑战甚至紧急情况都是DevOps文化的有效测试。开发人员，运营和客户拥护者是否会蜂拥而至并以团队的方式解决问题？事后验尸会集中精力改善下一次事件的结果，而不是指责吗？如果答案是“是”，则表明您的组织正在采用DevOps文化。
最成功的公司在每个部门以及组织结构图的各个级别都具有DevOps文化。在如此广泛的规模上，术语“ DevOps”通常过于狭窄，不再需要该术语。这样的公司具有开放的沟通渠道，并定期交谈。他们认为保持客户满意与开发团队的责任一样，都是产品管理的责任。他们了解DevOps不是一个团队的工作。这是每个人的工作。
自动化
自动化有助于消除重复的手工工作，产生可重复的过程，并创建可靠的系统。
对于尚未安装，构建，测试，部署和配置自动化的团队来说，它们是典型的起点。嘿：开发人员，测试人员和操作员一起工作比构建使所有人受益的系统更好的理由是什么？
刚接触自动化的团队通常从连续交付开始 ：通过自动测试的方法来运行每个代码（通常是基于云的基础架构促进），然后打包构建并通过使用自动化部署在环境中进行推广。
为什么？与人相比，计算机执行测试的方式更为严格和忠实。这些测试可以更快地发现错误和安全漏洞。自动化部署会向IT / Ops发出有关环境之间漂移的警报，从而减少发布时的意外。
DevOps的另一个主要贡献是“配置为代码”。开发人员致力于创建模块化，可组合的应用程序，因为它们更加可靠和可维护。可以将相同的想法扩展到托管它们的基础结构，而不管它是驻留在云中还是位于公司自己的网络中。
在DevOps世界中，“按代码配置”和“连续交付”并不是唯一的自动化类型，但是值得特别提及，因为它们有助于打破开发和运营之间的壁垒。当DevOps使用自动部署将经过全面测试的代码发送到相同配置的环境时，“在我的机器上工作！” 变得无关紧要。
精益
当我们在软件环境中听到“精益”时，我们通常会考虑消除低价值的活动并迅速行动-敏捷而敏捷。与DevOps更为相关的是持续改进和拥抱失败的概念，这是实验思维定式的基础。
DevOps的心态可识别持续改进的机会。有些是显而易见的，例如定期进行回顾，以便您的团队的流程可以得到改善。其他则比较微妙，例如针对产品的新用户进行A / B测试不同的入门方法。
我们感谢敏捷开发，因为不断改进已成为主流思想。敏捷方法的早期采用者证明，从现在起六个月后，今天，在客户手中的简单产品比在客户手中的完美产品更有价值。如果产品不断改进，客户将留下来。
猜猜是什么：失败是不可避免的。因此，您最好组建团队来吸收，恢复并从中学习（有人称其为“抗脆弱”）。我们相信，如果您不偶尔失败，那您就没有足够的努力。
就DevOps而言，失败不是应受惩罚的罪行。团队认为事情在某个时刻必定会变成梨形，因此他们为快速检测和快速恢复而构建。事后分析着重于流程失败的地方以及如何加强流程，而不是团队成员弄乱了代码。为什么？因为持续的改进和失败是齐头并进的。
测量
很难证明您的持续改进工作实际上可以在没有数据的情况下进行任何改进。幸运的是，有许多工具和技术可用来衡量性能，例如用户花在产品上的时间长短，该博客帖子是否产生了销售量，或者关键警报多久出现在您的日志中。
尽管您几乎可以测量任何东西，但这并不意味着您必须（或应该）测量所有东西。从敏捷开发的一页开始，并从基础开始：
- 从开发到部署花了多长时间？
- 经常发生的错误或故障多久发生一次？
- 系统故障后恢复需要多长时间？
- 现在有多少人在使用您的产品？
- 您本周获得/失去了多少用户？
有了坚实的基础，就可以轻松捕获有关功能使用，客户旅程和服务水平协议（SLA）的复杂指标。当需要进行路线图和制定下一个重大举措时，您所获得的信息会派上用场。
所有这些多汁的数据将帮助您的团队做出决策，但与其他团队（尤其是其他部门的团队）共享时，功能甚至更加强大。例如，您的营销团队希望可以销售闪亮的新功能。但是与此同时，您会看到大量的客户流失，因为该产品充斥着技术债务。提供支持您的路线图的用户数据（即使功能少且需要大量修复），也可以更轻松地达成共识并获得利益相关者的支持。
分享
开发团队和运营团队之间长期存在的摩擦在很大程度上是由于缺乏共识。我们认为，分担责任和取得成功对于弥合这种鸿沟大有帮助。开发人员可以通过帮助承担操作最大的负担之一：传呼机（如今是一种图形化构造）来赢得即时商誉。DevOps的构想是，构建应用程序的同一个人应该参与发布和运行它。
这并不意味着您要雇用开发人员，而只是期望他们也是出色的运营商。这意味着开发人员和操作员在应用程序的整个生命周期中都相互配对。
拥护DevOps的团队通常扮演轮换角色，开发人员可以解决最终用户遇到的问题，同时对生产问题进行故障排除。此人应对紧急的客户报告问题，在必要时创建补丁，并通过积压客户报告的缺陷进行工作。“支持开发人员”学到了很多有关如何在野外使用该应用程序的知识。通过对运营团队高度可用，开发团队可以建立信任和相互尊重。
正如我们所希望的那样，有一支魔杖可以将所有团队转变为高绩效的DevOps团队，而DevOps的转型则需要实践，文化理念和工具的融合。但是就像您已经读过的，打破开发和运营孤岛的好处是值得的-增强信任度，更快的软件版本，更可靠的部署以及更好的团队和客户之间的反馈循环。
拥抱DevOps绝非易事。但是，只要有了正确的思维方式，努力和工具，组织就可以进行DevOps转换，从而产生巨大的收益。
