TLDR
- DevOps 一词的由来
- DevOps 的基本模型: CALMS
- 度量 DevOps: Lead Time, Deployment Frequency, Time to Restore(MTTR), Change fail
DevOps 的起源
DevOps 的起源也许可以追溯到 2009 年 Flickr 的运维部门经理John Allspaw和工程师Paul Hammond 在 Velocity 2009 大会上的一次分享，“10+ Deploys Per Day: Dev and Ops Cooperation at Flickr”。在分享中，他们讨论 Dev 和 Ops 的目标是否存在冲突？Dev 的工作是添加新特性，Ops 的工作是保障稳定性；Dev 在添加新特性时所带来的变化，会导致系统运行不稳定。然而从全局来看，Dev 和 Ops 的目标是一致的，即都是“让业务所要求的那些变化能随时上线可用”。这引起了比利时独立IT咨询师 Patrick Debois 的兴趣，随后他组织了 devopsdays 大会，并在 twitter 上首次创建了 #devops 的标签。
DevOps 的 CALMS 模型
CAMS 模型是由两位 DevOps 先驱（John 和Damon Edwards ）提出来的。CAMS 代表 Culture（文化）, Automation（自动化）, Measurement（测量）, Sharing（分享） 四个单词的首字母缩写。随后《continuous delivery》的作者 Jez Humble 将 Lean（精益） 也加入其中，最终衍变成 CALMS 模型。
Culture（文化），是指拥抱变革，促进协作和沟通。
Automation（自动化）- 是指尽量通过自动化和工具替代人工环节，因为靠人运行的模式，无法提供效率的增强。在现阶段我们更需要利用云基础设施来实现自动化，提升效率。
Lean（精益）- 是指通过使用精益原则促使高频率循环周期。精益思想最早来自于丰田汽车，其核心首先是向客户交付价值，其次是减少浪费。在软件开发过程中，也包括很多浪费，包括流程及开发过程中的低效和浪费，都需要根据精益的思想进行解决和避免。
Measurement（测量）- 是指衡量每一个环节，并通过数据来改进循环周期。与下文中的 DevOps Metrics 会进行详解。
Sharing（分享）- DevOps 最初就是要将开发和运维整合在一起，自然要进行信息的分享，后来指组织内部更大范围的信息共享。分享也是指与他人开放分享成功与失败的经验，并在错误中不断学习改进。
DevOps Metrics
管理学大师彼得德鲁克曾经说过，“你如果无法度量它，就无法管理它”。在软件迭代的生命周期中，引入 DevOps 只是攫取了其 1 % 的价值。剩下 99% 的价值，需要我们去观测 DevOps 的使用情况，并且度量它，从中发现问题和缺陷，去改善工作流，从而进一步提高团队软件发布速度和服务可靠性。
指标
在 Google Cloud 发布的《ACCELERATE State of DevOps 2019》中，Google DORA(devops research & assessment) 团队采用 Lead Time，Deployment Frequency，Change Fail，Time to Restore 来衡量软件交付性能（Software Delivery Performance）的。
- Lead Time 是指代码从第一次提交到最后在线上运行的时间；
- Deployment Frequency 是发布频率；
- Time to Restore(MTTR) 是服务从出现故障或者服务给用户造成负面影响到服务被修复的时间；
- Change fail 是指发布造成事故的频率；
这些指标都是客观的，可以自动化地从日常迭代中采集；同时也是可执行的，这意味着通过改善工具链或工作流，可以使这些指标得到提升。这 4 项指标也足够全面，涵盖了从代码开发，review，测试，部署等从开发到上线的所有阶段。同时团队可以只关注这 4 个指标，从而屏蔽其他干扰因素的影响，获得较高的信噪比，因为指标中 Lead Time 和 Deployment Frequency 关注的是团队软件发布的产量，Time to Restore 和 Change fail 关注的是团队软件发布的稳定性和可靠性。另外这些指标也容易理解，可以向所有人传达出正确的信息。
分级
在报告中，DORA 指出数量和质量是可以兼得的。优秀的团队往往在交付产量和交付质量上都比效率较低的团队表现的好很多。DORA 根据实验数据，将软件交付性能分为 4 个等级，Elite，High，Medium 和 Low。
其中 Elite 的团队在 1 天内会上线多次，代码从提交到上线用时少于 1 天，发现问题后修复问题的用时少于 1 小时，发布事故的比率小于 15%。
报告中提到像 Amazon，Google，Netfix 这样的公司，每天要发布上千次，毕竟他们提供了上百种服务。频繁的发布让人想起马克吐温的名言，“Continuous improvement is better than delayed perfection”，持续的改进，胜过延迟的完美。
报告还指出，追求极致是可能的。2019 年达到 Elite 的 团队比例是 2018 年的 3 倍左右，并且 Elite 和 Low 之间差距巨大。
