大家说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等常见技术岗位的缩写解释，对于初入行者或不熟悉这些术语的用户，可以作为基础知识参考。