作者，北京老李：EXIN DevOps Master（大师级）讲师(首批全国十名)、国内首批EXIN Product Owner讲师（首批全国十名）、PMI-ACP讲师中国“黄埔一期”TTT、EXIN授权EXIN Agile Scrum Master讲师、首批ITIL Expert讲师、 Lean IT 认证讲师、PMP、Prince2专家级、EXIN云安全管理、EXIN 云服务管理、APMG ISO27001信息安全官（CISO）、ISO27001 LA、ISO20000 LA等多项认证。先后在北京、上海、广州等地主导软件开发、系统集成、咨询服务等工作，主要研究方向云安全管理、敏捷与DevOps落地实施。
1.DevOps是什么？
2007年，比利时独立咨询师Patrick Debois参与了一个政府数据中心迁移中的测试工作。他在做测试时，需要频繁往返于Dev团队和Ops团队之间。Dev团队已经实践了敏捷，而Ops团队还是传统运维的工作方式。看到Ops团队每天忙于救火和疲于奔命的状态，他想能否把敏捷的实践引入Ops团队呢，他写出了DevOps的论文敏捷的基础设施。
DevOps这个词就是Patrick DeBois创造的，所以，他经常被成为DevOps之父，但他喜欢说DevOps是一个人的问题。虽然DevOps通常被认为是一个技术问题，但实际上，DevOps是一个文化和业务问题。
DevOps2.0是软件工程的最佳实践，是领域一系列创新的集成.DevOps以一系列高效团队（敏捷2.0）的管理方法整合开发与运营团队的工作效率。
DevOps Master课程：DevOps1.0与DevOps2.0对比
DevOps工作方式，在跨职能团队中奖励速度、实验和协作的方式。它打破了IT组织内部开发人员和运维团队之间的传统壁垒，加速了软件发布的节奏。所有这些因素都适合当前的商业目标：改变业务，以便能够迅速改变以满足客户需求或新的竞争环境。加快步伐，这样一家制造公司就能更像一个初创公司，而不像一个官僚机构。实验和创新，这些目标是数字化转型的核心，这是目前许多CEO的首要任务。
DevOps2.0按照敏捷的方式去建立DevOps文化、DevOps原则、DevOps流程、DevOps工具，实现从敏捷治理、敏捷高效管理、敏捷精益管理、持续交付、轻量级ITSM等多个方面的综合敏捷管控。DevOps根据康威定律中的定义系统设计受限于组织自身的沟通结构。组织规模越大，灵活性越差，对组织提出了组织变革的发展方向，并结合DevOps的扩展实践NOOps,AIOps,DevSecOps，优化软件工程实践，应把20%的时间应该用于重构代码,改进架构，用于偿还技术债务。Garnter提出的文化、组织、流程、技术等方法的整体DevOps实现图，如下图所示：
Garnter提出的文化、组织、流程、技术等方法的整体DevOps实现图
https://www.douban.com/note/647732431/DevOps：10本DevOps推荐书及47个DevOps兼容工具
2.DevOps核心原则之CALMS
Ellucian CIO Lee Congdon说，也许是一种共有的主人翁意识，他认为这是团队文化变革的关键因素。DevOps核心原则之CALMS分别为 文化、自动化、精益、度量、分享。
CAMS模型是由两位DevOps先驱（John 和Damon Edwards ）提出来的。CAMS代表Culture, Automation, Measurement, Sharing四个单词的首字母缩写。CAMS已经成为许多DevOps从业者的价值参考模型。
2010年在美国山景城(Mountain View) 举办的DevOpsDays 活动中，Damon Edwards先生使用“CAMS”这个缩写，高度概括和诠释了DevOps，即文化（Culture）、自动化（Automation）、度量（Measurement or Metrics）和分享（Sharing）。随后Jez Humble先生将“L”精益 (Lean) 原则也加入其中，最终变成了CALMS。
Culture（文化）- 是指拥抱变革，促进协作和沟通
Automation（自动化）- 是指将人为干预的环节从价值链中消除
Lean（精益）- 是指通过使用精益原则促使高频率循环周期
Metrics（指标）- 是指衡量每一个环节，并通过数据来改进循环周期
Sharing（分享）- 是指与他人开放分享成功与失败的经验，并在错误中不断学习改进
“CALMS”完全吻合Patrick DeBois先生所一向倡导的“DevOps is a human problem” (DevOps 是关于人的问题) 的理念 。
详解DevOps系列：DevOps的核心-CALMShttps://www.douban.com/note/615474029/
推荐书《Effective DevOps: Building a Culture of Collaboration, Affinity, and Tooling atScale 》，DevOps Master官方指定学习用书。
3.DevOps管理实践之DevOps黄金三步法
Target CIO迈克·麦克纳马拉说聪明的启动是关键是目标过程的一个重要部分是创建一个加速学习环境，我们的团队称之为‘Dojo’，”，这也是DevOps所提倡的持续学习下实验。
《DevOps黄金三步法》http://www.douban.com/note/694641377/ 这个模型是由Gene Kim和Mike Orzen提出来的，Mike Orzen是"Lean IT"的作者。DevOps黄金三步法即系统思考，加大反馈循环，不断实验和学习的文化。DevOps黄金三步工作法即 从左到右的工作流、从右到左的反馈流、 持续学习与实验，如下图所示：
《DevOps黄金三步法》
DevOps黄金三步法》第一步： System Thinking （系统思考：强调全局优化，避免局部优化）、第二步： Amplify Feedback Loops （经过放大的反馈回路：创建从开发过程下游至上游的反馈环）；第三步： Culture of Continual Experimentation And Learning（持续做试验和学习的文化：持续做试验，承担风险、从失败中学习；通过反复实践来达到精通）详解：《DevOps黄金三步法》http://www.douban.com/note/694641377/
推荐书《ThePhoenix Project: A Novel about IT, DevOps, and Helping Your Business Win 》作者：Gene Kim，Kevin Behr，George Spafford。DevOps Master官方指定学习用书。
4.DevOps技术实践三原则
红帽公司CIO Mike Kellyy说当团队变得更具包容性和协作性时，领导者必须改变他们的策略和策略，以利用这种新的工作方式产生的能量，DevOps正是现在最佳选择。
在《DevOps Cookbook》中，DevOps模式分成4个领域
领域一，将开发延伸至生产中：包括拓展持续集成和发布功能至生产，集成QA和信息安全至整个工作流，确保代码和环境可在生产中直接部署，。
领域二，向开发中加入生产反馈：包括建立开发和IT运营事件的完整时间表用于帮助事件的解决，使得开发融入无指责的生产反思，尽可能使得开发可以自助服务，同时创建信息指示器用来表明本地的决策如何影响全局的目标。
领域三，开发嵌入到IT运维中：包括开发投入到整个生产问题处理链，分配开发资源用于生产问题管理，并协助退回技术债务，而且开发为IT运维提供交叉培训，增加IT运维处理问题的能力，从而降低升级问题的数量。
领域四，将IT运维嵌入至开发：包括嵌入和联络IT运维资源至开发，帮助开发创建为IT运维(部署，生产代码的管理等)使用的可重用的用户故事，定义一些可以被所有项目共用的非功能性需求。
实现四个领域需要遵从如下技术实现三原则包括：1、基础设施即代码（Infrastructure as Code）：DeveOps的基础是将重复的事情使用自动化脚本或软件来实现，例如Docker（容器化）、Jenkins（持续集成）、Puppet（基础架构构建）、Vagrant（虚拟化平台）等2、持续交付（Continuous Delivery）：持续交付是在生产环境发布可靠的软件并交付给用户使用。而持续部署则不一定交付给用户使用。涉及到2个时间，TTR（Time to Repair）修复时间，TTM（Time To Marketing）产品上线时间。要做到高效交付可靠的软件，需要尽可能的减少这2个时间。部署可以有多种方式，比如蓝绿部署、金丝雀部署等。3、协同工作（Culture of Collaboration）：开发者和运维人员必须定期进行密切的合作。开发应该把运维角色理解成软件的另一个用户群体。协作有几个的建议：1、自动化（减少不必要的协作）；2、小范围（每次修改的内容不宜过多，减少发布的风险）；3、统一信息集散地（如wiki，让双方能够共享信息）；4、标准化协作工具（比如jenkins）
推荐书《Continuous Delivery: Reliable Software Releases through Build, Test, andDeployment 》Automation 作者：Jez Humble&David Farley 。DevOps Master官方指定学习用书。
5.DevOps持续改进六原则
Matson CIO Peter Weis说任何变革中最揪心的部分是人民。有了诚实和透明，以及商业领袖的明确支持，你就可以培育变革文化。DevOps应遵从持续改进6原则，即
1.以客户为中心的行动：DevOps团队必须采取以客户为中心的行动，因为他们应该不断投资于产品和服务。
2.监控和测试所有内容：DevOps团队拥有强大的监控和测试程序非常重要。
3.自动化一切：自动化是DevOps流程的重要原则。这不仅适用于软件开发，也适用于整个基础架构环境。 4.端到端的责任：DevOps团队需要提供性能支持，直到它们终止为止。这提高了产品的责任水平和质量。5.作为一个团队工作：在DevOps文化角色中，设计人员，开发人员和测试人员已经定义。他们所需要做的就是作为一个团队完成合作。 6.持续改进：DevOps文化专注于持续改进，以尽量减少浪费。它不断加快提供的产品或服务的改进。
7.DevOps实例化原则
Vanguard CIO John Marcante说DevOps改变了IT领导原则的基本原则，比如如何看待需求、治理和风险。CIO必须挺身而出，勇敢地承担起推动企业业绩的责任。
8.送DevOps成熟度模型
Department of Homeland Security的首席技术官迈克尔•赫慕斯Michael Hermus说，让一个团队高效地生产软件，但不给企业增加实际价值是完全可能的。出于这个原因，他的团队正在寻求一套度量标准，包括威胁检测的准确性，这是他团队任务的关键。DevOps正是他所需要的管理与度量方法。
为你的组织找出不超过10个这样的指标，最好是减少。“考虑可以发现更广泛的组织或过程健康问题的度量标准，以及可以从计算机系统收集的更明显的操作和开发数据。”
CYBRIC联合创始人兼首席技术官迈克·凯尔(Mike Kail)说。“随着DevOps的转变，PMO的功能需要采用“微服务”的方法，因为较小的子项目可以实现更高的速度。”
9.爬楼
DevOps Master课程：如何一次通过DevOps Master考试https://www.douban.com/note/660291760/
DevOps Master课程：DevOps Master教练十二条原则https://www.douban.com/note/718124778/
DevOps Master课程：DevOps Master教练的三个层次https://www.douban.com/note/719145305/
DevOps Master课程：招聘DevOps工程师必问的12个问题（送DevOps实现的三个路径） 相关主题https://www.douban.com/note/709308373/DevOps Master ：
敏捷项目管理ACP中国“黄埔一期”https://www.douban.com/note/728728754/
敏捷管理课程：如何一次通过PMI-ACPhttps://www.douban.com/note/720287998/
敏捷管理课程：如何一次通过EXIN Scrum Masterhttps://www.douban.com/note/722250431/
敏捷管理课程：如何一次通过EXIN Scrum Masterhttps://www.douban.com/note/722250431/
https://www.douban.com/note/713613037/DevOps professional课程：只讲技术之CHEF（1）
https://www.douban.com/note/708968150/DevOps Master课程总结：知否知否，应是DevOps肥ITIL瘦（送ITIL4前生今世）
https://www.douban.com/note/708218842/DevOps Master课程总结：学习没有捷径（送DevOps安灯正确方法）
https://www.douban.com/note/694641377/DevOps Master凤凰项目沙盘总结：DevOps黄金三步法
https://www.douban.com/note/700603657/DevOps Master凤凰项目沙盘总结：履霜坚冰至，转型应自强不息
https://www.douban.com/note/693053178/DevOps Master凤凰项目沙盘总结：通过DevOps实现IT组织转型
https://www.douban.com/note/689504940/DevOps Master凤凰项目沙盘总结：DevOps起始质量之独孤九剑
https://www.douban.com/note/645016138/DevOps凤凰沙盘：一场精益敏捷探索之行
https://www.douban.com/note/629890513/DevOps凤凰沙盘：一场百玩不厌的质量感悟
https://www.douban.com/note/630638887/DevOps课后总结之DevOps游戏系列-DevOps的独孤九剑
https://www.douban.com/note/637665261/DevOpsMaster课程:回忆我与DevOps之父Patrick的交流
https://www.douban.com/note/647732431/DevOps：10本DevOps推荐书及47个DevOps兼容工具
https://www.douban.com/note/647732431/DevOps：10本DevOps推荐书及47个DevOps兼容工具
https://book.douban.com/review/9110485/DevOps：转型从正确地认知开始
https://www.douban.com/note/651734552/DevOps：从I型人才到E型人才
https://www.douban.com/note/651734953/DevOps：智能服务台是企业不能缺少的基石
https://book.douban.com/review/8928323/DevOps布道师:终身学习是终身成长的源动力
https://book.douban.com/review/8820627/《把读到的知识转化为能力三步法及完美学习的四步法》
https://www.douban.com/note/643862694/DevOps Master课程:脚踏实地学Pre-Master，一步一个脚印成为DevOps Master
https://book.douban.com/review/8805640/DevOps布道师为深度工作写的序：深度工作是心身的一种修练方法
https://book.douban.com/review/8795275/咨询基本功：咨询顾问基本功之书面沟通及“补充大餐”
https://www.douban.com/note/643251358/DevOps定义编年史：通过DevOps定义看DevOps发展
https://www.douban.com/note/637838681/DevOps应用：光大银行DevOps1.0到DevOps2.0研讨会
https://www.douban.com/note/639093367/DevOps应用：民生银行IT一体化管理与自动化发展（1）
https://www.douban.com/note/638965340/DevOps应用：工商银行DevOps进行时
DevOps Master课程：事半功倍的系统化学习https://www.douban.com/note/717180422/
https://www.douban.com/note/696842302/DevOps应用：工商银行DevOps进行时（2018年）
https://www.douban.com/note/722820106/DevOps Master课程：微软 DevOps的成功之路（送中行DevOps三架马车）
https://www.douban.com/note/641427886/DevOps应用：DevSecOps云下安全与云等保（云博会内容提前曝光）
站在IT治理Cobit2019角度看DevOps成熟度（COBIT可申请10PDU）https://www.douban.com/note/729309727/
https://www.douban.com/note/646007197/敏捷辩论
https://www.douban.com/note/655617439/敏捷服务管理：数字化转型核心
https://www.douban.com/note/696148785/DevOps Master课程总结：IT运维的昨天、今天、明天（IT运维四大“坑”）
DevOps Master：如何一次通过DevOps Master考试https://www.douban.com/note/660291760/
DevOps Master:课程总结之变更与DevOps集成https://www.douban.com/note/660466481/
艾利·高德拉特 “在瓶颈之外的任何地方作出的改进都是假象，在瓶颈之后作出任何改进都是徒劳的，而在瓶颈之前作出的任何改进则只会导致瓶颈处堆积更多的库存。”
【1】精益管理方法的术语
【2】高维度思考法
【附】高德拉特《目标》五个聚焦步骤：
第一步是确认约束点，直到确定那的确是整个部门层面的约束点，对非约束点的任何改进都只是幻觉，得不到实际任何价值；
第二步是利用约束点，寻找突破这些约束的办法，确保不让约束点浪费任何时间，永远不要让约束点迁就别的资源而干等着，而是应该专注于IT运维部对当前所需完成工作中优先级最高的那一项，一直都要这样；
第三步，使企业或部门的所有其它活动服从于第二步中提出的各种措施；
第四步，具体实施第二步中提出的措施，使第一步中找出的约束环节不再是整个部门的约束点；
第五步，回到步骤1，别让惰性成为约束，持续不断地改善；