DevOps时间指南-阿里云效
2022-11-03 17:08:06 0 举报DevOps实践指南 持续开发 持续运维 阿里云效
作者其他创作
大纲/内容
3. 基于特性的持续交付
本地开发
云端开发：对比本地开发云端开发优点
研发流程的产品化，从组件的新建到最终的发布一气呵成，不用再在多个平台工具上来回跳转；
屏蔽用户操作系统的差异，提供统一的研发环境，不用再解决 Windows/Mac 的差异，不用担心本地 Node.js 的
版本问题；
版本问题；
所有环境都会预装好必要的开发提效工具，如：规约扫描和修复工具、预览调试工具、各环境发布工具等；
充分释放本地磁盘空间；
代码安全管控；
研发过程变量采集，便于数字化度量；
代码评审
配套的数字化辅助工具
做好提交，即将提交做小做好
充分描述，对于代码评审描述应介绍本次改动的需求背景，改动范围及影响点。
数字化度量，通过数据洞察获得团队质量情况，有策略的提升团队技术能力。
代码检测
代码质量问题：我们通过代码评审、集成测试、代码检测、代码规范等一系列手段保障代码质量和可维护
性，从流程上保障开发团队能高效协作。
性，从流程上保障开发团队能高效协作。
代码安全问题
编码安全问题
依赖安全问题
测试提效
提升测试速度
分布式测试：为测试速度插上翅膀
测试用例解析与分发
分组用例的执行
分组测试结果合并
精准测试：有效识别出测试范围
提升测试有效性
提升测试覆盖率
收集完整的覆盖率
单元测试
手工/自动化测试
测试覆盖率能给研发过程带来哪些价值
增量覆盖率
线上覆盖率
测试环境与路由调用
多版本并行发版测试环境争用问题
功能测试和性能测试并行问题
测试环境与生产环境代码&数据同步问题
测试环境的数据脱敏及权限管理
应用环境能力
基于应用和变更的交付模式
提升构建的效率
基于制品元数据提升交付效率：制品元数据是指交付过程中产生的过程数据，包括：代码评审数据、安全扫描数据、回归测试质量数据。这些数据以交付物（制品）为载体。
4. 基于应用的持续运维
4.1 监管控一体化运维：运维的最终目的是 No Ops
新挑战
超大规模
运维效率
运维安全
业务连续性
解决思路：将监控预警和运维执行联动起来，视为一体，从而实现异常故障提前发现、自动定位、快速恢复地自动联动
安全防护
全景监控
多样化运维
4.2 业务系统安全工程：信息系统的稳定性和安全性
面临的挑战
系统故障问题频发
诱因负责，控制难度大
管理者缺乏安全感
解决方案实践
组织的顶层设计
事前的风险预防
事中的实时监控
事后的快速恢复
业务系统安全工程
业务系统安全工程框架
业务系统安全工程标准
4.3 全景监控：全景监控不仅是业务、应用、资源等分层监控能力的简单集成，更重要的是具备通过业务指标下钻分析到
应用状态，及从应用状态下钻分析到资源状态的纵向拓扑联动能力，也是各层指标的智能化健康检查能力的一体化监控。
应用状态，及从应用状态下钻分析到资源状态的纵向拓扑联动能力，也是各层指标的智能化健康检查能力的一体化监控。
传统监控的挑战
系统监控爆炸式增长
监控结果和业务目标之间欠缺联系
监控工具之间数据割裂，数据缺乏分析
监控维护成本高，报警准确率低
业务驱动的监控理念：以业务驱动的自顶向下的全景监控体系
业务监控：是整个监控体系的“顶层”，能够反映用户使用业务的真实情况，可以与业务结果直接挂钩，能够被不同
部门、不同角色的人员所理解。
部门、不同角色的人员所理解。
应用监控：提供应用中服务和系统层监控能力，能够直接反应系统运行状态，帮助研发人员全面了解应用中服务和中
间件的健康状态，快速定位系统问题。
间件的健康状态，快速定位系统问题。
云资源监控：提供应用依赖的各类云资源(如 RDS、OSS、SLB 等)的基本监控，在故障排查中能够为研发人员提供
实例级别的明细监控数据，快速确定是应用系统的问题，还是云基础实施的问题。
实例级别的明细监控数据，快速确定是应用系统的问题，还是云基础实施的问题。
统一的监控架构：宗旨是与业务系统解耦，对业务无侵入
业务监控：实时提取日志监控指标
业务域
业务场景
业务指标(三个黄金指标)
流量
延时
错误码
应用监控：提供常用的系统和中间件层面的监控组件；
云资源监控：通过“云监控” OPENAPI获取各类云资源的指标数据和报警事件，再将这些数据与 CMDB 中应用与云资源的关系信息连接，最终形成应用视角的云资源健康状态视图，解决了云基础设施监控与上层应用监控相互隔离的问题。
监控管理体系：好的监控体系除了有优秀的监控功能以外，还必须有与之配套的管理系统。提倡监、管、控一体化协作机制
4.4 发布策略
常见发布策略
停机发布：停机发版不适合互联网公司
特点
所有需要升级的组件被整合到一次发布中
一个项目中的大部分应用都会被更新
发布之前的研发流程和测试流程往往需要花很长的时间
发布时如果出现问题, 修复和回滚的成本很高
完成一次停机发布, 需要花费很久的时间, 且需要很多团队在一起才能完成
往往需要客户端和服务器端同步升级
优势
简单, 不太需要考虑新旧版本共存时的兼容性问题
劣势
发布过程中，服务不可用
只能在业务低峰期 (往往是夜间)发布，并且需要很多团队在一起工作
出现故障后很难回滚
适合场景
开发测试环境
非关键应用，用户影响面小
兼容性比较难管控的场景
金丝雀发布：选2%左右流量作为金丝雀，验证功能，
正常则推广到全部流量，异常则回滚
正常则推广到全部流量，异常则回滚
优势：
对用户体验影响较小，在金丝雀发布过程中，只有金丝雀用户会受影响
发布安全能够得到保障
劣势
金丝雀的机器数量比较少, 有一些问题并不能够暴露出来
实用场景
监控比较完备且与发布系统集成
灰度/滚动发布
策略：N次金丝雀发布的叠加，需要解决的问题：并行版本路由控制及流量权重，功能特性开关，新旧版本之间的共存和兼容性，快速回滚
优势
用户体验影响比较小, 不需要停机发布
能够控制发布风险
劣势
1. 发布时间会比较长
2. 需要复杂的发布系统和负载均衡器
3. 需要考虑新旧版本共存时的兼容性
适用场景
1. 适合可用性较高的生产环境发布
蓝绿发布
A/B测试
定义：AB 测试侧重的是根据 A 版本和 B 版本的差异进行决策，最终选择一个版本进行部署。举个例子，某功能有两个实现版本 A 和 B，通过细粒度的流量控制，把 50% 的用户总是引导到 A 实现上，把剩下的 50% 用户总是引导到 B 实现上，通过比较 A 实现和 B 实现的转化率，最终选择转化率较高的 A 实现作为功能的最终版本。
优势
1. 快速实验能力
2. 用户体验影响小
3. 可以使用生产环境流量做测试
4. 可以针对某些特定用户做测试
不足
1. 需要较为复杂的业务流量识别和控制能力
2. 需要考虑较为复杂的新旧版本兼容性问题
适用场景
1. 用来做业务探索和创新测试
2. 需要对多个方案进行决策
流量隔离环境发布：略
发布最佳实践介绍
1、发布计划清单-checklist
2、不同环境使用不同的发布策略
3、发布中关注监控报警
4、金丝雀发布和无人值守
5、持续集成和发布
4.5 编排运维
主要痛点
1、核心理念
2、技术思路
1、业务架构
2、技术架构
3、核心功能组件
4、使用步骤
5、关键能力
3、适用场景
4.6 智能运维
运维体系面临的挑战
四大挑战
智能运维实践
无人值守发布 (Unmanned Deploy)
无人介入运维-ChatOps (Unmanned Operations)
0. DevOps实施过程中
面临的诸多挑战
面临的诸多挑战
1. 工作流程自动化、标准化问题，如何让业务、产品、技术三种角色高效和有效地协同。
2. 资产管理问题。如何有效的管理代码、文档、应用、资源等关键资产。
3. 透明化和数字化问题。如何通过全局的信息透明促进协同，并通过数据洞察为团队改进指明方向。
4. 阿里巴巴特色DevOps实践
4.1 一站搞定需求、开发、测试、部署、运维的所有诉求。
4.2 松管控、 强卡点，在工具设计上弱化人为管控，把操作权限下放到一线研发，同时，又提供了全局和特定范围内的
卡点能力（如安全检测），保证发布的质量符合要求。
卡点能力（如安全检测），保证发布的质量符合要求。
4.3 可定制、 可复用， 可扩展，允许开发者根据应用特征和开发习惯定制自己的使用方式以及扩展组件，同时又能方便
地复用他人的优秀成果。
地复用他人的优秀成果。
1. 业务驱动的协作
业务运营层：需要三个核心能力
1. 业务规划能力：业务规划指的是基于业务目标、客户诉求、市场情况，结合资源约束等，做出取舍，决定做什么不
做什么以及何时做；
做什么以及何时做；
2. 交付协调能力：基于业务需求拆分和分配产品需求，并协调产品需求的交付过程，发现和处理问题和瓶颈，最终保
证业务需求的顺畅交付；
证业务需求的顺畅交付；
3. 业务反馈调整能力：在需求发布后即时收集用户和市场的定性及定量的反馈，并基于反馈调整后续的规划和业务演
进，保证业务进化和迭代的有效性；
进，保证业务进化和迭代的有效性；
产品交付层：产品交付层需要建设三个核心能力
1. 规划和演进能力：产品需求要响应即时的业务需求，还要关注长期的效率。
2. 排期和交付能力：决定需求的交付顺序和节奏，并管理交付过程，保证产品需求的快速交付。
3. 交付效能改进能力：改善团队的协作，产品的架构和设计，工程和技术实践等。
技术实现层
承载具体的实现工作，包括不同职能的任务：前端、后端、算法等。实施流程分为从设计到研发；从架构到代码。
2. 产品导向的交付
关注长期效率和业务价值：产品开发的目标分为 3 个大类
第一：直接服务于当下的业务。
第二：提前的产品布局。
第三：改进交付的效率和效能。
把工作分给相对稳定的多功能团队
从把“人分配到事情上”转化为“把事情交给团队”，它的核心变化有两点
第一、需求的处理方式，能够即时灵活的响应业务的变化。
第二、团队的组织方式。产品交付团队是相对稳定的，对长期的产品演进、交付效能、业务贡献负责。它是跨功能的、被充分授权，并相对稳定的。
持续积累高质量软件资产和团队工程技术能力(软件资产、
工程资产和组织资产)：累计资产or累计债务？
工程资产和组织资产)：累计资产or累计债务？
1、丰富和设计良好的原子服务；VS 糟糕的接口和服务设计，导致重用过程中的麻烦；
2、持续逼近业务本质，且具备持续演进能力的领域模型；VS软件复杂度增加、设计欠佳，造成扩展和维护困难；
3、与概念领域模型一致，且维护良好且有测试守护的设计及编码；VS 缺乏有效的测试守护的代码，导致回归测试工作量不断增加，软件质量劣化；
4、良好的工程实践和质量保障体系(持续交付流水线)；VS 组织规模膨胀，协同复杂度增加；
DevOps实施路径
DevOps实施的目标就是：让更多业务，更系统性地受惠。DevOps 的规模化实施就是要寻找平滑和可持续的路径来实现这一目标。
DevOps实施三原则
原则一：业务驱动原则
以业务的视角衡量 DevOps 的实施效果，并驱动 DevOps 的实施
原则二：去规模化原则
面对复杂的组织，先“去规模化（Scale Down）”再水平扩展（Scale Out）
原则三：渐进原则
从现状出发，寻求持续且渐进的改进。在系统改进目标的牵引下，以小步前进，每个小步都带来改进，最终实现系统和全面的转型。
0 条评论
下一页
