评估您的能力并衡量 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 不是一个团队的工作,而是每一个人的工作。


Automation helps eliminate repetitive manual work, yields repeatable processes, and creates reliable systems.

Build, test, deploy, and provisioning automation are typical starting points for teams who don’t have them in place already. And hey: what better reason for developers, testers, and operators to work together than building systems to benefit everyone?

Teams new to automation usually start with continuous delivery: the practice of running each code change through a gauntlet of automated tests — often facilitated by cloud-based infrastructure — then packaging up builds and promoting them through environments using automated deployments.

Why? Computers execute tests more rigorously and faithfully than humans. These tests catch bugs and security flaws sooner. And automated deployments alert IT/Ops about drift between environments, which reduces surprises when it’s time to release.

Another major contribution of DevOps is “configuration as code.” Developers strive to create modular, composable applications because they are more reliable and maintainable. That same thinking can be extended to the infrastructure that hosts them, whether it lives in the cloud or on the company's own network.

“Configuration as code” and “continuous delivery” aren’t the only types of automation seen in the DevOps world, but they’re worth special mention because they help break down the wall between development and operations. And when DevOps uses automated deploys to send thoroughly tested code to identically provisioned environments, “works on my machine!” becomes irrelevant.


When we hear “lean” in the context of software, we usually think about eliminating low-value activities and moving quickly — being scrappy and agile. Even more relevant for DevOps are the concepts of continuous improvement and embracing failure — which lay the foundation of an experimental mindset.

A DevOps mindset recognizes opportunities for continuous improvement everywhere. Some are obvious, like holding regular retrospectives so your team’s processes can improve. Others are subtle, like A/B testing different on-boarding approaches for new users of your product.

We have agile development to thank for making continuous improvement a mainstream idea. Early adopters of the agile methodology proved that a simple product in the hands of customers today is more valuable than a perfect product in the hands of customers six months from now. If the product is improved continuously, customers will stick around.

And guess what: failure is inevitable. So you might as well set up your team to absorb it, recover, and learn from it (some call this “being anti-fragile”). At Atlassian, we believe that if you’re not failing once in a while, you’re not trying hard enough.

In the context of DevOps, failure is not a punishable offense. Teams assume that things are bound to go pear-shaped at some point, so they build for fast detection and rapid recovery. Postmortems focus on where processes fell down and how to strengthen them — not on which team member messed up the code. Why? Because continuous improvement and failure go hand in hand.


It’s hard to prove your continuous improvement efforts actually improve anything without data. Fortunately, there are loads of tools and technologies for measuring performance, like how much time users spend with your product, whether that blog post generated any sales, or how often critical alerts pop up in your logs.

Although you can measure just about anything, that doesn’t mean you have to (or should) measure everything. Take a page from agile development and start with the basics:

How long did it take to go from development to deployment?

How often do recurring bugs or failures happen?

How long does it take to recover after a system failure?

How many people are using your product right now?

How many users did you gain / lose this week?

With a solid foundation in place, it’s easier to capture sophisticated metrics around feature usage, customer journeys, and service level agreements (SLAs). The information you get comes in handy when it’s time for road mapping and spec’ing out your next big move.

All this juicy data will help your team make decisions, but it’s even more powerful when shared with other teams — especially teams in other departments. For example, your marketing team wants shiny new features they can sell. But meanwhile, you’re seeing high customer churn because the product is awash in technical debt. Providing user data that supports your roadmap — even if it’s light on features and heavy on fixes — makes it easier to build consensus and get buy-in from stakeholders.


As much as we wished that there was a magic wand to transform all teams into high-performing DevOps teams, DevOps transformations require a blend of practices, cultural philosophies, and tools. But like you’ve read, the benefits to breaking down the Development and Operations siloes are well worth it — increased trust, faster software releases, more reliable deployments, and a better feedback loop between teams and customers.

Embracing DevOps is no small task. Yet given the right mindset, effort, and tools, an organization can undergo a DevOps transformation that yields significant benefits.

The long-standing friction between development and operations teams is largely due to a lack of common ground. We believe that sharing responsibility and success goes a long way toward bridging that divide. Developers can win instant goodwill by helping to carry one of operations’ biggest burdens: the pager (a figurative construct these days). DevOps is big on the idea that the same people who build an application should be involved in shipping and running it.

In conclusion…

Out of this idea comes the phrase, "you built it, you run it," which fosters a hands-on approach accross teams. This doesn’t mean that you hire developers and simply expect them to be excellent operators as well. It means that developers and operators pair with each other throughout the application’s lifecycle. Moreover, reports have shown that peer-reviewed code and products are the only review that results in better delivery and performance; in fact, external reviewers were no more effective that conducting no review at all.

Teams that embrace DevOps often have a rotating role whereby developers address issues caught by end users while, at the same, troubleshooting production problems. This person responds to urgent customer-reported issues, creating patches when necessary, and works through the backlog of customer-reported defects. The “developer on support” learns a lot about how the application is used in the wild. And by being highly available to the operations team, the development teams build trust and mutual respect.

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