devops实战笔记
# 基础知识篇
DevOps 的定义、价值、实施与衡量
# 01. DevOps的定义
DevOps（开发 Development 与运维 Operations 的组合词）是一种文化、一场运动或实践，强调在自动化软件交付流程及基础设施变更过程中，软件开发人员与其他信息技术（IT）专业人员彼此之间的协作与沟通。它旨在建立一种文化与环境，使构建、测试、软件发布得以快速、频繁以及更加稳定地进行。
# 软件工程三个重要发展阶段
# 瀑布开发模式
通过一种重流程，重管控，按照计划一步步推进整个项目的交付过程。
缺点：
软件开发活动需要在项目一开始就确定项目目标、范围以及实现方式，而这个时间点往往是我们对用户和市场环境信息了解最少的时候，这样做出来的决策往往带有很大的不确定性，很容易导致项目范围不断变更，计划不断延期，交付上线时间不断推后，最后的结果是，即便我们投入了大量资源，却难以达到预期的效果。
# 敏捷式开发模式
核心理念是，既然我们无法充分了解用户的真实需求是怎样的，那么不如将一个大的目标不断拆解，把它变成一个个可交付的小目标，然后通过不断迭代，以小步快跑的方式持续开发。
与此同时，将测试工作从研发末端的一个独立环节注入整个开发活动中，对开发交付的内容进行持续验证，保证每次可交付的都是一个可用的功能集合，并且由于质量内建在研发环节中，交付功能的质量也是有保障的。
敏捷之所以更快，根本原因在于持续迭代和验证节省了大量不必要的浪费和返工。
# DevOps模式
DevOps 是通过平台（Platform）、流程（Process）和人（People）的有机整合，以 C（协作）A（自动化）L（精益）M（度量）S（共享）文化为指引，旨在建立一种可以快速交付价值并且具有持续改进能力的现代化 IT 组织。
# 02. DevOps的价值
# 高效的软件交付方式
DevOps 状态报告的 4 个结果指标：
部署频率：指应用和服务向生产环境部署代码的频率。
变更前置时间：指代码从提交到成功运行在生产环境的时长。
服务恢复时间：指线上应用和服务出现故障到恢复运行的时长。
变更失败率：指应用和服务在生产环境部署失败或者部署后导致服务降级的比例。
# 激发团队的创造力
实施 DevOps，一方面可以通过种种流程优化和自动化能力，改善软件开发团队的工作节奏；另一方面，也可以让大家关注同一个目标，彼此信任，高效协作，调动员工的积极性和创新能力，从而让整个团队进入一种积极创造价值的状态，
而这所带来的影响远非建设一两个工具平台可比拟的。
# 03. DevOps的实施
# DevOps的三个支柱
对工具和文化的体系化认知，可以归纳到 DevOps 的 3 个支柱之中，即人（People）、流程（Process）和平台（Platform）。3 个支柱之间两两组合，构成了我们实施 DevOps 的“正确姿势”，只强调其中一个维度的重要性，明显是很片面的。
人 + 流程 = 文化
责任共担和质量导向、线上安全点数
流程 + 平台 = 工具
平台的最大意义，就是承载企业内部的标准化流程。平台上固化的每一种流程，其实都是可以用来解决实际问题的工具。
实际上，平台除了有用户量、认可度、老板加持等因素之外，还会有 3 个显著特征：
- 吸附效应：平台会不断地吸收中小型的工具，逐渐成为一个能力集合体。
- 规模效应：平台的成本不会随着使用方的扩展而线性增加，能够实现规模化。
- 积木效应：平台具备基础通用共享能力，能够快速搭建新的业务实现。
平台 + 人 = 培训赋能
当我们定义了期望达到的目标，并提供了平台工具，那么对人的培训就变得至关重要，因为只有这样，才能让工具平台发挥最大的效用。更加重要的是，通过最终的用户使用验证，可以发现大量的可改进空间，进一步推动平台能力的提升，从而带动组织整体的飞轮效应，加速组织的进化。
文化、工具和培训作为 DevOps 建设的 3 个重心，折射出来的是对组织流程、平台和人的关注，三位一体，缺一不可。
# 04. DevOps的衡量
《跨越鸿沟》这本书中提出了一个“技术采纳生命周期定律”，这个定律描述了一项新技术从诞生到普及要经历的 5 个阶段，这 5 个阶段分别对应一类特殊人群，即创新者、早期使用者、早期大众、晚期大众和落后者。这个定律表明，技术的发展不是线性的，需要经历一段蛰伏期，才能最终跨越鸿沟为大众所接受，成为业界主流。
任何技术的成熟，都是以模型和框架的稳定为标志的。
工信部旗下的中国信息通讯研究院牵头制定的一套 DevOps 能力成熟度模型。这套模型覆盖了软件交付的方方面面，包括敏捷开发管理、持续交付和技术运营三大部分，同时，也有与应用架构设计、安全和组织结构对应的内容。
# 步骤与原则
在实际参考模型和框架的时候，应该尽量遵循以下步骤和原则：
1.识别差距
通过和模型、框架进行对标，可以快速识别出企业当前存在的短板和差距，并建立企业当前的能力状态基线，用于对比改进后所取得的效果。
2.锚定目标
数字化转型的核心在于优化软件交付效率。
通过对标模型框架，企业需要明确什么是影响软件交付效率进一步提升的最大瓶颈，当前存在的最大痛点是什么，哪些能力的改善有助于企业达成预定的目标……同时，要根据企业的现状，甄别对标的差距结果，识别出哪些是真实有效的，哪些可以通过平台能力快速补齐。
通过现状分析，企业可以把有限的资源聚焦在那些高优先级的任务上，识别出改进目标和改进后要达到的预期效果。这些效果需要尽量客观和可量化，比如缩短 50% 的环境准备时长。
3.关注能力
模型和框架是能力和实践的集合，在应用模型的过程中，核心的关注点应该在能力本身，而不是单纯地比较数字和结果。
正确的做法是根据锚定的目标识别所需要的能力，再导入与能力相匹配的实践，不断强化实践，从而使能力本身得到提升。
4.持续改进
模型和框架本身也不是一成不变的，也需要像 DevOps 一样不断迭代更新，以适应更高的软件交付需要。
# 部署引力图
可以看出，当软件发布的频率从 100 天 1 次进化到 1 天 100 次的时候，分支策略、测试能力、软件架构、发布策略、基础设施能力，以及数据库能力都要进行相应的改动。比如分支策略要从长线分支变成基于特性的主干开发模式，而架构也要从大的单体应用，不断解耦和服务化。在实际应用中，企业涉及的领域甚至更多，因为这些仅仅是技术层面的问题，而组织文化方面也不可或缺。
# 实践案例
能力成熟度模型
# 落地实践篇
DevOps 的转型路径
# 平台工具篇
平台建设的 3 个阶段、产品研发和设计、不可忽视的开源工具
# 转型案例
1111