项目经验教训

1、 poi发布时，依赖方大量报错，找不到getPoiById接口，实际是存在的

背景：poi服务一共41个节点，每个节点17个端口，差不多700左右的节点，数据大节点列表服务；同时使用了随机端口的特性，所以每次发布完之后，接口的对应的端口存在变更的现象；

当poi发布时，在serviceMesh场景下会一直全量下发所有的节点列表，直到发布结束，因为属于大节点列表，所以节点列表更新的下发延迟很高，会导致上游服务存在没有及时感知到节点状态和端口变更的情况，所以导致少数请求出现invalid method name的报错；

解决方式：

基础服务平台

• 目前相关的上游服务mesh开关已经关闭，所以不会再收到这个问题的影响
• 节点列表更新的延时问题我们会高优进行解决，等解决后再开启mesh开关

2、  突然增加2000+错误 调用方拉雷达群催促  。。。 懵逼

查看错误：

 java.lang.NoSuchMethodError: com...client.Auth.authIdentityTLS(Ljava/lang/String;)Lcom/../client/AuthResponse; ——不是自身服务的错误；

com...inf. — 属于基础服务；Auth — 鉴权的，从找octo搜索相关appkey，查看对应服务的值班人员、公众号；提TT，处理人进群

不足之处：

   · 工作软件上沟通慢，直接拉相关同学线上会议沟通，快速处理下

   · 不敢把自己设置为处理人

3、单个调用链异常耗时定位

以volga这个服务为例,当查询该服务的调用链时，可能出现以下状况：

1. 整体耗时452，发现该服务调用下游服务正常，但是服务内部耗时严重，90ms～361ms 服务内部处理逻辑有一定问题，可查询代码进行优化。
2. 整体耗时645ms， 发现该服务调用RPCGroupDealPoiService.listPoiByPoiId 接口时耗时为494ms，明显这个接口调用耗时存在问题，开始先看下网络耗时，若网络耗时很大，则可能是跨级房调用，可以再看下上下游调用的机器ip；若网络耗时正常，则是该接口内部处理逻辑造成的问题，可以联系该接口负责人进行优化处理。

4、 项目流程总结

项目文档包括需求文档、设计方案、测试记录、CR记录、checklist

4.1 设计方案

    技术优化：当前现状梳理，目标方案调研，步骤功能拆分，里程碑（评判各步完成的标准），估时（领导最关注）。

    业务方案：背景、目标、价值（定性定量收益），需求反讲（与PM确认功能点，从系统角度拆分功能改动），详细设计（存储设计(mysql/缓存/ES/MQ)、配置、接口设计(http/RPC)、定时任务、类图、流程图/时序图、测试用例、监控报警打点、灰度方案）

4.2 CR

写完就发起CR，记忆深，不至于被问住，不要拖，记性本来就不好，越拖越忘。CR前做到对代码心中有数。把握主动权，不能交给别人。

移除代码，应该首先跟产品、调用方确认，是否还有用， 而不是删完代码再确认

 不要在for循环里调接口、操作数据库、缓存，避免大事务

4.3上线总结

1. 准备好checklist，避免遗漏。checklist在开发过程中可持续进行完善，如新增的配置，新申请的环境等，避免后续遗忘。
2. 按照checklist，提前把新加的配置配好；
3. 有灰度环境，则先上灰度验证；无灰度环境，是否有灰度控制开关、灰度验证名单
4. 依赖方先上线；
5. 代码发布；
6. 修改现有配置；
7. 被依赖方上线；
8. 线上验证
9. 项目复盘，收益量化

• 日常值班时，注意风险。。尤其牵扯导数据的，即使觉得毫无秘密性的数据，按规范来，不确定的问领导

5、 主R项目总结

对项目进展的把控能力，多端协作时push能力，对风险及时发现和同步；

对项目质量的严格要求，任务划分合理性，排期合理性 ——基本合格，但提升空间还很大

排期要留buffer，不可过分乐观， 给日常工作留下处理时间。

5.1 合同模板-线上电子合同协议更新

做的好的：

排期足够长 -- 不要不好意思排那么长。 合同模板的修改，虽然只是文字修改，看似很简单，但每次都非常耗时间，所以排期时留足够的buffer是明智之举。

不好：

不要直接对接业务，让产品判断是否改动需求。原则上，技术方案定下后，就不接受需求变动。

法务随时都在改动，且可能忘记自己都改了哪里，没有全面的标出改动； 产品一个心软没打回，开发就抓狂。总共12个合同模板，一个改动需要改12个文件。

存在的问题：

上线后，发现部分模板生成合同时，盖章样式出现偏差， 产生一定的法务风险， 法务确认风险可控。

原因分析：

• 开发时，使用了网上格式化工具对html进行格式化时，工具改变了文本内容，自动增加、改变一些标签，导致生成合同失败、内容格式出现偏差， 页面预览没问题，盖章后才显示错误，排查时很耗时间。
• 产品验收、QA测试时，没有完整的验完所有的模板，12个模板仅2个进行盖章操作。导致上线后才发现其他模板盖章偏差
• 进入开发阶段后，公司公告3.15封禁， 延迟一天上线。

需改进：

1，使用网上工具应慎重，多比较，小范围试错，不要一次性改完了12个模板，结果全错了

2，后续验证时，确保产品、QA验收了所有场景。很容易就可以测出的bug，却带到了线上，责任应归QA

3，排期时考虑可能存在的封禁日期，避开该时间段上线

5.2 合作商自主结算

背景：临时接手，对代理商的相关逻辑不太清楚的一个需求，需前期补足；自己主R的相对复杂的一个项目，涉及的功能点比较多且杂，有挑战能更好的成才。

做的好的地方：

设计阶段和相关人员充分沟通，全面的覆盖了相关功能点，做到无遗漏；

分工时，新同学不太熟悉项目，主动承担复杂功能；

人力紧张，且跨清明，前端人力并行项目，介入后告知要请假，导致只有一天的联调时间，时间紧有风险；提前进入联调，优先联调和前端相关的功能，消除风险。

不足：

对代理商的业务不太熟悉，在实际开发过程中，可能存在重复造轮子的情况；
涉及的功能点比较多，排期时间不够充分、分工也待完善，自己周末加班解决；对风险感知还是不够敏锐

改进： 学会合理均衡分配任务，新同学分配增删改查也是没问题的。如编排层一旦涉及了很多调用，对新同学也不友好，应自己承担。

分配任务时，不应该按工程分，按一个完成的功能分。

——到测试阶段，产品按下暂停键，做了个寂寞。

技能提升点

1，时间规划

    将要做的事放在每天任务池中，相同的放一起。什么时间做什么事，避免被打断，高效率做事，且要有条理；

2，分优先级

   标明每件事情的优先级，分清轻重缓急，合理安排时间，不要每件事都在做，没有一件做完的。

   学以致用，远离时间黑洞，根据优先级进行处理，工作效率提升显著。

3，目标对齐

    做事情前和领导对齐，自己理解的最终目标、时间节点是否和领导一致

4，提升工程化能力

     做项目时，要有全局观，不要急着去做事，先看why，what。不能只关注实现，而不关注背景、决策点；

    事后总结优点与不足，关注线上运行情况。

5，提升push能力

   与外部沟通交流时，不能只妥协，该坚持的要坚持；

   不要只专注自己的业务，关注一下别人都在做什么