远程办公第一天，钉钉崩了。我盯着屏幕上那个转不出来的群聊界面，第一反应居然是打开Fiddler抓包——这他妈是病，得治。
团队微信群里已经炸了，二十几个人的小公司，消息刷得比双十一还快。产品助理在问需求文档该传哪儿，前端小哥抱怨VPN连不上测试环境，最要命的是那个刚入职两个月的运营，直接在群里@我：“老板，今天的工作日报还要写吗？”我手指悬在键盘上三秒钟，最后回了句“用石墨文档先顶着”，然后切出去看自己服务器的监控面板。CPU占用率从平时的15%飙到87%，内存使用量像坐火箭，那几条代表API请求的折线已经快冲破图表顶端了。去年为了省钱选的2核4G轻量应用服务器，现在像个喘不过气的肺病患者。
其实去年做这个内部协作系统的时候，我就知道架构有问题。为了赶交付周期，所有服务都塞在同一个Docker容器里，MySQL和Redis共用一台机器，连负载均衡都没做。当时想的是“反正就三十个人用，先跑起来再说”。现在好了，三十个人同时在线，系统就开始抖了。最讽刺的是，我上周还在给客户吹嘘我们的SaaS方案能支撑千人并发，用的还是那套“微服务+弹性伸缩”的PPT模板。
抓包数据出来了，钉钉的API响应时间从平时的200ms飙升到12秒，然后直接返回502。我盯着那个HTTP状态码，突然想起去年双十一我们自己的电商项目崩掉的场景。一模一样的问题：数据库连接池耗尽。当时为了快速修复，我临时写了个脚本，把非核心业务的查询全部降级到从库，还加了层本地缓存。但那是预案，是提前演练过的。今天这种全国级别的流量洪峰，根本不在任何人的设计范围内。
团队群里开始有人发段子了，说阿里云的技术也不过如此。我没笑。我在想我们那个破系统，如果真遇到今天这种级别的并发，能撑几分钟。可能连五分钟都撑不到——用户登录那块用的是JWT令牌，但令牌刷新机制有个bug，高并发下会出现重复签发，去年测出来的时候我觉得“概率太低没必要修”。
下午三点，钉钉恢复了。群里安静下来，大家开始默默传文件、拉视频会议。我打开终端，SSH连上服务器，把Nginx的access日志拖下来分析。今天上午的UV比平时高了八倍，但PV只涨了三倍——说明很多人刷不进去就放弃了。最要命的几个接口：文件上传、实时消息推送、在线编辑锁。这三个功能去年都是我亲手写的，为了省事，文件上传直接用了同步阻塞，消息推送靠轮询，编辑锁更离谱，居然是用MySQL的行锁实现的。
我点了根烟（虽然去年就说要戒），在本地环境开了三个终端窗口。一个跑ab压测文件上传接口，一个模拟五十个用户同时抢编辑锁，另一个盯着服务器资源。不出所料，压到第三轮的时候，MySQL的CPU就100%了，锁竞争直接导致整个数据库僵住。那个瞬间我后背有点发凉——如果今天崩的是我们的系统，客户可不会像我们调侃钉钉这样调侃我们。他们会直接解约，然后在朋友圈骂我们是骗子。
晚上八点，我把技术负责人拉了个语音。没骂人，就说了三件事：第一，下周开始所有核心接口必须加熔断和降级，用Hystrix先顶上；第二，文件存储切到OSS，不能再放本地磁盘；第三，重新评估服务器配置，该升配就升配，别省那点钱。他沉默了几秒，说“老板，这得加预算”。我说加，从我的分红里扣。
挂了电话，我打开石墨文档，开始写今天的工作日报。写到最后一行的时候，我加了句备注：“今天钉钉崩了，但我们自己的系统没崩——不是因为我们技术好，只是因为我们运气好，用户量还不够大。”写完这句，我把它删了，换成：“技术债偿还计划启动时间：2020年2月11日。”
窗外的城市比平时安静很多，但互联网的世界比任何时候都吵。
