DevOps Master凤凰项目沙盘总结：高维度系统化思考
作者，北京老李：PMI-ACP讲师中国“黄埔一期”TTT、EXIN DevOps Master（大师级）讲师(首批全国十名)、国内首批EXIN Product Owner讲师（首批全国十名）、EXIN授权EXIN Agile Scrum Master讲师、首批ITIL Expert讲师、 首批CCSK4.0讲师 、 Lean IT 认证讲师、PMP、Prince2专家级、EXIN云安全管理、EXIN 云服务管理、国内首批APMG 信息安全官（CISO）TTT、ISO27001 LA、ISO20000 LA等多项认证。先后在北京、上海、广州等地主导软件开发、系统集成、咨询服务等工作，主要研究方向云安全管理、敏捷与DevOps落地实施。
1.什么是DevOps
Patrick Debois是DevOpsDays的创始人和DevOps运动的创始人，这也解释了为什么有些人把他称为“DevOps教父”。作为互动视频公司小镇英雄(Small Town Heroes)的首席技术官，他每天都要对这些DevOps实践进行测试，以交付移动应用程序，他最近还组织了一个新的活动，”移动交付日“。
DevOps一词的来自于Development和Operations的组合，DevOps 是一种思想、一组最佳实践、以及一种文化。突出重视软件开发人员和运维人员的沟通合作，通过自动化流程来使得软件构建、测试、发布更加快捷、频繁和可靠。
2018年PMI-ACP DevOps定义为:通过改善开发和运营员工之间的协作理顺交付流程的各种实践的集合。
2018年gartner DevOps定义：DevOps代表了IT文化的变化，在面向系统全局（上下文）采用敏捷、精益实践，关注于快速的IT服务交付。 https://www.douban.com/note/643251358/ 《DevOps定义编年史：通过DevOps定义看DevOps发展》
Patrick 认为DevOps的核心是解决“人”的问题。在合作的文化方面，每个人都有平等的发言权，开发和运维都很重要。这意味着有更多的相互尊重。这也会对彼此的问题产生更多的同理心，从而创造更好的工作环境。马丁路德金说：“信念，就是在你还没有看到整个楼梯的时候走出第一步”。
DevOps这个词是“开发”和“运营”两个词的组合，意思是表示公司的应用程序开发和IT运营团队执行任务的协作或共享方法。从广义上讲，DevOps是一种促进组织中这些团队(以及其他人)之间更好地沟通和协作的哲学。在其最狭义的解释中，DevOps描述了采用迭代软件开发、自动化和可编程的基础设施部署和维护。这个术语还包括文化变化，例如在开发人员和系统管理员之间建立信任和内聚，以及使技术项目与业务需求保持一致。DevOps可以改变软件交付链、服务、工作角色、IT工具和最佳实践。虽然DevOps不是一种技术，但DevOps环境通常有通用的方法。其中包括:
- 持续集成和持续交付或持续部署(CI/CD)工具，强调任务自动化;
- 支持采用DevOps的产品，包括实时监控和事件管理系统、配置管理和协作平台;和
- 使用DevOps方法并发实现的云计算、微服务和容器。
- DevOps方法是用于执行满足业务需求的IT项目的许多技术之一。DevOps可以与敏捷软件开发共存;IT服务管理框架，如ITIL;项目管理指令，如精益和六西格玛;和其他策略。
一些IT专业人士认为，仅仅把Dev和Ops结合起来是不够的，DevOps这个术语应该明确地包括业务(BizDevOps)、安全(DevSecOps)或其他领域。
DevOps是一种方法，旨在改善整个软件开发生命周期中的工作。您可以将DevOps过程可视化为一个无限循环，包括以下步骤:计划、编码、构建、测试、发布、部署、操作、监控和(通过反馈)计划，这将重置循环。
在理想情况下，DevOps意味着IT团队编写完全满足用户需求的软件，部署时不浪费任何时间，并在第一次尝试时以最佳方式运行。组织利用文化和技术的结合来追求这一目标。
为了使软件符合期望，开发人员和涉众就项目进行沟通，开发人员负责相互独立的小型更新。
为了避免等待时间，IT团队使用CI/CD管道和其他自动化将代码从开发和部署的一个步骤转移到另一个步骤。团队立即审查变更，并可以执行策略以确保发布符合标准。
2.高维度思考理论与方法
2.1高维度思考理论
世界很奇妙，有些事儿，我们知道，但有太多的事，我们不知道。我们永远都处于知道和不知道之间，所以很多人求道，而求道不得，退而求其次。在《高维度思考法》中对这一理论的描述区分了知、无知、未知。有人说无知者无畏，但最可怕的是”因为无知，而对于自己的无知一无所知“。
世界之大，未知的未知大于已知，从个人角度看最高维度的思考是了解：1.你是谁，2.你来自哪里，3.你的使命是什么？如果你笑了，正如老子所说：上士闻道，勤而行之，中士闻道，若存若亡，下士闻道则笑之，不笑不足以为道。 佛家说人应了生死，悟知见。正是对个人高维度思考的一种总结。
对于企业来讲，《高维度思考法》区分了三种状态，即知道自己知道、不知道自己不知道、知道自己不知道，DevOps这一管理方法，正是要把破我们的无知状态，在IT内，达到知道，即开发知识运维，运维知道开发，一体化进行IT管理。
《高维度思考法》提出管理的问题一定要注意“上下游“【1】问题，因为上游和下游，不仅要求各自必需的着眼点，所要求的工作价值观、技能也不相同，有时候甚至是相反的。高维度思考法的核心是应转换价值观，着眼于无知管理与未知管理【2】。解决问题应从上游开始，而不能仅从下游开始。因为这不能解决根本问题。DevOps也正是整合上下游的管理方法。
2.2.DevOps应用了哪些高度思考的方法
每个公司都面临着自己的挑战，但常见的问题包括发布时间过长、软件不符合预期以及IT限制了业务增长。
在DevOps文化中，当出现问题时，开发人员不会得到“在我的机器上工作”的响应。投入生产的变更是小的和可逆的。另外，整个团队都理解这些更改，因此事件管理大大简化了。
没有等待时间、手动流程和冗长的评审，DevOps项目可以更快地从需求转向实时软件。更短的周期时间可以避免需求的转移，从而使产品交付客户想要的东西。
DevOps解决IT专门化之间的通信和优先级问题。为了构建可行的软件，开发团队必须了解生产环境，并在实际条件下测试他们的代码。传统结构将开发和运营团队置于竖井中。这意味着当他们的代码交付功能时，开发人员会感到满意。如果发布版本在生产中中断，则需要由运营团队进行修复。
通过一个更快的从想法到实际软件的过程，公司可以利用市场机会。通过这种方式，DevOps为企业提供了竞争优势。
2.3.DevOps应用的价值在哪里？
Patrick Debois是一名软件开发顾问，他在2009年创建了DevOps这个术语，并将一个会议命名为DevOps Days。DevOps解决了敏捷软件开发方法的一个缺点，即迭代的、快速的代码开发并不一定会导致迭代的、快速的代码部署。
在敏捷深入运营的同时，IT管理员对ITIL中有时费力且过于复杂的变更管理步骤感到恼火。ITIL支持稳定、可靠和可预测的IT，而敏捷提倡协作和变更。DevOps引起了双方的共鸣。事实上，组织可以同时做ITIL和DevOps，特别是如果他们拥抱云。
DevOps的概念在2013年的《凤凰项目》一书中得到了普及。Phoenix Project使用虚构的叙述来说明地方性的问题，并帮助IT经理理解协作和共享技术的概念和好处。DevOps的早期支持者包括以下人员:
- Debois和他的合作者Andrew Clay Shafer;
- 凤凰计划的作者Gene Kim, Kevin Behr和George Spafford;
- Flickr有影响力的早期采用者保罗•哈蒙德(Paul Hammond)和约翰•奥斯帕(John Allspaw);
- 持续交付先驱Jez Humble和Dave Farley;
- 集装箱化倡导者约翰·威利斯;和
- DevOps报告的组织者，包括Alanna Brown和Nicole Forsgren。
随着DevOps的流行，组织正式采用了DevOps方法。例如，零售商Target发明了DevOps Dojo培训方法。从协作聊天机器人到内置在云服务中的CI/CD套件，供应商们在工具中吹捧支持devops的功能。DevOps工程师只是一个头衔。
随着人工智能的出现，从代码创建到事件管理，DevOps不断发展。对于DevOps来说，人工智能意味着更智能的自动化，甚至更短的等待时间，甚至从业务需求到技术提供的无缝转换——但在这成为现实之前，还有很多障碍。
虽然DevOps已经达到了主流地位，但并不是所有采纳者都是DevOps的完全皈依者。许多人依靠DevOps方法来实现创收的IT项目，在这些项目中，他们看到了在尖端工具和技能上的投资回报。
3.丰田精益与DevOps方法
3.1丰田精益套路的方法
《Toyota Kata》丰田的套路告诉我们如果不能从开始关注价值流，那么在制造业学习丰田你的核心不是机器（自动化，智能化）不行，而是你的人不行。人不能的根本原因，在于你的文化不行。所以有句顺口溜这么说：
一流公司靠文化，二流公司靠流程，三流公司靠能人；
一流公司做标准，二流公司做服务，三流公司做产品，
《Effective DevOps》这本书正是站在整体IT的视角去解决IT融合管理价值观和文化的差异，解决IT整体IT管理的问题。DevOps（Development和Operations的组合词）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。
比利时的独立IT咨询师 Patrick Debois在2009年提出DevOps，也没有想到DevOps能够成为现在业内的最佳实践之一。从《目标》、《凤凰项目》到再到《持续交付》再到《effective Devops》、《DevOps handbook》结合了业内IT敏捷化发展的潮流，DevOps是敏捷研发中持续构建（Continuous Build，CB）、持续集成（Continuous Integration，CI）、持续交付（Continuous Delivery，CD）的自然延伸，从研发周期向右扩展到部署、运维，不仅打通研发的“需求、开发与测试”各个环节，还打通“研发”与“运维”。DevOps 不仅适合于传统企业进行IT服务转型,也更适合于“软件即服务（SaaS）”或“平台即服务（PaaS）”云服务化平台应用。
总结：高维度思考法，应结合《目标》理解约束理论（Theory of Constraints, 简 称 TOC）在IT中的应用文化，通过不断地进行基于目标的瓶颈管理，才能突破当前的管理问题，持续改进高维度文化管理。任何工作都是态度决定一切，文化决定可行性。没有DevOps文化，也就是没有管理上的持续改进，无法从根本上进行企业转型。【附：高德拉特《目标》五个聚焦步骤-底现前】
3.2丰田精益套路与DevOps整体思考
DevOps与敏捷软件开发相关联：因为敏捷实践者将DevOps作为一种方法扩展到生产中。这种方法甚至被贴上了与ITIL中倡导的IT服务管理实践反文化的标签。DevOps没有一个官方框架。为了完善他们的策略，组织应该了解DevOps、敏捷和瀑布开发、站点可靠性工程(SRE)和SysOps的相关上下文，甚至DevOps内部的变化。
DevOps与瀑布开发：瀑布式开发包括一系列线性过程中的步骤和步骤。它的阶段是需求、分析、设计、编码和实现、测试、操作和部署以及维护。在瀑布式开发团队中，开发人员在一个隔离的环境中测试新代码以保证质量(QA)，并且——如果需求得到满足——将代码发布给生产中使用的操作。IT操作同时部署多个版本，具有广泛的控制。支持是运营部门的责任。瀑布式方法在软件发布之间产生了长时间的等待。因为开发团队和操作团队是分开工作的，所以开发人员并不总是知道阻止代码按照预期工作的操作障碍。
DevOps模型将开发、QA和IT运维工作与更少的门和更连续的工作流结合起来。例如，一些运营团队的职责在应用交付管道中向左转移到开发团队。IT操作为代码改进提供反馈。DevOps依赖于持续开发、持续集成、持续交付和持续监控过程，而不是封闭的步骤。
DevOps与敏捷开发：敏捷是敏捷宣言中定义的一种软件开发方法。敏捷团队专注于增量和快速的代码创建和交付周期，称为sprint。每个sprint都在最后一个sprint的基础上迭代，这在软件中创建了高度的灵活性，并适应不断变化的需求。在这个周期中，项目最初的愿景可能会丢失。
DevOps源于敏捷在提高开发速度方面的成功，开发和运维团队之间以及组织的it和业务部门之间的脱节变得很明显，这严重阻碍了敏捷软件交付给用户。
在敏捷工作流中，开发和运营团队有各自的目标和领导。当一个组织同时使用DevOps和敏捷时，开发和运维团队在整个软件开发生命周期中管理代码。敏捷工作通常都有一个框架，比如Scrum，而DevOps没有框架。
DevOps与SRE:站点可靠性工程是与敏捷和DevOps同时出现的。它始于21世纪初的谷歌，本质上是软件开发生命周期中以编程和自动化为重点的方法。解决问题的方式应该防止它们再次发生。死记硬背的任务应该最小化。
SRE工具箱与DevOps非常匹配。两个学科的目标都是持续改进。SRE和DevOps工程师试图消除开发和运营之间的隔阂。虽然DevOps也可以扩展到业务涉众，但SRE通常停留在IT流程的范围内。
DevOps与SysOps:SysOps通常表示管理大型分布式应用程序(如SaaS产品)的生产部署和支持的IT管理员或IT团队。与DevOps采用者一样，SysOps团队应该精通云计算和自动化，以及其他能够使应用程序在大规模运行时表现良好的技术。SysOps团队对IT停机和事件进行故障排除，监控性能问题，执行安全规则并优化操作。
与其他IT管理员一样，他们关注高可用性、容错、安全性和性能。虽然SysOps专业人员可能会使用一些开发工具并理解开发过程，但他们的工作并不像DevOps工作那样专注于开发。但是，SysOps角色可以存在于DevOps和SRE组织中。
DevOps与DevSecOps:一些组织扩大了DevOps的范围，包括其他部门。在DevSecOps中，安全规划、扫描、测试和审查在DevOps循环中不断发生。BizDevOps侧重于将主管、应用程序所有者和其他业务涉众与开发、测试和支持软件的技术团队联系起来。虽然多合作总比少合作好，但这些合作者必须分享有效、及时和精确的输入。
4.全局化视角看待工作
《凤凰项目》写了IT发展过程的种种间隙。他意识到开发团队和运维团队的工作方式和思维方式有巨大的差异，即开发团队和运维团队生活在两个不同的世界，而彼此又坚守着各自的利益，所以在这两者之间工作到处都是冲突。通过全局化视角可以帮助企业解决管理上的冲突，并以业务价值为驱动力，提升IT融体服务效能。全局化视角是指：
4.1以业务视角为出发点：以业务的视角看问题，从业务价值链出发，并在业务价值链中聚焦在整个业务价值化的的整体效能输出。以应用精益管理的思维为基础，不断地优化价值链。
因为，只有这样才能把IT的整体服务水平进行不断地提升，当你尝试在一个程序中优化性能，也应站在业务的视角看是否要以现在就进行优化，例如：区分业务忙时与业务闲时，区分关键业务工作日与IT运维日等，才能更好地把IT与业务进行结合，不仅仅是支持，而应是更加了解业务。
4.2明确业务模型，改进约束点：理解不同业务的业务模型，掌握整个企业流程，而非盲人摸象，明确业务关系与业务挑战，只有真正理解一个公司是如何运营的，才能真正理解技术是如何为企业服务。
4.3可视化，透明化：所有的项目都应该是可视化的，而不应该存在无法触及到的暗礁，这就是看板理论与应用的重要性。一个好的看板应该是可以很好的看到项目或服务的进展，通过充分地可视化与透明化，加大了问题的暴露，并且通过看板加强了部门与部门之间的沟通，通过《Lean IT》的持续改进看板，持续不断地改进才能在全局持续提升与改进。
5.系统化视角看待工作
系统化:指采用一定的方式，对已经制定颁布的规范性文件或者流程进行归类、整理或加工，使其集中起来作有系统的排列，以便于使用的活动。
亚里士多德说“整体大于部分之和”，就是意识到了系统成员之间的相互关联和影响，会让整体出现部分的加和没有的性质。这在系统论里叫做“涌现性”。DevOps这一管理方法的流行，也让IT人，真正地理解了开发与运维的工作平等，工作互信，工作依存，相到影响，DevOps也正是从这一系统化的管理视角出发，解决部门与部门，团队与团队的相互冲突。详见《Effective DevOps》。
IT运维和开发是直接相联的。中国的很多企业运维都是由开发人员兼职去做实现的，。这也证明了运维在很多的企业是依附于开发，并且不受重视，这就导致很多开发人员一个错误的观念，运维相对于开发是不重要的。系统化视角是指：
5.1平衡速度和质量：很多企业非常关注质量，很多企业非常关系速度，在这一种平衡线上，应从系统化角度去思考，对速度与质量做出平衡，即不能速度为上，也不能质量无顶，因为对于企业的资源投入都是需要财务收益进行平衡，即必须有pre-ROI和post-ROI进行平衡，才能事半功倍，而不是事倍功半。
5.2应用PDCA：没有完美的人，和没有完美的系统系统是一样，只有持续不断地持续改进才能达到即定的ROCE,实现VOI的价值输出。DevOps正是内置了PDCA的管理方法，才能这一体系，与很多管理体系进行兼容与内置。（见前文）
通过《凤凰项目》我们可以看到我们每个人都是Eric，而凤凰项目对于我们的日常工作，就好像制造业生产线和凤凰项目的差别一样巨大。一方面说明了今天自动化与智能化的必要性，另一方面通过学习《凤凰项目》黄金三步工作法”和“四种工作内容”持续我们的工作效能（见前文《DevOps黄金三步法》）
5.3拥抱风险与变更：世界的变化来源于不断地变化 ，世界维一不断的就是变化。只有拥抱风险才能创新。承担风险是为了学习。没有风险，世界反而不自在，因为人们无法学习更新。
新产品开发应通过同理心(Empathy)、原型法(Prototyping)、用户故事(Storytelling)三个最基本的管理方法进行产品及服务的创新工作，DevOps是基于敏捷方法的扩展，是对Agile方法的前端扩展与后端扩展，只有不断地进行价值探索，识别新价值，才能在数字化的今天实现价值功用与功效【详见ITIL】的整体价值链的管理能力提升。
5.4合理区分工作：《凤凰项目》把工作区分为四类，分别为1.业务项目、2.内部IT项目、3.变更、4.计划外工作。第四类工作是计划外工作。 与其他种类的工作不同，计划外工作是恢复性工作，几乎总是让你远离目标。因此，知道你计划外工作从何而来就显得尤为重要
自动化流水线，仅是DevOps整体价值链中的一个环节，24个加速度《赋能》，加快了企业IT文化的建设与精益管理的应用，企业不断地拥抱DevOps这一管理文化，才能在今天不断变化的VUCA时代，站在世界的前端。EXINDevOps系统化的学习体系，让我们理解实现DevOps这一管理体系文化、精益、持续交付、轻量级ITSM的重要性，并且能够通过DevOps转型，实现企业的腾飞。
6.《凤凰项目》DevOps实战
《凤凰项目》一个IT运维的传奇故事：讲述了一位IT经理临危受命，在未来董事的帮助和逐步梳理的DevOps“黄金三步法”，最终挽救了一家具有悠久历史的汽车配件制造商的故事。小说揭示了管理现代IT组织与管理传统工厂的共通之处，让我们不仅能对如何管理IT组织心领神会，更重要的是将以完全不同于以往的视角来看待自己的工作环境。
总结：DevOps 是敏捷整个IT部门内的扩展，DevOps是高维度系统化思考的集成展现。
中文版Effective DevOps来了：
附： 自强不息学习书目推荐
《凤凰项目The Phoenix Project》：敏捷 DevOps故事类的书目，通谷易懂。-DevOps Master官方教材
《站点可靠性工程师Site Reliability Engineering》。SRE一本解释谷歌 SRE 实践的书，DevOps 诞生之前的 DevOps”被人熟知-DevOps Master官方教材
《精益创业The Lean Startup》：发现了如何精益工作，快速失败和更快盈利。
《精益企业Lean Enterprise》：说明了DevOps 背后的商业动机。
《基础设施即代码Infrastructure As Code》：说明了为什么所有公司都有必要采纳这种做法。
《布道之道Driving Technical Change》：大多数技术型组织内的常见性格特点。
《人件Peopleware》：管理工程师团队的经典图书，有一点过时，但仍然很有价值。
7.DevOps自评估
创建需要提出的问题类别，并根据具体应用得出答案。下面是几个问题的例子
1．DevOps基于《敏捷原则》进行了扩展，你是否遵循敏捷原则？
2．DevOps基于《精益IT》进行了扩展，你是否在工作中进行浪费与价值流的识别？
3．DevOps基于《持续交付》，你是否使用源代码库？
4．DevOps基于《持续交付》，你是否使用静态代码分析工具？
5．DevOps基于《持续交付》，你是否使用构建自动化工具？
6．DevOps基于《持续交付》，你使用场内基础设施还是基于云的基础设施？
7．DevOps基于《持续交付》，你使用配置管理工具、安装应用程序软件包的脚本还是运行时环境？
8．DevOps基于《持续交付》，你是否使用自动化脚本在生产和非生产环境中部署应用程序？
9．DevOps基于《持续交付》，你是否使用功能测试、负载测试、安全性测试和移动测试的自动化工具?
10．DevOps基于《轻量级ITSM》，你是否使用应用程序和基础设施监控工具？
8.爬楼
数字化领导力系列：
数字化领导力：基于DevOps与ITIL4梳理的八个新兴数字化管理岗位https://www.douban.com/note/783809248/
数字化时代：转型是一种必然，从DevOps到业务敏捷https://www.douban.com/note/795400708/
敏捷管理课程：业务敏捷的核心是一种组织能力!!!送：业务敏捷报告2020版解析及下载https://www.douban.com/note/794006236/
https://www.douban.com/note/799988465/ 新兴技术:如何一次通过EXIN&BCS 人工智能管理课
咨询基本功系列课程
咨询基本功系列第一讲：把读到的知识转化为能力三步法及完美学习的四步法 https://book.douban.com/review/8820627/
咨询基本功系列第二讲：显见是心与学会提问 https://book.douban.com/review/8709052/
咨询基本功系列第三讲：显见不动与信念 https://book.douban.com/review/8524974/
咨询基本功系列第四讲：显见不失与学会讲故事 https://book.douban.com/review/8909761/
咨询基本功系列第五讲：显见无杂与沟通的艺术 https://book.douban.com/review/8573156/
咨询基本功系列第六讲：见性惟真与书面沟通七步法 https://book.douban.com/review/8795275/
咨询基本功系列第七讲：见性无碍与故事思维 https://book.douban.com/review/8471462/
咨询基本功系列第八讲：显见不分与沟通圣经 https://book.douban.com/review/8550605/
咨询基本功系列第九讲：见性超情与深度工作 https://book.douban.com/review/8641784/
咨询基本功系列第十讲：见性离见与完美咨询 https://book.douban.com/review/12493989/
咨询的基本套路、IT咨询基本方法内训课程，欢迎大家收看，收听，收获到咨询的基本功：）
如何一次通过系列:
如何一次通过DevOps Foundation考试 https://www.douban.com/note/759867840/
如何一次通过ITIL4 Foundation考试https://www.douban.com/note/778661405/
如何一次通过DevOps Master考试 https://www.douban.com/note/660291760/
如何一次通过PMI-ACP https://www.douban.com/note/720287998/
如何一次通过EXIN Scrum Foundation https://www.douban.com/note/769868855/
如何一次通过EXIN Scrum Master https://www.douban.com/note/722250431/
如何一次通过APMG ISO/IEC20000:2018版 LA https://www.douban.com/note/762608725/
如何一次通过CCSK4.0（网盘下载CCSK4.0，送DevSecOps宣言中文翻译版） https://www.douban.com/note/764185464/
如何一次通过EXIN CCC云服务管理专家认证 https://www.douban.com/note/762735674/
敏捷服务管理系列：如何正确理解ITIL4 https://www.douban.com/note/763416570/
敏捷管理课程：业务敏捷的核心是一种组织能力!!!送：业务敏捷报告2020版解析及下载https://www.douban.com/note/794006236/
敏捷服务管理系列：如何正确理解ITIL4 https://www.douban.com/note/763416570/
DevOps沙盘总结系列课程
DevOps Master凤凰项目沙盘总结：IT涅槃重生之路 https://www.douban.com/note/681066663/
DevOps Master凤凰项目沙盘总结：“IT业务一体化”驱动业务价值 https://www.douban.com/note/662925305/
DevOps Master凤凰项目沙盘总结：高维度系统化思考 https://www.douban.com/note/703020201/
DevOps Master凤凰项目沙盘总结：履霜坚冰至，转型应自强不息 https://www.douban.com/note/700603657/
DevOps Master凤凰项目沙盘总结：一场精益敏捷探索之行 https://www.douban.com/note/645016138/
DevOps Master凤凰项目沙盘总结：通过DevOps实现IT组织转型 https://www.douban.com/note/693053178/
DevOps Master凤凰项目沙盘总结：DevOps黄金三步法 https://www.douban.com/note/694641377/
DevOps Master凤凰项目沙盘总结：DevOps起始质量之独孤九剑 https://www.douban.com/note/689504940/
DevOps Master凤凰项目沙盘总结：一场百玩不厌的质量感悟 https://www.douban.com/note/629890513/
DevOps Master凤凰项目沙盘总结：DevOps的独孤九剑 https://www.douban.com/note/630638887/
DevOps Master凤凰项目沙盘总结：同理心是DevOps成功关键 https://www.douban.com/note/685838159/
DevOps Master凤凰项目沙盘总结：做最有价值的事 https://www.douban.com/note/681074230/
2020年2月EXIN DevOps及敏捷前置要求与学习路径推荐 https://www.douban.com/note/752263618
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/
敏捷项目管理课程：建立持续改进的个人看板 https://www.douban.com/note/745245657/
DevOps Master系列:再论DevOps核心原则CALMS https://www.douban.com/note/731775271/
DevOps Master系列:如何把DevOps与CMMI整合 https://www.douban.com/note/759766513/
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/DevOps Master课程:回忆我与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云下安全与云等保（云博会内容提前曝光）
敏捷项目管理沙盘：一场随需而变的深度体验（1）https://www.douban.com/note/629584594/
站在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，别让惰性成为约束，持续不断地改善；
