参考资料：极客时间-DevOps实战笔记
DevOps基础理论篇
1. DevOps的定义
DevOps定义：
DevOps是一种文化、一场运动或实践，强调在自动化软件交付流程和基础设施变更过程中，软件开发人员与其他信息技术专业人员彼此之间的协作和沟通。他旨在建立一种文化和环境，使构建、测试、软件发布得以快速、频繁以及更加稳定的进行。
软件工程的三个重要阶段：
瀑布开发模式、敏捷开发模式、DevOps开发模式。
2. DevOps的价值
软件的价值：
软件慢慢从企业内部的支撑系统和成本中心，变成了企业服务的直接载体和利润中心。
软件交付的效率和质量成为企业的核心价值和核心竞争力。
DevOps的价值：
提高软件的交付效率和交付质量。
DevOps的四个结果指标：1.部署频率；2.变更前置时长；3.服务恢复时间；4.变更失败率。
3. DevOps的实施
DevOps工具：
工具是提升效率最直接的手段。
标准化、流程化。
但是工具没办法解决人的问题。
DevOps文化：
职责共担、持续改进。
DevOps的三个支柱：
-
人+流程=文化
在具体的流程下，人会形成一套行为准则，而这套行为准则会潜移默化的影响软件交付效率和质量的方方面面。这些行为准则组合到一起，就形成了公司的文化。
-
流程+平台=工具
流程标准化，并固化到平台。
-
平台+人=培训赋能
平台是标准化流程的载体，一方面可以规范和约束员工的行为，另一方面通过平台赋能，所以人都能以相同的操作，获得相同的结果。跨领域之间的交接和专家就被平台所取代。
4. DevOps的衡量
DevOps能力成熟度模型：
步骤和原则：
影响软件交付效率和质量进一步提升的最大瓶颈是什么？识别出改进目标和改进后要达到的预期效果。
关注能力，持续改进。
部署引力图：
DevOps落地实践篇
1. 价值流分析
VSM（value stream mapping）：
持续交付平台 -> VSM价值流交付平台。
价值就是带给企业生存发展的核心资源，比如生产力、盈利能力、市场份额、用户满意度。
VSM就是价值流图，通过价值流图对软件交付过程进行建模，使整个过程可视化，从而识别出交付过程的瓶颈和各个环节的依赖关系，不断优化和改进。
VSM关键要素：
前置时间
增值活动时间和不增值活动时间
完成度和准确度
2. DevOps转型路径和常见问题
两种轨迹：
自底向上，自顶向下。
需求管理层的认可和支持是必选项。
通用路径：
寻找合适的试点项目。
寻找团队痛点。
快速建立初期的成功。
快速展示和持续改进。
DevOps转型的J型曲线：
随着交付能力的提升，质量能力和技术债务开始显现。比如大量的手工回归测试、耦合性太强。
3. 业务敏捷
交付能力提升，可以帮助业务以最小成本进行试错，将新功能快速交付给用户。
所以，开发更少的功能，聚焦用户价值，持续快速验证，就成了产品需求管理的核心思想。
4. 精益看板
丰田准时化生产系统，拉动式生产，关键在于限制在制品数量。
在制品数量上升，导致交付周期变长，交付质量下降，团队信任下降。
精益看板实践的5个步骤：
可视化流程
定义清晰的规则
限制在制品数量
管理工作流程
建立反馈和持续改进
可视化流程：
根据价值流定义看板。
竖向队列，按价值流转的各个主要阶段进行划分。比如需求、开发、测试、发布。
横向泳道，用于需求与需求之间划清界限。
定义清晰的规则：
可视化规则
显示化规则
限制在制品数量：
限制在制品数量，理论上交付的前置时间应该大大缩短。
关键节点：
- 需求流入节点。业务方和研发团队关于需求的PK。研发团队需要承诺业务方以最快的速度交付最高优先级的需求。
- 需求流出节点。开发团队自己负责业务的发布。
管理工作流程：
每日站会。关注被阻塞的任务。
队列填充会议。对任务的优先级进行排序，展示需求的开发状态。
发布规划会议。以最终交付为目标，同步研发团队和业务方的信息。
建立反馈和持续改进：
持续改进和对人的尊重，才是一切改进方法的终极坐标。
5. 配置管理
配置管理，是站在软件交付全生命周期的视角，对整个开发过程进行规范管理，控制变更过程，让协作更加顺利，确保整个交付过程的完整、一致和可追溯。
核心理念：版本变更标准化、将一切纳入版本控制、全流程可追溯、单一可信的数据源。
6. 持续集成
认识CI：
CI就是持续集成，集成什么？为什么要持续？
集成软件，软件集成是一件高风险、不确定的事情。
越痛苦的事情，越要频繁的做。
CI的定义：
CI是一种软件开发实践，团队成员频繁的将他们的工作成果集成到一起（通常每人每天至少提交一次，这样每天就会有多次集成），并且在每次提交后，自动触发运行一次包含自动化验证集的构建任务，以便尽早地发现集成问题。
实施CI的三个阶段：
-
每次提交触发完整的流水线。
关键词：快速集成。
1.1. 统一的分支策略。定义以集成为目的的分支。
1.2. 清晰的集成规则。基于时效性的要求，不同层的CI，步骤和要求不同。
1.3. 标准化的资源池。资源池按需初始化，环境标准化，任何任务可以在任何节点运行。
1.4. 足够快的反应周期。CI环节不能超过10-15分钟。
-
每次流水线触发自动化测试。
关键词：质量内建。
2.1. 匹配合适的测试活动。
2.2. 树立测试结果的公信度。
2.3. 提升测试活动的有效性。
-
出问题第一时间修复。
关键字：文化建立。
机制：10分钟内修复代码，如果不能修复就回滚。
让CI发挥价值的关键，在于团队面对持续集成的态度，以及团队是否建立的持续集成的文化。
7. 自动化测试
自动化测试要解决什么问题：
产品交付速度提升，给测试工作带来了很大挑战。要测试的内容越来越多，但是测试的时间越来越短。
适合的场景：回归测试、接口测试、兼容性测试、压力测试。
面临问题：投入产出比、上手门槛、维护成本高、测试设备投入高。
自动化测试设计：
单元测试、接口测试、UI测试。
自动化测试开发：
工具和平台支持。
测试数据、用例、脚本的管理，测试过程中的数据收集、度量、分析和展示，以及测试报告的发送，都是成熟的自动化测试框架应该具备的功能。
自动化测试结果分析：
- 覆盖率
- 测试误报率
8.内建质量
不应该将质量依赖于检验工作，因为检验工作既昂贵，又不可靠，最重要的是，检验工作并不直接提升产品质量，只是为了证明质量有缺陷。正确的做法是将质量内建于整个流程之中，并通过有效的控制手段，来证明流程自身的有效性。
内建质量的核心原则：
- 问题发现得越早，修复成本就越低。
- 质量是每个人的责任，而不是质量团队的责任。
内建质量的实施思路：
我们应该在软件交付的各个环节中注入质量控制的能力。
需求环节，定义清晰的需求准入规则。比如价值、可行性、依赖、描述、拆分、验收条件。
开发环节，代码评审和持续集成。比如需求匹配度、实现清晰度、自动化检查机制（风格、风险、安全漏洞）。
测试环节，自动化测试和手工探索测试，覆盖安全、性能和可靠性。
部署和发布环节，线上监控和危险操作扫描。
优先加强哪个环节？从源头入手。
内建质量的实施步骤：
选择合适的检查类型。投入产出比高。
定义指标并达成一致。指标项、参考值。静态指标值和动态指标值。
建立自动化执行和检查能力。在源头设置质量门禁。
定义问题处理方式。
持续优化和改进。核心目标不是通过质量门禁，而是为了质量提升。
内建质量常见问题：
9. 技术债务
代码七宗罪：
量化技术债务：
比较常用的开源软件是SonarQube。
计算出来的技术债务会因为开启的规则数量和种类的不同而不同。
解决方法和原则：
步骤：共识、可见、止损、改善。
原则：
让技术债务呈良性下降趋势
优先解决高频修改的问题
在新项目中启动试点
技术债务无法被消灭，也不要等到太晚
需要优先处理的问题类型：
大量重复代码
类之间严重耦合
方法过于复杂
条件判断嵌套太多
缺少必要的异常处理
多表关联和缺少索引
代码风险和缺陷
安全漏洞
10. 环境管理
环境管理的挑战：
环境种类多。比如开发环境、测试环境、生产环境。
环境复杂度高。现代应用的架构逐渐从单体应用向微服务应用转变。
环境一致性难以保证。
环境交付速度慢。
环境变更难以追溯。
基础设施即代码：
基础设施即代码，就是用一种描述性的语言，通过文本管理环境配置，并且自动化完成环境配置的方式。
典型的就是以 CAPS 为代表的自动化环境配置管理工具，也就是 Chef、Ansible、Puppet 和 Saltstacks 四个开源工具的首字母缩写。
环境管理实践：
开发运维打通的GitOps实践
开发环境的治理实践
开发本地测试的实践
11. 部署管理
部署和发布：
部署：通过技术手段，将本次开发测试完成的功能实体，应用到指定环境的过程。
发布：将部署完成的功能生效，对用户可见和提供服务的过程。
质量思想：
传统的质量思想：要在发布之前确保本次变更的功能万无一失。
DevOps的质量思想：要在保障一定质量水平的前提下，尽量加快发布节奏，并通过低风险发布手段，以及线上测试和监控能力，尽早地发现问题，以一种最简单的手段来快速恢复。
一定的质量水平：
与定义一个发布质量标准相比，更重要的是扭转团队的质量观念。质量不再是测试团队自身的事情，而是整个交付团队的事情。如果出了线上问题，团队要一起来定位和修复，并且反思如何避免类似的问题再次发生，从失败中学习。
测试能力向前、向后延伸，一方面，提供工具和平台帮助开发更容易自测，另一方面，加强针对线上监控埋点等类型的测试，保证线上问题可以快速暴露，正常获取可以辅助分析玩家行为的数据，全面提升整体的发布质量。
低风险的发布手段：
蓝绿发布、灰度发布、暗部署。
线上测试和监控：
如果验证发布是否正常，核心在于线上测试和监控。
DevOps新理念，监控就是一种全量的测试。
快速恢复：
线上诊断，阿里的Arthas。
解决问题，向前修复和向后回滚。
故障自愈，服务降级和兜底策略。
12. 混沌工程
混沌工程：
混沌工程是一门在分布式系统上进行实验的科学，目的是建立人们对于复杂系统在生产环境中抵御突发事件的信心。
复杂的分布式系统，Netflix 公司在 2014 年公开的微服务调用关系图：
服务可用性实践：
日常的系统可用性保障活动，故障演练、服务降级方案、全链路压测。
如何发现潜在风险，比如Netflix的混乱猴子，随机关闭生产环境中的实例。
不要把可用性的假设建立在依赖服务不会出问题上。
混沌工程的原则：
建立稳定状态的假设。业务指标、技术指标。
真实世界的事件。
在生产中实验。
持续的自动化实验。
最小的影响范围。
13. 正向度量
DevOps的核心目标，提高交付效率，提高交付质量。围绕目标，拆分度量指标。
如何定义指标：
明确受众
直指问题
量化趋势
充满张力
定义指标有哪些原则：
全局指标优于局部指标
综合指标优于单一指标
结果指标优于过程指标
团队指标优于个人指标
灵活指标优于固化指标
哪些指标最重要：
如何开启度量工作：
细化指标
收集度量数据
建立可视化平台
识别瓶颈并持续改进
14. 持续改进
团队最应该具备的能力：
持续改进，始终能够找到新的突破，持续追求更好的状态。
DevOps做到什么程度算实现转型落地？核心就是团队具备了持续改进的能力，而不是简单的引进了几个工具，建立几个度量指标。
PDCA方法论，Plan（计划）、Do（实施）、Check（检查）、Action（行动）。
持续改进的核心，在于建立一个学习型的组织。
学习型组织的4个实践：
-
鼓励正向回溯和总结
当问题发生之后，事先准备一份详尽的故障分析报告，并拉上相关方彻底分析问题的根源，给出改进任务的具体时间点。
预留固定时间进行改进
在团队内部共享业务指标
-
激励创造性，并将价值最大化
在团队成员的绩效目标中，增加对团队贡献和技术创新的要求，在团队内部鼓励创新类工作。
在团队内部建立激励和选拔机制，为好的想法投入资源，把他们变成可以解决类似问题的工具。
DevOps平台工具篇
1. DevOps平台建设的三个阶段
阶段一：从无到有
建议：引入开源工具和商业工具，快速补齐现有能力的短板。
如何选择工具？选择主流工具。
- 需求管理工具 Jira；
- 知识管理工具 Confluence；
- 版本控制系统 GitLab；
- 持续集成工具 Jenkins；
- 代码质量工具 SonarQube；
- 构建工具 Maven/Gradle；
- 制品管理 Artifactory/Harbor；
- 配置管理工具 Ansible；
- 配置中心 Apollo；
- 测试工具 RF/Selenium/Appium/Jmeter/TestNG；
- 安全合规工具 BlackDuck/Fortify；
阶段二：从小到大
经过了第一个阶段，企业交付链路上的工具基本已经齐全了。团队对工具的需求从够用到好用开始转变。另外，随着业务发展，团队扩大，差异化需求也成了摆在面前的问题。再加上，人和数据越来越多，工具的重要性与日俱增。
建议：使用半自建工具和定制商业工具，来解决自己的问题。
半自建工具有哪些注意事项：
设计时给扩展流出空间
实现时关注元素治理
阶段三：由繁到简
建议：使用整合工具来化繁为简，统一界面，简化操作，有效度量。
-
企业工具平台治理
找到软件交付的主路径，用一个平台覆盖这条主路径，从而串联各个单点的能力。
-
打造自服务的工具平台
用户登录平台，实现自己的操作，查看自己关心的数据。
2. DevOps产品设计的五个层次
五个层次：战略存在层、能力圈层、资源结构层、角色框架层和感知层。
第一个层次：战略存在层
把战略建立在不变的事物上。
DevOps产品战略定位：效率、质量、成本和安全。
第二个层次：能力圈层
明确哪些是自己的核心竞争力，哪些是自己的边界和底线。
第三个层次：资源结构层
对资源的整合和调动的能力就成了核心竞争力。
至关重要资源，领导的支持。
第四个层次：角色框架层
在用户的角度看待问题，要在他们当时的场景下，去解决他们的问题。
不要让你的产品只有专业人士才会使用。
第五个层次：感知层
UI界面。
3. 现代流水线必备的十大特征
