此题名为2023年前俩月总结（注：相关人员皆采用代号出现）

奈何时间已经过去许久，许多事已经无从记起。因此参考往期例会进行汇总。

年后回来的一月份依然有两周的工作，即0130计划。但是当时主要工作记不清了，暂时略过。还是从2月份开始

2月份主要工作依然集中在巡检详情及其他接口的优化上。

按照时间线的顺序，

1、新增需求 结果删除接口。通过和SE的讨论初步定位软删，即通过设置state字段为deleted代表该条结果被删除，从逻辑上算是被删除了，但是依然存储在数据库中。（3月份该需求可能又会有变动，同时此处实现过程也为考虑后期概览页接入后的相关问题，此处都为后话了）

2、新增数据库日志。这部分内容的优化主要源于一起未知事件，起因是在出版本后，有测试人员（“嘚儿”）捕捉到一个bug，存在某条巡检任务持续执行且不结束的问题，且由于巡检为串行执行，因此阻塞了其他巡检任务的执行，任务等级定性为严重。针对此类问题的解决思路应为定位原因、提出解决方案、解决、验证、关闭。启哥下派任务的时候，并未严格按照该流程去执行，此乃大忌。后面虽然通过补救没有造成影响，但依然要杜绝此类事件的再次发生。言归正传，通过我们的验证，定位到原因为在往数据库写入数据的时候存在写入异常，但数据库方面却并未捕获到异常，因此主要存在日志记录不完全的问题，最终解决方案，在数据库写入过程中将必要的日志信息记录，并针对此类事件情况做应急处理，例如将未能执行成功改的任务状态置为失败，不影响其他任务的执行。综上，为了杜绝此类事件的发生，将该处理方式在巡检中体现，但是，由于存在大量对数据库的操作，且操作方式、操作类型的不同，结合兜底机制让我感觉此处存在某些逻辑问题，目前尚未排查出来。！！！插眼！！！

3、用户接口。即在前端不提供用户信息的前提下，由后端自行获取。初步方案为由其他团队提供SDK。但是由于时间紧张，通过沟通讨论，由后端自行解析数据获取，沿用至今。大致方案为：用户信息存在于Header的"X-CC-AuthData"中，base64加密的json结构体，因此在已知该结构体结构后可以直接获取到owner数值。该方案在当时能正常实现该过程，但是之后，提供该结构的团队在处理不同版本是出现字段被修改的情况，导致巡检后端会采集到空值。后续处理方案为巡检后端暂不做处理，由对应团队进行解决。

4、版本号接口。该接口通用户接口一样，都需要后端自行获取，但是该信息处理上要更复杂一些。需要从K8S环境变量中获取clusterversion，同时定义与之对应的结构及权限。此处细节说不清…在波哥辅助下完成该接口的实现。具体细节,,,,,未完待续……

5、在巡检联调过程中，发现GORM 存在的一个硬伤，Updates 方法支持 struct 和 map[string]interface{} 参数。当使用 struct 更新时，默认情况下，GORM 只会更新非零值的字段。因此需要将struct结构转换为map结构才不会出现问题。暂不理解为啥不支持。

6、巡检详情中，region部分需要新增一个执行进度，设计初期并未注意到该部分，或者将该部分的字段名写错，所以后面也要杜绝此类事件的发生。同时，交互稿和UED在此处呈现不同形式，由于后端和前端分别看到的是各自的设计稿，后期需要同时关注，提醒SE及时关注此类问题。该接口的时间没有产生其他问题。

7、0228巡检进入各自提测环节，主要工作为解决测试提交的bug，同时进行多region环境的测试环节。期间也产生多个bug。

8、在巡检联调过程的同时中，搭建了多region-单节点环境。由于前期看错文档才导致一直部署失败，后期才部署成功。部署期间由于其他团队鉴权的问题也重新清空环境，重新部署新版本。

9、巡检后端新增需求，新增failed字段和total字段。早先只新增failed的level，当时为了减少对数据库的操作，因此采用不新增字段的方案，扣分的地方也采用了不新增字段的处理方式。由于后期又新增了该字段，前期的处理尚未进行优化。0330新增需求不做介绍。

二月份大致工作如上。主要集中在巡检服务调试，以及部分需求上的调整，总体来说中规中矩，没有过多问题出现，bug二月份名下有一个单子，通过问题定位到是其他部门服务的问题，单子指出。

有个有意思的现象是，过年假期回来后看自己以前的代码，真的是这么一种意境：我乘一叶扁舟，在大海上驰骋。这个现象是一定要避免滴，还是要加强编码能力。对服务整理有足够的理解。差不多就这样了，实在没有字数凑了。吟诗一首：低头赶路、敬事如仪、自知自心、其路则明。啥意思不知道，看辩论赛看的，就是觉得高级。