第五类:事情忘记做了
案例18:某渠道新增payChannelApi时忘记通知账务团队配置clearingChannelApi,导致渠道清算出错。
案例19:数据域人员在做完数据订正后,临时任务没有及时下线,导致后续任务运行冲突,引发后续ODS数据丢失,导致当日数个报表丢失部分数据。
案例20:技术人员在预发环境做验证时,创建了推送消息,但没有及时删除,导致推送消息被生产环境的定时任务捞起并发送给用户,给用户造成困扰。
为防错,请思考以下问题。
如何做到在渠道新增payChannelApi时,不需要通知账务团队配置clearingChannelApi?
临时任务忘记下线了,怎么防?测试用的消息忘记及时删除了,怎么防?归根结底,在做系统设计的时候,要充分考虑到人的特点:人是会忘记事情的。要针对这点做设计优化:要有提醒能力,而且提醒能力要有双保险(就像早上的闹钟可以设定两个,防止一个被不小心按掉就睡过头了)。系统本身要有兜底设计:如果人把事情忘记了,什么都没做,那么最坏的情况会怎么样。
第六类:事情没按照正确的方式做
案例21:在线上变更时,技术人员没有按照正确的顺序推送两个配置开关,导致系统报错。
案例22:网关系统的设计是如果出现多个SPI以https开头,则会造成https上下文混乱。如果有多个以https开头的SPI,则要用其他的前缀来命名。某业务人员不了解这个“潜规则”,配置了多个以https开头的SPI,导致线上问题。
为防错,请思考以下问题。
如果两个配置开关必须按照特定顺序推送,那么如何确保它们不会被按照错误顺序推送?就像有些汽车不挂到P档是不能熄火的,不熄火是不能拔钥匙的。
能否做到两个配置开关无论按照什么顺序推送都可以工作?
案例22就是我们平时所说的“坑”。配了多个以https开头的SPI,就是踩坑了。其实,有坑就是防错设计没做好的后果。在复盘故障的时候,遇到这类防错设计没做好,让别人踩坑的,一定要追究挖坑团队的责任。就算挖坑的当事人已经走了,这个团队也要背责。
另外,案例22也属于“输入值没有第一时间做校验”的问题,明知道不能有多个以https开头的SPI,在配置时就应该及时报错并拒绝。