既不是前端、客户端，也不是后端，而是那群扛着稳定性大旗的兄弟。
1.
我的好友，前阿里 P9 架构师华仔曾聊起过稳定性工程师们长久以来的窘境，他用扁鹊三兄弟的典故打了个比方。
这里其实藏着一个“神医悖论”。魏文侯问扁鹊，三兄弟中哪位医术最高明？扁鹊答：“大哥最好，二哥次之，我最差。”明明扁鹊是远近闻名的神医，为何却这样评价？
扁鹊解释说：大哥在病情发作前就铲除了病因，旁人看不出，名气传不出去；二哥在病症初起时便下手，别人以为他只会治小毛病，名声局限在乡里；而他自己专治重病危候，旁人眼见他在生死边缘妙手回春，便认定他医术最高明。
这跟高可用系统建设简直如出一辙。不论公司是设有专门的 SRE 团队，还是让各个业务团队自行兜底高可用；也不论是靠着自研平台提高可用性，还是纯靠人力堆砌保障，都逃不开一个灵魂拷问：
到底怎么证明你的可用性做得够好？你为可用性投入的价值究竟有多大？
2.
前阵子，一位大厂负责稳定性模块的老哥约我吃饭，席间大倒苦水：公司最近要裁员，他必须亲手“优化”掉两三个人头。
这让他左右为难。本来稳定性这边人手就捉襟见肘，再砍掉两三个，这平台还怎么扛？一旦出事，锅最后还是要他来背。至于现阶段的 AI，别说帮他省人力，别再让本就风雨飘摇的稳定性指标雪上加霜就谢天谢地了。
他咬着牙蹦出一句：
“靠！我真想把那几个能力最强的干掉，让整个平台全崩了，然后带着他们出去单干！”
我听完呵呵一笑。一般这么说的，都是嘴上刚烈，职业道德包袱压得死死的，根本干不出来。
在“降本增笑”的逻辑下，每一个负责稳定性的程序员，都是帝国的糊裱匠。
3.
另一位朋友——B 站的毛剑老师，在稳定性圈子里几乎成了某种另类的图腾。
前两年网易云音乐宕机之后，马上就有人扒出他们团队不久前做的机房迁移方案，一通转发搞得人尽皆知。
我当时写了篇文章调侃说，此情此景，毛老师大概打了个喷嚏。毛老师转发了那篇文章，只回了四个字：勿 cue。
稳定性建设是一件必须做，却极难说清到底有多好的事情。技术团队费大把精力搞稳定性，总得让老板们看到工作价值吧？于是精心整理一篇技术方案总结。然后事故一来，就被挖出来群嘲，草台班子里再添一员。
心里真苦啊。
4.
如果试着去总结稳定性程序员的困境，我甚至能列出九层：
1 干得越好，绩效越难写
业务程序员靠制造变化来赢得功劳，稳定性程序员靠阻止变化失控来证明价值。问题是，失控一旦被成功阻止，功劳似乎也跟着一起蒸发了。
2 责任无限，权限有限
典型的权责倒挂。业务团队享受快速上线的局部收益，潜在故障成本却转嫁给了稳定性、客服、运营和值班人员。
3 永远困在“救火→没时间做稳定性改造→继续救火”的死循环里
大厂嘴上招的是稳定性工程师，实际使用方式却像一支永远在线的“技术物业”。
4 自动化越成功，剩下的事故越变态
自动化本身就有个经典悖论：当日常、简单、重复的故障都被机器接管处理以后，留给人类收拾的，往往都是那些一旦没接住就可以直接跑路的 P0 级灾难。
5 值班不止消耗时间，还有持续性的警觉
墨菲定律说，只要有概率发生事故，事故就一定会发生。但如果一个程序员长期处在睡觉不敢静音、下班不敢不带电脑、洗澡都得攥着手机的状态里，最终消耗的是人的精神持续性。
6 复盘号称无责，实际常开成批斗大会
“无责复盘”很多时候只是个开场白，就像一句体制内“原则上同意”——你懂的。当事故复盘跟绩效处罚绑定以后，复盘的目标就不再是找系统崩溃的真相，而是找到那个能背锅的小可爱。
7 懂得很多，简历却不好写
优秀的稳定性工程师什么都要懂：网络、数据库、操作系统、分布式系统、中间件……可写简历时，却很难精准地向用人市场展示自己的价值。
8 经常吃力不讨好，被业务团队嫌弃
稳定性团队要搞好可用性，就得收权限、加管控、上压测、暂缓上线……业务团队常觉得他们就是个卡点。可是，一旦放行出了事，稳定性要负责；死卡着不放，又要被 diss。
9 AI 正在把稳定性工程师变成“屎山管理员”
上游借助 AI 一天能生成过去一周的代码量，下游却还得靠人类逐行审查、建立监控、处理依赖，并承担上线后的全部后果。
写代码的人提效了，审代码的人拥堵了，处理事故的人加班了。
你说他们苦不苦？
如果你也有类似的体会，不妨来云栈社区和众多稳定性工程师一起聊聊。
发表于 昨天 22:27
|
查看: 4|
回复: 0
