一、日常问题
1）临时小需求
在日常研发过程中，难免会临时加些小需求，例如增加个标识、字体换个颜色、间距增加等。
这类需求虽然不复杂，但是很多时候都会打乱自己的开发节奏。
最近我收到个修改需求，来来回回改了四次。因为只是和我口述了下需求，我按照口述修改。
后面测试就发现了些场景需要过滤，再马上修复。上线后，由于没有设计稿，我所设计的界面效果，与产品所想的不一致。
再做了两次修改，虽然花的时间不多，但是着实费劲。归根到底，还是因为需求不明确导致的。
下次遇到此类问题，需要和产品将需求描述清楚，有必要的话，还可以叫上测试，从场景到呈现，都要一一询问，以免遗漏。
2）服务调用错误
周二晚上有人上报某个排行榜数据不更新，排查后发现是 Node 调用服务端的服务没成功（服务调用错误 getaddrinfo ENOTFOUND xxx）。
从而让 Node 报错引起 Pod 重启，接口就访问不到数据了。
其实调用服务端接口都已经做错误捕获（try-catch），但是在 catch 分支中没有返回对象。
最直接的办法就是先给一个默认的返回值，不出现 undefined 的错误，也能让 pod 不再重启。
改完代码上线后也到了晚上 23 点，pod 是不再重启了，服务端接口大部分能成功调用，但也有比较少的失败。
第二天来公司，运维和我说，后端的 Pod，当 CPU 过高时就会自动重启，而这种情况在访问量比较大的时间段会比较频繁。
这个骚操作也是无奈之举，他们现在也没资源去做代码优化，只能通过重启的办法来缓解线上过慢的请求。
那么运维给我们部署了一套单独的服务，专门就由我们来调用，不会重启，调用的域名更新后，果然不再有请求失败的错误了。
其实还有一种叫做熔断的模式，就是如果发现上游服务调用慢，或者有大量超时的时候，直接中止对于该服务的调用，直接返回信息，快速释放资源。
这里就需要再做代码优化了，后续可以优化优化。
3）数据库CPU异常
从 10 月 8 号开始，每天凌晨 3 点数据库都会推送异常告警，CPU 的使用率超过了 60%。
一开始以为是偶发现象，因为之前也有这种突然增长的情况，但每天都会告警就有问题了。
找运维排查，说了一张表，将表名推给相关组排查，发现并不是他们的服务引起了。
这说明运维的推断有误，因为每天都是定时的，所以感觉是在跑一个定时任务。
运维再次锁定到一条 delete 语句，用于删除七天前的监控日志，执行时间长达 10 分钟，在这段时间，CPU 飙升。
DELETE FROM `web_monitor` WHERE `ctime` <= '2024-10-08 00:00'很有可能与最近的日志量上涨有关，之前每日的数据在 70W 条左右，而现在达到了 100W 条左右。
运维说他那边也可以配置数据库的定时操作，然后在语句中会加 limit 限制，这样就不会占用太长时间。
不过，我最终还是没有让他配置，主要是因为如果定时操作出现异常，还得找运维修复，并且没有告警，异常了也不会知道。
这个服务对于我比较重要，所以还是决定自己优化，方式也简单，同样是加 limit 限制，只不过多几次循环。
最近，服务端的接口也老报 500 错误，有几天报的比较厉害，都影响了我监控的性能指标，也反馈了两次。
二、工作优化
1）协作依赖
最近在做组内 1V1 时，发现了协作依赖的问题。
就是在多组协作时，会存在依赖关系，但这是个单向依赖，并且被依赖对象并不知道有人在依赖他。那么当修改或遗漏逻辑时，也不会去通知依赖人，就有可能出现问题。
就是你的代码逻辑有个前置条件存在于其他组，当其他组更新代码时，并不知道会影响你，那你的这段代码就会无法执行，导致用户上报。
这个双月遇到了两次这个问题，一次是我们依赖别人，另一次是别人依赖我们。
有个审核的功能，服务端会将一条记录插入一张表中，我们会从这张表中去查是否有这条记录。
但这次服务端换了个人做更新业务，他没有将记录插入，从而导致我们组的逻辑异常。
这个问题我更倾向于觉得他们组对常规功能没有保留详尽的技术文档，出现了逻辑遗漏。
另一次是数据组在做数据统计时，会依赖操作记录的一个字段，我们会写入这个字段，这次产品修改了这个字段的格式，从而导致统计异常。
这个问题我更倾向于若有数据相关的需求，尽量提前告知数据组，避免无法统计结果。
其实最简单直接的解决方案是提前通知依赖人，但是难点就是不知道有这么一个人存在，所以在实际项目中就会出现遗漏。
而且我感觉这种协作问题应该还蛮多的。
2）告警不是一串数字
国庆假期前，偶尔收到了几个 500 的错误，没有当回事儿，以为就是偶发现象。
没想到国庆假期期间突然出现了大量的 500 警告，一查原来是网关转发的时候报 502、503、504 错误。
这就导致收到了非标准的 JSON 格式，调用 response.data.xxx 就会报 undefined 的错误。
知道原因后，马上修改，将网关转发改成内部的接口调用，并且给代码加了些 undefined 的判断。
3 号 23 点多的时候发布代码，4 号的指标就正常了。
期间还发现了大量的慢响应，是之前正常的 20 多倍，查看接口日志，最后锁定是依赖的服务端接口出现了异常。
联系了运维和服务端的人，后者没有回应，前者去查了下，说是其他接口影响了整个服务，而这些接口并不是我们调用的。
最后给我们单独配了 POD，只有我们访问的接口才会请求这个 POD，5 号的慢响应占比马上就恢复了。
对数据的不敏感，以及无视告警，让自己在国庆期间还要连夜改代码，都是自己作的，怨不得别人。
虽然是上游影响了下游，但是造成影响后，还是得下游来背锅，所以未来的话，数据还是要盯紧些，不要只是当成一串数字。