功能

店铺、商家后台页面改版。

出现的问题

• 出现大量有规律的性能低的关联查询sql
• 出现个别查地区商情的性能低的sql
• 数据库负载比正常情况高，平时是2以下，上线后在3-5之间，有过7的高峰

问题解决

• 关联查询的sql是在查询的数据和转换的结果对象不一致的时候，由JPA底层数据补全机制产生，不影响正常功能，也不会抛异常，就是产生的sql会有差异，该规律已经证实并且安排开发同事做相应修改。
• 个别地区商情的性能低的sql已经优化，不再影响性能。

开发总结

• 要加强对JPA底层机制的理解和认识，核心业务尽快补全单元测试，以便后续修改能第一时间发现性能上的差异。
• 加强核心表、核心业务、性能相关变动的敏感度，涉及的功能、接口需要整理清楚。
• 加强监控和调试的能力，尽早从数据库sql监控+线程监控定位到问题入口，并在开发环境的应用设置sql打印输出，重现问题并调试。

DBA总结

• 提供数据库的压力等级，以便开发、协调、项目管理人员判断以及决策，以pg数据库为例，多核服务器以核数为紧急分界线，例如16核服务器在负载16以下为数据库可承受程度，高于此标准需要立即采取措施，包括屏蔽相关功能、回滚等，当然低于此标准也要根据时间规律做提前流量高峰的预估，不等于百分之百安全。
• 中大型系统上线后，不管有无问题，应该持续监测数据库负载、慢sql等，建议1-2个小时左右，例如这次的上线，如果提前进行的，没有碰到各页面发布高峰调用接口频繁的话，不一定在现场马上发现问题。

QA总结

• 对复杂系统上线的风险意识不够，在测试阶段有些出现不频繁的性能问题没有追查到底。
• 测试数据实时性不够，压接口的时候，有些接口没有数据会隐藏一些问题，建议以后在最后回归测试的时候重新拿线上当天数据来测试。
• 复杂系统测试需要和开发确认影响范围，对核心表、核心业务的变更，需要覆盖更大的测试范围。

项目、协调总结

• 影响大的系统，例如商城、产品报价库等，如果在上线过程中遇到问题，在达到回滚警戒时间点时，如果仍然没有头绪，或者虽然有头绪但是对系统有非常严重的影响并且解决时间比较长的情况下，要坚决尽早回滚。
• 由上一条引申出，上线的回滚计划和措施要认真准备，并提前做回滚测试，否则回滚也会带来不可预知的风险，在真正需要回滚的时候雪上加霜。
• 在处理故障的过程里，考虑采用各种临时替代措施争取时间，例如降级服务、屏蔽不重要的影响大的功能、静态页面替换、简单逻辑功能替换负载逻辑功能等等。
• 整理好项目对外的各种影响，在上线时分类检查和采取降级处理时提供依据，例如对外提供的接口应用在哪些页面、栏目、应用等等。