中国最危险的程序员工种

本文来自微信公众号： 碳基智 ，作者：碳基智

1

我的好朋友，前阿里P9，架构师华仔老师曾经对负责稳定性的程序员兄弟们做过一番评述，生动地描绘了他们长久以来所面临的窘境，他化用了扁鹊三兄弟的典故解释了这个问题。

这里面存在一个“神医悖论”，魏文侯问扁鹊三兄弟中谁的医术最高明。扁鹊回答说：“长兄最善，中兄次之，扁鹊最为下。”扁鹊医术精湛，神医名声远播，为什么扁鹊却认为大哥二哥比他强呢？

扁鹊解释说：大哥治病于病发之前，一般人不知道他事先除去了病因，故而他的名气无法传出去；二哥治病于病情初发之时，一般人以为他只能治轻微小病，故而他的名气只及本乡里；而扁鹊治病于病情严重之时，所以他们认为扁鹊的医术最高明。

在建设高可用系统的时候，一样会遇到“神医悖论”。不管公司是有专门的SRE团队，还是各个团队的直接负责系统高可用；也不管公司是为了可用性做了很多基础系统，还是各个团队靠人力来保障可用性，都会面临这个问题：

你怎么证明你的可用性做得好？你的可用性投入是有很大价值的？

2

前一阵有在大厂做稳定性模块负责人的老哥跟我吃饭，席间吐槽聊到了最近公司要裁员，他必须解决掉至少2-3个人员指标。

他很为难，因为本来稳定性相关的人手已经捉襟见肘，还给他干掉2-3个人这平台还要不要了，出事了最后不还是他背锅，现阶段的AI别说给他替代部分工作，就是别把本来就风雨飘摇的稳定性指标搞崩都不错了。

他咬着牙跟我说：

靠！我都想把那几个能力强的干掉，然后让整个平台都崩掉，我再带着他们去创业好了！

我呵呵笑了，一般这么说的人都只是口嗨，过重的职业道德包袱之下，根本做不出这种事来。

降本增笑的逻辑之下，每个负责稳定性的程序员都是帝国的糊裱匠。

3

我的另一位朋友，B站的毛剑老师，在稳定性这个圈子里已经成为了一种另类的图腾。

比如前两年网易云音乐宕机之后，立马有人翻出来该团队不久前所做的机房迁移方案，一通转发给人搞得人尽皆知。

于是我写了篇文章说，此情此景，毛老师可能打了个喷嚏。毛老师转发了这篇文章说，勿cue。

稳定性建设是一个不得不去做，却又很难说做得有多好的事情。但技术团队费了那么大的精力去做这个事，得让老板们知道背后的工作价值，于是写了一篇技术方案的总结文章。然后出事故了，被挖出来嘲讽，草台班子再添一员。

心理苦啊。

4

如果要去总结稳定性程序员的困境，我甚至可以罗列出9层：

1干得越好，绩效越难写

业务程序员靠制造变化获得功劳，稳定性程序员靠阻止变化失控证明价值。问题是，失控被阻止以后，功劳也一起消失了。

2责任无限，权限有限

典型的权责倒挂，业务团队获得快速上线的局部收益，但潜在故障成本被转移给稳定性、客服、运营和值班人员。

3永远困在救火-没时间做稳定性改造-继续救火的循环里

大厂嘴上招的是稳定性工程师，实际使用方式却像一支永远在线的技术物业。

4自动化越成功，剩下的事故越变态

自动化本身就存在一个经典悖论，当日常、简单、重复的问题被机器处理以后，人类要接管的往往都是那些没接住可以直接跑路的P0事故。

5值班不只消耗时间，还有持续性的警觉

墨菲定律有言，如果有可能发生事故，事故就一定会发生。但如果程序员始终处在睡觉不敢静音，下班不敢不带电脑，洗澡还要拿着手机的状态里，最终都是对人的持续性消耗。

6复盘号称无责，实际经常开成批斗大会

无责复盘往往只是开场白，就像一句体制内的原则上同意一样，你知道什么意思。当事故复盘与绩效处罚绑定以后，复盘的目标就不再是寻找系统崩溃的真相，而是找到一个能背锅的小可爱。

7懂得很多，简历却不好写

优秀的稳定性工程师啥都要懂，网络、数据库、操作系统、分布式系统、中间件……但写简历的时候，却很难精准地向用人市场展示出自己的价值。

8经常吃力不讨好，被业务团队厌恶

稳定性团队要搞好稳定性，就要收敛权限，要增加管控，要搞压测，要暂缓上线……业务团队往往认为其存在对自己是一种卡点。但，一旦放行，事故要负责；不放行，又会被diss。

9 AI正在把稳定性工程师变成屎山管理员

上游借助AI一天可以生成过去一周的代码量，下游仍要靠人类逐行审查、建立监控、处理依赖和承担线上后果。

写代码的人提效了，审代码的人拥堵了，处理事故的人加班了。

你说他们苦不苦。