大家好，我是 Sunday。
前天我刚在公众号发了一篇文章：一个月，我们积累了两万多的用户...，并且对整个简历汪都进行了大幅度更新。
本以为这次更新会是一次“顺利的迭代”。没想到，第二天就变成了一次真实的“灾难演练” 了😭
昨天一天服务器被打崩了 两次！两次啊！ 内存最高飙到 93.73% ，直接把服务器给干崩了。。。。
这事一想，还真是挺戏剧性的
- 前天：我很开心地说“我们更新了模板，性能更好了”
- 昨天：我很紧张地看 “怎么内存炸了..”
- 今天：我很冷静地坐下来写这篇文章，告诉你这事儿到底怎么发生的、怎么排查、怎么防、为什么这种事情其实是产品长大的必经阶段
那么下面，我就按 时间线+技术拆解+产品视角，完整讲一遍。
1. 先说时间线
昨天的异常不是那种“全天有点慢”，而是两个时间点突然拉满：
第一次爆炸：上午 10:00 左右
告警来了，说内存异常上升。
我打开阿里云控制台看，进程还活着，但内存曲线是陡的，访问在短时间内集中到某几个接口，并且因为内存满了导致服务器卡死，所以的请求全部中断，并且 没有办法链接服务器
第二次爆炸：下午 15:00 左右
看板显示：CPU 18.644%，内存 93.73%。
CPU 没啥问题，就是 内存 再次炸了
那张图就是这次的“犯罪现场”
2. 为什么怀疑是被攻击了
如果是正常用户暴增，一般会有这么几个特征：
- UA 会比较多样（Chrome、Safari、移动端一堆）
- 请求路径会分散（首页、模板列表、编辑页、下载页都有）
- 峰值一般是业务高峰期（中午、晚上、发文后）
但我昨天看到的情况比较反常，更像是“脚本式访问”：
- 请求路径集中出现在耗资源的接口上（比如 PDF 生成、简历下载这类）
- UA 信息比较一致
时间点是两个 突刺，而不是半天慢慢涨，类似于下图，大家做个参考
服务器 CPU 不高，内存高，这说明不是大量计算，而是大量“需要在内存里做事”的请求
这就引出了这次事件最关键的一点：
真正能打爆你服务器的，往往不是首页，也不是普通的 JSON 接口，而是你自己写的、最耗资源的那个功能。
在简历汪这里，就是 PDF 生成。
3. 为什么 PDF 生成这么“脆弱”？
来，我们讲点技术的。
正常一个前端接口，比如：获取简历列表 /api/resume/list，它的整个调用链大概是：
- 验证权限
- 查询 MongoDB
- 做一点字段裁剪
- 返回 JSON
这里面的任何一步都不怎么耗内存，就是纯 I/O + 一点点 CPU。
但 PDF 不一样，PDF 背后是：
- 渲染简历 HTML
- 加载字体文件
- 使用 Puppeteer 打开一个无头浏览器页面
- 在这个页面里渲染刚才的 HTML
- 再把这个页面导出 PDF
- 再把生成的二进制转成流或文件
- 再返回给用户
这个流程里面有两个字最可怕：“并发”。
做一份 PDF，没问题、做十份 PDF，CPU 高一点还能忍、做一百份 PDF，同时做，还都在生成阶段。那么低内存的服务器就会直接炸了
那么这次的现象（CPU 不高，内存93%）就是典型的瞬时高内存任务堆积导致的问题。
4. 我采取了哪些应急策略
1. 先保活
简单来说，就是 用你能想到最快的方式，让服务器运行起来。
因为，服务直接链接不上，所以最好的方式就是 直接强制重启服务器
2. 在诊断
服务器重新活了之后，就需要复盘问题，看看到底是咋回事了。
这里一定要注意 关注日志，特别是 应用日志（NestJS Logger） 看看当前的请求是一个 IP 发起的，还是大量 IP 发起的。是一个接口被打了，还是多个接口都被打了。
从而找出问题可能出现的原因
3. 最后做一些加固工作
加固工作分为两部分：
- 软件加固
- 硬件升级
软件加固
软件加固主要是两部分：
- 限制应用内存占用上限
- 限制 mongoDB 内存占用上限
硬件升级
这个就简单了，服务器直接升级内存就可以的。。。 又花了几百大洋。。。
5. 最后的一点思考
其实这次事件，让我重新理解了“上线”这个词。
以前的我觉得上线是一件开心的事：代表产品进步、功能更新、体验更好了。
但现在我觉得：上线代表着你的应用会真正的暴露在公网下，从而带来很多挑战。
它不是说你可以跑起来就完的，而是要可以撑得住各种意料之外的情况。
比如：
- 在资金不够的情况下，如何尽量的榨取服务器的性能，但是又不能让它崩了
- 一些被攻击出现的时候，如何可以及时发现，并且让应用保活
目前简历汪已经有了两万多用户，日活也可以达到 1000 左右，我们也收到了很多用户的感谢
希望简历汪可以帮到更多的同学，完成自己的简历，最终拿到满意的 offer！
