一、敏捷的局限性的促使devops诞生
敏捷的局限性：敏捷只注重开发阶段的敏捷，未涉及到整个产品生命周期流程其他环节导致采用敏捷开发流程后效果不明显。
devops成为企业数字化转型的助推器，扮演基础设施的角色，通过加速业务创新，快速部署，最终保证业务系统稳定的运行。
国内的公司已经开始采用自研或者开源的工具实现了devops，但是当前的devops还是比较基础，从自动化入手，将手动编译，打包，部署等环节转变为自动化的模式。大部分只停留再初级阶段
为什么大部分公司的devops都停留在初级阶段？
1、人才紧缺
2、devops的技能待提升，大部分专业工程师都是半路转岗而来，比如运维，测试，只熟悉的领域，但是对整个流程理解不深（在我现在的公司，就是由一些测试人员去做devops 平台开发）
3、缺乏整体全局视角的的学习资料
其实devops的一种理念和思想，将现代科学技术和技术应用到端到端的价值链中，通过对企业的文化，流程，和制度的变革获得更大的成功
端到端是devops的主线
devops主要思想是持续改进
新时代的软件开发流程--devops
那怎么样才能做好devops，要以下三个大的原则
1、要全局观
2、要以始为终
3、要持续改进
当前市场竞争激烈，企业期望可以更快的将产品投入市场，所以devops是每个企业绕不过去的话题
二、devops的发展历史
精益软件开发和敏捷软件开发是devops发展的基础，devops并不从属于敏捷，是在敏捷的基础上改进的一种开发方法
精益敏捷
精益思想来自20世纪的丰田汽车，一个绝对消除浪费的系统
精体现在对产品的质量的追求上，精益求精
益体现在通过低成本，少消耗，企业才能获得收益
浪费的事情
库存---在软件研发流程中代表：未完成的工作
过度处理---在软件研发流程中代表：不必要的流程，没有人读的文档
过度生产---在软件研发流程中代表：额外的特性
运输-------在软件研发流程中代表：信息传递的知识丢失
等待-------在软件研发流程中代表：延迟，等待决策，等待资源分配，释放
移动-------在软件研发流程中代表：任务的切换
缺陷-------在软件研发流程中代表：缺陷，bug
通过价值流图可以实现在开发过程中的梳理流程到底有没有价值，有价值，无价值，无价值但是必须
敏捷 2001年雪鸟会议，宣布敏捷出现，成立敏捷联盟
敏捷开发的关键点
开发人员和业务人员相互合作，欣然面对需求变化，就算到了开发后期也一样，为客户价值。通过敏捷响应变化
降低每个迭代交付的批量大小，短周期交付，经常交付可工作的软件，一般2到4周发布一个版本，客户可以更早的使用产品，开发人员也可以更快的相应客户的需求
敏捷仅仅涉及到软件开发阶段，其他流程并未涉及到，所以企业感受不明显
devops打通了端到端的软件开发流程，将开发和运维相互融合，最终高效的，高质量的交付用户价值，为企业赢得市场
三、影响地图：用来解决产品规划和需求的利器
端到端：从需求提出到需求被发布到生产环境交付给用户的整个过程
最佳实践： 是指被业界广泛采用的，被证明有效的方式方法
使用影响地图确保：产品规划，里程碑规划和用户分析的大方向是正确的
为什么要做产品规划
软件开发过程中，有多少功能是用户真正需要的
软件开发过程中，有没有做到一半就取消的功能和产品
软件行业的一个成功率很低的行业
1994年，软件项目成功率为16%（统计了8000个项目）
2004，软件项目的成功率为29%（采用敏捷和精益敏捷的思想，统计了40000个项目）
为什么软件项目的成功率这么低？
1、不了解用户的真实需求
2、更关注了软件功能本身，忽略了需要交付的业务目，
3、对产品缺乏整体的认识和理解
所以挖掘客户的真实需求非常重要，所以我们需要找到一个工具来挖掘客户的真实需求
影响地图：是一种战略规划方面的技术，影响地图通过回答 why who how what来输出思维导致
why 为什么要做这件事，为什么要开发这个功能。答案一定的业务目标，不可不切实际，符合smart原则
who 实现这个目标和那些人或角色有关系 ，包括正面的人和负面的人或者角色，主要角色 次要角色 场外角色
how 考虑这些角色是如何影响最终的目标的实现，考虑角色是如何帮助或者阻碍目标的实现
what 讨论做什么可以实现这个影响，筛选出有价值的部门，优先完成
影响地图的特点
结构化：第一层是目标，第二层是角色，第三层是影响，第四层是交付物
整体性：从目标，到角色 到交付物的树状试图
协作性：各个角色沟通和协助的桥梁
动态性：是需要不断迭代更新，不断完善的。影响地图是基于价值的
四、用户故事：对用户需求达成一致的利器
对于一个用户需求，产品 开发 测试对需求的理解完全不一样，最终的交付的产品也，不是客户所需要的
用户故事，一种将用户需求可视化的工具
软件开发是一个团队项目，由一个又一个功能组成，整个开发流程中，功能就像篮球比赛中的篮球一样，从队员的手里传递，最终交给投篮最准
的人投入，每个队员的共同目标是将篮球投入篮筐
软件开发流程里，产品经理对功能需求分析，开发人员对功能代码实现，
测试人员对功能进行测试，最后运维人员将功能部署到生产环境，交付给客户
共同的目标：将功能交付给客户
团队协助要做到高效协作并非容易的事情
达成共识的方法：让软件开发过程中每个角色都能理解用户的需求是什么，工作内容是什么
那么，写文档可以解决问题么？
文档并不能达成共识
人们习惯性的根据自己的经验见识在文档范围内思考，难免对内容理解不到位，造成误解
看文档就像看旅游的照片一样，和自己当时的心境是有关系的，不同的人看到的最终结果是不一样的
达成共识唯一的方法是各个相关方坐到一起，用有效方式进行讨论，最终寻求一致理解。
有效的方式就是讲用户故事
用户故事 是从用户的角度 讲用户如何使用，让大家理解一致，才能做更符合用户需求的软件
如何讲好用户故事？
讲故事是核心观点
1、聚焦全景 ：将一个大的需求进行合理的拆分，拆分后的需求就被称为用户故事，需要
从整体的视角出发，和团队一起理解正在开发的产品，共同讨论每个故事在整个产品中的定位
，优先级，共同权衡
2、3C原则：在极限编程提出的
卡片，写下所期望的软件特性，是用户故事的载体，记录每个用户想要的产品的功能特性
交谈，聚在一起对要开发的软件进行深入的讨论，请相关人员围绕卡片中的用户故事进行讨论
每个参与者都需要提问，其他人回答。让参与者对用户故事理解达成一致
确认，对完成的特性的进行确认（验收条件），考虑如何判断用户故事已经完成，明确验收
条件
3、使用故事模板：统一团队交流的语言，可以提升讨论的效果
用户故事的讲解可用采用下面的模板
作为xxx角色。我需要xxx功能特性，以便于解决xxxx问题
讨论有那些用户角色，不同的角色对软件的诉求的不同
讨论要做的功能，不仅仅讨论页面的功能，还要讨论背后的逻辑，隐含需求
讨论功能的价值
讨论异常情况，以及出现后的解决方案
讨论开发周期
软件开发是一个团队项目，在团队中沟通协调至关重要
五、看板方法：暴露问题和持续改进的方法
看板方法的目的是让：工作流程可视化
通过限制每个周期中卡片的数量限制进行中进行中的工作项的数量，只要团队具备处理能力
才能拉入新的任务项
看板也来源于日本丰田
卡片数量代码团队能处理的任务的上限
为了解决团队过载问题，需要将团队成员工作可视化
看板方法包括可视化工作流程，定义流程运作规则，限制在制品数量的拉动系统，
是一种在团队成员工作不过载的前提下实现按时交付的管理方法
从现状出发，渐进式，增量式的特色的改进方法
如何使用看板方法
1、价值流映射，从响应客户请求创造价值开始到完成请求交付用户价值为止所需实施的一系列相关行动。如果想要更快的交付用户价值，需要了解整个流程的运行情况，价值流映射
能帮助了解整个流程。
在每个环节都会有三个数据
LT：前置时间或交付时间，指工作项目从开始到结束所消耗的时间，包含等待时间
PT：处理时间是指处理该工作项的时间
%C/A：完整度与准确度的百分比，该值表示返工的比率，一般是估计值
使用看板方法可以发现影响价值交付的瓶颈
2、定义工作项的类型
以需求为中心的工作项，包括需求，功能和用户故事
以开发为中心的工作项，包括重构，缺陷，优化等
以运维为中心的工作项，包括扩容，备份，故障
其他事务型的工作项。包括培训，会议
3、看板可视化的设计
将步骤抽象为分析，设计，开发、测试、发布关键环节，就可以设计出工作项需要流经的
看板的列
每列分为进行中，完成
团队成功工作项可视化，端到端交付流程可视化，系统瓶颈和问题可视化
是最基础的实践，暴露问题
4、现实化定义规则
定义规则，比如工作项进入下个阶段需要满足什么条件
5、限制再制品的数量。需要明确每个环节的在制品的数量
在制品是进行中或者等待中的任务项的数量，当小于限制数量是才可以拉入新的任务项
6、跟踪工作项
为了顺畅的交付高质量的用户价值
一般有站会。对着看板检视工作的完成的情况，审视看板。跟踪工作项，促进价值流动
关注 积压的需求 中断的需求 阻碍的需求 即将到期或者已经到期的需求还未完成
长时间停止的需求
7、持续改进
小批量 短周期 团队尽快收集用户关于软件的反馈，持续改进
可以采用戴明的PDCA
计划 执行 核对/检查总结 处理，对上步的输出进行总结和处理分析
六、非功能需求：影响用户满意度的关键因素
如何有效的关注非功能需求
根据FURPS+需求分类模型，需求一共分为以下几类
功能性需求
易用性需求
可靠性需求
性能需求
可支持性需求
非功能性需求：系统交付的标准，较难定义，度量，测试，和跟踪，一般描述为系统
如何提供功能（how）
而功能性需求一般描述为（what）
功能性需求只是海平面上的可以看到的冰山，但是在海平面以下，有很多非功能性的隐含的需求
产品负责人要关注整个产品的需求，从源头上重视非功能需求开发，团队才能真正交付可以工作的软件
在软件开发过程中，明确定义的非功能性需求实现是用于评估软件成功的关键
非功能性需求 对 系统架构，系统交付时间 总成本 测试策略都有影响
非功能需求在需求管理阶段就要将其纳入到统一的流程管理中
需要创建具体的任务用来管理这些非功能性需求
非功能性需求实现是有成本的，他们之间可能会有排斥，实际开发过程中，会根据
非功能性需求的实现难度，做出权衡
如何分析非功能性需求（四层非功能性需求分析法）
任何一个功能都可以描述成下面这句话
每个《系统》提供《功能》给《关系人》
每个《功能》必须要满足《条件》才能满足《关系人》的需求
功能性需求表示系统应该做什么
非功能性需求表示系统应该怎么做
分析步骤
1、识别系统的中的干系人
2、基于开发人员的知识和经验从关系人角度制定功能目标
3、拆解功能为子功能
4、识别每个子功能中的非功能性需求
非功能性的度量（要可度量）
吞吐量（qps，tps）
可靠性
扩展性
非功能性需求的设计原则
SOLID原则和IDEALS原则
非功能性需求的测试
定义基准
定义场景
定义成功与失败
非功能性需求的监控（监控每个请求的完整的调用链路的时间消耗）
七、代码预检查：如何提供代码入库的质量
在代码提交到代码仓库前进行检查，包括静态检查，Code Review，测试，编译
等多种方式，目的是保证提交到代码库的代码的质量
本地检查 一般在开发人员本地进行检查
本地提交 代码提交到本地仓库进行检查
远程提交 代码提交到远程仓库的时候进行检查
分支合并 代码从一个分支合并到另外一个分支的时候进行检查
为什么要做代码预检查：软件是业务发展的核心，高质量的软件可以带来更好的收入，赢得市场
初创功能可以适当的降低代码的质量
可读性：代码不仅是给机器看的，是给人看的
可维护性
减少技术债务
代码预检查的实践
质量不是一种行为，而是一种习惯
以循环的方式不断改进
1、本地检查的实践
优点
发现和修复问题的成本最低
效率最快
缺点
需要开发人员具有很强的自觉性
工具
SonarLint FindBugs CheckStyle，PMD,阿里规范插件
本地构建 maven编译，gradle编译
本地测试 单元测试，检查代码的逻辑问题
2、本地提交检查 （执行git commit）
优点
时机适中
效率较高
基于git的hook机制，可以自动识别简单问题
缺点
只能进行静态检查
同样以来开发人员的自觉性
工具
pre-commit
3、远程提交检查 （git push'）
优点
可以进行深层次的检查
可以做到强制检查
可以加入人工评审的环节
可以控制每次提交的代码质量
缺点
时机较靠后，反馈周期较长
需要搭建代码服务器
维护成本较高
每次提交都检查，就拖慢开发节奏
工具（可以考虑做增量检查）
SonarQube
人工评审
自动化测试（jacoco）
八、技术债务：勤借勤还，再借不难
如何有效管理技术债务
什么技术债务
由于交付的压力，都存在如下问题
1、文档没有写，或者与当前的版本不匹配
2、架构设计也只是满足当时的需求
3、代码中留下很多待优化的代码片段
4、遗留代码缺少文档，缺少单元测试，无人能改，无人敢改
技术债务的概念
指那些现在不做，但是如果一直不做，会影响软件健康发展的事情，比如过时的架构设计，比如需要重构的代码，不过未实现的需求不属于技术债务
技术债务是如何产生的
生产阶段
意识阶段
临界点：已经阻碍软件的正常发展
补救：偿还债务，软件进入正常发展
产生的原因
1、和业务有关（时间和成本的压力，业务目标不匹配，当需求不明确主要非功能性需求）
2、上下文变化（业务上下文的改变，技术变化软件硬件中间件不断变化，自然进化）
3、开发流程（无效的文档关键的文档还是必须的，测试自动化不足，流程的不匹配）
4、团队（经验不足，分布式团队：沟通问题和协调导致理解不一致，非专属团队）
管理技术债务的原则和实践
管理技术债务不是一项一次性的活动。他是软件开发过程中的一部分
1、避免技术债务的产生
具有丰富开发经验和能力的人参与到项目中
具有丰富经验和能力的人把控项目的进度和质量
建立系统化的业务知识和技能培训，提升团队的整体实力
2、提前发现技术债务
单元测试框架，通过单元测试来发现
静态代码分析的工具
持续集成
3、尽快偿还技术债务，根据技术债务的大小，难易缓急
立即偿还技术债务
标记技术债务
九、配置管理：实现一包到底的必胜手段
配置管理：在每个环境中使用相同的部署包，通过配置项来管理每个环境的差异
什么是配置管理
最初指版本控制，现在指一个过程，通过该过程所有与项目相关的产物以及他们之间的关系都被唯一定义，修改，存储和检索
应用程序是由软件代码，运行数据，以及配置信息共同组成的
配置信息是如何描述和存储的
以键值对的形式存储
通过配置文件存储，当前yaml是采用最多的形式
可以存储在数据库，版本控制库，文件目录，环境变量
十、环境管理
如何快速的交付一套可用的环境----环境管理
环境是指应用程序运行所需要的的所有资源和配置信息
1、服务器的硬件信息
2、操作系统的信息
3、应用程序运行所需要的中间件的信息
4、应用程序本身的版本，数据以及配置信息
环境管理就是准备部署环境的过程以及部署之后对环境的管控，既能保证准备环境的
快速和一致性，又使得部署后的环境能够有效的利用
为什么要做环境管理
1、手工部署环境会导致很多问题
容易出错
非常低效
不方便做测试验证
一般情况下，环境的物理服务器，操作系统是不会经常发生变化的，变化的只是上层
应用程序以及依赖的中间件服务。这时可以完全采取git的配置管理方式来快速创建
环境
部署平台的设计思路
git仓库（部署脚本）----》CMDB（配置管理数据库）----》部署平台----》环境
Git仓库
基础设施即代码，就是基于软件开发实践的基础设施自动化的方法，通过对代码
进行更改，实现构建和变更基础设施的一致性和可重复性。并通过自动化测试等
实践验证基础设施的可用性
优点
1、可重用性
2、一致性
3、透明性，每个人都可以看代码
配置管理数据库（CMDB）用于存储和硬件软件相关的信息
如何建模才能包含环境中的涉及的元素，以及元素与元素之间的关联关系
数据如何录入？能不能自动化，能不能自定义查询接口
如何与部署脚本集成，获取哪些数据
CMDB的数据准备，工作量很大
1、自动扫描
2、人工录入
部署平台
1、克隆部署代码的脚本
2、调用CMDB接口
3、执行部署脚本
十一、持续集成
通过频繁的提交，每天多次将团队成员的工作内容进行集成。通过自动化测试平台
验证集成后的系统是否可用，今早的发现问题，修复问题，使开发中的软件一直保持
可工作的状态
什么是持续集成
1、每当有人提交代码的同时就集成一次
为什么要做持续集成
软件有个特点。在没有开发完成之前，很长时间内是无法运行应用程序的，一般都是
前期开发各自的功能模块，最后在集成阶段将功能集成在一起，进行测试
1、由于长期在各自的分支上开发，导致在集成阶段合并分支产生大量的冲突，无法合并
2、由于之前未进行任何集成导致在集成阶段耗时太长或根本无法集成
3、由于之前并未进行任何测试，导致系统集成后发现并不满足需求
解决方法就持续集成：主要有两种持续集成
1、即时集成：团队成员每次提交后进行测试，并执行编译，构建自动化测试等任务来检查个人提交的代码是否可用
2、定时集成：类似每日构建，在指定时间自动执行一次集成过程
当前的持续集成主要指即时集成
工作流程
1、开发人员在本地工作空间提交代码到代码仓库
2、版本控制系统通过webhook等机制实时通知持续集成服务器
3、持续集成服务器克隆最新代码到服务器本地，或专用服务器
4、在持续集成服务器或专用服务器上执行构建脚本，对最新的代码进行检查，编译构建、代码静态扫描、代码动态扫描、单元测试等
5、运行结束自动生产报告
6、执行报告通过邮件知会干系人
版本控制系统用于存储和软件相关的所有内容。如应用程序源代码，数据库脚本，构建脚本，和部署脚本等，是基于git的分布式的版本控制系统
对于应用持续集成实践，版本控制系统提供了基本的版本控制能力
为了提高持续集成的效率，当代码提交后，会采用实时的通知机制，目前版本控制系统都提供了基于webhook或基于消息的通知i机制，当不同类型的事件发生后，会通知注册方
持续集成工具，目前jenkins比较常用
如何触发构建
1、定时构建
2、当提交代码到gitlab触发构建
3、轮询的方式SCM
自动化测试
持续集成的目的是提前发现代码中存在的问题，保证软件是可工作的
如下三种测试是需要加入到持续集成种的
单元测试
集成测试
验收测试
为了做好持续集成，对开发人员的要求
1、要频繁的的提交代码，每天至少一次，还需要合并的主干分支
2、每次需要提交一个完整的任务，一个功能不要提交一半
3、构建失败后要立即修复
十二、API管理：应用程序编程接口
就是要将api的生命周期，api的注册，使用，版本等管理起来，为调用方提供统一的
api管控平台
目前常用的api的架构风格是 REST API ，REST 依赖于无状态，可缓存和客户端和服务端的通信协议，比如http
REST的原则
1、统一的接口描述
2、客户段和服务器端的都要遵循统一的接口
3、无状态
4、可缓存性
5、分层系统
构建RESTful api的最佳实践
1、使用RESTful url设计API
2、使用HTTP的动词对资源执行进行CURD操作
3、当前HTTP动词无法映射到操作时候，使用URL中的操作
4、API的版本（在url路径中包括版本信息）
API的生命周期管理
api创建
1、API的创建，基于api生成器生成api，该方法主要在项目初期使用
2、从代码扫描生成api，该方法主要在项目中后期使用
API的测试
API的接口逻辑
API的文档
API的性能
API的安全
openapiif 可用比较每次提交的api的差异
API发布
1、api版本不应该破坏任何现有的客户端
2、尽可能的少频率的变更api的主版本号
3、进行向后兼容，避免生成新的api的版本
4、api版本不应该与软件版本挂钩
管理api的版本 （在url路径中指定，在http的header中指定，比如在X-API-Version中的header标识）
API是目前微服务时代的非常关键的一部分，将软件的各个组成部分串联起来，形成一个整体对外提供的服务，对api的有效管理也能加快软件的开发速度和提升软件的质量
十三、自动化测试：提高测试效率的不二选择，只有尽可能的全面的测试覆盖，才能降低软件出错的概率
自动化测试不是什么？
不是指自动化生成测试代码，而是自动化的执行由开发人员或测试人员编写的测试代码
绝对不要手工去做任何可以被自动化处理的事情
自动化测试不适合做什么？
1、用户体验测试
2、探索性测试
为什么要自动化测试
1、加快了测试速度，缩短了测试时间
2、时间充足了，还可以更多的功能
3、节约时间和降低执行成本
软件开发全生命周期中，测试是频繁且重复的活动，每次提交代码后都需要测试以确保新代码的变动不会受到影响，在每次软件发版之前，也需要系统回归测试，一旦自动化测试 建设完成，就可以做到无人值守的运行，甚至可在多台机器上
并行执行
4、减少出错的概率，提高准确性
自动化测试每次执行都会执行相同的步骤，并且每次都会生成详细的测试报告，
测试报告不受人的因素影响，手工测试容易受个人经验和情绪的影响，易出错，
人员的流动性又使得测试知识无法沉淀
5、提高测试覆盖度
自动化测试可以增加测试的深度和范围，从而提高软件质量
6、可以加快反馈效率
自动化测试在每次提交代码后，自动触发并将测试结果通知团队中的开发人员，大大缩短开发人员获得反馈的时间
7、可以模拟手工无法完成的测试的场景
比如并发访问的场景
因此，自动化测试通过快速批量的执行测试用例，减少测试时间，加速反馈的回路，提升软件质量
如何实现自动化测试
实现自动化测试也是需要成本的
1、定义自动化测试的范围：区分哪些适合做自动化测试，哪些适合做手工测试
面向业务，评价产品的测试--手工测试
面向业务，支持团队的测试--自动化&手工
面向技术，支持团队的测试----自动化
面向技术，评价产品的测试----自动化&手工
2、定义自动化测试的层次
UI测试（10%的精力）《服务测试（20%的精力）《单元测试（70%的精力）《基础设置自动化测试（测试数据和测试环境的准备的效率）
基础设施层：准备用于自动化测试的数据和环境，可使用自动化或基于容器
的方式进行构建，常用工具ansible，chef，puppt，jenkins
单元测试：争对代码方法，类和包进行的测试，一般属于代码级的测试并与
企业内部的持续集成流水线集成，常用工具xunit系统
服务测试层：针对服务之间的接口进行测试，一般服务接口之间的交互测试，常用工具postman，soapUi等
UI测试：针对界面的功能进行测试，一般在一个或多个应用里进行端到端的的流程测试，应关注重点功能，常用工具又selenium，appium等
3、与持续集成流水线集成
搭建自动化测试平台和持续集成流水线集成
a、开发人员提交代码到git仓库进行分支合并
b、持续集成服务器接收到合并事件后，触发编译构建单元测试等检查，将
结果通知给开发人员
4、部署到测试环境中，该环境属于集成环境，部署该服务依赖的其他组件
5、跑自动化测试用例
测试是软件生命周期中非常重要的一个阶段，也是非常耗时的环节
十四、部署流水线：打造一站式部署的关键平台
搭建一套从开发到测试到运维的流水线，能够实现一键式的软件部署到生成环境
部署流水线的阶段
提交阶段
自动化测试阶段
手工测试阶段
发布阶段
部署流水线相关实践
1、一包到底
将软件从源代码编译构建出一个部署包，在后续的流程中都统一使用
这一个部署包
减少了编译时间
保证了部署包的一致性
2、相同的部署方式
使用相关的流水线，相同的部署方式部署任意一套环境，包括生成环境
将部署脚本和配置信息分离
采用相关的部署方式是降低软件发布风险的方法之一
3、对部署冒烟测试
调用接口检查是否能正常返回
4、自动化部署平台
部署流水线的重要组件，通过封装统一的部署流程，提供易用的用户界面，对外提供统一的软件部署能力
十五、混沌工程 ：通过问题注入提高系统的可靠性
通过在生成环境中对系统进行破坏来不断增强软件的健壮性
混沌工程就是故意破坏事物的特殊方法，通过在生产环境中捣乱，以发现生产环境中可能出现的 隐藏问题
混沌工程并不仅仅是搞破坏，混沌工程是传统测试的补充，在经过传统测试后系统以及稳定，可在生产环境中被任意破坏，来进一步增强系统的稳定性
混沌工程的核心思想是以可控的方式主动注入故障，以验证系统的行为是否符合我们的预期，并在不正常的情况下进行修复，以此提高系统的稳定性
为什么要实施混沌工程
创建可靠的软件是当前企业获取用户，赢得市场竞争的基础
传统的测试只能保证软件的应用层的质量，无法保证应用程序以及各种服务或整个系统在任何情况下都能正常使用
混沌工程可以主动测试生产环境中各种压力下的行为，通过比较假设行为和实际行为。可在系统出现故障前发现问题并修复问题
可以对软件和基础设施进行比传统形式更广泛的测试和验证
发现传统测试无法发现的问题
帮助团队了解系统在真实环境中的行为，服务如何被中断以及都有哪些bug
增强的系统的稳定性和可靠性，提供用户的体验
如何实施混沌工程
1、首先收集一组基线指标数据
基础设施监控指标（服务器的cpu、内存、io、磁盘使用率，网络延迟，丢包）
告警指标（可按服务统计每周告警数，处理告警的时间以及每种服务每周最频繁的告警类型）
严重级别指标（可按照服务统计每周不同严重级别的事件数量以及按照服务统计每种严重级别的MTTD,MTTR,MTBF）
应用指标（应用程序的可观察性指标，事件的数量，请求的响应事件，数据库连接数，QPS,TPS）
2、模拟真实事件
攻击：将故障输入到系统中，如消耗计算资源，关闭系统，丢弃网络包等方法，攻击是单个故障的注入方式
场景：将一组工具保存为一个集合，场景的攻击可按照顺序执行，可更好的
控制攻击方式并可模拟比较复杂的故障保存下的场景，可被重复执行并能观察系统随时间的行为变化
3、分析观察结果
系统行为是否符合预期
如果系统有监控告警等系统，是否可以按照预期运行
本次实验发现了哪些新问题
告警系统多长时间检测到问题，并发出通知，该时间是否可以接受
实验结束后，系统是否自动恢复到正常状态，还是需要人工干预
4、重复实验
修复问题后，进行重复测试
修改攻击的内容
5、将手动测试转换为自动化测试
混沌工程落地离不开工具和平台 chaoblade
十六、度量指标：寻找真正好用的指标
事实上很多团队和组织在实施devops时都专注于技术而忽略了度量和文化方面
度量是实施devops的关键要素，如把devops比作一辆车，哪之前造工具搭建平台就是
车身，度量是车的仪表盘，devops的度量也需要一些指标来指导devops的持续改进
什么样的指标是好指标，如何才能找到好的指标
为什么要度量指标
1、度量的前提是要有一套打通端到端的devops平台，否则在优秀的度量也只是
局部度量
2、度量的本身的投入产出比并不像CICD效果明显，很多度量只是给上面看的，而不是真正的想解决问题
度量指标是devops一开始就需要想好的
精益思想的核心理念是持续改进，清晰明确的度量指标作为指引，才能达到持续改进的目标，在持续改进这条路上，没有终点，永远在路上
度量能够提供信息来帮助我们知道现在在哪里，距离目标还有多远，我们是在沿着目标前进还是在倒退，程度如何
度量指标是需要从devops平台获取的，一开始要考虑有哪些度量指标，如何获取，对devops平台的设计有指导意义
度量指标不是目的（容易给人以达到重点的错觉），而是手段(发现潜在的问题)，
不是控制（容易给人以一种静态目标的心里暗示）而是改进（以动态的目标直入人心）
什么样的指标是好指标
关于寻找好的指标这一块，有些企业有一个误区，就是要度量所有的内容
更多的指标需要投入更多的资源关注软件研发各方面，最终导致每个指标的效果并不好
以kpi的形式完成指标，最终的完成的是数量而不是质量
好的指标的标准
1、可度量的 指标必须是可衡量的是一个定量指标而不是非常好，非常快的定性的指标
2、相关联的
指标必须能度量对业务有重要影响的因素
3、不可更改的
团队成员不能影响度量指标的结果
4、可实施的
指标能够通过技术的手段获取并且数值是真实可靠的
5、可追溯的
指标必须是能够直接反应软件研发过程中的存在的问题
在找出需要跟踪的指标前，需要确定组织面临的挑战以及要解决的问题（衡量的标准就是解决或改善现有的问题）
1、代码质量
2、团队成员
3、发布效率
好的指标是用来解决实际业务问题的
1、缩短产品上市时间：前置时间
衡量从用户需求提出到最终交付用户的时间
2、提高软件开发的效率（流动效率）
使用流动效率，查看瓶颈点，并将工作重心放在如何改善流动瓶颈的地方，等时代时间减少，软件开发效率就高
3、解决团队正在处理的事项和计划外事项的冲突
使用在制品数量，以暴露工作内容过载的团队或团队成员，使得每个团队成员的工作更加均衡
4、解决未完成的重要工作不被遗忘的问题
使用 停留时间，或者过期时间，来度量未完成的工作在系统里停留了多长时间，如果超过设置的阈值则进行预警以暴露风险
5、减少生成环境中用户发现的问题数量
使用缺陷逃逸率。使得bug尽量在测试环境或预生产环境中发现
要避免不符合devops时代的指标
1、传统的工程指标
如MTBF（平均故障间隔时间）在devops时代意义就不大，系统长期稳定性不是首要目标，devops时代是通过快速部署来保证系统稳定性的
2、基于竞争的指标
切勿基于团队成员或团队之间的竞争来建立指标，度量指标的目的是解决业务问题，不是晾晒团队成员的技术水平的手段
3、虚荣性的指标
比如每周代码行的统计，不该以代码行数无意义的指标评判开发人员的工作量的指标，最终交付的功能的及时性和质量才是最重要的
4、不要根据获取指标的难易来取舍指标
如何使用这些指标
反馈循环是有效改进的基础，通过度量指标反馈有助于更加精准的调整团队的行动，改善整个组织的沟通
step1：收集数据（收集关于软件研发过程中的数据，作为后续分析的原材料）
平台方面本身具备收集数据的能力，设计平台要有针对度量指标方面的设计，如每个任务都要有开始时间和结束时间，每个事件应该有发生、处理、解决的时间记录，事务间的关 联
提供统一的报表
人的方面，团队成员有效参与能充分发挥平台的能力，devops平台虽将研发流程操作尽可能自动化，有些内容还是需要人工配合，提交代码按照规范来提交，需求id和缺陷id关联等操作
step2：分析数据
step3：根据分析数据，调整流程
step4：重复执行
十七、团队能力：团队能力==交付能力
当人员过于专业时，就会形成筒仓，在进行软件研发活动时，需要在不同部门之间进行多次沟通和交接，当没有空闲时还需要排队，这就导致交付时间的推迟
如何解决这样的问题
团队的T型人才观，才可以解决这样的问题
I型（专家）
精通某个领域
其他领域的技能或者经验很少
很快遇到瓶颈
对下游的浪费和影响不敏感
抵制灵活或可变的计划
T型（通才，全栈工程师）
精通某个领域
拥有很多领域的技能
能突破瓶颈
对下游的浪费和影响敏感
帮助制定灵活和可变的计划
E型
精通某几个领域
有多个领域的实践经验，执行能力强，能持续创新
潜力无限
在企业中可以通过交叉培训的方式，为工程师提供学习的机会，并定期让他们在不同岗位之间轮岗，来提高相关的技能
T型团队就需要掌握团队成员在技能上的熟练程度，并对薄弱环节的人员进行有针对性的培训
制作技能图谱，可以了解团队成员的优势和不足，且需要定期更新，每隔三个月
技能栈 团队成员A 团队成员B
java
go
python
如何度量团队的交付能力
如果有一个比较紧急的项目，应该交给哪个团队比较合适：需要通过具体的指标来度量团队的能力
研发过程可视化很差：很难准备的定义一个需求开发到完成具体需要多长时间，以及每个团队每个迭代的具体产出
工作切分的随意性：软件研发的工作事项没有统一的标准，需求可大可小，没有固定的期限
度量团队效能的误区
侧重产出而不是结果
侧重个人或局部的度量而不是团队或全局的度量
比如代码行数的统计，在完成代码逻辑时候尽可能多写代码，导致软件变得臃肿，使得代码维护成本更高
比如故事点数的统计，将需求拆分成故事，用用户故事点数来估计每个故事的大小，以此来表示预期完成这些故事需要的工作量
好的度量团队效能的指标
专注全局结果：奖励开发人员的高吞吐量，以及运维团队的系统稳定性
关注结果而不是产出：没有为企业创造的产出是没有意义的
效能度量的指标
1、软件开发的前置时间（需求提出到部署到客户环境的时间）
2、部署频率（越快越好）
3、软件部署的变更失败（指版本部署的客户环境失败后需要回滚的概率）
4、恢复时间（服务故障到服务恢复的时间）
5、服务运维的可用性（团队确保软件和服务可用的能力）
十八、响应速度；天下武功，唯快不破
在如今这个数字化的企业时代，软件的发布速度，问题的修复速度是企业
制胜的法宝
有2个企业发现了市场上的机会，这时谁能将机会变成产品发布到市场上，谁能赢得先机
什么是响应速度
1、软件发布的速度，从软件立项到发布到生产环境，交付给用户使用的时间，是端到端的发布的时间，代表了团队对市场机会的响应速度
2、特性的发布，从特性的评审完成到集成测试验收测试，在到发布到生产环境的时间，代表了团队对用户需求的响应速度
3、缺陷发布，只发现这个缺陷，到故障定位和故障修复的时间，代表了团队对测试和运维的响应速度
提高响应速度的根本就是缩短软件的交付周期
哪些因素会影响到响应速度
软件开发是一项复杂的，交付最终价值的工作
资源利用率：指影响软件交付的相关资源在软件交付活动中所占的比例，比如团队成员，服务器设备，时间等；但是软件开发是一个顺序执行的工作，每个阶段都会依赖前面的阶 段，这就意味着即时投入再多资源交付周期也不可能无限制的缩短；另外资源利用率越高，工作任务在队列中等待的时间就会越长，交付周期也会增长，如果一个人同时处理多个 任务，在任务的切换也会额外占用时间，关键资源，关键人物被积压着长的任务队列，慢慢会称为整个交付的瓶颈
任务的大小，也是影响软件交付的因素，当任务的大小不一致，就会导致处理任务的时间不一致，就会产生等待，等待就是一种浪费，会延长软件的交付周期，因此，在拆分需求时候，尽可能的将任务拆分的均衡，减少等待的时间
在制品的数量，通过看板方法可视化进行中的工作，以此来控制在制品的数量，在制品数量越多，团队成员不断进行任务切换导致其他任务的等待和团队成员利用率太高造成瓶颈。可用限制在制品的数量
自动化的程度，减少手工操作 自动化编译，扫扫描、部署、测试
如何度量响应速度的指标
价值交付的效率，如用户需求多久能发布，也就是前置时间；累计流图是看板系统中重要的度量，用来展示开发过程中各个阶段的在制品数量
工程的效率，指devops平台的本身的能力记录时间等关键信息，编译效率，测试效率、部署效率
编译效率，代码编译需要cpu资源，每个编译机同时处理的任务是有限的，当有多个编译任务执行时，就会有任务在等待，为了最大化的利用编译机的效率，可用采用容器构建的 方式，当有编译任务的时候，可用启动一个docker容器，编译完成后就销毁；代码库的大小也会影响编译效率；编译工具的设置，编译工具使用最新的版本
测试的效率，回归测试、功能测试、非功能测试，尽可能的自动化，用例数，测试成功率
部署效率，从开始部署到部署结束的时间，部署频率是一个全局指
效率的提升不会一蹴而就，而是通过不断地优化和持续改进实现的，这也是就度量指标来指导改进的目的
十九、软件质量：决定系统成功的关键
具备高质量软件，高效率的企业走的更快更远
低劣的软件质量，高效率的则会让企业死的更快
什么是软件质量
领导者需要了解当前的软件质量是多少，存在什么问题，软件质量的发展趋势是什么，这些就是软件质量的度量
软件质量分为内部质量和外部质量
内部质量是指被开发人员感知的质量，在开发过程中，要尽早发现，尽早修复，内部质量问题，可以提高发布到生产环境中的产品的外部质量
外部质量是指能够被用户感知的质量，外部质量是决定产品是否成功的关键，提高外部质量是团队成员最终的目标
测试覆盖率是衡量代码质量的一个方法，自动化测试中代码的覆盖程度，包含单元测试，集成测试，回归测试的测试覆盖率。业界一般认为测试覆盖率达到80%就可以了，测试一 定是有效测试，无效的测试即便100%覆盖也没有任何意义
测试缺陷数量在测试阶段发现的缺陷的数量，测试阶段，目的就是发现问题，不能惧怕发现问题，测试人员要分清哪些是bug，哪些是需求改进
测试质量的检查不能做为衡量团队成员能力的依据，也不做为绩效考核的标准，以结果性，全局性的指标为最终指标
外部质量
内部质量已经做的很好，那外部质量就一定很好么？这个不一定
需要从用户满意度，产品非功能性去考核外部质量
用户满意度，从最终用户的角度对产品的评判，收集用户对产品或服务的评价信息。净推荐值（推荐-不推荐），是衡量用户满意度的黄金标准
产品的非功能性，可靠性（出现服务不可用的概率）、性能（使用产品的流畅性、卡顿、延迟）等等
软件质量，这已决定产品成功与失败的关键因素，分为内部质量和外部质量，二者相辅相成，互相影响，内部质量是源头，外部质量是结果
二十、业务价值：软件发布的最终目的
敏捷宣言中，第一条原则规定：我们最重要的目标是通过持续不断的尽早交付有价值的软件，使用户满意
通过将有价值的软件，满意的用户和企业最终业务目标相联系，就能实现企业业务的价值，即商业目标，比如用户量的增长，收入的增加，成本的降低
实施devops的目的是什么？
devops的目标（提高部署频率，缩短故障恢复时间，提高服务可用性），最终实现用户满意度，提高用户满意度，实现业务目标（市场份额增长，用户数增长，用户使用市场增长），最终实现企业目标（收入增长）
可用看到devops的目标并不是实施devops的最终目标，业务目标和企业目标才是实施devops的最终目标
如何衡量业务的价值
devops的度量不仅仅要度量发布的频率，代码缺陷数，需求数等研发指标，还要度量用户、市场占有率、净推荐值等数据的变化
软件是通过每一次发布来交付用户需求，也只有在软件发布后，之前做的所有的能力才能体现出来价值
如何衡量软件发布带来的增量价值？
比如会增加收入么，会降低成本么，会吸引更多用户么，会阻止现有用户离开么
在发布阶段就要确定发布的功能范围，也要衡量发布后的价值，以便确定项目收益与实际收益是否匹配，是否真正实现了业务的价值
可用通过下面几个指标来衡量
1、用户访问量，PV
2、独立访客数，UV
3、新增用户数
4、用户的忠诚度，用户的粘性（重复购买的次数、决策时间的长短，对竞争者的态度，对产品问题的态度）
5、用户的留存率
6、市场占有率，决定了企业在概率的利润
7、净推荐值eNPS
