无障碍创业三难破局：用自动化运维提效降本

　　去年九月，凌晨三点十七分，我盯着屏幕右下角那个跳动的“12:17”发呆——其实早该是凌晨了，但服务器时区没调，我一直懒得改。客服工单弹出来第三条，说用户点“立即创业”按钮后，页面卡在加载动画不动，后台日志里连个错误码都不报，就干干净净一条空行。

　　我原以为是前端 JS 阻塞，结果查 Chrome DevTools 里 network 标签页，发现 POST /api/v1/startup 请求压根没发出去；再切到 console，看到一行灰字：“Uncaught ReferenceError: initLaunch is not defined”，可这函数明明上个月就删了，删的时候还跟前端小张当面确认过，他说“老逻辑彻底下线了”。

　　小张当时靠在门框上啃苹果，咔嚓咬一口说：“你删的那是 demo 环境里的，正式环境 deploy 脚本里 copy-paste 漏了一行，我自己也没注意。”——他手里苹果核还滴着水，掉在运维组新换的灰色地毯上，洇开一小片深色圆点（地毯上周刚换，厂商标签还没撕）。

　　我重新拉 release 分支，改 deploy.sh 第八次，加了个 pre-check 判断 initLaunch 是否存在，存在就 exit 1。跑完 CI，绿灯亮了，我松口气，点了上线。结果二十来分钟之后，首页 502 率从 0% 直冲到 37%，监控图上那根红线像被人狠狠往上拽了一把。我抓起电话打给 CDN 厂商，对方说“你们源站健康检查失败”，我翻 openresty access.log，里面全是 502，但 upstream 日志里却没记录任何请求——就像你推一扇门，门开了，人却没进去。

　　（那天早上保洁阿姨来拖过地，水桶在机柜旁放了半小时，插线板底下有潮气，我后来才发现，但和这次 502 没关系。）

　　最后查到是负载均衡器里 health check path 写错了，指向了一个已废弃的 /healthz-v1，而 v1 这个路径，早在半年前就被 Nginx 的 location 块用 return 410 永久删掉了。厂商配置模板里硬编码着这个路径，我们每次部署都自动继承——没人去碰它，因为“从来没出过事”。

文章配图，仅供参考

　　后来我们把 health check 改成 /ping，加了个 curl -f 的超时判断，又在自动化部署脚本里插了两行：先 check path 是否 200，不通过就中止。上线第七次，绿了。当天下午，CEO 在群里发了个红包，标题叫“无障碍创业三难破局”，配文是“技术要让普通人敢点那个按钮”。我点开领了，两块三毛。

　　反正这事让我看清一点：所谓“优胜劣汰”，不是谁代码写得漂亮，是谁能先发现那个根本没人看一眼的 /healthz-v1，是小张啃苹果时漏掉的那一行 deploy 脚本，是我自己明明记得删过 initLaunch，却忘了它还在另一个地方被 import 过三次——三次都是不同的人写的，三个 commit 时间差了四十七天。

　　有谁碰到过这个吗？health check 用 return 410 的时候，下游设备真会把它当健康异常吗？我看了三份文档，两份说“只要不是 5xx 就行”，一份没提，第四份……第四份我找不到了。

（编辑：航空爱好网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!