CALMS 框架

挑战甚至是紧急情况都是对 DevOps 文化的有效考验。开发人员、运维人员和客户支持人员是否共同作为一个团队来解决问题？突发事件事后析误是否专注于改善下一次事件的结果，而非相互指责？如果答案为“是”，那么这是一个表明您的组织正在接受 DevOps 文化的好迹象。

最成功的企业在各个部门以及组织图上的各个级别都具有 DevOps 文化。在如此广泛的范围内，术语“DevOps”通常过于狭隘，因而不再需要该术语。此类企业设有开放的沟通渠道并定期开展对话。他们认为，让客户持续满意是同等重要的产品管理责任和开发团队责任。他们明白 DevOps 不是一个团队的工作，而是每一个人的工作。

自动化有助于消除重复的手动工作、产生可重复的流程，以及打造可靠的系统。

对地尚未实现自动化的团队而言，通常应首先构建、测试、部署和配置自动化功能。另外：使开发人员、测试人员和运维人员达成协作而非构建系统以惠及每个人的更好的理由是什么？

对自动化不熟悉的团队通常会从持续交付开始：这是一种通过自动化测试手段运行每个代码更改的实践。它通常由基于云的基础架构进行推动，随后可打包构建并借助自动化部署将其推广到不同环境中。

为什么呢？计算机能比人类更严格、更如实地执行测试。这些测试可以更快地捕获错误和安全漏洞。自动化部署可以提醒 IT/运维人员不同环境之间存在差异，从而可在发布时减少意外事件。

DevOps 的另一大贡献是“配置即代码”。开发人员努力创建模块化、可组合的应用，因为它们更加可靠且可维护。同样的想法还可以扩展到托管这些应用的基础架构，无论其位于云端还是公司自己的网络上。

“配置即代码”和“持续交付”并非仅存在于 DevOps 环境的自动化功能，但由于它们有助于打破开发和运维之间的壁垒，因而值得在此特别提及。当 DevOps 使用自动化部署将经过彻底测试的代码发送到具有相同配置的环境中时，“在我的机器上工作！”便会变得无关紧要。

在软件环境中听到“精益”一词时，我们通常会想到消除低价值的活动和快速迁移，也就是变得朝气蓬勃且工作敏捷。与 DevOps 更为相关的是持续改进和接受失败的概念，这为实验性思维奠定了基础。

持有 DevOps 理念的人们会认识到持续改进的机会可谓无处不在。有些机会显而易见，例如，定期进行回溯，以便改进您团队的流程。有些机会则不易察觉，例如 A/B 对您产品的新用户测试不用的加载方法。

归功于持续改进成为主流思想，我们才实现了敏捷开发。敏捷方法的早期采用者已经证明，今天客户手中的简单产品比六个月后客户手中的完美产品更有价值。如果该产品得以持续改进，则客户会坚持使用下去。

猜猜看：失败是不可避免的。因此，您也可以组建自己的团队以应对失败、进行恢复和汲取经验教训（有人称之为“反脆弱性”）。在 Atlassian，我们认为如果您在一段时间内没有遭遇到一次失败，那么您没有付出足够的努力。

在 DevOps 的背景下，失败不是应受到惩罚的过错。团队认为有些事情必然会在某些时候变得“一团糟”，因此他们建立了快速检测和迅速恢复。事后析误会着重关注关乎流程出现故障的位置以及如何进行增强，而非哪个团队成员搞砸了该代码。为什么呢？因为持续改进和失败是息息相关的。

我们很难证明您为持续改进而付出的努力真能改进除数据以外的一切。幸运的是，有大量用于衡量绩效的工具和技术，例如用户对您的产品花费了多少时间、那篇博文是否带来了任何销售，或者关键警报在您的日志中弹出的频率。

尽管您可以测量几乎任何内容，但这并不意味着您必须（或者应该）测量一切。借鉴敏捷开发，从基础知识开始：

从开发到部署需要多长时间？

经常出现的错误和失败的发生频率如何？

系统发生故障后多久才能恢复？

目前有多少人在使用您的产品？

您在本周获得/损失了多少用户？

有了坚实的基础，则更容易围绕功能使用、客户旅程和服务水平协议 (SLA) 获得精细的指标。您掌握的信息将在进行路线绘图和规划您的下一个大动作时派上用场。

所有这些丰富的数据都将帮助您的团队做出决策，但如果与其他团队，尤其是其他部门的团队共享，会发挥更强大的作用。例如，您的营销团队想要获得吸引人的新功能，以便销售。但与此同时，您却发现客户流失率很高，因为产品充斥着技术债务。提供支持您路线图的用户数据（即使功能较少而修复较多）可以更容易地达成共识并获得利益相关者的支持。

尽管我们希望有一根魔法棒可以将所有团队转变为高绩效的 DevOps 团队，但 DevOps 转型需要融合各种实践、文化理念和工具。但是，正如您所读到的那样，打破开发和运维孤岛所带来的好处是非常值得进行转型的：增加信任、加速软件发布、实现更可靠的部署以及在团队和客户之间建立更好的反馈回路。

实施 DevOps 并非易事。但是，只要有正确的思路、努力和工具，组织就可以进行 DevOps 转型，从而带来显著收益。

开发和运维团队之间长期存在摩擦的主要原因是缺乏共同的基础。我们认为，分担责任和共享成功对弥合分歧大有助益。开发人员可以通过帮助分担运维人员重大责任之一的“呼叫器”（如今是一种比喻性结构）而立即赢得好感。DevOps 在很大程度上所贯彻的理念是：应用的构建者也应参与其交付和运行流程。

此观念催生了一个短语：“谁构建，谁运行”，它可促进跨团队的动手实践方法。这并不意味着您雇佣开发人员只是期望他们也能成为出色的运营人员。这意味着，开发人员和运营人员需在应用的整个生命周期中并肩工作。此外，有报告显示，经过同行评审的代码和产品是唯一能带来更好交付成果和效果的审查。事实上，使用外部审查人员的效果并不比不进行任何审查来得更好。

采用 DevOps 的团队通常会设立一个调和角色。借助此角色，开发人员能解决最终用户遇到的问题，同时对生产问题进行诊断。此人可在必要时创建补丁以响应客户报告的紧急问题，以及处理积压的客户所报告的缺陷。“支持开发人员”了解有关如何在野外使用该应用的大量信息。开发团队对运维团队高度可用，因此两者可建立信任关系并彼此尊重。

Atlassian 为希望使用自己喜欢的工具构建所需工具链的团队创建了 Open DevOps，这要归功于与领先供应商和 Marketplace 应用的集成。立即试用。