极客时间持续交付36讲学习笔记Word文件下载.docx

1、 它就和Java中的不可变类完全相同：类实例一旦创建,就无法变更，而可以变更的是指向实例的引用。 对但可的包、配置文件、软件应用和数据，都不做CRUD （创建、替换、更新、删除）操作。对于已经存在的斟出设施,不再在其上创造任何新的事物1构建一个新的基础设施；2测试新的基I出设施是否符合需求；3将引用指向这个新的基础设施；4保留原有基础设施以备回滚。不可变（Immutable ）的前提是无状态。容器技术解决的问题（仅仅通过发散和收敛是解决不了的）顺序问题频率问题蝴蝶效应Immutable的衍生黄金映像，指的是将绝大部分不变的斟出设施（包括操作系统、大多 数软件、基本配置等）,包含在映像内，只留很

2、少一部分变更通过脚 本执行解决VDI（虚拟桌面），指的是操作系统运行在后端的服勢器上,用户只使 用属于他自己的虚拟桌面，无法改变后端的系统内容；Phoenix Server,指的是完全被破坏的服务器，能够从灰烬中自动进 行恢复；基础设施即代码,指的是把基设施的构建以代码的方式组织起来， 从而通过运行代码可以完全构建出你想要的全部基础设施。o用户体验角度落地发布系统1张页面展示发布信息，且仅有1张页面,展示发布当时的绝大多数信息、数 据和内容,这个页面既要全面，又要精准。2个操作按钮简化使用，即页面上除了 回滚按钮常在外,最多同时展示2 个操作按钮。目的是要降低发布系统的使用难度，做到谁开发,谁

3、运行。3种发布结果，即成功、失败和中断状态，目的是简单、明了地显示用户最关心的发布结果。4类操作选择，包括开始发布、停止发布、发布回退、发布重试,目的是使状 态机清晰明了。 5 个发布步骤,即 markdown、download, install, verify 和 markup。这里需要注意到的是，verify这步包含了预热，由于耗时往往比较长，一般采用 异步的处理方式。单个实例的发布过程,分为5个步骤：markdown :为了减少应用发 布时对用户的影响,所以在一个实例发布前,都会做拉出集群的操 作，这样新的流星就不会再继续进入了。download :这就是根据版本 号下载代码包的过程；i

4、nstall :在这个过程中,会完成停心艮勢、替换 代码、重启服务这些操作；verify :除了必要的启动预检外，这一步还 包括了预热过程；markup :把实例拉回集群,重新接收流臺和请求。6大页面主要内容，包括集群、实例、发布日志、发布历史、发布批次、发布 操作，来统一、简洁而又详细呈现发布中和未发布时的各种信息。三个原则信息直观,聚合操作简单，直接步骤与状态清晰O发布系统架构要求清晰健壮低耦合 分布式、高可用、易扩展注意点每台服勢实例上的发布脚本一旦产生则不再修改，以达到不可变模型 的要求；发布引擎和Salt Master之间采用异步通信，但为增强系统健壮性， 要有同步轮询的备案；面对频

5、繁的信息获取，要善用缓存，但同时也一走要慎用缓存，注意 发布信息的新鲜度。技术点 布系统的核心模型主要包括Group、DeploymentConfig, Deployment、DeploymentBatch ,和 DeploymentTarget 这 5 项携程之所以这样设计,是因为group这个对象直接表示一个应用的_ 组实例,这样既可以支持单机单应用的部署架构,也可以支持单机多 应用的情况。借助于Celery分布式任务队列的Chain函数，发布系统将上述的 Markdown. Download. Install. Verify, Markup 五个阶段走义为 个完整的链式任勢工作流，保证一

6、个Chain函数里的子壬务会依次 执行。堡垒就是预发布实例,它就是生成集群的一个子集，但发布后，首先 不接入外部正式流星，做自测用，自测通过后才接入生产流呈除堡垒批次外的每个发布批次均采用了 Quick and Dirty的发布方 式，即不管成功或失败，优先尝试把版本发布完，继续执行下个发布 批次，后续再解决个别目标服务器发布失败的问题。刹车机制,即在每个批次开始发布任勢前,系统会根据用户设置的单 个批次可拉出上限比,进行失败率的计算与控制。发布时,旦达到 这个失败率，立即中断当前发布，从而保护Quick and Dirty发布方 式各个机房艇了发布包专用的存储系统，实现了类似CDN的功能，编

7、 译和打包系统在彳壬何一个写入点写入发布包,都会尽快同步到各个 IDC及各个独立存储中,这样真正发布时,服务器只需从本IDC或本 网段做下载。 降级机制可以保证发布系统做到，只有部署包存在,就能恢复服勢。子主题 点火优化O 我们借助于VI （ Validate Internal）框架中间件，实现了 Verify过程的自动化,我们把这个过程形象地叫作点火单机多应用IIS架构的弊端o由于ns的设计问题,不同虚拟目录之间可能存在共用应用程 序池的情况,即多个应用运行在同一个进程下,导致任何一个 应用的发布都可能对其他的关联应用造成影响。o解决这个问题采用的方案是,去除根目录的被继承作用，默认 每个虔

8、拟目录就是一个应用,并且每个虚拟目录的应用程序池 独立。而每个虚拟目录以应用的名称命名，保证单机上不会发 生冲突。单机单应用的优势O单机单应用不需要考虑分配服务端口的问题,所有的Web应 用都可以使用同一个统一端口（比如,8080端口）对外服勢o单机单应用在故障排除、配置管理等方面同样具有很多优势。 言以籲之,简单的才是最好的全星发布的优势o增星发布对回滚非常不友好，你很难确走增臺发布前的具体内 容是什么。如果你真的要确走这些具体内容的话，就要做全版 本的差异记录,获取每个版本和其他版本间的差异,这是一个 巨大的笛卡尔积,需要耗费大呈的计算资源，简直就是得不偿 失O我的建议是,全星发布是互联网

9、应用发布的最好方式。使用标志位O携程在设计系统时,用不同的标志位来标识发布系统、运维操 作、健康检测，以及服务负责人对服勢的Markup和Markdown状态。4个标志位的任何一个为Markdown都代 表暂停服勢,只有所有标志位都是Markup时,服务中心才会 向外暴露这个服勢实例。O 解决多角色对服勢markup和Markdown的冲突问题对于生产环境，发布结束才是最危险的时刻监控分类用户侧监控o访问速度和结果网络监控o CDN与核心网络业务雌o关注核心业务扌旨标的波动应用监控o服务调用链糸统监控o即基础设施、虚拟机及操作系统用户侧监控通过打点或者走期日志收集端到端监控O访问呈O访问成功率

10、O 响应时间O发包回包时间O不同维度：地区、运营商、App版本、返回码、网络类型等移动端日志備表现雌o CPUO内存OO卡顿、白屏O堆栈分析唯一用户ID监控网络监控网络监控并不需要做到太细致和太深入，因为大多数网络问题最终也 会表现为其他应用层面的故障问题。但是,如果你的诉求是要快速走 位root cause ,那就需要花费比较大的猜力去做好网络监控了公网内网监控无去处理的两种情况累积效应,即系统异常需要累积到一走呈后才会表现为业务异常；业务的阴跌，这种小幅度的变化也无法在业勢监控上得到体现。三个重要问题测试环境是否监控?o测试环境的监控需要视作用而走，如果不能帮助分析和定位问 题,则不需要很

11、全面的监控；发布后监控多久？O 般发布后,我建议继续坚持监控30分钟，把这个流程纳入 发布流程中；如何确走异常是由发布引起的？o完整的运维事件记录体系，可以帮你走位某次故障是否是由发 布引起的。 07.测试管理O代码静态检查 代码静态检查,即静态代码分析,是指不运行被测代码,仅通过分析或检查源 程序的语法、结构、过程、接口等检查程序的正确性，并找出代码中隐藏的错 误和缺陷（比如参数不匹配、有歧义的嵌套语句、错误的递归、非法计算、可 能出现的空指针引用等等）。 在整个软件开发生命周期中，有70%左右的代码逻辑设计和编码缺陷属于重 复性错误,完全可以通过静态代码分析发现和修复SonarQube是一

12、款目前比较流行的工具,国内很多互联网公司都选择用它来 搭建静态检查的平台o破坏性测试第一，破坏性测试的手段和过程，并不是无的放矢，它们是被严格设 计和执行的。不要把破坏性测试和探索性测试混为一谈。第二,破坏性狈赋,会产生切实的破坏作用，你需要权衡破坏的量和 度。破坏性测试与普通测试流程,唯一不同的是,绝大部分昔通测试可以 在测试失败后,继续进行其他的测试；而破坏性测试,则有可能无法 恢复到待测状态,只能停止后续的测试。绝大部分破坏性测试都会在单元测试、功能测试阶段执行。而执行测 试的环境也往往是局部的测试子环境。 优点破坏性测试还能很好地证明整个分布式系统的健扌士性走义破坏性测试就是通过有效的

13、测试手段,使软件应用程序岀现奔溃或失 败的情况,然后测试在这样的情况下,软件运行会产生什么结果，而 这些结果又是否符合预期混沌工程混沌工程是在分布式系统上建立的实验，其目的是建立对系统承受混 乱冲击能力的信心。鉴于分布式系统固有的混舌属性,也就是说即使 所有的部件都可以正常工作，但把它们结合后，你还是很难预知会发 生什么。通过一些受控实验,我们能够观察这些弱点在系统中的行为。这种实 验方法”就被叫作混沌工程。案例O 混沌工程的一个典型实践是,Netflix公司的Chaos Monkey 系统。这个系统已经证明了混沌工程的价值和重要性，值得我 们借鉴o Chaos Monkey会在工作日期间,随

14、机地杀死一些服务以制造 混乱,从而检验系统的稳走性。而工程师们不得不停下手头工 作去解决这些问题,并且保证它们不会再现。久而久之，系统 的健扌士性就可以不断地被提高。科学实验的四个必须步骤科学实验都必须遵循的4个步骤：将正常系统的一些正常行为的可测 呈数据走义为稳走态；建立一个对照组,并假设对照组和实验组 都保持引入真实世界的变呈，如服务器崩溃、断网、磁 盘损坏等等;尝试寻找对照组和实验组之间的差异,找出系统弱点。稳定态越难被破坏，则说明系统越稳固；而发现的每一个弱点， 则都是一个改迸目标。o Mock与回放 Mock如果某个又嫌在测试过程中依赖于另一个复杂又嫌,而这个复杂又嫌 又很难被从测试

15、过程中剥离出来,那么就可以利用Mock去模拟并代 替这个复杂对象。嗨o基于对象和类的Mock 适合模拟DAO层的数据操作和复杂逻辑,所以它们往 往只能用于单元测试阶段推荐 Mockito、EasyMockO基于微服务的Mock到了集成测试阶段，你需要模扌以一个外部依赖服务时， 就需要基于微服务的Mock推荐 Weir Mock、Mock Server回放 定义O要做到和实际用户操作一致,最好的方法就是记录实际用户在 生产环境的操作，然后在测试坏境中回放实现O即先通过虚拟交换机，复制和记录生产用户的实际请求,在测 试时回放这些真实操作，以达到更逼真地模扌以用户行为的 目的 08.持续交付平台化O

16、好处及原因随着软彳判支术的发展壬何企业最终都将面临多技术栈的现实随着持续交付业勢的发展,团队会越来越庞大,分工也会越来越明细随着持续交付技术本身的发展，还会不断引入新的工具,或新的流程方法O初衷互联网厂商平台化的玩法，往往是指自己搭台子,让其他人唱戏。高可用、可扩展O平台四大核心模块四个模块是持续交付平台中最核心，最容易做到内聚和解耦的模块。每个核心 模块的周围,又围绕着各种子模块,t匕如：代码管理模块，往往会和代码审 核、静态扫描和分支管理等模块相联系；集成编译模块，也会与依赖管理、单 元测试、加密打包等模块相生相随的；环境管理模块，离不开配置管理、路由 管理等模块;发布部署模块,还需要监控

17、模块和流控模块的支持。O抽象公共服务需要抽象的公共功能，主要包括：账户与权限,包括单点登录，以及鉴权、授 权体系等等;用户行为日志,即任可行动都要能够被追溯；消息通知，即提供 统一的通知能力；安全与故障处理，即系统级的防护能力和故瞳降级。O细节标准先行O云计算带来的变革云计算的弹性能力，使得计算资源的提取成为持续交付过程的一个自然步骤。云计算的Immutable ,可以保证计算资源的生命周期与持续交付过程一致。云计算本身不区分环境,这样可以获取与生产环境几乎一样配置的资源。o缠说话如何衡呈系统健康度 有的时候即使宕机了，特别是在夜间，因为没有用户使用，其实际影 响几乎为0宕机时间这个单一指标，

18、不能全面地评价系统的稳走性采用如下的实施方案：首先，我们通过监控、保障、人为记录等手间和故障时长。然后，计算过去三个月内这个时间段产生的持续交付 平均业务星。所谓业务星,就是这个时间段内，处理的代码提交、code review ;进行的编译、代码扫描、打包;测试部署；环境处理; 测试执行和生产发布的数星。最后，计算这个时间段内的业务臺与月 平均呈相比的损失率。这个损失率，就代表了系统的不稳走性率，反 之就是稳创生率了。注重长尾看数据不仅要抓大势，也要关注细节,特别是异常细节。大的故障和影响,往往都是岀于一些非常愚蠢的失误。-常用衡星指标稳走性性能O与性能相关的扌颤,我匕傲关注的有：push和f

19、etch代码的 速度;环境创建和销毁的速度;产生仿真数据的速度;平均编 译速度及排队时长;静态检查的速度;自动化测试的耗时；发 布和回滚的速度。成熟度o与代码管理子系统相关的指标包括：commit的数星，code review的拒绝率,并行开发的分支数星。O与环境管理子系统相关的指标包括：计算资源的使用率,环境 的平均大小。O与集成编译子系统相关的指标包括:每日编译数呈,编译检查 的数据。O与测试管理子系统相关的指标包括:单元测试的覆盖率,自动 化测试的覆盖率。O与发布管理子系统相关的指标包括：周发布数星，回滚t匕率。 09.持续交付移动4PPO移动端交付和后端服务交付的不同点对于移动App的

20、持续交付来说,我们特别需要维护版本的相关信息,并对每 个版本进行管理。移动App和后端服务的持续交付体系,在构建管理上的不同点，主要体现在 以下三个方面：你需要准备Android和iOS两套构建环境，而且iOS的构建 坏境还需要一套独立的管理方案。因为，iOS的构建环境，你不能直接使用 Linux菌以机处理，而是要采用Apple公司的专用设备。在整个构建过程中, 你还要考虑证书的管理，不同的版本或使用场景需要使用不同的证书。如果证 书比较多的话,还会涉及到管理的逻辑问题,很多组织都会选择自行开发证书 管理服勢。为了解决组件依赖的问题，你需要持别准备独立的中央组件仓库， 并用缓存等机制加快依赖组

21、件下载的速度。其实，这一点会和后端服务I：匕较相 像。发布管理 首先，移动App无法做到强制更新，决走权在终端用户。其次,移动App在正式发布到市场前,会进行时间比较长的内测或公 测。最后，移动App的分发渠道比较多样。o移动App的持续交付体系的搭建完全可以借鉴服务端的持续交付的经验。然后，再针 对移动App固有的特点,进行改迸和优化。o移动APP交付流水线pipeline发布快车模式发布快车,就像一列由多节车厢组成的火车，每一节车厢代表一个发 布版本,整个火车以一节节车厢或者说一个个版本的节奏,走期向前 发车。而工程师们,则会把自己开发完成的功能集成到一节节的车厢 上,这样集成在一节车厢的

22、功能代码,就形成了一个新的版本。三个关键点o第一个关键点是,并不是说所有开发的功能,都一走要集成到 最近的那节车廂、最近的那个版本中。o第二个关键点是,我们必须要保证固走间隔的发车时间,每 周、每两周都可以，但必须保证每个车厢到点即发。O第三个关键点是,这个过程的最终产物是可以发布到市场的版 本,而不是发布到用户侧的版本。代码分支策略构建通道O我们会在功能分支合并入Master分支前，增加一次构建（Merge CI Service ）,这次构建的作用是保证功能分支的集 成是成功的,否则不允许合并；同时,对于一个代码仓库来 说,增加的这次构建过程要保证是串行的，即如果这个仓库正 有一个合并构建在

23、逬行，则后续的合并构建需要等待。o发布流程iOS系统的发布步骤为：构建，导出ipa包，记录符号表，备份,上传至 iTC; Android系统的发布步骤为：构建打包,更新渠道标识，签名，保存 mapping文件，备份，上传至发布点。o提升效率提升效率最好的方法就是2个字：解耦。落到技术实现上来说,就是通过组件 化形成合理的开发框架实践经验:利用组件化的思想提升开发效率，但同时也会带来组彳牛依赖及发布 的问题；利用扁平化依赖管理的方法解决组件依赖和发布的问题，同时采用二 进制交付的方式,进一步提高构建效率；合理利用静态代码扫描、UI自动 化、自动Monkey等测试工具和方法,逬一步提升测试效率;确

24、保分发的精 准性和稳走性,是提升发布效率的有效手段。 01持续交付体系概述O要点配置管理环境管理构建集成测试管理O趋势持续交付必须以平台化的思想去看待，单点突破是无力的；的实施,也要顺应技术的变迁，善于利用技术红利;与系统架构、运维体系息息相关,已经不分彼此。O误区过度强调自动化过度强调溺呈化过度强调特殊化O难点事难做人难找效果难以度量O目的提高研发效率 02 基本概念O持续集成这个从编码到构建再到测试的反复持续过程,就叫作持续集成O持续交付这个在之后，获取外部对软件的反馈再通过逬行优 化的过程就叫作,它是的自然延续。是一个承上启下的过程,它使有了实际业务价值, 形成了闭坏,而又为将来达到持续

25、部署的高级目标做好了铺垫。从（自动化发布）开始推进,这才是一条优选的路 径。O持续部署-”持续部署”就是将可交付产品,快速且安全地交付用户使用的一套方法和系 统，它是的最后一公里O价值显性价值在最终用户和研发团队之间建立紧密的反馈环：通过持续交 付新的软件版本,以验证新想法和软件改动的正确性，并衡星这些改 动对软件价值的影响。这里说的软件价值”，说白了就是收入、日 活、GMV等KPI指标了。-隐性价值 对于管理者o技术选型o标准落地o协作效率o黑天鹅防范对于团队主管O知识传递O专注于业务O持续工作对于产品经理O产品的第一个用户o进度和质星O随时发布对于程序员O加强对软件工程的认识O工作效率和质

26、量O挑战和乐趣O如何衡呈绩效 将所有的不可持续点进行记录和分解,通过OKR的考评方式,将消灭这 些点作为目标，拆解出来的可行动点，作为关键结果,以这样的方式来完成绩 效考评。o影响持续交付的因素人（组织和文化）第一个层次：紧密配合，这是组织发展，部门合作的基础第二个层次：集思广益,这就需要组织内各个不同部门,或不同职能 的角色,跳出自身的舒适区第三个层次：自我驱动,是理想中的完美组织形式软件企业与交付有关的研发部门包括四个：产品、开发、测试和运 维。而这四个部门天然地形成了一个生产流水线如何解决组织问题O 成立项目管理办公室（Project Manage Office ,简称PMO ） 这样的监督型组织,帮助持续交付落地；O独立建立工程效能部门，全面负责包括持续交付在内的硏发效率提升工作;使用壬形式，如Scrum r打破职能部门间的隔离墙产品的形式组织团队，各团队自行推进持续交付0文化先行是前提事（流程）耗时长的流程完全人工的流程 信息报备类的流程O持续交付过程中同样会产生各种信息流，这些信息有些需要广 播，有些需要走点传递。实施持续交付后，这些信息报备类的 流程一走会通过异步i