重复话多，用来复盘时copy直接用

一、协调&排查

1.多人协作开发分工时，存在分工覆盖不到的地方

主R需要认真考虑是否存在遗漏点，必须时拉各个方向对业务比较熟悉的同学一起评估下

2.在需求中途引入开发资源时，前后RD之间的信息没有对齐

必须保证信息的对齐：前面的人改了什么，相关改动是否完成自测、联调，上下游对接口的相关安排等等

3.出现问题时，多位eagle同学分散处理问题，没有把信息汇总到一起，导致各查各的，增加了故障排查时间

故障时使用雷达工具处理问题，信息汇总、协调处理缩短故障处理时间。

4.宿主机、虚拟机当时都存在告警，但是故障处理同学没有第一时间得到这些告警信息，增加了故障排查时间。

Eagle后续将宿主机、虚拟机相关告警、异常推送给雷达，缩短故障定位时间。

5.没有第一时间将宿主机禁止调度。导致新扩容服务器又分配到故障机器

类似宿主机出现故障，第一时间需要禁止调度分配，避免新服务器分配到此。

任何存在超过1年的“流程”，“sop”，“合作模式”都需要被review和迭代。“陈旧的经验”会难以匹配飞速发展的基础技术平台

二、测试

1.代码没有充分测试就上线

代码有改动，必须有测试

2.修改旧逻辑变动要严谨自测，不能由于变动较小忽略测试场景的回归测试

修改代码后一定要做好测试场景的回归

3.系统跨度广、代码改动多，但是缺乏核心流程的回归

要引入QA资源，上线后一定要进行核心流程的回归验证

4.本次需求接入的sls本身存在一定的稳定性问题，加上测试环境的不稳定，给测试过程带了不少的问题，容易造成测试延期和隐藏真实问题。

在没有充分调研和实践的情况下，大型、重要的需求，尽量不要引入没有使用过的技术，否则很难评估对需求开发、测试和上线的影响。

5.测试case

根据核心链路梳理的影响点，确定测试用例，需覆盖全部上下游的影响点

6.局部测试没问题，整个链路的测试同样不能忽视；

RD自测要到位，边界case都要覆盖到，并且case要做到互不影响

7.未充分自测，未按照上线流程来模拟测试环境，导致测试环节未提前发现问题

应当在联调和测试环节充分自测，将测试环节100%模拟线上环节，提前发现问题

三、报警 跟进

1.上线过程中忽略r****报警、在观察上线机器数量不多的情况下得出没有问题的结论、忽视历史报警。

上线过程和上线完成后要时刻关注r*****报警，对于任何报警，都要“视若己出”，不放过任何一种异常报警。

2.npe这类严重的代码bug，报警等级太低，rd注意不到。

提高npe、数组越界等此类严重bug的报警报警，通过短信、电话等方式通知rd。

3.frog报警噪音多，没有专人优化、跟进并对报警结果负责。

优化f***、f**对账规则、进行降噪、增加报警的响应和跟进。

4.凌晨团长结算定时任务的各环节监控项存在漏配置电话告警的情形，导致问题发生时未能及时响应。

整理团长支付作业每个对外依赖调用失败后的处理预案（现象&修复方法）

5.部分新增对账场景缺乏跟进。

需建立对账差异问题的跟踪机制和升级流程，明确问题责任人，确保对账差异问题在期望的时间内得到响应和解决

6.大象报警没有区分优先级，同时大量无效信息报警，导致有效信息被淹没

1. 报警机制优化： 1. 区分优先级，划分报警不同等级内容不同优先级公众号推送； 2. 高优先级报警增加短信、电话报警；2. 增加夜里值班机制3. RPC调用报文长度排查，避免同样问题再次发生

7.无用的告警信息太多，淹没了真正有用的告警信息，RD无法及时发现暴露出来的问题

现在服务的监控告警正在加紧治理中

四、代码review

1.提交代码需要和组内同学交叉review

提交代码后，与组内同学做详细的codereview，不要太过相信自己的编码能力，对自己的代码负责

2. MCC配置需要至少两位RD同学check，避免误操作；

3.代码review遗漏了关键部分逻辑

  代码review阶段：根据方案设计，验证代码实现方式和方案设计是否一致

4.上线代码调整，测试覆盖点要周知QA；

加大代码review的力度

5.thrift新增字段时，IDL客户端与服务端表示状态的字段编号没有对齐，导致客户端无法从服务端反序列化出正确的值

thrift IDL定义中字段编号是有意义的，定义时需要考虑对上下游的影响

6.商家banner需求一起上线，遇到问题后，回滚时影响了商家banner的功能

线上禁止搭车，避免需求上线相互影响，也不便于定位问题和快速回滚

7.对于新增的状态机字段，开发在自测阶段只关注了能否取到值，而忽略了验证字段的业务逻辑

涉及到状态机修改的需求，在自测阶段一定要覆盖到所有的状态

8.上线环节把控不够，review环节投入的人力和精力不够，自测环境相关验证工具不足

所有核心的刷数工具重新进行技术评审和codereview

9.风险控制流程存在缺失，在出现问题异常数据之后，没能及时的发现问题并在流程中终止，应该增加相关的数据校验流程，即使程序漏洞出现了重复计费的情况也能在流程上实现拦截，不使错误数据流向下游环节

所有的技术改造（包括刷数工具等，只要涉及系统改动），均纳入项目管理流程，技术评审-开发-自测-测试-上线-验收。

10.全链路数据验证方案缺少，没有对各环节业务数据的比对校验流程，有了异常数据也很难被发现

增加监控，增加对账维度，保证数据验证维度的全面性，借鉴业内如银行等良好先进的做法，做到及时发现问题，使问题不产生损失。

五、改动 风险

1.处理线上问题，需要对线上数据持续关注和验证，避免引发二次问题

将每次操作的内容做详细的记录，保持对线上环境的敬畏之心

2.上下游沟通一定要明确具体的交互。比如这次我和xx这边的结构定义，没有落地到wiki中，造成了隐患

和外部的交互一定要落地wiki，按照流程规范进行

3.服务日志的缺陷导致问题解决时效性会大大降低

确保对旧逻辑代码的变更做好日志标记，即使改动很小

1.方案整体设计中就要考虑全流程中的风险点并留有足够的时间去处理

项目过程中的质量要把控到位，尤其是相关外部资源的引入更应该是考察的重点

2.假设期间过程中有没有完成的，需要进行客观的评估。不能有半点的马虎，比如这次的随机抽查等形式

上线和延期的思考。正确对待上线，是否达到可上线状态要客观评论，有风险做到延期也不能上线

3.业务或者其他方给的数据一定要进行校验，把关一定要到位

问题及时周知相关方：影响方、以及影响

2、上线分支中包含了与本次需求不太相关的改动逻辑，影响上线观察和自测

遵循上线规范，一次上线中最好只包含本次需求prd中的内容，避免未知因素影响正常上线和影响问题定位

1、未全面考虑上线方案，上线逻辑中依赖前后端同步上线，存在不稳定因素

正确制定上线checkList文档，上线方案应该考虑本次上线的所有改动，多向有经验的同事咨询和请教

1.服务部署发布不规范：错误的选择在仓储作业高峰进行了发布、发布的时候不应该短时间内全量部署发布，应该选择灰度发布

规范服务部署发布：部署发布前要对发布功能的影响范围进行统计，避免在其和其影响范围的使用高峰期进行发布

  在未确定影响的情况下，服务要灰度部署，确认对线上无影响的情况下再逐步全量发布

1 开发中接到产品需求之后，只是做到了判断建品限制准确性，但是设计思路上存在问题。产品的建品限制解除是对应供应商层面，通过动销的sku查找到所属的供应商，如果此供应商还有建品限制，就给此供应商解除限制。开发设计是在商品层面，通过为首次动销的sku添加动销标志，然后通过供应商是否存在动销过的sku来判断是否解除限制。导致最终只是做到实现产品功能，但是开发设计存在逻辑缺陷。

以后在需求评审结束开发进行之后再遇到新的需求或者需求变更，应该让产品在群里周知相关RD、QA,并且进行需求评审，保证产品、RD、开发在需求上对齐，达成一致。

需求开发时候应该从产品层面做到代码逻辑合理正确完整，脉络清晰。应该将建品限制逻辑设计为通过接收到动销的sku消息来查找对应得供应商，如果供应商未解除限制，便给对应得供应商添加解除限制标志，然后再给此供应商发短信通知已经解除限制，跟产品层面对齐。

4.系统上线后，对于改动的内容没有进行线上验证

系统上线后，需要周知相关方，并在线上对相关页面逻辑进行验证

六、设计

1、涉及金额计算的功能未考虑幂等设计

财务系统的方案设计中任何场景下均需Check是否需要幂等设计，尤其是涉及金额计算的（现有的方案模版中已有「涉及金额的需有幂等设计」相关要求）。

重新梳理需幂等改造的功能点。

涉及金额的人工操作产品化或工具化。比如代理商结算单税损金额退回操作，或其它商税损金额退回操作等。

2.希望下游能够对依赖接口失败做异常处理等，而不是自己默认数据和逻辑。因为数据恢复成本往往会比异常处理成本要高。

下游业务方对于上游异常应该快速失败，而不是默认逻辑，否则容易造成问题放大

3.上下游的没有数据监控

对核心链路，需要梳理出全部的上下游影响点，包括数据库、缓存、对外消息、对外RPC调用等

针对退款链路，完善跨系统之间的上下游的监控

方案设计阶段：详细设计中，若涉及到核心链路的变更，必须提供完整的伪代码或流程图。

方案评审阶段：根据核心链路梳理，重点检查上下游影响点是否不受影响

6.上线后：灰度放量，放量期间持续关注组内数据一致性和跨系统的数据一致性

2.服务没有实现业务隔离：两个不同的功能部署在同一个微服务当中，上线会互相影响；线程池使用不规范，多个不同的功能复用了同一个线程池

对于不同的业务进行隔离，比较紧迫的就是先要对需要使用线程池相关的功能进行线程池资源隔离

做好资源隔离，比如不同的大业务要拆成微服务，小业务的话要做好共享资源（比如线程池、数据库等）的隔离

线程池接入垂直线程池组件，内部提供了线程池的完整监控，报警及动态调参的功能

1.完全依赖用户配置迁移无法保证服务端集群流量的正常迁移

短期：通过组合日志的形式实现来甄别客户端是否都配置生效或者正常流量迁移

长期：

1.实现鉴权方式接入客户端，目前3.4.6版本无鉴权功能，自研一套KMS鉴权访问，当前仅支持A(客户端) -> B(ZK)

2.3.5.0+版本支持简单的鉴权访问

1、索引数据变更后，没有及时进行数据比对，也没有确认线上数据使用场景。

ES索引变更必须至少提前1天实施数据双写并完成数据比对。才可对外提供服务。

2、索引分片逻辑变更，直接对原有索引进行修改，没有双写操作和回滚方案。

相关技术实现变更，必须输出方案文档，并约时间进行review。

3、大项目上线，没有做到灰度方案对齐，对于流量放开时间没同步，上线完成后，没有进行线上数据验证

横向项目对接，必须跟进对方上线方案和灰度方案。灰度方案必须跟进灰度范围变更时间点及放量范围

1、与外部服务交互时，缺少外部服务异常状态时稳定性思考与建设；

对存在外部调用情况，增加重试机制，增加监控告警；

2、缺少完备的监控手段，故障期间感知问题不足；

重要接口，缓存要有必要的降级手段；

3、重要的接口/数据缺少必要的降级方案；

数据异常时，需要有重试机制保障数据生成。

4、数据体量较大时，缺少快速恢复的手段。

七、响应

1、值班人员处理不熟悉业务的问题时未找相关rd确认。

值班工单处理时遇到不熟悉的业务方向的刷数问题，应该交给相应业务的负责人check俢数逻辑之后再提交。

2 本次直接关停kafka虽然解决了问题，但是从问题出现到解决中间花费了几分钟，没有及时止损而且操作风险很大。关停kafka后也没有第一时间通知上级，耽误了问题善后时间。

3 事故发生后没有任何应急措施，从问题出现到解决花了几个小时，如果是白天上线，几个小时之内可能造成大量客户投诉。

下次开发如果再遇到线上故障应该第一时间选择回滚，然后立即通知上级，商量采取补救措施。应该为短信发送功能设计一个应急sop，以防在出现问题时可以直接快速实施补救方案