劫后回望——一次系统崩溃的复盘

11月11日23:30左右系统奔溃，12日16:30系统恢复。下周进行商业谈判合同签订。

---

• 现象：

  • 客户视角：打开首页，地图上无法显示一些业务信息，相关联的部分数据会出现无法显示，系统大面积瘫痪。
  • 开发视角：定位到一个接口，调用时间过长，504请求超时或502nginx错误，重启无法解决问题。
  • 运维视角：mysql的cup占用率高达700%。

• 分析：

  • 发起接口请求，服务器响应超时，定位在后端接口的查询效率过低
  • 第一时间的想法是某几个sql的问题，开始在开发环境对sql的查询做优化，由于是一个报表统计类的接口，需求的频繁变更，增量式的开发，导致一个接口的调用查询语句近百余条。添加索引，减少表联查次数，控制数据量较大表的查询条件。将效率提升了60%，但任耗时5.7s。投放生产环境接口请求依然超时。
  • 为什么开发环境请求5.7s的接口，投放生产环境却请求超时呢？带着这个大问号，把目光投向数据库，将生产库数据下放到开发库中，调用接口需要800s，可以谓之灾难级的响应速度。
  • 经过几个800s，将几个耗时较长的查询摘出来，这些语句每一次平均查询时长在90s左右，都指向了两张表，于是对两张表的数据进行了查询，发现从系统奔溃起11日数据增长为20w，12日竟达300w，致使查询效率低下，接口响应变得很慢。
  • 找到源头：因业务扩张，增加部署了四个子系统，代码从主系统而来，共用同一个数据库，其中的两个系统的一个定时任务没有关闭，导致原本每天3W条数据的表，17小时增长320w。

• 反思:

  • 作为接口的开发者，对业务实时明白清晰，将上个版本无用的代码及时注掉。事实上本次事故的代码确实是上版本的产物，没有及时注释导致事故。
  • 高内聚，低耦合，对业务进行解耦，一个接口，调用查询太多次，很不安全。
  • 代码完成后，要注重质量，反复打磨逻辑，给出更优实现，这一点尤为总要。
  • 测试的重要性。压力测试！由于业务变更过快，导致测试人员无法跟进项目，只能是开发人员自研自测。但人都是不可靠的。。。

• 管理:

  • 项目大半年，一直处于自主研发，时间紧，任务重，迭代过快，很多环节的缺失。
    • 重新审视项目流程，需求收集，需求转移，开发任务下发，代码把关，测试(测试环境–>预生产环境–>生产环境)，版本迭代。
  • 面对紧急状况的预案，以此次事故为例
    • 做好快照式的回退(规避问题)
    • 加强发现问题，解决问题的效率(解决问题)

---

一次事故，一次深度的反思，发现自己的问题，减少失误，凡事预则立，不预则废。25岁生日的经历，写给自己。