【亚麻伤痕文学】在一个组待了五年多，终于还是进Focus了。聊聊我感受到的劳动的异化

写在前面：楼主目前在找工作，急需加米看面经，希望大家帮帮忙。万分感谢！

以下是正文：

首先，给大家一个忠告：在亚麻，大家千万不要在同一个组待太久，温水煮青蛙，慢慢地可能就会被Focus/pip。

介绍一下背景。楼主2021年入职亚麻，在AWS一个做运维自动化的组，一直干到现在。我们组负责的内容就是保证AWS下面某一个类型的服务器的整体健康，要通过各种自动化的workflow把挂掉的服务器重新修好（比如通过运行一些脚本、apollo activation、重启、重装environment、重装系统、reprovision等等）。我们组还有一个兄弟组。一开始我们两个组是同一个组，后来拆分出来，我们组是SDE为主，做运维自动化；他们组则是以System Engineer为主，做手动运维。我们两个组的目标是一致的：把挂掉的服务器重新拉起来。

本文我主要想聊的是我感受到的劳动的异化。而这种异化的感觉，在我们组不同的发展阶段也是不同的。

首先在我们组的上升期，我们组只own一个fleet（即一种server），那个时候我们的automation还很不完善，所以很多问题都是sev2。还记得那个时候，每天夜里都能有至少两三个sev2，然后我们的oncall schedule是分白班和夜班的，白班每人轮一周，夜班每人轮一宿。而我们组的sev2也相对地简单直接：“xxx host挂掉了，把它修好”。于是，我们全组人花了一整年，把组里的自动化完善到了能够覆盖90%以上的情况，这样，我们组夜里都sev2终于变少了。那个时候是我刚入职工作的第一年，刚出学校的我，竟然天真地以为好日子要来了。

自动化覆盖完善后，首当其冲获益的就是我的manager，她获得了一次升职加薪，变成了我的skip manager，并且把我们组从原本的一个组，拆成了偏dev的我们组，和偏ops的兄弟组。然后，她招来了新的manager，来分别领导我们组和我们的兄弟组。并且，她争取来了更大的scope，把大org下面别的fleet的ops load直接onboard到了我们这个小org。我们不是先有generic service，再onboard别的组的业务；而是先onboard了别的组的ops load，再由我们自己慢慢消化。于是，白班oncall我们组和兄弟组拆开了，而夜班oncall则是依旧一起承担。新的ops load来了，夜班的oncall又繁忙起来了，每夜至少两三个page又变成了我们日常的常态。

这是我第一次感受到劳动的异化：程序员明明是最希望用写代码的手段，把自己从繁重重复的劳动中解放出来的群体，而我们却通过我们自己的努力，向leadership证明了：我们还可以有更多的bandwidth。我们解放的不是自己，我们解放的bandwidth。我们的劳动只是告诉leadership：scope还可以更大。所以，这就是很矛盾的一个点：程序员们希望通过自身努力，让scope不变的前提下，让劳动减轻；而manager们则希望让员工劳动不变甚至稍微更多一些的前提下，让scope扩大。我曾经在其他平台上跟一位当manager的网友交流过这个观点，而对方的回复则让我脊背发凉：如果manager都不去接更大的scope，大家就要失业了。这句话当然没错，但这恰恰暴露了资本最残酷的逻辑：你的劳动成果不归你自己所有，而当你的劳动成果让你没有更多的活可干时，它非但不能把你从劳动中解放出来，反而还会异化你，让你失去靠劳动挣钱的资格。

后来，我们组为了应对多个fleet的情况，重构了我们所有的automation，搭建了新的系统，希望把旧的业务逻辑onboard到我们组内的新系统里来。这个时候是我们和我们兄弟组逐渐分道扬镳的开始。首先，oncall渐渐地分开了，我们从之前的devops偏dev，变成了90%都是dev的一个组。同时，我们组的service是要承接多个fleet的，而我们的兄弟组，依旧是保持着只是own那一个fleet的运维工作。

后来，我们组不断地与兄弟组在老fleet上查缺补漏，把90%的自动化进一步提升到了大概95%以上。这个过程中，我们两个组的角色定位是，他们是customer，给我们提需求，我们则负责实现。而我们组的人员也分成了两部分，一部分专注于新系统的构建，另一部分（包括我）则负责与兄弟组对接，实现他们要求的自动化的内容。随着自动化程度进一步上升，leadership发现兄弟组不需要这么多运维人员了，于是就开始逐步把一部分system engineer替换掉，换成SDE。有一个跟我挺聊得来加纳来的的黑人大叔，就这样在一次人员变动里被layoff了，两周后，他们组迎来了新的面孔。前一周，他还给我看他两个上中学的儿子打篮球的视频，说着他的家庭幸福；下一周，他的slack头像就变成灰色的了。

这是我第二次感受到劳动的异化：我们兄弟组自己提出的需求，我们组给他们实现了这些需求，却导致了他们的失业。我记得，那年股票还涨了不少。甚至上面的人也说，公司优化掉了一些人、减少了成本，于是股票就应声而涨了。我记得当时的自己并不开心。晚饭时，我老婆跟我分享着股票大涨的喜悦。我对她说，这钱，带血啊。这是多少像我们这样的组干掉自己的同事换来的。

再后来，我们组的系统愈发成熟，也onboard了更多的各种各样的fleet。而我们的兄弟组，也在去年我们最新一次reorg里换成了全员SDE的阵容。而这个时候，我们组的新系统却依旧没有支持这个我们自己的最老最大的fleet。所以，一个目标就刻不容缓了：我们要refactor这个庞大的legacy automation，把它整合进我们组的新系统里，然后把相关的新版本automation彻底handoff给刚刚大换血完的兄弟组，因为此时他们已经是全员SDE了，完全可以自己维护这些automation，而我们组则需要更加专注于这个系统本身，走向更偏infrastructure的方向。

于是，去年一整年，我们出动了70%的人员，彻底重构了这个legacy automation，而我作为在组里待了四年多的元老，自然承担了这个重构当中很重要的角色。当时是L6做的high level design，而我（L5）则是在他的基础上做了tech design。很多技术细节也都是我们两个人为主导确定下来的。基本上就是他指方向，我则是他的枪。于是，这一套automation，我从1.0版本，看着它一点点羽翼丰满，又看着它逐渐臃肿，同时看着它如何干掉了我们兄弟组的老人，到最后经我自己的手，完完整整地做出来了这个2.0的版本。最后交付地很顺利，查缺补漏后，到今年2月份，我就请了个一个多月的长假，用光了所有PTO回了趟国。

戏剧性的事情开始于今年4月，我从国内回来后，就听说组里的L6要走了。同事跟我一说，我才明白是怎么回事。由于这个automation是基于我们组现有的infrastructure的架构的，但又不完全一样，于是我们去年决定顺便建一个新的pipeline，作为最新版本的infrastructure，之后把所有的fleet都统一整合到这个pipeline上来。而大换血后的兄弟组，作为这一套automation新的owner，则认为他们需要有自己的pipeline、package，所以要求我们组把去年新建的pipeline也一并handoff给他们。我们的L6跟他们组撕逼无果，我们组的manager则一直置身事外、美美隐身，于是L6用AI生成了一个32页的大CR，直接override后就merge了，然后秒离职。所以，这个，在兄弟组强烈的要求下，我被manager按着脑袋去接手了L6扔下的烂摊子：把infrastructure也一拆两半，把那一半的infrastructure也连带着跟这些automation workflow一起handoff给他们。由于此时这个2.0版本的automation已经上线，我顶着outage的风险，尽最大可能性在基本上zero outage的情况下把所有错综复杂的依赖捋清、拆开、建新的pipeline、新的CDK、重新部署了一份给他们组。一系列艰难险阻就不赘述了，而我的manager依旧美美隐身。终于，在这个拆分彻底完成时，manager把一纸Focus拍在了我的脸上，上面赫然写着一行大字：由于我做这个infrastructure拆分时耽误了太久，导致拖慢了其他项目的进展，我的delivery result有待提高。

就这样，我第三次感受到了劳动的异化，而这一次刀子则是落在了我自己的脖颈上。我们辛辛苦苦完善自动化，送走了兄弟组的老人同事们，而当我辛辛苦苦把自动化进一步完善，handoff给兄弟组的新人同事们后，送走的竟是我自己。这几年，我的经验基本上是跟这个automation深度绑定着的，而我把这一系列东西做到100%
handoff走，我在自己组也就失去了价值。我自己的劳动成果，终于还是变成了宣告我死刑的那颗子弹。而这个automation新的owner，看着git blame上面我的名字，也只是会说一句：“他已经不在亚马逊了”。

其实仔细回想，站在更宏观一点的视角，我被放入Focus是与整个组的情况也是息息相关的。前面一直在说，我们组在逐渐脱离开fleet owner这个身份，而要转变为own一个服务、一个infrastructure。然而，AWS内部修服务器的company wide的服务就有很多很成熟的体系，而我们作为某个org下面的某个组，自然不可能做成company wide级别的infrastructure。所以这注定了我们组的ownership是要与业务逻辑深度绑定的。而业务逻辑则是fleet owner该操心的事。于是，我们组本来想做的fleet agnostic也没有真正做成。同一个workflow，应对不同fleet owners的不同需求，衍生出了各种版本、各种逻辑分支，代码再一次变得臃肿冗杂。这个时候，我们发现我们处在了一个高不成低不就的位置了。于是，今年我manager就决定把我们组三四成的人派出去，其各个fleet owners的这些customer teams里面做away team work，即帮他们更好地onboard到我们的系统里，并且直接帮他们在他们组的codebase里写代码、向他们组的manager汇报工作进展。可能站在manager的角度来看，当scope无法继续扩大时，就是这个组灭亡的前兆了。而pip的压力从上面压下来，我便成了那个头一个的牺牲品。

不扩张就死亡，这不正是资本的逻辑吗？成功扩张的一方，整合了资源、扩大了scope，他们的劳动者却不得轻松。没能成功扩张的一方，被别人吃干抹净，他们的劳动者则失去了工作与收入。我昨天挣的钱，带着别人的血；别人今天挣的钱，也带着我的血；而当AI整合了一切、消灭了一切的工作时，他们的钱，将带着我们的血。物竞天择，适者生存，这就是美国的经济引擎最底层的代码。这高薪的工作让我们失去了自由，这何尝不是一幅金手铐；而这金手铐又多少次地化作了一把金手枪，发射了一枚金子弹，消灭了我们的阶级同胞；股票涨了、职级升了、scope变大了、经济繁荣了，但可别忘了，别人手里的金手枪，也顶在你的脑袋上呢。你真的自由吗？

写到最后，我知道我说的这些并无力改变些什么，更救不了我自己。我只能衷心地祝福大家：“愿你我有朝一日能够获得不被剥削与异化的自由，劳动者万岁、人民万岁！”

再强调一遍：我目前已请FMLA，在找工作，急需加米看面经！！！谢谢大家！！！

L6到底还是L6，跑得飞快

在公司要多学少做，工作是为了让自己成长，贝佐斯不缺你这份劳动。我在亚麻好多年基本就没出过活，基本一两年一个组学懂了就去下个组，等把这一片都学会了就可以去startup了

Handoff 的开始其实就是 Focus | PIP 的开始了， Scope 都已经不在了， 这个组在上级面前就没有存在必要了。 而从一开始，抢Scope 其实是 经理和 L6 要干的活。 经理不在 roadmap 里抢 scope, 基本就宣告这组 的再见了。
和资本主义没太大关系， 很难说是 亚麻独有的经营管理文化还是整个科技圈有 pip 制度的公司通用的经营管理文化。 亚麻需要用 Focus | PIP 来避免中低层变成一滩死水， 维持效率， 但同时 这也催生了由上到下的政治斗争。

lz给你加米了 你最后升到l6了吗 我组一个大哥l5升l6的时候我全程目睹 基本是自愿996 随时发消息人都在线

匿名用户 发表于 2026-10-15 21:43
lz给你加米了 你最后升到l6了吗 我组一个大哥l5升l6的时候我全程目睹 基本是自愿996 随时发消息人都在线

谢谢！我离L6差得远呢。升L6确实很难

我也是亚麻出来的。楼主不应该把这套观察推广到所有公司。论这种方式的缺德，亚麻绝对是鼻祖

卸磨杀驴？

首当其冲用错了

S3 Keystone?

我呆过亚麻和其他公司，只能说这个是亚麻自己的问题，总是搞一些没用的scope