事为先，人为重–事在人为

参考来源：
极客时间专栏：DevOps实战笔记，作者：石雪峰
课程链接：https://time.geekbang.org/column/intro/235

时代的典型特征 VUCA

VUCA 是指易变性（Volatility）、不确定性（Uncertainty）、复杂性（Complexity）和模糊性（Ambiguity），它代表了这个时代的典型特征。（在书籍《复盘》，作者沈磊那里也听过这个说法）

运维行业ITIL V4 的指导原则

关注价值、关注现状、交互式流程和反馈、协作和可视化、自动化和持续优化、极简原则和关注实践。

DevOps 技能发展路线图

根据这幅路线图，你要从编程语言入手，理解操作系统原理、系统性能、网络安全、基础设施即代码、CI/CD、运维监控和云技术等软件工程的方方面面理解…（从入门到劝退，大而全，小而精）
What is DevOps？
参考：https://roadmap.sh/devops
SVG的图片，不知道怎么拽过来，能正常访问，这个路径图的网站还挺有意思的，可以推荐给阮一峰的网络日志的周刊里。

DevOps技能模型

对于要想成为 DevOps 工程师的几条建议

1. 集中强化代码能力

未来的世界是软件驱动的世界，编程能力即将成为下一个必备能力，甚至连国务院发布的《新一代人工智能发展规划》中都提到，要在中小学普及推广编程教育。

而写可以用的代码，和写好的代码之间，距离绝不只是一点点而已。你可能会说，以后都用人工智能来编程了，可问题是人工智能从何而来？又是谁来训练和标注人工智能的呢？所以，越是基础的能力，越不会过时，比如数学、核心的编程思想、数据结构，以及基于代码构建对世界的认知和建模能力。

如果你现在只是刚开始接触代码，我建议你给自己定一个目标，专门强化自己的代码能力，至少花 1 年时间，从新手变成熟手，这对于你未来在 IT 行业的发展，至关重要。

2. 培养跨职能领域核心能力

相信经过几年的工作，你已经具备了当前岗位所需要的基本能力，这是你当前赖以为生的根本。那么在这些能力的基础上，逐步发展跨领域跨界的能力，尤其是那些核心能力，就成了投入产出比最高的事情。
举个例子，如果你是软件开发工程师，那么恭喜你，你已经走在了代码的道路上，接下来，运维能力就是你要尝试攻克的下一个目标。而在这些目标中，比如操作系统、自动化部署以及云能力，就是你要最优先发展的跨界能力，因为它们是运维的核心，也是了解运维最好的出发点。反过来说，如果你从事的是运维行业，那么除了常用的脚本以外，核心代码能力就是你的目标。

3.DevOps 核心理念和业务思维

如果你不理解 DevOps 到底是什么，那何谈成为 DevOps 工程师呢？因此，像 DevOps中的核心理念，比如精益敏捷、持续交付，以及很多实践，你都要有所了解。

DevOps 在公司的落地是大势所趋，也许你所在的团队也会参与其中，那么除了做好自己的本职工作外，你也可以多参与，多思考，看看推进的过程是怎样的，涉及到的角色又在做些什么，项目的整体进展和计划是什么。在实战中练习和补齐短板，对于积累经验来说，是不可或缺的。

4. 潜移默化的软实力建设

类似沟通能力、同理心、自驱力、学习能力、主动性等，无论从事任何职业，都是你身上的闪光点。很多天生或者从小养成的习惯，需要长时间潜移默化的训练才能有效果。

很多时候，IT 从业人员给人的印象都是不善表达，再加上东方文化的影响，本身就比较含蓄，这对很多沟通和表达来说，都是潜在的障碍。这个时候，就要尽量把握已有的机会，比如多参加团队内部的读书分享、公司内部的讲师培训报名等。
我的建议就是 6 个字：勤练习，多总结。就像DevOps 一样，持续改进和持续反馈，培养自己的自信心。

最后，我想强调的是，就像 DevOps 没有明确的定义一样，DevOps 工程师的技能也没有
明确的限定，所以，你要时刻保持好奇心，持续学习，总结出自己的能力体系，并在实践积
累经验，这样才能在激烈的竞争中占得先机。

建立起DevOps 体系认知

介绍 DevOps 的定义、价值、实施与衡量
软件开发的模式的改进（网规的考试内容中也学习过）
1.瀑布流模式
按部就班的先聊需求，确认方案，然后开始建设，检验合格，交付，开发完成转维护；
2.敏捷开发模式
小步快走，你想要的是这样的吗？对照效果看看再确认，是这样的吗？行，那我们接着开发；
3.DevOps 模式(要解决什么问题？)
DevOps 最开始想要打破的就是开发和运维之间的对立和隔阂。在传统模式下，度量开发团队效率的途径就是看开发完成了多少需求。对于运维团队而言，他们的考核指标却是系统的稳定性、可用性和安全性。

运维和运营的区别
运维团队转向运营团队，他们需要持续不断地把线上的真实数据和用户行为及时地反馈给需求团
队，来帮助需求团队客观评估需求的价值，并及时作出有利于产品发展的调整，这样一来，
业务也被引入到了 DevOps 之中，甚至诞生了 BizDevOps 这样一个专门的词汇。

DevOps 的定义（3P+calms）

DevOps 是通过平台（Platform）、流程（Process）和人（People）的有机整合，以
C（协作）A（自动化）L（精益）M（度量）S（共享）文化为指引，旨在建立一种可以
快速交付价值并且具有持续改进能力的现代化 IT 组织。

DevOps的目标

试图通过体系化的研发实践导入、软件架构的整体革新、组织管理理念的不断升级和企业文化的影响塑造，来帮助企业改善整个软件交付过程，在实现高吞吐量的同时保证服务的总体稳定性，从而真正实现又快又好的软件交付目标。

DevOps 的 4 个结果指标(交付效率和交付质量),

1. 部署频率指应用和服务向生产环境部署代码的频率。
2. 变更前置时间：指代码从提交到成功运行在生产环境的时长。
3. 服务恢复时间：指线上应用和服务出现故障到恢复运行的时长。
4. 变更失败率：指应用和服务在生产环境部署失败或者部署后导致服务降级的比例

DevOps 的 3 个支柱(文化、工具、培训赋能)要义与核心

人 + 流程 = 文化，在具体的流程之下，人会形成一套行为准则，而这套行为准则会潜移默化地影响软件交付效
率和质量的方方面面。这些行为准则组合到一起，就构成了企业内部的文化。

流程 + 平台 = 工具，企业内部流程的标准化，是构成自动化的前提。试想一下，如果没有一套标准的规则，每一项工作都需要人介入进行判断和分析，那么结果势必会受到人的因素的影响，这样的话，又如何做到自动化呢？

而平台的最大意义，就是承载企业内部的标准化流程。当这些标准化流程被固化在平台之中时，所有人都能够按照一套规则沟通，沟通效率显然会大幅提升。平台上固化的每一种流程，其实都是可以用来解决实际问题的工具

平台 + 人 = 培训赋能，平台是标准化流程的载体，一方面可以规范和约束员工的行为，另一方面，通过平台赋能，
所有人都能以相同的操作，获得相同的结果。这样一来，跨领域之间的交接和专家就被平台所取代，当一件事情不再依赖于个人的时候，等待的浪费就会大大降低，平台就成了组织内部的能力集合体。

DevOps的模型和框架

DevOps 能力成熟度模型

这套模型覆盖了软件交付的方方面面，包括敏捷开发管理、持续交付和技术运营三大部分，同时，也有与应用架构设计、安全和组织结构对应的内容。

DevOps 的能力实践和能力框架

能力实践定义了企业落地DevOps 的路线图和主要建设顺序，能力模型可以指导支撑方法的各类实践的落地建设；
能力实践时刻跟随企业价值交付的导向，而能力模型的积累和沉淀，能够让企业游刃有余地面对未来的各种挑战。

建设-DevOps 的实施要点

企业需要立足自身，识别差异，锚定目标，关注能力，并持续改善软件的开发交付效率，立体化的实施框架，通过模型、方法、能力和实践的相互作用，实现全方位的能力提升。

建设-DevOps 的通用实施路径 -三步工作法

“DevOps 三步工作法”。它来源于《DevOps 实践指南》，高度抽象的“三步工作法”，概括了 DevOps 的通用实施路径。
第一步：流动。通过工作可视化，限制在制品数量，并注入一系列的工程实践，从而加速从开发到运营的流动过程，实现低风险的发布。

第二步：反馈。通过注入流动各个过程的反馈能力，使缺陷在第一时间被发现，用户和运营数据第一时间展示，从而提升组织的响应能力。

第三步：持续学习和试验。没有任何文化和流程是天生完美的，通过团队激励学习分享，将持续改进注入日常工作，使组织不断进步。

第一步“流动”所要解决的问题。通过使用价值流图对软件交付过程进行建模，使整个过程可视化，从而识别出交付的瓶颈和各个环节之间的依赖关系;

第二步：寻找团队痛点，所谓痛点，就是当前最影响团队效率的事情，同时也是改进之后可以产生最大效益的事情。

第 三 步：快速建立初期成功，切记不要把面铺得太广，把战线拉得太长，这其实是DevOps 转型初期最典型的一个陷阱。
最关键的就是识别一个改进点，定义一个目标。比如，环境申请和准备时间过程，那么就可以定义这样一个指标：优化 50% 的环境准备时长。这样一来，团队的目标会更加明确，方便任务的拆解和细化，可以在几周内见到明显的成果。

为什么 VSM 会是企业 DevOps 转型的第一步呢？

1. 看见全貌。
   对于流程改进来说，第一步，也是最重要的一步，就是能够看见全
   貌，这样才能从全局视角找到可优化的瓶颈点，从而提升整体的交付效率。

2. 识别问题。
   VSM 中的几个关键指标，也就是前置时长、增值和不增值时长，以及完成度和准确度，
   都是可以客观量化改进的指标。当面对这样一幅价值流图的时候，我们很容易就能识别出当
   前最重要的问题和改进事项。

3. 促进沟通。
   在我们开展 VSM 梳理的时候，团队才第一次真正了解上下游团队的职责、工作方式，以及让他们痛苦低效的事情。这时，我们通常会设身处地地想：“只要我们多做一点点，就能大大改善兄弟团队的生存状况了。”实际上，这种同理心对打破协作的壁垒很有帮助

4. 驱动度量。
   收集 VSM 数据的过程本身，就需要平台间的打通和数据共享，以及自动化的推进，这有助于度量活动的开展。

5. 价值展现。
   对于企业而言，任何投入都需要有产出。要实现 DevOps 的转型，企业需要投入大量的精力。那么如何让高层领导明白企业交付效率改善所带来的价值呢？价值流梳理就是一种很好的方式。因为 VSM 从价值分析而来，到价值优化而去，本身就是在回答 DevOps 对于企
   业的价值问题。

价值和价值流图

价值就是那些带给企业生存&&发展的核心资源，比如生产力、盈利能力、市场份额、用户满意度等。

VSM 是Value Stream Mapping的缩写，它起源于传统制造业的精益思想，用于分析和管理一个产品交付给用户所经历的业务流、信息流，以及各个阶段的移交过程。

说白了，VSM 就是要说清楚在需求提出后，怎么一步步地加工原材料，进行层层的质量检查，最终将产品交付给用户的过程.

VSM 中有哪些关键要素和概念呢？

有 3点是你必须要了解的。

1.前置时间（Lead Time，简称 LT）。前置时间在 DevOps 中是一项非常重要的指标。具体来说，它是指一个需求从提出（典型的就是创建一个需求任务）的时间点开始，一直到最终上线交付给用户为止的时间周期。这部分时间直接体现了软件开发团队的交付速率，并且可以用来计算交付吞吐量。DevOps 的核心使命之一就是优化这段时长。

2.增值活动时间和不增值活动时间（Value Added Time/Non-Value Added Time，简称VAT/NVAT）。在精益思想中，最重要的就是消除浪费，也就是说最大化流程中那些增值活动的时长，降低不增值活动的时长。在软件开发行业中，典型的不增值活动有很多，比如无意义的会议、需求的反复变更、开发的缺陷流向下游带来的返工等。

3.完成度和准确度（% Complete/Accurate，简称 %C/A）。这个指标用来表明工作的质量，也就是有多少工作因为质量不符合要求而被下游打回。这里面蕴含了大量的沟通和返工成本，从精益的视角来看，也是一种浪费。

关于前置时间

有很多种解释，一般建议采用需求前置时间和开发前置时间两个指标进行衡量，关于这两个指标的定义，你可以简单了解一下。

需求前置时间：从需求提出（创建任务），到完成开发、测试、上线，最终验收通过的时间周期，考查的是团队整体的交付能力，也是用户核心感知的周期。

开发前置时间：从需求开始开发（进入开发中状态），到完成开发、测试、上线，最终验收通过的时间周期，考查的是团队的开发能力和工程能力。

##END提示，>!<