查看原文
其他

网易严选基于“服务画像”的长效稳定性能力建设实践

陶然 ITPUB 2023-03-21

本文根据张伟杰在【第十五届中国系统架构师大会(SACC2022)】线上演讲内容整理而成。



 本期分享嘉宾 

张伟杰

网易高级技术专家

【嘉宾介绍】来自网易严选,12年起从事技术质量工作,先后就职阿里、网易公司。目前作为稳定性保障、数据算法质量团队负责人,从事性能&稳定性、大数据&算法质量、研发效能等方向解决方案建设。

本文摘要微服务架构下的复杂在线系统,在保证系统稳定性方面存在以下典型难点:

1,从微观视角看,除了基建、运维的传统专职角色外,稳定性保障职责大多拆分到了各个“小型”研发团队手中。在繁重的需求压力下,各研发团队面临精力有限、目标模糊、人员交替等难题,导致稳定性建设水平参差不齐、依赖“事故驱动”。

2,从宏观视角看,由于复杂的调用链路和依赖关系,大量微服务组成了一个高频迭代的大型系统,对线上运行风险的快速识别和上线前拦截提出了较高挑战。

网易严选技术团队在过去几年中,面对上述挑战,从基础能力搭建到研发模式调整,逐步建立起一套技术团队广泛实施、覆盖全站1.5k个服务端应用的稳定性解决方案。

分享大纲:

1、严选稳定性建设的背景和难点

2、完善基建:工具链搭建和落地应用

3、落地长效机制:基于服务画像的标准化方案,以及在研发团队、迭代模式中的适配

4、拥抱DevOps:高频迭代下的稳定性风险发布卡点策略




背景和难点

网易严选是一家独立品牌电商,技术系统涉及C端:导购、交易、用户等;B端:库存、商品、客服等;数据&算法:智能营销、搜索、个推等;技术平台:自研、开源引入;PaaS/IaaS基建:自研、网易集团。

网易严选技术系统有两大特点:其一,高度微服务化,拥有1500+后端应用(服务)、30+特性研发团队;其二,业务需求饱和,全站服务端每周1000+次发布。

关于稳定性能力建设目标,网易严选希望通过工具、流程、团队等方面建设,持续、有效的识别和消除系统运行风险。如今正面临诸多挑战:

首先,风险难以充分识别,仅靠线上运维兜底是不行的,导致我们频繁救火、复盘;其次,需求迭代压力很大,投入不足,运动式治理、难以持续;最后,团队多、人员流转,导致标准混乱,依赖个人能力,人走政息、落地不易。

针对上述挑战,2019年严选决定建设一套长效的稳定性保障能力,并制定了阶段性目标,目标一:风险能力要充分识别,大促无故障;目标二:在高强度迭代压力下,持续性消费风险;目标三:守住基线,更快交付。


基础能力建设

从2019年开始,严选频繁落实研发标准和规范,以及快速建设了一些工具和平台。在工具平台建设方面,主要包括四大部分,即监控-报警-快恢、性能和容量管理、可靠性评估和治理、变更管控。

在性能、可靠性评估能力方面,下图左侧是生产环境全链路压测,导购交易链路,覆盖200+个线上应用集群,从2019年开始累积识别、修复风险点500+。

上图右侧是生产环境故障攻防演练,应用层故障识别流量标记后生效,让用户无感知,从2019年开始累积识别、修复风险点70+。

在应急预案管理方面,严选第一件工作就是把预案标准化,建立了5W1H标准化在线管理,300+在线预案,已支撑20+场大促。严选将预案实现了自动化,打通了各个技术平台,所有预案可一键执行,在大促高峰时段,做到了自动提前执行、自动恢复。同时,严选还建立了预案防腐,在S级大促之前,要做到100%评审、演练通过率。


落地长效机制

要知道,在研发规范、工具平台都具备后,仍然存在落地困难等诸多问题:

第一,工具需要更好用,最好是无人值守;第二,对系统“稳定性”的“水平”、“当前风险”,各团队、各职能缺少标准定义,沟通、协作成本高;第三,目标不清晰、成果难量化;第四,迭代需求繁重,难以驱动研发团队改进。因此,工具+规范并不等于实际落地。

对于落地长效机制,严选认为由三部分组成,包括更低成本的风险识别和治理能力、合理的度量能力和适应高速迭代的技术运营方案。

如何把风险识别和拦截做到更低的成本?例如,不仅要在大促之前做压测,平时也可以进行测试,实现常态化性能基线,安全保障是前提,做到基于依赖链路自动审计,将SOP线上化、压测值班线上化。据了解,从2020H1起,严选就实现了双周固定核心链路线上压测,完整实施小于30分钟每次。

在依赖变异监测方面,微服务整体稳定性存在“水桶效应”,历史事故和线上问题,30%以上来自不合理的依赖调用。常见高风险场景如过大调用扇出扇入比,危害是下游轻微抖动,上游成倍放大;在过大超时设置时,会导致被下游拖垮、雪崩等等。

严选方面采用了全域调用拓扑,据统计,约有10万个逻辑节点(接口)10万+条边,且随着迭代高频变更,人工治理成本高。严选的思路是自动化变异监测,T+1更新构建全域依赖拓扑,预发环境每日无人值守遍历故障注入。最终效果是覆盖100%依赖拓扑,做到每日自动监测,识别风险项6000+,低成本,不到人工review的千分之一。

在稳定性风险标准化度量方面,度量是改进的前提,合理的稳定性风险量化方案,应该具备哪些条件?为什么不直接选用SLA?我们考虑了以下几个指标:

1,指标成熟度:易理解、有共识、可获取

2,抗干扰能力:客观事实数据、减少人为干扰;能拉齐不同实现难度

3,指标透明能力:引入灰盒、白盒指标,方便下钻治理、方便任务分解和排期

4,指标灵活性:权重可调,牵引团队阶段性重心

针对上述需求,严选推出全新的度量方式——服务稳定性画像。其设有六大评估维度,即SLA可用分、基线压测分、容灾能力分、应用风险修复分、存储风险修复分、配置规范分。据严选统计,事实指标占比80%+,灰盒/白盒指标占比70%。

下图是目前严选采用的服务画像

严选实现了数据层统一聚合,汇总500+表,建设全域稳定性&质量&效能数仓;在服务/接口/集群、项目/迭代/需求、工程/分支/commit、团队/个人、日/周/月/季等多维度分析;在低成本可视化方面,采用敏捷BI报表。

在长效技术运营方面,严选设置了研发团队OKR,L1服务大于85,L2/L3服务大于80,在协作流程方面设置了虚拟技术运营小组,月度Story做到提前筛选排序,开发+QA自主拆解,月度复盘。

在最近一年多的时间里,严选长效技术运营已覆盖后端应用1500+,覆盖C端、B端各业务线共30+特性研发团队,达成OKR基线的服务,占比从80%提升到95%。

在C端研发团队稳定性治理任务上,严选治理事项当月完成率从过去最低50%,提升到85%以上,研发团队用于稳定性治理的总投入降低30%以上,严选正在从“大促+事故驱动”到“常态运营”转换,目前,严选已经连续20个月无稳定性事故。


拥抱DevOps

严选如何在DevOps流程中实现稳定性的治理?我们认为本质是在不损失交付效率的前提下,确保质量基线,同时进一步确保质量+稳定性基线。

下面这张图是严选天枢-DevOps研发效能平台

在产品方面有需求管理和交付协作,在研发方面有服务新建或维护、git仓库、代码扫描等等,在测试方面有编译构建、测试验证、集成回归、预发验证、上线审核和生产发布,在测试时有染色环境,集成回归时也有相应的回归环境,在预发和上线之前,我们会做性能基线卡点和变更风险监测。

简单总结,我们做了三件事情:第一,服务画像分,影响发布窗口:高分服务,不受窗口限制,大促不封版;第二,预发环境性能基线卡点:服务性能退化发布前自动拦截;第三,变更风险自动检测:DB、配置中心、MPS订阅配置完备性检查,发布前后监控数量对比,异常第一时间识别。

下面是系统截图

左图是性能基线发布卡点,我们发现流水线自动触发,预发发布阶段增加了3分钟,据统计,从2022Q3开始,拦截5例性能退化发布。

右图是变更风险检测,据统计在发布风险拦截方面,已经成功拦截变更错误367次,在制品合规性检查方面,不合规制品拦截5310次。


未来展望

未来,严选将持续深度融合DevOps流程,稳定性风险拦截环节持续左移,希望在研发阶段、测试阶段、甚至是需求阶段就能够实现风险的提早识别,而不是把所有的工作放到后面。同时,严选还希望引入算法能力,将风险探测和拦截能力增强,体感减弱。


近期文章精选 

创新是国产数据库的唯一出路 | DTCC2022

金融级系统海量流量下高可用架构的道与术

光大银行实时流数据平台架构实践

小红书近线服务统一调度平台建设实践

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存