一个有意思的报告:线上故障引发问题原因分布。
共 790字,需浏览 2分钟
·
2022-11-01 18:14
今天看了个线上故障原因排行分析,数据采样不是很广,但也不致于不能参考,样本率本身也很难界定,当然越大越准,根据我个人开发经验来看,这个数据还是很符合我日常开发出现问题的规律的。对业务影响度最高的原因主要集中在以下几个方面:
(看原帖子的画质不怎么好,我还专门去 echarts 网站重新渲染了一个“完美”的图)

1. 配置数据参数错误:(1.0)属于操作不当,粗心。
2. 代码逻辑错误:(0.74)纯粹的bug,测试没有覆盖到。
3. 架构设计问题:(0.45)开发对系统设计经验不足,个人无法避免,可以通过团队规范(技术评审)来避免,早发现早治疗。
4. 网络故障:(0.4)面对网络抖动问题,看公司基础架构能力了,完善的备用网络,自动切换,以及告警机制,能否及时通知到所有受影响的业务方。
5. 硬件损坏问题:(0.35)开发无能为力,不需要关心,遇到就是倒霉。
6. 其他类别问题:(0.34)诡异问题。
7. 性能不足问题:(0.28)取决于对线上业务量提前评估,运营如果搞活动提前通知技术,突发流量需要看公司基础架构有无自动弹性扩容能力,如果有,开发是否接入且正确配置参数。
8. 遭受攻击导致:(0.09)这个,看公司安全团队了,开发一般也做不了什么。
总结:代码逻辑错误和配置参数错误引发的P0问题最多,主要由初次上线或者变更引起,但是,由于代码逻辑变更及灰度流程相对成熟,配置数据变更影响度最高。这需要配置中心有完善的灰度机制,且需要开发人员严格遵守,这就取决于团队如何约定执行开发规范了,有的靠开会教育,效果不好就靠KPI强制要求,就是谁出问题谁背最低绩效,这个完全看老板风格,不同团队,做的好坏的程度也参差不齐。
通过这个分析,面试时如果被问在工作中遇到的故障,如何发现,如何修复等类似问题,可以按照这个故障原因优先级来归类。
如果你还遇到其他原因,欢迎留言,你都遇到过什么问题?