故障的反思

生产故障，P1级别，从程序的角度看来不难
我们底层的SDK包中的入参某个字段是枚举值，例如[0,1,2]，调用方在调用该接口的时候由于他们传参错误，传递了一个3进来，程序处理如果不在枚举值中那么取default值：0
站在我们程序的角度，我们覆盖了0，1，2，非枚举值这四种情况，确保了程序的正确运行，但调用方本来期望是传递2过来，但由于他们程序出错了传递了一个3进来，导致我们当作0处理了，从而产生了故障。

出现故障，首先是解决问题，而不是定责。

通过关闭接入开关，暂时解决问题，后续调用方会上代码修复，我们底层做监控。
而最困惑的是定责：各打五十大板，两个部门各自背负50%的责任。
问题是出现在调用方，但底层作为项目方，没有把控好联调质量。

造成这个原因就是：调用方接入的时候没有通知底层，底层不知道这件事，就没有安排联调。

后续解决方法，提供思路：

• 做好线上日志监控，针对关键字段匹配告警规则，第一时间发现问题，减少造成的损失；
• 提供基线用例给调用方，但调用方来接入的时候必须跑完我们提供的基线用例；
• 大联调时关注关键字段，确保每个环节无误（这个很难做到，涉及多系统联调/跨部门合作）

这个故障的意思不在于技术层面，而是流程上，跨部门合作上；底层怪调用方不通知，调用方怪底层没做好异常处理，这种破事很多；制定规则，邮件记录；