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的核心是解决“人”的问题。在合作的文化方面，每个人都有平等的发言权，开发和运维都很重要。这意味着有更多的相互尊重。这也会对彼此的问题产生更多的同理心，从而创造更好的工作环境。马丁路德金说：“信念，就是在你还没有看到整个楼梯的时候走出第一步”
2.转型的背景
2018年再一次寒冬开始了IT的人的学习时代，随着AI技术时代的到来，我们必将持续学习，自强不息，以应对VUCA时代，以及随着到来的“35岁被裁”、“40岁被裁”，努力到有一天，也能当上总裁。
2018年开始了拼学习能力的时代，也开启了IT大融合的时代，从开发到运维，再到安全，这是一个DevSecOps的时代（广告：编写中《DevSecOps》）。
EXIN DevOps Master号称是2018年最具价值的IT培训证书，站在巨人的肩膀上，让我们能站的更远，看得更高。DevOps它不仅仅代表着是对数字化转型的IT管理体系的支持，也是IT发展规律从人肉模式切换到自动化模式的管理理念的支撑。
DevOps Master课程是凛冬将至（Winter is coming）最具企业和个人投资的大师级直考认证，也是理解与证明DevOps管理体系的水平验证。在DevOps Master课程中将学习精益理论、持续交付、敏捷精要、轻量级ITSM的管理核心内容。通过三天的学习（2天理论+1天沙盘）不仅能学习到最权威的DevOps精华，还能学习到凤凰项目这一实践课程。
DevOps的好处包括:
- 减少IT部门之间的竖井，增加IT部门之间的交流;
- 软件更快地进入市场;
- 基于反馈快速改进;
- 更少的停机时间;
- 通过构建、验证和部署对整个软件交付流水线进行改进;
- 自动化减少了繁重的工作;
- 通过增加开发中的责任和代码所有权，简化了开发过程;和
- 更广泛的角色和技能。
然而，DevOps的挑战也是不少:
- 组织和IT部门的变化，包括新的技能和工作角色;
- 昂贵的工具和平台，包括有效使用它们的培训和支持;
- 开发和IT工具扩散;
- 不必要的、脆弱的或不安全的自动化;
- 跨多个项目和团队扩展DevOps;
- 由于快速失败的心态和工作普遍化vs.专业化，部署风险更大;
- 法规遵从性，特别是当需要角色分离时;和
- 新的瓶颈。
DevOps意味着来自开发和IT运营团队的承诺，即理解存在于软件项目每个阶段的关注点和技术边界。同意kpi的改进，例如更短的生产周期或更少的bug。通过跨工作角色的沟通，为持续的流程奠定基础。
评估现有的开发和IT运维工具。确定缺点，例如总是手动处理的步骤或没有api与其他工具连接的工具。考虑为整个公司在一个DevOps流水线上进行标准化。通过一个流水线，团队成员可以从一个项目转移到另一个项目，而无需重新技能培养。安全专家可以加强流水线，并简化许可证管理。这种方法的代价是DevOps团队放弃了使用最适合他们的方法的自由。
该组织现在有了DevOps的思维模式、追踪成功的指标和有能力的工具。注重最佳实践、知识共享和技能发展，以持续改进。优化工具和技术，确定影响kpi的障碍和差距。组织可以使用DevOps成熟度模型作为采用指南，成熟度五级如下所示:
- 初始:团队被隔离;工作是反应性的，并通过特定的工具和过程选择来完成。
- 已定义:试点项目定义了DevOps方法、基本流程和工具。这是概念的证明。
- 管理:组织通过从试验中吸取的经验教训来扩大DevOps的采用。试验的结果对不同的工作人员和项目类型是可重复的。
- 度量:在适当的过程和工具下，团队共享知识并改进实践。自动化和工具连接性增加了，标准通过策略实施。
- 优化及持续改进。DevOps可能演变成不同的工具集或过程来适应用例。例如，面向客户的应用程序有更高的发布频率，财务管理应用程序遵循DevSecOps实践。
3.DevOps转型价值点
3.1价值点1：DevOps实现敏捷IT运营
根据《凤凰项目》把IT工具区分为业务项目、IT内部项目、变更 、计划外工作或救火工作，通过工作合理区分，并与精益敏捷运营结合，使用看板这一管理方法，实现敏捷IT运营。实现企业敏捷IT运营，首先通过管理分类进行区分，包括业务项目、IT内部项目、变更、计划外工作或救火工作实现敏捷IT运营。
业务项目：应对理论（DevOps精益敏捷开发），通过DevOps2.0实现持续价值交付。
IT内部项目：应对理论（DevOps持续交付+基础设施即代码）,通过DevOps2.0实现内部项目的持续改进与优化
变更：应对理论（敏捷ITSM+精益理论）通过DevOps2.0实现在价值流中统一开发与运维的安全可靠的高质量输出
计划外工作或救火工作：（敏捷ITSM+敏捷开发）通过DevOps2.0融合IT服务管理（事故和问题等流程），实现低成本、高效率的工作交付。
3.2价值点2：DevOps实现企业文化转型
企业转型必不能少的就是管理方法，应用新型IT管理方法能够在最大限度上推进企业与员工的文化转型与技术转型，但在此也应认识到，实现DevOps不能解决的所有问题，解决问题的起点是融合Dev与OPS，实现统一IT价值交付。
DevOps在国外十年实践，有些企业一直徘徊在自动化流水线，未能进行组织DevOps2.0文化建设，未能实现企业的整体价值交付，使企业未能全面转型，并有些企业导致失败。
DevOps成功的道路很多，可以说是条条大路通“DevOps”，但企业DevOps失败的原因究其根本还是在企业DevOps文化建设，没有DevOps文化，只有工具的DevOps，它将无法带来企业技术的创新与突破。
因为只有好的DevOps文化，才能真正地改变企业中的每一个人，实现DevOps工作方式与思考方式的改变。实现企业内在思考与外在工具的完美统一。
DevOps不是万能药，不能包治百病，在四个象限内解决IT整体管理与持续业务价值交付。DevOps可以让实现企业文化转型，让企业员工发挥工作热情、实现价值提升。
3.3价值点3：DevOps实现企业敏捷组织转型
DevOps被誉为敏捷2.0的管理方法，解决敏捷管理方法最后一公里的问题。文化是DevOps和技术转型的重要组成部分。技术和管理实践塑造了文化，而文化反过来又有助于提高效能产出。组织不断地学习可以促进文化转变，在事件发生后进行mpr或RoI等方法，可以实现从企业IT价值流到IT流程的持续改进，通过不指责这一《effective DevOps》的核心文化，实现企业的组织级转型。但《凤凰项目》中也提到“预防措施是需要识别出问题，但问题就在于你怎么能全面识别风险并且去防止它？
所以建设DevOps可以帮助企业实现敏捷组织转型，去拥抱凤险，应对变化，由病态型组织，转变为效能型组织《Westrum》，才能让组织通过这一DevOps管理方法，实现企业的组织转型。下图为《Westrum》三类组织文化类型
4.DevOps转型过程中的误区
Patrick说：这听起来像是一个奇怪的建议，但是许多人将通过一些与DevOps实践相关的工具来了解DevOps。工具是重要的，但它们只能帮助您到这个程度。我从来没有想过要把任何事情都固定下来，所以人们必须不断地思考。如果您确实需要指导方针，可以考虑敏捷宣言，但要有更广阔的视野。找到最重要的瓶颈，并尝试与不同的团队合作来改进它。当您解决一个瓶颈时，您可能会发现瓶颈现在已经移动到一个新的位置。
在《凤凰项目》中针对变更进行了定义变更，变更就是对应用程序、数据库、操作系统、网络或硬件进行的物理、逻辑或虚拟操作，并且这样的操作可能对相关服务产生影响。这和ITIL的定义是类似的
高风险变更：在目录中的变更项目，不仅必须提交变更申请，而且必须在通过审批后才能安排实施。
注：归纳出真正的高风险变更，数量要少、风险性要大，范围在覆盖到那些最脆弱的服务、应用程序和基础架构。操作人员需要针对这些变更形成一些报告，说明变更的成功概率以及相关联的故障时间。
中等风险变更：变更提交者有责任向可能受到影响的人员进行咨询并得到其认可。完成以上工作后，拿到此次变更的受影响人员的确认函，他们就可以提交变更申请，在审核通过后即可以安排操作日程。
低风险变更：ITIL称之为标准变更。对于之前已多次成功实施的变更，只需要提前批准就可以执行。这类变更仍需要提交申请，但可以不经过显式的批准流程就可以安排操作日程。
未经授权的变更：不准出现未经授权的变更，也不准在服务中断期间再出现未经公开的变更。
要想实施好DevOps需要管理好转型过程中的变更与变化。
4.1误区:开源流水线工具省钱
工具可以帮助DevOps实现转型，随着jenkins持续集成工具跟随着DevOps2.0一起进行了升级，支持了DevOps的绝大多数相关产品，也让企业应用DevOps开源工具成为一种新的应用模式。也有很多企业认为使用开源产品，自己招流水线全栈工程师即能解决运营费用的问题，在此应注意：
安全风险：开源产品，由于是开源，所以存在所有开源代码全面暴露的风险，即开源是全面对所有用户开放，我在编写《DevSecOps》过程中查阅了很多相关资料，在信息安全方面存在很大的安全风险，并且开源由于是代码公开，并且存在更新不及时的问题，极易造成SQL渗透、HTTP注入、ROOT提权等高风险重大安全事件。DevSecOPs具体工具包括：
代码存储库：版本控制的源代码存储库使多个开发人员能够处理代码。开发人员签出和输入代码;如果需要，它们可以恢复到以前的代码版本。这些工具保存对源代码所做修改的记录。如果没有跟踪，开发人员可能难以跟踪哪些更改是最近的，哪些代码版本对最终用户可用。
构件库：源代码被编译成用于测试的工件。工件存储库支持版本控制的、基于对象的输出。工件管理与版本控制的源代码管理出于同样的原因，是一个很好的实践。常见的工件存储库包括JFrog工件和Nexus存储库。
CI/CD流水线：在版本控制存储库中提交的代码更改将自动触发后续步骤，例如静态代码分析或构建和单元测试。用于源代码管理的工具包括Git和GitHub。
CI / CD流水线应用：CI/CD使DevOps团队能够在开发生命周期中通过自动化频繁地验证并向最终用户交付应用程序。持续集成工具初始化流程，以便开发人员可以根据需要在共享存储库中创建、测试和验证代码，而无需手动工作。持续交付通过产品级测试和发布管理的配置设置扩展了这些自动步骤。持续部署可以更进一步，调用测试、配置和配置，以及监视和潜在的回滚功能。用于CI、CD或两者的常用工具包括Jenkins、GitLab和circlci。
容器：容器是共享操作系统上软件的隔离运行时。容器提供了抽象，使代码能够在不同的底层基础设施上以相同的方式工作，从开发到测试和分段，再到生产。Docker是最著名的容器化软件，而微软提供了特定的Windows容器选项。容器编排器——比如Kubernetes和商业Kubernetes发行版Red Hat OpenShift和Amazon Elastic Kubernetes Service——可以自动部署、扩展和维护容器。
配置管理：配置管理系统使IT能够基于脚本或模板提供和配置软件、中间件和基础设施。DevOps团队可以为软件代码发布设置部署环境，并通过配置管理工具在服务器、容器和vm上实施策略。对部署环境的更改可以进行版本控制和测试，因此DevOps团队可以将基础设施作为代码进行管理。配置管理工具包括Puppet和Chef。
云环境：DevOps组织经常同时采用云基础设施，因为他们可以自动化云基础设施的部署、扩展和其他管理任务。AWS和微软Azure是最常用的云提供商。许多云供应商也提供CI/CD服务。
监控：监视工具使DevOps专业人员能够观察系统、网络和基础设施上代码发布的性能和安全性。他们可以将监控与提供运营智能的分析工具结合起来。DevOps团队一起使用这些工具来分析代码更改如何影响整个环境。选择范围广泛，但包括New Relic One, Dynatrace, Prometheus, Datadog和Splunk。
云DevOps流水线：公共云提供商提供了原生的DevOps工具集，用于其平台上的工作负载。一个不完整的列表包括AWS CodePipeline和CloudFormation, Azure DevOps和pipeline，以及谷歌云部署管理器。云采纳者可以选择使用这些预先集成的服务或运行第三方工具。例如，一个组织可以使用HashiCorp Terraform或CloudFormation为其AWS工作负载制作“基础设施即代码”模板。
交付模型：作为服务的DevOps是一组工具的交付模型，这些工具促进了组织的软件开发团队和IT运营团队之间的协作。在这个交付模型中，提供者组装了一套工具并处理集成，以无缝地覆盖代码创建、交付和维护的整个过程。
4.2.误区：版权及升级问题：
很多人认为开源代码是免费的，但这是有前提条件的。就目前而言，国内大部分开源产品，虽然可以免费试用，但前提条件是免费仅限于个人研究非商用的情况下，如果用户公司商用并且发布在互联网上，就需要收费，且费用很高。企业的知识产权随着我国的重视程度，以及欧美国家的知识与商业保护，请在使用免费产品只认准开源协议，尤其是开发工程师及产品经理，防止“插刀教”。
4.3误区： 组织转型可以copy
《凤凰项目》一书真实地再现了企业面临的问题与挑战，其中企业也经过了多轮的裁员，并且整个企业无心做事，人浮于事。IT运转效率低下，公司市场占有率直线下滑。组织经过了”生死一线“，才在”带头人“的领导下，实现了DevOps的成功转型。
企业转型必有阵痛，没有随随变变就成功的企业，组织转型必然需要付出时间、财力、知识、文化等学习成本，成功转型DevOps的企业虽然具有一定的借鉴性，但一定不具有copy性，组织转型不具有复制性，并且在今天这个变化的时代，DevOps是一种持续改进的管理进化。
DevOps的关键要素CLAMS，其中C指文化、L指精益、A指自动化、M指指标、S指分享，组织转型的试点成功，也应更加关注企业转型的成功，实现企业的转型必将是跨多个部门的DevOps，而不仅仅是一个部分的DevOps，在每个组织应根据不同组织的行业特点与行业管理监管与治理的要求，在ISO38500、ISO20000、ISO27001、ISO31000等国际标准的框架下进行DevOps融合管理，才能真正实现组织的DevOps转型成功。
还有很多误区，后面慢慢写。手打版还是很累的。。。。。北京老李 2018年12月18日晚
5.DevOps的技能要求
DevOps通常被认为是一种哲学或协作IT文化，而不是严格定义的工作描述或技能集。因为这个领域非常广泛，DevOps的职位更适合IT多面手而不是专家。
DevOps工程师的角色并不是沿着一个职业轨道发展。专业人士可以从不同的背景进入这个职位。例如，软件开发人员可以获得操作方面的技能，比如主机基础设施的配置，从而成为DevOps工程师。同样，具有编码、脚本和测试知识的系统管理员也可以成为DevOps工程师。
许多DevOps职位招聘要求具备容器、云计算和CI/CD知识，以及软技能。DevOps工程师可能还需要更改流程并解决组织问题以实现业务结果。在DevOps组织中经常发现的其他标题包括:
- 基础设施开发;
- 网站可靠性工程师;
- 构建和发布工程师;
- 完整的开发人员;
- 自动化专业;和
- CI / CD平台工程师。
大多数入门级的DevOps工作要求计算机科学或相关领域的学位，包括编码，QA测试和IT基础设施组件。更高级别的职位可能需要在系统架构和软件设计方面的高级学位。在这条职业道路上的人也应该通过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》：管理工程师团队的经典图书，有一点过时，但仍然很有价值。
《目标：一种持续改进的流程》
《团队领导的五大障碍：关于领导力的寓言》
《丰田管理：为了获得改进、适应性和优异业绩而管理员工》
《持续交付：发布可靠软件的自动化构建、测试和部署方法》
《发布它！：设计并部署作好生产准备的软件》
《The Visible Ops Handbook: Implementing ITIL in 4 Practical and Auditable Steps》
《Visible Ops Security: Achieving Common Security and IT Operations Objectives in 4 Practical Steps》
《Personal Kanban: Mapping Work | Navigating Life》
《Kanban: Successful Evolutionary Change for Your Technology Business》
6.DevOps自评估
创建需要提出的问题类别，并根据具体应用得出答案。下面是几个问题的例子
1．DevOps基于《敏捷原则》进行了扩展，你是否遵循敏捷原则？
2．DevOps基于《精益IT》进行了扩展，你是否在工作中进行浪费与价值流的识别？
3．DevOps基于《持续交付》，你是否使用源代码库？
4．DevOps基于《持续交付》，你是否使用静态代码分析工具？
5．DevOps基于《持续交付》，你是否使用构建自动化工具？
6．DevOps基于《持续交付》，你使用场内基础设施还是基于云的基础设施？
7．DevOps基于《持续交付》，你使用配置管理工具、安装应用程序软件包的脚本还是运行时环境？
8．DevOps基于《持续交付》，你是否使用自动化脚本在生产和非生产环境中部署应用程序？
9．DevOps基于《持续交付》，你是否使用功能测试、负载测试、安全性测试和移动测试的自动化工具?
10．DevOps基于《轻量级ITSM》，你是否使用应用程序和基础设施监控工具？
7.爬楼
数字化领导力系列：
数字化领导力：基于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，别让惰性成为约束，持续不断地改善；
