店匠科技交付体系探索以及实践

如果无法正常显示,请先停止浏览器的去广告插件。
分享至:
1. 店匠科技交付体系探索以及实践 无负担发布体验
2.
3. 关于我 阳衡锋,店匠SHOPLAZZA 资深前端架构师 / SRE ,有 13 年的 web 前端研发经验,主要负责店匠 SHOPLAZZA 的发布系统相关 工作, 对前端架构, SRE 有丰富的实践经验。 加入店匠SHOPLAZZA 前,曾在百度工作,负责公司运维自动化产 品,国际化产品研发。
4. • 背景 • 业界案例剖析 • 店匠科技的交付平台建设 • 总结&收益 • Q&A
5. 背景一:公司业务发展很快,研发团队急剧扩张 • • 2021年研发年初 60 +,目前 180 + 线上变更频次成倍增加,本季度上线次数目前 400 + • 据统计,30% 的线上 P0 事故是由发布直接导致 • 不断增加的流程,多级审批,发版流程低效
6. 背景二 : 系统越来复杂,稳定性降低 • 系统规模急剧扩张,新功能无法准确评估其线上影响以及功能上线出现的 bug • 无法准确评估每次发布前后各项关键指标的变化 • 关键业务指标转化率经常失守 • “ 上线忧虑症 ”
7. 背景三 : 新需求决策变难 • 产品调研无法获取一手数据以验证假设是否成立 • 上线没有数据可以支撑功能对业务指标的影响
8. 碰到的问题总结 核心转化率指标 服务稳定性 质量 迭代速度需要持续提升 发布频率越来越高 速度 成本 最低成本验证假设
9. • 背景 • 业界案例剖析 • 店匠科技的交付平台建设 • 总结&收益 • Q&A
10. Google SRE : 发布工程 “ 发布工程( Release Engineer ) 是软件工程内部的一个较新、发展较新的学科,专注于 构建和交付,为保障服务的可靠部署与变更需要制定可靠的发布流程, SRE 需要保证二 进制文件和配置文件是以一种可重现的、自动化的方式构建出来的。”
11. 持续实验 ( 一万次实验法则 ) “ 亚马逊的成功是每年、每月、每周、每天进行多次实验的结果。 ” Facebook : “ 我最为自豪的事情之一是我们成功的关键在于测试框架...... 在任何时候,都不只有一个 Facebook 版本正在运行,而是一万个左右 ”
12. Facebook : 假设驱动开发 分析对比 确认 提出假设 调研数据 设计实验 快速上线 收集数据
13. Netflix Canary 发布 自动化 Canary 分析 (ACA) 平台 * https://netflixtechblog.com/automated-canary-analysis-at-netflix-with-kayenta-3260bc7acc69
14. • 背景 • 业界案例剖析 • 店匠科技的交付平台建设 • 总结&收益 • Q&A
15. 系统架构 Gateway 配置中心 数据仓库 浏览器 用户数据收集 N% 流量 service1-v1 N% 流量 数据分 析平台 service1-v2 service1 Prometheus serviceN-v1 serviceN 基线版本 serviceN-v2 serviceN Canary 版本
16. 平台特性 • • • • • 请求分流 数据收集 全自动无人值守 数据分析平台 满足上线, AB 实验需求
17. 请求分流 hash( user_id+layer ) % 100 <= 50 ? Gateway hash( user_id+layer ) % 100 > 50 ? service1-baseline service1-canary Header: x-rf,ywgd100-owl-v21s3s11 serviceN-baseline serviceN-baseline Header: x-rf,ywgd100-owl-v21s3s11
18. 用户数据收集 网关 Gateway Cookie: user_id:782904813 user_tag:ywgd100-owl-v21s3s11 用户标示以及当前分支 浏览器 track('pageview', { env_tag: 'ywgd100-owl- v21s3s11' }) 所有事件上报加分支字段 数据仓库
19. 全自动: 自动部署 Git tag 触发 Jenkins 部署任务 标准镜像交付 读取部署版本配置 基于 helm 模板多版本部署
20. 全自动: 自动放量 5% traffic 10% traffic 50% traffic 100% traffic 20% 偏差 √ 10% 偏差 √ 5% 偏差 √ 3% 偏差 √ 大于阈值 自动停止上线
21. 全自动: 多上线并行,自动调度 主题层 结算层 • 实验1 实验2 分支A1 分支B1 分支A2 实验3 分支B2 分支A3 分支B3 实验4 分支A4 流量正交 • 业务分层,各层中的实验并行运行 • 上线实验结束自动开始下一个实验,自动从流量池中选取流量 分支B4 t
22. 分层:按部署服务字典计算layer 实验 1 dragon 实验 2 tiger 实验 3 … layer值 1 6 rosefinch 12 owl tiger owl tiger rosefinch dragon 2^3 2^2 2^1 2^0
23. 分层流量原则 实验 1 0001 实验 2 0110 实验 3 1100 } & } & 服务无交集,流量可以重叠 服务有交集,流量不可以重叠
24. 数据分析平台 综合得分(OEC) = 加权(核心转化率,性能指标) 收集 100 + 指标 基于 U 检验判断是否显著
25. 实时数据:核心转化率 电商购物流程漏斗 各个环节转化率 置信度 最小可度量影响
26. 样本量估算 确定实验正常停止 Minimum Detectable Effect 最小测量误差 * https://www.optimizely.com/sample-size-calculator/?conversion=6.28&effect=2.39&significance=95
27. 置信度: 实验结果是否显著 出现 99%可信度负面显著 认为导致核心转化率下降 上线需要停止 *https://abtestguide.com/calc/
28. 护栏指标: 确保上线数据可信 PV / UV 新/老用户 语言 SRM 样本偏差比例 浏览器 国家 是否参与之前实验 实验目标客户匹配比例 页面访问构成比例
29. 用户行为数据分析 Lighthouse 指标:LCP ( Largest Contentful Paint ) 页面最大元素渲染 时间分位值 • 服务端响应时间 分位值 • 响应接收时间 分位值 • JavaScript 报错次数 •
30. 服务端指标 Pod CPU / Memory / Restart • 接口响应慢请求比例 • Http 接口状态分布 •
31. 历史数据经验 • 降低技术参数的分析门槛 • 打败 N% 历史实验数据 • 经验传承
32. 满足上线, AB 实验需求 上线 AB 实验 • 验证没有负面影响。 • 验证具有正面影响的假设。 • 粒度可以比较大。 • 验证单一假设。 • 时间较短,参与流量很大。 • 时间较长,参与流量较小。
33. • 背景 • 业界案例剖析 • 店匠科技的交付平台建设 • 总结&收益 • Q&A
34. 总结: 无负担上线 • 请求分流 • 数据收集 • 数据分析平台 • 全自动无人值守 • AB 实验 确保上线质量 上线效率提升 支持产品决策
35. Q&A We are hiring!
36.
37.

首页 - Wiki
Copyright © 2011-2024 iteam. Current version is 2.137.3. UTC+08:00, 2024-11-25 10:46
浙ICP备14020137号-1 $访客地图$