最近阿里云一位年轻的员工发出了一封公开信，挑战上司在团队内部的绩效分配，认为其严重不公平。有兴趣的朋友可以搜一下一个《阿里云陆逸被中亭团伙打压情况说明.pdf》，但是信件本身的标题是《一封来自底层员工的情况说明信》，收信人是“尊敬的阿里云的各位领导们、调查组的同学们“。

这个事本身是非对错，外人很难判断。作为云计算用户，我更感兴趣的是信件中透露的阿里云研发实践。公开信透露了不少很有说服力的细节，可以让我们大概了解阿里云的研发运作模式。

不对产品投入工程师

这位年轻人在信中说：

同时我又参与了 RUM前端监控项目，在我刚刚接手前端监控产品的时候，前端监控是一个千疮百孔充满技术债的项目，前端监控的上一任后端负责人零蛋早就在几年前就离开阿里加入了网易，在这几年时间内，前端监控产品根本没有后端的 Owner。

我之前听说阿里云不少复杂的产品，其实就几个小年轻带着外包团队在干活。这位年轻人提供的案例，就把这个现象揭示得更彻底：这次连个小年轻都没有，而且持续好几年。

这里需要对不熟悉云计算的朋友解释一下，虽然产品名叫前端监控，但是所有的数据存储和展示都发生在后端，类似微信虽然是一个 App，但是大部分数据都在后端处理。

依照年轻人的叙述，即使他本人也不是100%投入到后端，所以后端从头到尾连一个人力都没有投入过。

云厂商一直主张专业化分工，比如前几天阿里云首席架构师韩鸿源先生说：

真正能把裸资源更好地运行起来，是需要一个非常有实力的团队，这样的团队在一些较小规模的公司里是不太可行的。

韩先生说得很有道理，但是联系实际的话，如果一个团队的一个员工跳槽到网易，owner 就常年缺失，恐怕很难自称“非常有实力”。我不知道 ARMS 的几个客户是怎么看待这个内情的，搞得不好，他们团队自己都能安排出更多的后端工程师。

工程师和行业前沿脱节

这位年轻人在信中提出，他和一些同事“引领业界 OpenRUM 标准”。笔者没有听说过这个标准，以为是和 OpenTelemetry 一样的业界正在探索的新标准。

实际上，OpenRUM 只能算是腾讯阿里博睿数据三家公司的一个有益的失败尝试。项目的 GitHub 主页连README 都没写完，原定的月例会只在 2022 年 9 月开过一次，4 个 Contributors 制定的协议也是乱七八糟的。

这里我不是在指责年轻人的工作不够好，毕竟他刚毕业两年，一开始就不可能肩负“引领业界标准”的重任。我只是有点悲哀的发现：阿里云这个在技术上非常自负的年轻人，技术眼界如此之低，以至于把 OpenRUM 当成了业界标准。

我这里粗暴的猜测，阿里云从来没有把他这样的高潜年轻人送去 KubeCon 或者其他行业会议参加国际水准的技术交流。年轻人被隔离在行业动态之外会让他产生很多误解，比如他称呼DataDog 为“行业巨头”，这个称号应该说是不太准确的。DataDog 虽然成立于2010 年，但是这几年才成为行业有重要影响力的选手，业界一般把 DataDog 看作监控领域里高速增长的挑战者。

无效的加班文化

年轻人很动情的说：

作为一个已经拿到正式 offer 的实习生，我每天 9点左右来到公司，几乎每天是组里面的第一个到的同学，晚上每天要加班工作到 9点左右，周末基本也都会来公司学习和工作，几乎是 997的作息。

作为工程师，笔者看到这一段之后非常不舒服。我有朋友开了个印刷厂，买了一台几百万的印刷机器，都会定时停机检修机器。而我们阿里云的工程师把自己当成永动机，997 的卷。这是不人道而且没必要的。

笔者在瑞典一家前沿互联网公司工作的时候，有同事找 HR 投诉说一些发展中国家来的同事工作时间太长，深夜还在提交代码，让他感到很有压力。HR 积极干预，杜绝了此类现象。HR 并不是在做善事，从公司角度看，长时间工作的工程师，产出质量不可控，也影响了团队的整体效率。

尤其让我不舒服的是，年轻人刚毕业两年，就已经开始暗中观察同事的加班记录并且记了笔私账：

据我观察，我们老ARMS的同学工作时长要远高于中亭嫡系如穹谷和铭少，他们一般晚上吃完晚饭就不见了，而像玄裕基本每天要工作到每天晚上十点以后，嘉川都要工作到晚上九点二十左右

我看不出这种比较有任何意义。软件开发确实有体力劳动的成分，但是主要是一种脑力劳动。基础软件开发对智力含量要求更高。而绝大多数脑力劳动者的有效工作时间，一天顶多两三个小时。每天从早上九点工作到晚上十点以后的那种人，说句难听的，更适合去富士康郭台铭的流水线上拧螺丝。

我们可以看一下业界最优秀的基础软件发明者。发明 SkyWalking 的吴晟经常泡在微信群里跟人闲聊，发明 Vue 的尤雨溪经常在推特上跟人撕逼。用我们工程师经常说的一句话来说，懒惰是发明之母^[1]。正是因为懒到不想做无聊的重复劳动，所以才发明新技术让工作更高效更有趣。

华为算是中国最能加班的公司了，但是任正非先生也主张华为的研发员工要多喝咖啡：

世界IT行业最发达的地区在美国，在持续引入高端专家的同时，我们的高级干部和专家也要冲破局限，每年走出去和世界交流，不要像中国老农民一样，只知道埋头苦干，要善于用一杯咖啡吸收宇宙能量。我们经常参加各种国际会议和论坛，杯子一碰，只要5分钟，就可能会擦出火花，吸收很多“能量”。你们一天不改变你们的思维习惯，就不可能接触世界，不接触世界怎么知道世界是什么样子的，有时候一句话两句话就足以道破天机，擦出思想的火花。

——《风物长宜放眼量——任正非在华为成都研究所业务汇报会上的讲话》，2014年1月5日

如果一个团队沉迷于 997，以加班时间长为荣，以加班时间短为耻，很难相信这个团队会有任何创新的动力。这种团队甚至可能会无中生有创造出一些不必要的工作以有班可加从而感动自己感动领导。但是他们的实际产出，是 OpenRUM 那种玩意，水准相当于湖南省耒阳市仁义乡湾头村五组花鼓戏团的花鼓戏水准。

一个本来对技术有信仰的年轻人，被塑造出这么一个思维，非常可惜。

具体到云计算，大多数云计算用户非常讨厌重复工作。AWS 中国的 Daniel Wellington 客户成功案例^[2]说得非常好：

每逢电商大促季，在中国，我们熟悉的场景都是全员通宵奋战。而在DW，就可以晚上只安排少量的运维人员值班，而由另一时区的运维团队代劳。如果有系统异常，直接进入相关区域的账号进行第一轮检查和处理以及紧急修复操作。若需要，才会联系当地人员一起进行第二轮的问题修复。这样的替补机制，能让运维人员以正常的作息时间应对24小时不停的在线业务。

希望阿里云的朋友们能够意识到：工程师少量加班不可避免，但是长期加班不仅不道德，而且反映了团队技术水准差，无法自动化。最好的状况是：由于云厂商发明的新技术，让甲方吃着火锅就把双十一给过了。云厂商赚的钱，应该是出卖脑力获取的高科技溢价，而不是出卖体力和健康的 997 血汗钱。

业余水准的产品管理

这位年轻人还提到一点：

商业化逻辑改造，我对这个项目也是尽心尽力去干，但是这个项目需求总是一变再变，每次做了很多的东西，过了两种都需要推倒重来，但是我还是坚持用心去做。但是这个商业化产品的商业化改造，至少十几个人做过，其中的逻辑之复杂，没有几个人能搞的明白，随便一改，就可能引发线上计费 Bug，至少导致 ARMS产品 GAAP几十万的资损。同时中亭等人对我开始进行压迫，每次商业化一出现问题就开始责难我

定价和计费，是一个非常专业的领域。在华为的运营商产品线，有专门的部门负责定价。业界有专门的 Pricing Professionals，和 Supply Chain Professionals 一样，都是非常专业的岗位。即使阿里云缺乏这种专业人士，也应该让那些混了多年江湖的产品经理去主导 Pricing。没有商业经验的工程师去主导 Pricing，类似让步兵直接开坦克，100% 会失败。

年轻人说“至少十几个人做过”并且“没有几个人能搞得明白”，并不是因为“需求总是一变再变”，而是因为没有专业人士能把变化的需求和不变的需求分割开来。这个失败和十几个同事的能力无关，关键在于他们没有 Pricing 的专业知识。年轻人参加工作不过两年，从来没有参与过企业外购软件的采购决策，也没有直接参与过软件的销售，别说专业 Pricing 知识了，他连基本的商业经验都为零，根本就不可能接得住这个任务。分派他去主导商业化逻辑改造，我认为确实是管理者无法辩解的严重错误。

滥用的 Code Review 和故障复盘

公开信还提到了两个让我这个工程师非常不安的现象。

（上司）就开始抓代码质量，统一进行代码 Review。当时轮到了我，中亭和中亭的嫡系，对我的代码各种挑刺，短短一百行代码恨不得挑出 30个毛病，我承认我的代码仍有很大的提升空间，可是他们在几十个人面前，对一个加入团队不到一年的同学，这种模式进行打压不就是单纯的 PUA吗，我做的不好我可以改进，但是我也有尊严啊，我也是个人，中亭和其嫡系们，有把我们老 ARMS团队的人当人来看吗？

代码评审是我们工程师通行的质量管理手段。它基于这么一个事实：不管一个人有多聪明多细心，他总是考虑得不完善，需要同事提供 peer review。因此它也暗含了这么一个规则：一个人的代码被驳回或者被要求重写，并不代表此人水平不行。代码评审过程中的意见不应该被视作对原作者的批评。这条规则被广泛采纳，大名鼎鼎的 Linus 就因为喜欢在代码评审的时候攻击原作者，被社区停职了一段时间。

但是显然，从年轻人的描述看，他在代码评审过程中被高强度的评价了，个人尊严被践踏了，以至于他怀疑代码评审并非一个质量管理手段，而是一个政治手段。他的这个怀疑是有道理的，因为我就听到朋友分享这种案例：“老板想开一个组员，HR 不让，然后老板让他 review 那个组员的时候挑刺。”

我们工程师发明代码评审用来互相帮助，却被用来互相攻击，这非常悲哀。

与此同时，我发现年轻人也被这种互相攻击的文化污染了。他提出：

他只是在我的实现基础上稍作修改，可是即便如此仍然导致了RUM线上问题，几十个 RUM的商业化用户计费受损，这部分可以详见 RUM计费改造复盘文档

业界主张 Blameless Postmortem（无批评事后复盘）^[3]。一个故障发生之后，复盘的过程中，我们假定每一个参与者都是有良好意图的。复盘的目的是从已经发生的事故吸取经验，改进流程和工具，而不是寻找替罪羊。由于不会被指责，因此大家会积极的提交故障报告，使得故障尽早被处理；复盘的时候也会主动分享信息，使得总结更有深度。

笔者本人撰写了多份复盘报告，从来不提同事的名字，如果一定要提及的话，也把 Ma Chi 缩写成 M，把 Andersson 缩写成 A，这样基本也无法定位到具体的个人了。

年轻人用团队的复盘记录来证明同事不能胜任工作，和他指控经理用代码审查来证明他不能胜任工作，其实是一回事。假如我们 100% 相信他的叙述，很遗憾双方都滥用了我们工程师的工具来服务不太光明的办公室政治目的。这是对我们工程师群体的冒犯。

我顺便也看了一下ARMS的产品，工程质量确实不敢恭维。比如 Upload - 上传SourceMap^[4] 是一个典型的写入操作，但是访问级别被定为READ，HTTP Method 用的是 GET 而不是 POST。这是一个非常典型的实习生水准设计。考虑到年轻人多次强调他主导了很多设计，我对此也不再惊讶了。

学历歧视

年轻人本来应该充满朝气，信奉英雄不看出处。但是这位年轻人强烈的攻击同事“学历不行”。实际上他的同事是大连理工大学的，也是老牌985，并非不行。

即使同事学历真的不行，也不应该作为一个攻击点。HR 学历歧视，是因为他们希望用一个硬性指标快速的筛选简历，就是为了节省成本。但是入职之后，工程师之间有充分的机会去互相了解，根本没有必要再去看学历了。笔者在北欧招聘和应聘软件工程师的过程中，只有 HR 关心过学历，工程师之间都用代码笔谈。一个良好的变量命名风格，一个考虑到边界条件的测试用例，一个安全的多线程并发，一个完整的CI/CD pipeline，都比毕业学校更有说服力。

我不知道年轻人这种学历歧视和学历崇拜是从哪里习得的，即使是从学校习得的，阿里云显然也没有提供一个开放的工程师文化帮助年轻人塑造更健康的工程师观念。

被阿里云耽误了

总体而言，我觉得这位有激情有理想的年轻人，被阿里云耽误了。不仅没有接触到业界前沿技术和文化，反而被培养出一些不太健康的习惯：以加班时长论英雄，把质量工具用于政治目的，用学历替代工程师标准。当然最为悲剧的是，他的身心健康受到了长期而且严重的损害。先不论绩效评判对错，阿里云作为中国领先的 IT 供应商，没有给员工提供健康保障，放任这种长期的伤害，是不可原谅的。希望年轻人能得到他应得到的尊重和帮助。

参考资料