店匠科技交付体系探索以及实践
如果无法正常显示,请先停止浏览器的去广告插件。
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.