Close

CALMS 框架

评估您的能力并衡量 DevOps 之旅的进度。

Ian Buchanan

首席解决方案工程师


CALMS 是一个框架,它可用于评估公司采用 DevOps 流程的能力,同时也是在 DevOps 转型期间衡量是否成功的一种方法。该首字母缩写词由《DevOps 手册》的合著者 Jez Humble 提出,且分别代表文化 (Culture)、自动化 (Automation)、精益 (Lean)、衡量 (Measurement) 和分享 (Sharing)。

文化


DevOps 不仅是一个流程或另一种开发方法,而是一种文化变革。而且,DevOps 文化的一个重要组成部分是协作。

除非开发人员和 IT/运维专业人员合作,否则世界上的所有工具和自动化功能都将变得无用。原因在于,DevOps 并不能解决工具问题,它能够解决的是人为问题。

您可将 DevOps 视为敏捷开发团队的演变,而其中的不同之处在于此时会默认包括另一个部分:运营。打造以产品为导向的团队来代替基于职能的团队,是朝正确方向所迈出的一步。它包括开发、QA、产品管理、设计、操作、项目管理,以及长期运行产品所需的所有其他技能组合。与其让一个团队完成所有工作或招聘“DevOps 专业人员”,不如有一个能够无缝协作的基于产品的团队。

通过设立共同的目标、制定合作计划等,可以促进开展合作。在一些公司,突然转变为基于产品的团队的情况会过猛过快。因此,相关步骤需要更为细致。开发团队可以且应该邀请运维团队内适当的成员参加冲刺计划会议、每日站会和冲刺演示。运维团队可以邀请关键开发人员参加其会议。了解其他各方的工作、想法和挣扎是一种敏捷、有机的工作方式。

相关资料

了解 DevOps 优势

相关资料

构建 DevOps 文化

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

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

自动化


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

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

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

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

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

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

精益


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

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

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

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

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

测量


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

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

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

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

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

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

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

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

所有这些丰富的数据都将帮助您的团队制定决策,但它在与其他团队共享时可发挥更强大的作用,尤其是其他部门的团队。例如,您的营销团队想要获得可用于销售的吸引人的新功能。然而与此同时,您认为该产品充斥着技术性负债,因此会产生较高的客户流失率。提供支持您制定路线图的用户数据(即使此做法的功效平平,且需大量修正),从而使达成共识更为容易,同时得到利益相关者的认同。

分享


尽管我们希望有一根魔法棒可以将所有团队转型为高效能的 DevOps 团队,但 DevOps 转型需要实践、文化理念和工具的融合。但是,正如您所读到的那样,打破开发和运维孤岛的诸多好处非常值得尝试转型:提升信任度、加速软件发布、更可靠的部署以及团队和客户之间更好的反馈回路。

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

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

总之......


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

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

Ian Buchanan
Ian Buchanan

Ian Buchanan 是 Atlassian 的 DevOps 首席解决方案工程师,他专注于新兴的 DevOps 社区以及 Jira、Bitbucket 和 Bamboo 的应用,以实现更好的持续集成和持续交付。虽然 Ian Buchanan 在 Java 和 .NET 领域拥有丰富而深厚的经验,但他最广为人知的身份则是在大型企业内采取精益和敏捷实践的拥护者。

在他的职业生涯中,他自始至终成功管理了处在各个生命周期阶段的所有企业软件开发工具。他曾推动组织范围的流程改善,提高工作效率、产品质量和客户满意度。他建立了多个重视自我导向和自我管理的跨国敏捷团队。不说话或编码的时候,Ian 总是沉迷于解析器、元编程和特定于领域的各种语言。


分享这篇文章
下一个主题

推荐阅读

将这些资源加入书签,以了解 DevOps 团队的类型,或获取 Atlassian 关于 DevOps 的持续更新。

Devops 示意图

DevOps 社区

Devops 示意图

DevOps 学习路径

地图插图

免费试用

注册以获取我们的 DevOps 新闻资讯

Thank you for signing up