持续交付 36 讲
王潇俊
携程系统研发部总监
39682 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 42 讲
开篇词 (1讲)
结束语 (1讲)
持续交付 36 讲
15
15
1.0x
00:00/00:00
登录|注册

30 | 持续交付中有哪些宝贵数据?

发布管理子系统指标
测试管理子系统指标
集成编译子系统指标
环境管理子系统指标
代码管理子系统指标
发布和回滚速度
自动化测试耗时
静态检查速度
平均编译速度及排队时长
仿真数据生成速度
环境创建和销毁速度
push和fetch代码速度
损失率计算
故障时间统计
案例分享
尝试通过数据分析解释和解决问题
推进持续交付过程中遇到阻力
持续交付能力成熟度指标
性能相关指标
稳定性相关指标
使用数据推动、优化持续交付体系
利用数据改善业务开发团队的持续交付过程
发现网络流量瓶颈问题
长尾数据分析
计算业务量与月平均量相比的损失率
计算过去三个月内故障时间段的持续交付平均业务量
监控、保障、人为记录等手段统计故障时间
思考题
常规系统指标数据列举
案例3:数据推动持续交付
案例2:数据抓大势,看细节
案例1:用好的数据衡量系统
如何用数据去优化持续交付体系

该思维导图由 AI 生成,仅供参考

你好,我是王潇俊。今天我和你分享的主题是:持续交付中有哪些宝贵数据。
通过我前面和你分享的内容,相信你已经掌握了持续交付流水线所包含的五个主要动作:代码管理、环境管理、集成和编译管理、发布管理,以及测试管理。而且,你也应该已经初步掌握了建设持续交付体系的基本方法。
那么,如何使这个初步建立的持续交付体系更上一层楼呢?现在我们都选择用数据说话,所以优化一套系统的最好办法,就是从数据角度进行分析,然后找出优化方向,再进行具体的改进。
所以,我今天就分享一下,我在携程建设持续交付系统时,遇到的几个与数据密切相关的案例。通过对这些数据的分析,我们可以明确优化系统本身处理能力的方向,也可以快速发现日常工作中与持续交付相违背的行为,从而再次展现我们搭建的持续交付系统的作用。

案例 1:要用好的数据来衡量系统

让我记忆犹新的第一个案例,是我们持续交付平台刚上线时,就遇到了一个很大的问题。这个问题就是,这套系统的稳定性怎么样?
这个问题不仅老板会问你,用户会问你,其实你自己都会问自己。如果没有相关的数字指标,那我怎么证明这套系统的稳定性好呢?如果我无法证明这套系统的稳定性,又怎么说服整个公司,把它当做研发的核心流水线呢?
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文从实际案例出发,探讨了如何利用数据来优化持续交付体系。首先,文章介绍了如何用数据来衡量系统稳定性,提出了通过统计故障时间和业务量来计算系统的稳定性率,从而更准确地评估系统的稳定性。其次,文章强调了数据分析需要关注细节,特别是异常细节,通过长尾数据分析发现了系统中的潜在问题。最后,文章阐述了如何利用数据推动持续交付,通过分析发布数据趋势,发现了团队的集中式发布模式,并进行了相应的流程改造。这些案例充分展示了数据在持续交付中的重要性,为读者提供了实用的数据分析方法和优化策略。文章内容丰富,案例具体,对于正在进行持续交付体系建设的技术人员具有一定的借鉴意义。文章中列举了常规系统指标数据,包括稳定性相关指标、性能相关指标和持续交付能力成熟度指标,并提供了相应的数据分析方法。通过三个实际工作中的例子,文章分享了如何利用持续交付中产生的数据来衡量系统稳定性、发现问题并推动持续交付流程的改进。同时,作者提出了思考题,鼓励读者分享在推进持续交付过程中遇到的阻力,并通过数据分析解决问题的案例。整体而言,本文为读者提供了丰富的数据分析方法和实用的优化策略,对于正在进行持续交付体系建设的技术人员具有一定的借鉴意义。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《持续交付 36 讲》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(2)

  • 最新
  • 精选
  • 九脉一谷
    产品质量问题是现在最头疼的问题,开发到现在一直都没有一个稳定版本。在devops推进过程中不知道用哪些指标来考核产品的质量。

    作者回复: 分级的bug数量统计即可,bug/commit数量也可以。 你说的问题看起来还是功能切分没做好,从分支开始就要考虑功能开发的粒度和解耦。一般一个功能分支,2周都合不进主干的,要么就是太复杂了,要么就是初期就买划分好。要重新规划。切分分支要考虑很多,难度、资源、外部依赖等等

    2018-09-11
    1
  • 戴斌
    早期,我们最大的拦路虎是 配置变更、用户上传文件管理等种种问题影响持续交付,这些都只能逐个击破,持续迭代去完善
    2020-03-25
收起评论
显示
设置
留言
2
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部