【原】在工作中遇到的两件事及其思考

1

事件

我们内部有专门给其他团队提需求的系统，用来减少沟通成本。前几天打开系统，看到一个小需求：我们提供的接口会判断是否在短时间内采用相同的参数发起多次请求。如果是多次请求，只处理第一个，剩下的返回「相同的请求正在处理中」的提示。需求方希望可以突破这个限制，允许多次相同请求过来。

我拿到这个需求后简单的想了想，突破这个限制是有风险的，这是我们目前用的限流手段，突破是一个系统隐患。另外需要知道如果允许此操作，产生的结果是否真的是用户期望的。这边是北京的团队，需求方是上海的团队。所以我采用了语音沟通的方式，告知了业务方的风险。业务方也告知了我们需求的场景，沟通后我确认业务方的需求是合理的，我们这边需要开发支持。

然后我在群里同步沟通结论，给出了这边的排期。是一周的时间。实际在第二天我就开发完上到线下测试环境了。因为开发很简单：我加了一个布尔型的变量skipXXXXCheck。默认是false。如果这个变量为true就可以突破此限制。上线后我告知业务方可以测试了。同时告知自己的实时方法，将新添加的参数补充到了对外文档的哪个地方，怎么用。

业务方说这个方法和自己的理解不太一致。业务方的理解不是一个布尔型的变量，而是有一个唯一码，不然网络抖动的话会扩容两次。我再次确认自己的理解，业务方说是这样，并且贴了在系统里需求的下面有评论，评论里有写希望是一个唯一码。

我考虑了一下觉得合理，就将这布尔型的变量skipXXXXCheck改成了字符串。这个字符串会参与参数签名的计算，这样这个参数不同，就不会被认为是相同的请求。然后我再次上线测试环境。

观察没有问题打算上正式环境的时候，领导帮忙review代码。询问为什么要改成字符串，我说服了领导这个的合理性。领导提出了另外一个问题：那这个参数名要改，既然不是布尔型，则skipXXXXCheck不合适，可以用XXXExtra之类的，我同意，于是再次修改后上到了生产环境。通知业务需求完成。

总结

之所以把这件事拿出来，肯定是因为自己做的不好。但是凡事两面，先看好的方面。

好的方面

先评估需求的合理性，与业务充分沟通。而不是一拿到就开发。同时，充分沟通后同步了结论，给出排期，做好周知。

最好的完成需求是不开发就能完成需求。所以拿到需求，需要确认要做的事情是合理的、必要的，在做对的事。

不好的方面

经历了两次修改才上线，还是很多事情一开始没有想清楚。

开发的时候，有疑问没有解决就开发了。疑问1：去掉限制带来的隐患怎么避免。疑问2：需求下面有评论，评论没有充分理解就开发了。

确定业务方的解决方案是合理的，直接改了类型，却没有回过头来再次考虑设计的问题：字段名要严格遵循要表达的意思。

2

事件

在CAT系统上，看到一个错误，这个错误的触发率为百分之一。分析后得出结论是在特定条件下响应时间过长超时导致。这个错误只是在实时列表展示页会偶发出现。因为这个展示页会需要展示一个全量，而不是特定参数下的特定值。

为了解决这个问题，我提出要做两件事：

1>因为之前从一个系统连接到另一个系统取数据，需要改成直连，让系统之间领域更清晰明确，减少耦合，也降低传输时延。

2>全量接口不和其他核心接口共用。写一个新接口，这个接口只从数据库取数据，不再进行每条数据的数据再次校验。数据校验的工作有专门的任务去做。核心接口使用的目的是兜底策略，这个全量的给后台用的接口没有必要。

根据这个方案，我进行了前端和后端的开发。前端主要是修改URL地址和新的返回值对应。这个页面是内部运营系统，只有我们大团队内部用。对应的后端系统之前一直在进行新老系统的切换，本身这个前端页面用的人少，很长一段时间都不好使。但是CAT上的错误会影响我的服务质量，这是本次开发的关键。认真联调测试后，将每个测试结果都放到的提报代码review的wiki中，方便帮忙审阅代码的人根据测试内容知道做了什么，效果怎样。

然后因为前端代码我有merge到主分支的权限，并且一个后台自己内部人看的前端系统也没有什么风险，就直接上线了。后端代码我想耐心的等到发版日再上线。

正好在发版日，旁边一个内部团队的同事过来找我问我做的后端系统是不是系统挂了。我说没有啊，怎么了。前端看起来列表不可用。我解释说这是因为前端系统发版了，后端没发版，不影响核心逻辑，我发版一下。同事问我那你周知了吗？我道了歉，发版后通知问题已解决。

总结

把这件事写出来是特别不好意思的一件事情。因为这整件事情用一个词形容再合适不过：「业余」。

主观的认为一个后台接口本来就没有几个人用不需要周知。虽然是内部人员，也可以理解为收到了客诉。这是个很严重的后果。因为对于我所在的基础架构部门来说：最核心的两个指标就是业界领先性和用户满意度。

这整件是体现了自己意识和专业性的不足，血泪的教训。