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