目录
1、幂等失败
思考：
凡涉及【幂等】设计修改，需要做好代码review；
测试需要做专项测试；
上线前，需要灰度发布；
2、 运营同学调整配置，引发某些规则失效，大盘数据下跌
思考：
缺少监控机制，没有发现大盘数据异常；
3、压测造数据问题，导致集群fullGC
思考：
压测数据，数据倾斜、分布、量级等等，需要充分评估；
压测场景数据，需要和真实用户场景数据，做充分比对；
压测时，需要先预热，然后缓慢增加压力；
4、配置错误，误操作了线上
思考：
核心配置，需要增加double check审批人；
配置更改后，增加灰度；
代码设计考虑配置错误情况(比如，只要配置不正确(格式，大小写等)，就按不配置处理、或直接不允许保存)
5、容量不足，外加没有限流，导致无法提供服务
思考：
核心业务，可能临时突增流量部分，需要添加限流；
需要新增前期压测；
6、大流量下DB内存出现雪崩，写入慢
思考：
压测模型没有充分评估，缺少场景，加入压测场景；
7、上下游交互的API的结果不一致，导致资损
思考：
涉及资金，一律需要严格上下游对焦 + 链路测试；
链路上需要对账；
8、线上和预发的缓存没有隔离，导致线上缓存数据格式转换问题
思考：
线上和预发共用缓存和DB，本身感觉没太大问题，但问题是需要线上和预发数据做好某个角度的隔离。 比如，电商业务，可以做门店维度隔离、权限维度隔离
9、分支代码合并解冲突问题引发线上问题
思考：
代码review粒度不够，需要加强
回归测试场景覆盖不够，需要全面评估
风险高的改动上线前必须灰度
10、内存泄露导致OOM-killer后无法提供服务
思考：
需要check 监控覆盖程度、机器探活能力、机器快速下线
增加上线前灰度
安全生产思考
线上发生了严重故障，影响了大规模的用户，一般来说，这个问题都逃过了安全生产防护：
1、代码实现/变更检查
2、线下测试
3、灰度
4、监控
5、快速止血
根据业务本身需要，安全生产需要不同侧重点的投入，但这里貌似有个悖论：
线上没有故障，感觉不到安全生产投入的价值/或者没有太大动力投入安全生产；
线上频出故障，感觉安全生产投入也没有价值。
其实这里关乎一个问题： 安全生产的产出衡量问题。
安全生产的几个抓手
1、面向失败设计，深耕细作好代码review，这需要boss层的大力推动和支持；
2、监控告警，需要未雨绸缪，同时防止被太多的“干扰性”报警；
3、核心业务，特别是可能产生资损的地方，需要做好对账和监控、以及快速止血；
4、可能引发重大问题的改动，最好经过double check；
5、避免线上场景裸奔，即做好 功能测试、压测、针对性专项测试。
6、快速发现、快速止血、容灾、自愈是种能力，只有试了，才知道系统&团队有没有，所以故障演练必不可少。
扫一扫
181
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
