大家说SDE(SWE)已经很没前途了现在，那SRE(PE)是不是要更没前途了？
SDE/SWE与SRE/PE岗位前景的深入探讨，聚焦AI对技术岗位的潜在影响，SRE在复杂系统维护中的独特价值，以及DevOps、Platform Engineer角色的融合趋势。
1. 关键信息
- （之前已归纳）原帖楼主（SDE/SWE，mid level）考虑转 SRE/PE，对该岗位前景存在两种观点：
- 观点1：可靠性工作会被进一步抽象化，需求减少，对领域知识要求降低（如自动化仪表盘、集成日志系统）。
- 观点2：SRE/PE 接触基础架构，影响范围广，技术栈要求高且杂，竞争相对较小。
- （之前已归纳）楼主希望听取坛友看法，特别是 SRE/PE 现身说法。
- （之前已归纳）新增回复（第11楼）提到，如果工作已经没前途，那么 SRE/PE 是否更没前途，暗示了对 SRE/PE 岗位前景的担忧，并可能认为 SRE/PE 的工作内容也可能被自动化和抽象化，导致需求减少。
- （之前已归纳）新增回复（第14楼）提出相反观点，认为SRE重复性工作越来越少，并形象地描述为“堆新的东西解决旧时代的问题然后新的东西又有新的错法的美感”，暗示SRE岗位面临的是问题演变和技术栈更新，而非简单被自动化取代。
- （之前已归纳）新增回复（第15楼）是一位刚入行的new grad，表达了对SDE/SWE和SRE/PE等方向性讨论的迷茫，并表示非常需要听取各种意见。
- （之前已归纳）新增回复（第21楼）指出，AI更容易替代新产品、新服务、新代码的生成和分析。
- （之前已归纳）新增回复（第21楼）列举了AI难以替代的场景：处理“屎山”代码、自由格式日志、术语不一致、公司收购产品的集成、成本节约等。
- （之前已归纳）新增回复（第21楼）提到，AI分析复杂代码库的成本非常高，目前依赖于投资者的资助，一旦热钱断流，高昂的按使用量和资源计费将成为问题，且“屎山”的分析结果常有错误。
- （之前已归纳）新增回复（第23楼）用“电子泔水喂电子泔水”形象地比喻了某种情况，可能暗示了AI或自动化在处理复杂、低质量代码时的局限性，或者是一种对某些技术趋势的戏谑。
- （之前已归纳）新增回复（第24楼）认为SRE的impact（好的坏的都有）很容易比较大，这可能是SRE岗位不易被替代的原因之一，因为其决策和操作对系统有显著影响。
- （之前已归纳）新增回复（第25楼）指出，SRE和DevOps本质上是一体两面，在现代很多情况下由一人担任，且职责界限模糊。上云后SRE依然需要，只是面对的对象从数据中心转变为云，更多地被称为Infra engineer或Platform engineer。
- （之前已归纳）新增回复（第26楼）引用了“platform engineer和DevOps其实要会的差不多，本质就是一个东西”的观点，进一步强调了SRE、DevOps、Platform Engineer之间的关联性和趋同性。
- （之前已归纳）新增回复（第34楼）认为，相比于产品开发（feature开发）通常有“完美”解决方案或可通过砸钱解决，SRE处理的Incident（建立在坏了的基础上）往往没有完美方案，更多是风险、收益、时间损失的权衡，因此短期内SRE的壁垒比AI高。
- （之前已归纳）新增回复（第35楼）提到，SRE接触Infra，scope大，更容易有Impact。但也有观点认为离钱越近的Impact越大。同时，资本家曾让SRE写自动化工具，工具写完后SRE被裁，让SWE兼职SRE。
- （之前已归纳）新增回复（第36楼）戏谑地提出，如果AI出错，应扣除其消耗的tokens，甚至按比例进行赔偿。
- （之前已归纳）新增回复（第37楼）提及一项论文研究，指出训练模型水平和参数大小接近平方关系，提升模型分数需要指数级增长的参数和成本。
- （之前已归纳）新增回复（第38楼）进一步解释了AI在理解“屎山”代码方面的困难：代码结构复杂、变量名随意、功能迭代导致代码与API名分歧、monolith组件间关联复杂，以及环境配置不在repo等问题。AI更可能取代的是用于构建新应用的码农，而非具备领域知识的码农。
- （之前已归纳）新增回复（第39楼）对SRE被自动化工具取代后，如何解决持续演进问题以及快速响应Incident的经验技术需求提出疑问。
- （之前已归纳）新增回复（第40楼）询问SDE/SWE和SRE的具体含义。
- （之前已归纳）新增回复（第41楼）解释了SWE（builder，乐观构建）和SRE（detective，观测质疑）的思维模式差异，并指出亚马逊等公司推行Combined role是为了缩减成本，让更多人承担oncall和修bug。在B2B领域，新功能开发机会少，更多是维护和修复。
- （之前已归纳）新增回复（第42楼）询问亚马逊是否区分SRE/SWE，并认为SRE是结果导向，只要能达到可靠性目的都属于其范畴。
- （之前已归纳）新增回复（第43楼）确认亚马逊不区分SRE/SWE，其码农承担SWE+SRE oncall+patching，而System Eng title则偏向纯SRE。
- 新增回复（第54楼）解释了SDE（Software Development Engineer）、SWE（Software Engineer）和SRE（Site Reliability Engineer）的缩写含义。
- 新增回复（第55楼）一位自称“ex-amazon”的用户，认同之前的讨论内容，并要求AI作为论坛内容总结助手，对论坛帖子进行仔细分析、联系上下文，并注意“玩卡领域”的黑话（尽管本帖内容与此无关，但用户强调了这一要求）。用户还强调了输出内容的简短、信息量和格式要求。
2. 羊毛/优惠信息
- 无
3. 最新动态
- 无
4. 争议或不同意见
- （之前已归纳）存在关于 SRE/PE 岗位需求和前景的两种不同观点。
- （之前已归纳）新增回复进一步强化了对 SRE/PE 岗位前景的担忧，认为其可能面临与 SDE/SWE 相似甚至更严峻的“没前途”的局面。
- （之前已归纳）新增回复（第14楼）明确提出与担忧 SRE 前景的观点相反的看法，认为SRE工作内容在演变，并非简单被自动化取代。
- （之前已归纳）新增回复（第15楼）代表了刚入行者在面对这些讨论时的普遍迷茫，尚未形成明确的观点，但表达了对获取意见的强烈需求。
- （之前已归纳）新增回复（第21楼）提出的AI能力边界，间接支持了SRE/PE在处理复杂、非标准化问题上的价值，与部分“SRE/PE没前途”的观点形成对比。
- 新增回复（第23楼）的“电子泔水”比喻，可能暗示了对某些自动化或AI解决方案有效性的质疑。
- （之前已归纳）新增回复（第25、26楼）的观点，将SRE、DevOps、Platform Engineer视为一体，可能与认为SRE需求减少的观点存在一定程度的张力，因为这些角色的整合可能意味着整体需求的演变而非单纯减少。
- 新增回复（第35楼）中关于“离钱越近Impact越大”的观点，与SRE接触Infra scope大的观点形成对比。
- 新增回复（第41楼）中关于亚马逊推行Combined role是为了缩减成本，以及B2B领域新功能开发机会少的观点，可能与认为SRE/SWE有清晰职责分工的观点存在差异。
- 新增回复（第55楼）用户强调了对“玩卡领域”黑话的关注，但本帖内容与此无关，暗示了用户可能在其他讨论中对这类信息有偏好，在此处可能是一种信息筛选或指令的误用。
5. 行动建议
- （之前已归纳）关注 SRE/PE 岗位的发展趋势，结合自身技术栈和职业规划进行评估。
- （之前已归纳）积极寻求 SRE/PE 岗位从业者的经验分享。
- （之前已归纳）新增回复暗示，在评估 SRE/PE 岗位前景时，应考虑其工作内容被自动化和抽象化的可能性，以及这可能带来的需求变化。
- （之前已归纳）新增回复（第14楼）的观点提示，在评估SRE岗位前景时，应关注其工作内容的演变性，以及技术栈的更新和新问题的出现，而非仅停留在被自动化取代的担忧上。
- （之前已归纳）对于刚入行的从业者（如第15楼用户），积极参与和关注此类讨论，听取多方意见，有助于形成更清晰的职业发展方向。
- （之前已归纳）根据新增回复（第21楼），在评估SRE/PE前景时，可以关注其在处理“屎山”、非标准化数据和复杂集成等AI难以有效解决的领域的能力和价值。同时，也要认识到AI在某些方面的优势，并考虑其潜在的成本影响。
- 根据新增回复（第25、26楼），理解SRE、DevOps和Platform Engineer角色的整合趋势，并认识到上云后这些角色的演变，有助于更准确地定位和发展职业方向。
- 根据新增回复（第34楼），认识到SRE在处理复杂、无完美方案的Incident中的价值，以及其在风险权衡方面的壁垒。
- 根据新增回复（第35楼），理解SRE工作的影响力与其接触的基础设施范围相关，但也需注意“离钱近”的Impact论。警惕资本家为降本增效而进行的SRE工具化和岗位合并。
- 根据新增回复（第37、38楼），理解AI在处理复杂、低质量代码（“屎山”）方面的局限性，以及其在模型训练成本上的挑战，这可能为SRE提供一定的技术安全边际。
- 根据新增回复（第41楼），区分SWE和SRE的思维模式差异，并理解部分公司（如亚马逊）推行Combined role的策略，有助于更清晰地认识不同岗位职责和公司用人策略。
- 新增回复（第54楼）提供了SDE、SWE、SRE等常见技术岗位的缩写解释，对于初入行者或不熟悉这些术语的用户，可以作为基础知识参考。
LZ过去一直都是SDE/SWE， 现在大概算是个mid level吧。
最近有机会去当SRE了，认真了解并和周围朋友聊了下这个岗位的前景得到两种不同的观点。
观点1：这些reliability的东西肯定会越来越被抽象出来，所以需求越来越少，像比如以前古早时候每个组恨不得都得有人懂怎么用linux 那些command tool去debug和检查resources. 现在就是一堆dashboard和集成的很好的log系统了，对domain knowledge的要求越来越低。
观点2：因为这些平时接触的都是infra，所以更容易有impact因为天生scope就很大，而且这本身就是个对技术栈要求比较高比较杂的岗，竞争会小。
我感觉这两种观点也不是互相完全矛盾的，但还是想听听坛友的看法，尤其最好是能有SRE（PE）来现身说法，身边实在是除了一个entry level的PE其他一个都找不到。
只有做ai有前途 其他都是草鸡
Infra 和 sre 没 ai 都早不行了
别说有ai帮你
prod swe 会这两年被ai 替代
结束了就是结束了
@Dmitrii2333 很适合老D回答的问题
AI 更容易替代：
代码生成
单点问题排查
log 分析
AI 不容易替代：
故障时的决策权衡
风险判断
业务优先级冲突处理
组织沟通
这些恰好是高级 SRE 的核心。
我觉得以后sde/swe乃至mle都会是某种程度的sre，如何prompt出鲁棒的系统是一门艺术
要不看看infra里的network？全是闭源的东西llm不太能会 也没法背锅
等我六月入职“entry level的pe”之后说不定会有新的发现
确实感觉SRE重复性的工作太多了非常适合上AI，感觉这一波写skills最勤快的就是SRE
说的就是我了 内部存logs和metrics的数据库稍微小众，各种naming和label都是独自的风格，感觉ai不可能自己弄明白，而且内部数据也不可以上传给什么gpt，gemini。现在在跑自己的local LLM，猛写了一堆skill教agent怎么查数据。打算用ai agent干掉其他sre
工作已经没前途了
你不是被封了吗
有点精辟，之前雀食没这样思考过。感谢回复。
我恰恰感觉相反，感觉SRE重复性的工作现在越来越少。有一种堆新的东西解决旧时代的问题然后新的东西又有新的错法的美感。
好喜欢泥潭这些讨论贴
才入行的new grad现在很迷茫，非常需要听听对这些方向性思考的各种意见
有sre的都是一些内部infra的公司
上云之后都直接devops了
sre迟早会被cloud和devops替代，ai只是加速这个过程
楼上说的不容易ai替代的点其实早就被devops替代了
说实话现在讨论哪个岗位更没前途就像在讨论泰坦尼克号上哪个舱位更安全 与其纠结title不如想想怎么让自己不可替代
现在正在做infra 我感觉platform engineer和DevOps其实要会的差不多
主要是这个池子岗位少 好处是人也少 不用面对产品 你的customer可以说是internal devs 但是傻逼也很多
没啥不能替代的
我感觉可能你是不是印度人 会不会push和没法替代吧
用公司的AI coding工具的时候看到一行小字说SRE不让开YOLO mode，这么想想SRE反而没那么容易被取代？
此外AI容易替代新产品，新service，新code的生成和分析。
AI不容易替代：屎山，垃圾free form log，inconsistent terminology across context （一个词在不同的地方有不同的意思），主公司和被收购产品的integration，cost saving等等。
AI分析复杂code base其实也是有一套的，但是这个analysis背后的cost特别贵。目前只是因为Ai能吸引热钱所以是投资者在资助码农几乎免费使用这个功能。热钱一但断了，开始按照usage和resource计费，那么谁来付这大几万甚至十几万、几十万的单次分析cost呢（况且屎山的分析经常是错的）？
cope harder
还什么组织沟通
人都被替代了还哪有什么组织？
ai和自己沟通不方便吗？
这不就是用电子泔水去喂电子泔水么哈哈哈
可能因为SRE的impact（好的坏的都有）很容易比较大哈哈
没有这种说法。sre和devops本来就是一体两面，在现代基本都是由一个人担任。sre和devops职责很早以前就模糊不清了
上云之后也是需要sre的，本来就是domain knowledge，云只是把 data centre 层的东西简化抽象了，但是具体保障 reliability 的工种依然存在，只是面对的对象从dc变成了更简单的云
现在更多的叫 infra engineer or platform engineer
【引用自 Allen_Z】:
platform engineer和DevOps其实要会的差不多
本质就是一个东西
我觉得做infra从业壁垒会比纯码农稍高一点，因为domain knowledge还是挺多的，而且有个很重要的oncall背锅职能
ai可能会因为快速triage快速gather context消灭一部分岗位，但是这个职能本身我觉得暂时不会消失，应急响应用ai来做还是有点超前，让ai agent直接到生产该配置切流量啥的还是有点吓人
【引用自 BeanCounter008】:
Ai能吸引热钱所以是投资者在资助码农几乎免费使用这个功能
是吗？LLM inference cost现在已经降得非常低了呀，1m token 十几美元。真正花钱的是训练，半年50B的成本。如果以后大规模推广或者模型无法进步，现在的模型已经足够替代普通人了
不是token本身的价格高低，而是token的权重不成比例。分析屎山收的钱不足以cover后台的cost，屎山分析卖便宜了。
目前一个核心问题，AI背锅吗？
出了问题比如预算超支、胡编乱造造成客户损失等等这个法律责任在谁？
理论层面取代人很简单，但是法理上很难完全成立。但我不想反驳你，你有你的坚定belief，而且我也大部分认同你预估的方向。
我只是更相信带来的各种问题会出现一阵混乱期。热钱一旦消失，是ai公司自己先死还是其他公司先死就不一定了。大概率就是一起demise然后世界缓慢接近三战边缘。
为什么说屎山分析卖便宜了呢？我看目前深度思考所读的内容也是当作token收费的呀
具体数字不清楚。之前看的video解释大概可以理解为API token成本偏向线性而后台计算的成本呈指数性甚至阶乘性。
还有video吗，这个解释挺有意思的
赞同。而且我这两天又想了下。做产品做feature很多时候其实是能有一个“完美的”解决方案的，不行砸钱也能解决。真出了incident很多时候由于已经建立在坏了的基础上，很多时候是没有一个完美方案的，更多只是风险收益时间损失的tradeoff，感觉短期内壁垒还是比ai高不少。
【引用自 kylerrrliu】:
因为这些平时接触的都是infra，所以更容易有impact因为天生scope就很大
你确定？离钱越近的impart越大吧
【引用自 kylerrrliu】:
现在就是一堆dashboard和集成的很好的log系统了
你说得对，所以之前资本家降本增效的时候都是让SRE当SWE写这些工具，写完了把SRE开了，让SWE用这些系统兼职当SRE
哈哈哈我昨天和人聊过类似的。
我当时就吐槽要是AI出了错的东西或者比如幻觉，就该扣tokens，比如这问题花了5000 tokens，错1赔10还给我50000 tokens。
这个有个论文我有印象，虽然可能说的不是同一个。
我看的那个大概意思结论是训练的模型水平和参数大小是接近平方的关系， 也就是说越往后需要提升同样的模型分数，参数增加的需要越来越多，参数数量又是和训练成本相关的。
一个是线性的字符总量，一个是神经网络图。图至少也是平方级了。而且屎山之所以称之为屎山不就是因为很难看懂？ 变量名瞎起虽然少见，但是功能迭代了多次之后代码内容与API名有所分歧已经是大概率。monolith每个component之间有着各种神奇的关联。这还不算那种环境config不在repo里面的情况。
AI所取代的不是带有domain knowledge的那些码农本身，而是直接用于做一个新的application取代行业里的老牌application，然后变相让那些码农失业。
【引用自 uplus5f7b】:
SRE当SWE写这些工具，写完了把SRE开了，让SWE用这些系统兼职当SRE
那怎么解决持续演进的问题，不演进了？而且出incident快速响应还真需要点经验和技术
【引用自 kylerrrliu】:
SDE/SWE
这些到底都是啥意思？SRE又是啥？
其实SWE/SRE的概念是被亚麻厂和脸厂混淆过的。
概念上，SWE的思维更偏向一个builder，日常是乐观的build more things。而SRE的思维更偏向一个detective，日常是观测、质疑、求证、发掘。
本质是两种不同的思维模式。虽然可以用一个engineer去接手两方面的task，但是每个engineer的底层思维模式只会适合其中一种。如果全都是builder那就很容易incident满天飞，如果全是detective那就会never get things done。
亚麻厂之所以大力推进combined role的概念就是因为这样可以大力缩减成本，还可以骗pao。因为file H1b/perm的时候，combined role只需要同一个template。招人的时候“we use cutting edge technology”，实际上是让更多人加入oncall rotation然后修bug。IT行业这么广，除了热钱涌入的startups，大多数都是老牌B2B，哪来那么多机会做new feature。
我没有在亚麻待过，亚麻不区分sre/swe？
我认知里认为sre是一个结果导向工种，不是过程/技术导向，只要能达到reliability目的那么都是sre的scope
亚麻不区分。
亚麻的码农干的是SWE + SRE的oncall部分，外加一些patching。亚麻的System Eng title进去了干的是纯SRE （那种老牌组基本不会真给你做系统架构的role的，一大堆SDE3、Architect、Principal之类的嗷嗷待哺呢）。
【引用自 camh】:
sre和devops本来就是一体两面，在现代基本都是由一个人担任
所以说SRE被代替了啊，产品开发的dev也顺手把本组的ops给做了
AWS之类的主流云产品AI辅助直接写infra as code然后deploy，自动扩容，可靠性比99%公司内部infra要可靠。我现在公司规模也算不小，但是内部hdfs三天两头出问题，aws s3出问题可是要上热搜的。
更别提现在supabase/vercel之类的服务，小公司码农甚至不需要任何system design的知识就可以AI辅助全栈开发
这不是sre被替代，是sre本身职能演变。
你公司没有单独的infra guy？
这不是sre被替代，是sre本身职能演变
你可以把这个称为演变，但事实就是只会ops的人越来越难找工作。SRE的裁员是先于码农开始的
你公司没有单独的infra guy？
有啊，而且这几年一直在裁
SRE不是只会ops 这个概念本身就是谷歌发明的，sre是结果目的导向的演变形态。sre需要深入参与业务，给业务组提供支持和指导。不写码的纯ops本来已经在上个时代就消灭的差不多了
我就职过的公司里，infra团队一般都很累，需要快速响应业务团队的各种需求，同时作为知识库要深入参与业务提供guidance解决方案，目标就是通过各种手段让业务团队专注于写码降低复杂程度，明确服务态度提高业务方面的满意度。相对应的，infra团队也会比较受尊重。
不过我也知道不是所有的公司都这样，有些公司依然存在纯oncall背锅的工种
正如我上面所讲：
【引用自 camh】:
上云之后也是需要sre的，本来就是domain knowledge，云只是把 data centre 层的东西简化抽象了，但是具体保障 reliability 的工种依然存在，只是面对的对象从dc变成了更简单的云
platform, devops, sre, 本质在现代已经是一个岗位了
听起来你的公司像是还保留着纯ops职位，是传统公司？
其实是新公司想省钱。一般比较新的公司/service没有那么多的对客户的保障，更多是以低价来吸引客户。减少岗位种类会增加很多reorg的flexibility，task可以到处assign。但不代表
【引用自 camh】:
platform, devops, sre,
是一个人全能均衡做好的。大多数人肯定还是偏科某一个方面，这是由技能和思维方式决定的。
当“新公司”逐渐成熟成为传统公司的时候，承担的客户越来越多，scale越来越广，PM把功能改的越来越离谱（就是你的architecture不适合某个方向但是PM就要做），渐渐的所有的坑就都出来了，然后就会有你说的那些本该淘汰的岗位。
而且很多码农其实意识不到，很多PM和高层在你没意识到的时候，已经分析完市场把战略定了，甚至PRFAQ已经发出去了，某些抽象的公司可能已经把promise都给客户了。你作为engineer argue与否，architecture能不能支持这些功能等等，并不重要。你deny的次数够多直接fire，然后再找一个yesman。
That’s how corporate works
【引用自 camh】:
platform, devops, sre,
【引用自 BeanCounter008】:
但不代表
是一个人全能均衡做好的。大多数人肯定还是偏科某一个方面，这是由技能和思维方式决定的。
我的意思是，这几个工种合并是已经在发生的事情，他们的目的几乎是一致的，技能树也是极其类似的，合并是非常合理的选择
【引用自 camh】:
他们的目的几乎是一致的，技能树也是极其类似的
但是个体的思维方式是不同的，适用的role不同。job position虽然都是同一个，但每个人都有他们最适合的role。
思维方式对一个人擅长的领域的影响很大的。
I guess we can agree to disagree 如果不是 reliability-minded 根本不会选择这种 pan-infra 工作
会干这行的都是热爱
人无法躲过历史洪流的。行业趋势左右摇摆也是一个evolve的过程。IT行业还是会继续缩水，一个decade之内都不会很乐观，不是说某一种角色就能完全躲得掉。
除非我们是巴菲特。
当然，行业肯定要进步，岗位也会不断改变。
我说的是我认为这几个岗位融合是现在进行时，实实在在正在发生
SDE 是software development/developing enginner SWE是software enginner。
SRE是site reliability enginner。
google是google.com
gpt 和Gemini是gpt和gemini
作为一个ex-amazon深以为然