三年架构设计：从0到10亿的运维实战 Growth Roadmap

　　去年11月份，凌晨三点十七分，我盯着监控面板上那条突然塌陷的 Redis 连接数曲线，手没抖，但右耳后根那块肉自己跳了两下——就那种你刚被蚊子叮完、又不确定是不是错觉的弹跳。

　　客服系统炸了，不是报警，是彻底静音：所有工单进不来，前端返回的全是 502。我们仨在运维室，老张蹲在地上用笔记本垫着敲命令，小陈把耳机线缠在手指上绕了六圈，我捏着热茶杯，杯底一圈水渍慢慢晕开，像没关紧的阀门在漏。

　　我原以为是上游服务挂了，查了负载、查了日志、查了 Pod 状态，全绿。直到小陈把 nginx error log 拖到最底下，第七行写着：“upstream timed out (110: Connection timed out) while connecting to upstream”，而 upstream 指向的那个 IP，是我们上个月刚切过去的、新买的第三方风控插件服务地址。

　　老张说：“他们 SDK 里写了‘默认重试三次’。”
我说：“可我们没配 timeout，它卡死在第三次连接超时前，就不往下走了。”
他顿了顿，抬头看我：“……他们文档第二页，加粗写的‘必须设置 connect_timeout ≤ 3s’。”

　　我没回。
因为就在三小时前，甲方技术总监在群里甩了一句话：“你们那个‘架构演进路线图’PPT第17页，说‘高可用靠冗余’，可现在连个风控都扛不住，还谈什么演进？”

　　我们其实没用他们 SDK 的默认配置——改过，改成 5 秒。但忘了同步改他们那个隐蔽得要命的环境变量：REDIS_TIMEOUT_FALLBACK。它不走 configmap，硬编码在他们 Java agent 里，启动时读 /etc/agent/conf.yaml，而那个 yaml 文件，是我们部署时自动生成的，生成逻辑写在 ansible playbook 第八次迭代版本里，和当前线上版本差了两个 patch。没人记得这事。包括我。

　　热咖啡早凉透了。我把它搁回桌上时碰倒了半盒回形针，哗啦一声，散在键盘缝隙里，有三枚卡进了空格键下面——我伸手抠的时候，指甲盖刮到金属边，有点疼，但没出血。

　　小陈这时候念了一句原文，是他们接口文档里的一段小字：“当 FALLBACK 超时未生效时，降级策略将退化为直连主库。”
我就愣住了。
主库？哪个主库？我们根本没有连他们主库的权限。我们只开了 Redis 白名单。
我打开他们的部署拓扑图 PDF（本地缓存的 v2.3 版本），翻到附录 C，发现那个“主库”其实是他们测试环境的一个 MySQL 实例，IP 段根本不在我们 VPC 内。但他们的 agent，在 fallback 失效时，居然会尝试解析一个硬写死的域名——risk-core-dev.internal，而那个域名，上周被他们运维手动加进了我们集群的 CoreDNS 的 stubDomains 列表，理由是“方便调试”。

　　我也不知道该先骂谁。
反正老张已经 SSH 进 DNS 服务器，删了那行 stubDomains 配置；小陈在 reload nginx 之前，先 curl 了十次那个风控接口，确认响应时间回到 86ms；而我，盯着屏幕上刚跑出来的 traceroute 结果，第九跳停在了 10.24.7.112——那是我们核心网关节点，也是昨天刚升级过的那个内核补丁版本（5.10.197-rc1）所在机器。

　　哦对，那天中午食堂土豆烧牛肉里有片没削净的皮，嚼起来沙沙的，我吐了两次，第三次没吐出来。
还有，我工牌挂绳断过一次，是夏天的事，用透明胶粘过，现在一弯脖子还能看见胶痕反光。

　　最后那个 502 消了。不是因为我们改了什么，是因为风控插件那边半夜自动滚动更新了 agent，新包里删掉了 FALLBACK 逻辑，改成了兜底熔断。他们没发通告，没留日志开关，就默默上线了——就像上次他们把 metrics 端口从 9100 改成 9101 时一样安静。

文章配图，仅供参考

　　三年架构设计：从0到10亿的运维实战 Growth Roadmap？
它站得住的地方，确实是优胜劣汰。
但我不确定被淘汰的，到底是那个没配对的 timeout，还是我们还信“文档能跟上代码”的人。

　　有谁碰到过这个吗？

（编辑：航空爱好网）

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