DevOps实践指南读后感-5

DevOps实践指南

DevOps是一种软件工程文化和实践，旨在统一整合软件开发和软件运维。DevOps运动的主要特点是强烈倡导对构建软件的所有环节（从集成、测试、发布到部署和基础架构管理）进行全面的自动化和监控。DevOps的目标是缩短开发周期，提高部署频率和更可靠的发布，与业务目标保持一致。

development/operations，一组过程、方法，系统的总称，用于促进开发（应用程序、软件工程），技术运营，质量保障部门之间的沟通，协作和整合。

 

本书为DevOps转型提供了从启动到实现所必须的理论、原则和实践案例。

它是传统敏捷、精益管理和ITSM管理等实践的大融合。

 

在系统的稳定性、可靠性、可用性、安全性方面达到世界一流水平。

技术债务是指我们当前所做出的决定会导致一些问题，而这些问题随着时间的推移会越来越难解决，未来可采取的措施也越来越少。

精益运动：

精益的两个主要原则包括：坚信前置时间（把原材料转换为成品所需要的时间）是提升质量、客户满意度和员工幸福感的最佳度量指标之一；小批量的任务交付是缩短前置时间的一个关键因素。

敏捷宣言：一个重要的原则是“频繁的交付可工作的软件，交付周期可以是数星期也可以是数月，推荐更短的周期”。

敏捷基础设施和velocity大会

持续交付：持续交付中“部署流水线”确保代码和基础设施始终处于可部署的状态，所有提交到主干的代码都是可以安全的部署到生产环境。

丰田套路：所有企业都有日常的工作流程，而这些工作流程决定了最终的产出。通过设定目标，制定每周的详细计划，并持续改善日常工作，如此循序渐进，才能达到优化和持续改进的目的。

 

第一部分 devops介绍

1、第一部分包含以下内容：

流动原则：它加速了开发、运维到交付给客户的流程。

反馈原则：它使我们能够建设出更加安全可靠的工作体系。

持续学习与实践原则：它打造出一种高度信任的文化和一种科学的工作方式，并将对组织的改进和创新作为日常工作的一部分。

2、价值流：

一个组织基于客户的需求所执行的一系列有序的交付活动或者是为了给客户设计、生产和提供产品或服务所需从事的一系列活动，它包含了信息流和物料流的双重价值。

技术价值流：

把业务构想转化为向客户交付价值的、由技术驱动的服务所需要的流程。

 

3、前置时间和处理时间

前置时间在工单创建之后开始计时，到工作完成时结束。

处理时间则从实际开始处理这个工作开始计时，在不包含这个工作在队列中的排队等待时间。

返工指标：%C/A：

完成时间和精准的总花费时间的百分比。

自动化测试和探索测试

 

第二章

我们的目标是在缩短代码从变更到生产环境上线所需时间的同时，提高服务的质量和可靠性。

单间流：每次操作只执行一个单位产品的处理。

持续识别和改善约束点：

识别系统的约束点

决定如何利用这个约束点

基于上述决定，考虑全局工作

改善系统的约束点

如果约束点已经突破了，请回到第一步，但要拒绝惯性导致的系统约束。

约束点包括：

环境搭建、代码部署、测试的准备和执行、紧密耦合的架构

 

提升技术价值流的流动性对实施devOps来说至关重要。为此我们需要将工作可视化、限制在制品📚、减小批量大小、减少交接次数、持续的识别和改进约束点、以及消除日常工作中的困境。

 

第三章 反馈原则

第一步工作法的描述原则，使得工作能够在价值流中从左向右快速的流动。第二步工作法描述的原则是，使得从右向左的每个阶段中，能够快速持续的获得工作反馈。我们的目标是建立安全可靠的工作系统。

四项措施让复杂系统更安全的工作：

管理复杂的工作，从中识别出设计和操作的问题。

群策群力解决问题，从而快速的构建新知识。

在整个组织中，将区域性的新知识应用到全局范围。

领导者要持续培养有以上能力的人。

群策群力的原因如下：

防止把问题带入下游的处理环节，否则不但修复的成本和工作量会呈指数级增长，而且还会欠下技术债。

防止工作中心启动新的工作，那样可能会在系统中引入新的错误。

如果问题还没有得到解决，那么工作中心在下一次操作中，可能还会遇到相同的问题，需要更高的修复成本。

PDCA环：

Plan 计划 Do 实施 Check 检查 Act改进

可制造性设计旨在设计零件和工艺品过程，让成品能够以更低的成本、最高的质量和最快速的流程生产出来。

非功能性需求：

架构、性能、稳定性、可测试性、安全性和可配置性

建立快速的反馈机制，对于实现技术价值流中的高质量、可靠性和安全性至关重要。，为此，要在问题发生时识别问题，群策群力解决问题并构建新的知识，在源头控制质量，并且不断为下游工作中心做优化。

 

第四章

技术信息价值流的核心是建立高度信任的文化。

扛脆弱性：

通过加压来增强弹性的做法。

 

 

第二部分 从何处开始

第五章

选择合适的价值流作为切入点

提高发布速度或实现按需发布，从而拥有更强的迭代能力和对客户反馈的响应能力。

绿地项目：指在未开发的土地上建设的项目。

棕地项目：指在以前用于工业生产的土地上建设的项目。

双模IT：

指的是企业能够支持各种类型的服务演讲。

记录性系统：指类似于ERP的系统，它的交易和数据的正确性是至关重要的。-做的正确

交互性系统：是指面向客户或员工的可交互系统，例如电子商务系统和办公软件。-做的快速

 

第六章

理解待转型价值流中的工作

如何向客户交付价值：

做什么工作？谁来做？该采取什么措施改善流程？

确定创造客户价值所需的团队：

绘制价值流图，把必要的工作可视化；以价值流图为导向，帮助团队更好、更快速的创造客户价值。

产品负责人：作为业务方的代言人，定义系统需要实现的功能。

开发团队：负责开发系统功能。‘

QA（质量保证）：给开发团队提供反馈，并确保系统功能符合需求。

运维团队：负责维护生产环境，并确保系统能够良好的运行。

信息安全团队：负责系统和数据的安全。

发布经理：负责管理和协调生产环境部署以及发布流程。

技术主管或者价值流经理：负责“从始至终的保障价值流的产出满足或超出客户期望”。

 

第七章 参考康威定律设计组织结构

康威定律：系统设计受限于组织自身的沟通结构。组织的规模越大，灵活性就越差，这种现象就越明显。

组织结构类型：

职能性组织结构：注重提高专业技能、优化分工和降低成本。

矩阵型组织结构：试图结合职能性和市场型。

市场型组织结构：注重快速响应客户需求。

全栈工程师：指那些熟悉或至少大致理解整个应用栈（例如代码、数据库、操作系统、网络和云）的通才。

 

第八章 将运维融入到日常的开发工作

目标是以市场为导向，让小团队快速、独立地为客户提供价值。

每日站会：目的是在整个团队范围内分享信息，同时了解正在做和将要完成的工作。

昨天做了什么？今天要做什么？遇到什么难题？

 

第三部分

创建必要的技术实践和框架，从而使开发到运维的工作能够稳定的快速流动，并确保不会造成生产环境的混乱或客户服务的中断。这意味着需要降低生产环境中部署和发布变更的风险。

持续交付包括打好自动化部署流水线的基础，确保团队能够使用自动化测试持续验证代码是否处于可部署状态，确保开发人员每天都将代码提交到主干，以及构建有利于实现低风险发布的环境和代码。

第九章 为部署流水线奠定基础

部署流水线的目的能够基于版本控制系统中的信息重复搭建整套生产环境。

按需搭建开发环境、测试环境、生产环境：

我们不再需要运维团队收到构建和配置环境，而是可以自动化的方式完成以下操作：

复制虚拟化环境

构建“裸金属物理机”的自动化搭建流程

使用“基础设施及代码”的配置管理工具

使用操作系统自动化配置工具

使用一组虚拟镜像或容器

在公有云、私有云或其他Paas中创建新环境。

配置漂移：

脆弱的工件：

摆设：

雪花服务器：

完成不是指开发人员认为完工，而是指成功的构建和部署应用，并且确定它在类生产环境中按预期运行（最好在迭代结束之前，就处理过与类生产环境类似的负载和数据集）。

 

第十章 实现快速可靠的自动化测试

创建自动化测试套件的目的是提高集成频率，使测试从阶段性活动演变为持续性活动。

开发过程中的持续集成（continuous integration ci）通常是指将多个代码分支持续集成到主干中，并确保他们都会通过单元测试。

在持续交付和DevOps中，持续集成还要求在生产环境中运行应用，并且通过集成测试和验收测试。

单元测试：通常独立测试每个方法、类或函数。

验收测试：通常整体测试应用，确保每个功能模块按照设计正常工作（如符合用户故事的验收标准，API能正常调用），而且没有引入回归错误（没有破坏以前正常的功能）。

单元测试和验收测试区别：单元测试的目的是证明某一部分符合程序的预期……验收测试的目的则是证明应用能满足客户的愿望，而不仅仅符合程序员的预期。

集成测试：保证应用能与生产环境的其它应用和服务正常地交互，而不再调用打桩的接口。

打桩：Stub，就是把所需要的测试数据塞到一个对象里，重点关注测试目标的方法，对于不易构造或者不易获取对象和方法都采用桩来代替，这个过程叫打桩。

Mock对象：模拟真实对象的对象。

非功能性需求：包括可用性、可扩展性、容量以及安全性等。

 

第十一章 应用和实践持续集成

分支在版本控制系统中的主要作用是，让开发人员可以并行的工作在软件系统的各个组成部分，同时避免开发人员提交代码对主干的稳定性造成影响，或引入错误。

 

第十二章 自动化和低风险发布

部署流水线要求：

用相同的方式处理所有环境的部署，通过对所有环境（开发、测试、生产）采用相同的部署机制，可以提高生产部署的成功率，因为它已经在流水线中成功的部署过很多次了。

对部署执行冒烟测试：

维护环境的一致性：

构建：部署流水线必须基于版本控制系统构建可部署到任何环境的软件包。

测试：任何人都应该能够在他们的工作站上或测试系统中运行任何一个自动化套件。

部署：任何人都应该能够将这些软件包部署到具有访问权限的任何环境，通过执行脚本来完成部署。

 

部署：指在特定的环境中安装指定版本的软件（例如，将代码部署到集成测试环境中或生产环境中）。具体的说。部署可能与某个特性相关，也可能无关。

发布：把一个特性（一组特性）提供给所有客户或一组客户（例如，5%的客户开发特性。）

发布模式：

基于环境的发布模式：在两个或者更多的环境中部署系统，但实际上只有一个环境处理客户流量（例如，通过配置负载均衡切换流量）。将新的代码部署到非生产环境中，然后再把生产流量切换到这个环境。（蓝绿发布、金丝雀发布、集群免疫系统）。

基于应用的发布模式：对应用进行修改，从而通过细微的配置变更，选择性的发布或放开应用特性。（开关）

 

持续集成是指，频繁的（一天多次）将代码集成到主干。

持续集成的目的：就是让产品可以快速迭代，同时还能保持高质量。

持续交付是指，所有开发都在主干上进行小批量工作，或者在短时间存在的特性分支上工作，并且定期向主干合并，同时始终让主干保持可发布状态，并能做到在正常的工作时段里按需进行一键发布。开发人员在引入任何回归错误时（包括缺陷、性能问题、安全问题、可用性问题等），能快速得到反馈。一旦发现这类问题，就立即解决，从而保持主干始终处于可发布状态。

 

持续部署是指，在持续交付的基础上，由开发人员或运维人员自助式的定期向生产环境部署优质的构建版本，这通常意味着每天每人至少做一次生产环境部署，甚至每当开发人员提交代码变更时，就触发一次自动化部署。

持续集成是持续交付的前提条件，持续交付是持续部署的前提条件。

 

持续交付：持续交付中“部署流水线”确保代码和基础设施始终处于可部署的状态，所有提交到主干的代码都是可以安全的部署到生产环境。

 

第十三章 降低风险发布的架构

架构是影响工程师生产力的首要因素，它还决定了能否快速和安全地实施变更。

 

第十四章 建立能发现并解决问题的遥测系统

遥测被广泛的定义为：一个自动化的通信过程，先在远程采集点上收集度量数据，然后传输给与之对应的接收端用于监控。

日志级别：

调试级别、信息级别、警告级别、错误级别、致命级别

信息辐射器：指团队放置一个非常显眼位置上的手写、绘制、印刷、或电子信息展示，让所有团队成员以及路过的人都可以快速浏览最新信息：自动化测试次数、速率、事故报告、持续集成状态等。

 

第十五章 分析遥测数据以更好的预测故障和实现目标

异常检测：搜索不符合预期模式的数据条目或事件。

 

第十六章 应用反馈实现安全部署

服务回传机制：当生产环境的一个服务变得非常脆弱时，运维部门能把支持这个服务的责任交回给开发部门。

 

第十七章 将假设驱动的开发和A/B测试融入日常开发

A/B测试：在一个网站上，给访问者随机的展示一个页面的两个版本之一，即控制组（A）或实验组（B）。基于这两组用户后续行为的统计分析，可以判断两者的结果是否存在显著差异，从而找出实验组（例如，功能的变化、设计元素、背景颜色）和结果（例如，转化率、平均订单大小）之间的因果关系。

 

第十八章 建立评审和协作流程以提升当前工作的质量

同行评审是要求工程师请同行对他们的变更进行评审，这种实践称为代码评审。

结对编程：程序员结对在一起工作。

肩并肩：在一名程序员编写了一段代码后，评审程序员接着就逐行阅读他的代码。

平均恢复时间：MTTR

 

第十九章 将学习融入日常工作

坏苹果理论：通过消除肇事者而消除错误的观念。

标准化模型：用制度和系统管理一切，包括严格遵守时间表和预算。

实验模型：在一种类似于研究和设计的实验室文化中，对每天的每次实验和每条新信息进行评估和辩论。

演练日的目标是帮助团队模拟和演练事故，使其具备实战能力。

 

第二十章 将局部经验转化为全局改进

测试驱动开发：在编写代码之前编写自动化测试。

 

第二十一章 预留组织学习和改进的时间

改善闪电战：指的是在一个专门的时间段解决特定的问题，通常长达几天。

MVP：最小可行性产品。

 

第二十二章 将信息安全融入每个人的日常工作

三大关键业务衡量标准：开发速度（即向市场提供功能的速度）、客户交互的故障（即服务中断、报错）、和合规响应时间（即从审计提出请求到提供所有必需的定量和定性信息的时间）。

静态分析：

动态分析：

依赖组件扫描：

源代码完整性和代码签名：

欺诈：当系统运行不正确时，让无效或未经检查的输入进入系统，从而造成财务损失，数据丢失/被盗、系统停机、破坏，或者对另一个系统的攻击。

 

第二十三章 保护部署流水线

ITIL3种类型：

标准变更：遵循既定批准流程的低风险变更，但也可以是预批准的。

常规变更：风险更高，需要权威机构评审或批准的变更。

紧急变更：在紧急情况下必须立即投入生产环境的变更（例如，紧急安全补丁、恢复服务），属于潜在的高风险变更。

MTTR：平均故障恢复时间

破坏性测试：指的是在最严酷的操作条件下执行长时间的耐久性测试，直到摧毁测试部件。

 

附录9 猿猴军团

捣乱大猩猩：模拟整个AWS可用区域（AZ）的故障。

捣乱金刚：模拟整个AWS地区（Region)的故障，如北美或欧洲。

延迟猴子：在其Restful客户端服务器的通信层人为引入的延迟或停机，以模拟服务降级，并确保相关服务正常工作。

一致性猴子：查找并关闭不符合最佳实践的AWS实例（例如，实例不属于任何自动伸缩组，或服务目录中没有值班工程师的电子邮件地址）。

医生猴子：检查每个运行的实例，找到不健康的实例，如果负责人没有及时修复，就主动关闭实例。

看门猴子：确保他们的云环境没有混乱和浪费，搜索未使用的资源并处理。

安全猴子：一致性猴子的升级版，找到并终止有安全违规和漏洞的实例，例如AWS安全组配置错误。