Loading... # 软件工程的未来是 SRE 技术分析 # 一、概述 ## 1. 背景 随着 AI 编码助手和无代码平台的兴起，代码编写的门槛大幅降低。然而，真正的工程挑战不在于编写代码，而在于长期稳定地运行服务。 ## 2. 核心观点 当代码变得廉价时，运营卓越能力成为竞争壁垒。任何人都可以构建一个演示版本，但要让服务长期稳定运行需要真正的工程能力。 ## 3. 关键论点 SRE（Site Reliability Engineering，站点可靠性工程）将成为工程领域最热门的职位。人们热衷于编写全新代码，但很少有人愿意承担运行服务的责任。 # 二、问题分析 ## 1. 代码编写的现状 ### A. 编写代码变得容易 现代开发工具和 AI 辅助让编写代码的门槛大幅降低。一个会计人员通过 Google 搜索、无代码工具和电子表格宏就能构建工具，将每周 10 小时的工作缩减到 1 小时。 ### B. 演示版本的陷阱 构建一个能工作的演示版本很容易，大约只需要完成 90% 的工作。但真正重要的是剩余的 190%。 ## 2. 运维的隐形负担 ### A. 边缘案例的持续涌现 每个新周期都会发现新的边缘情况，需要不断修补。 ### B. 技术债务的累积 业务规则不断变化，时区和夏令时等问题让系统变得脆弱。 ### C. 维护者的困境 创建者被自己构建的系统束缚，无法休假，无法培训他人接手，系统永远无法完美运行。 ## 3. Feynman 的"计算机疾病" 物理学家理查德·费曼将这种现象称为"计算机疾病"：人们沉迷于自动化和修补，却忘记了这并非必需。有趣的部分是自动化，不有趣的部分是提供服务。 ```mermaid graph LR A[编写代码] -->|容易 90%| B[演示版本] B -->|困难 190%| C[稳定服务] C -->|持续负担| D[边缘案例] C -->|持续负担| E[技术债务] C -->|持续负担| F[维护困境] D --> G[计算机疾病] E --> G F --> G G -.限制.| H[真正工程能力] ```  # 三、运营卓越的核心要素 ## 1. 服务导向思维 ### A. 用户视角的转变 用户不购买软件，他们雇佣服务。用户不在乎 iCloud 如何工作，只希望照片能神奇地在所有设备上同步。用户不关心 Word 或 Notion 的实现，只想编写、分享和查看更改。 ### B. 软件的隐形性 优秀的软件是隐形的。当服务正常工作时，用户不会注意到它的存在。 ## 2. 可靠性工程的关键问题 ```mermaid graph TB Root[运营卓越] Root --> R[可靠性] R --> R1[正常运行时间] R --> R2[缺陷率] R --> R3[恢复速度] R --> R4[故障检测] Root --> D[依赖管理] D --> D1[上游依赖] D --> D2[供应商监控] D --> D3[故障隔离] D --> D4[数据保护] Root --> T[团队协作] T --> T1[防止破坏] T --> T2[系统化流程] T --> T3[超越单人大脑] Root --> G[全球化支持] G --> G1[跨时区响应] G --> G2[自动化恢复] G --> G3[24/7 可用性] Root --> S[安全性] S --> S1[安全更新] S --> S2[数据保护] S --> S3[隐私保护] S --> S4[信任建立] Root --> A[服务保障] A --> A1[SLA 承诺] A --> A2[法律保证] A --> A3[可靠性验证] ```  ## 3. 运营卓越的具体指标 ### A. 可靠性指标 - 正常运行时间是多少 - 缺陷率如何 - 从缺陷中恢复的速度有多快 - 是用户主动报告还是系统先发现问题 ### B. 依赖管理 - 能否掌控上游依赖 - 当供应商出现问题时，是主动发现还是等待用户投诉 - 能否从故障中恢复而不丢失重要数据 ### C. 团队协作 - 如何防止工程师破坏彼此的系统 - 是否有系统化的流程让团队高效协作 - 能否构建超越单人大脑认知限度的软件系统 ### D. 全球化支持 - 当用户在不同时区、工程师已休息时出现重大问题，能否在用户放弃前解决 ### E. 安全与信任 - 是否跟进行安全更新 - 会否泄露用户数据 - 用户能否信任你 - 能否提供法律约束力的服务保证 # 四、为什么 SRE 是未来 ## 1. 代码产能的爆发 AI 编码助手让代码编写变得廉价。当人人都能快速构建演示版本时，差异化竞争的焦点转向服务质量和稳定性。 ## 2. 服务经济的崛起 软件不再是产品，而是服务。用户不关心实现细节，只关心服务体验。这要求工程团队从"项目交付"思维转向"服务运营"思维。 ## 3. 复杂性的指数增长 现代软件系统日益复杂，涉及微服务、分布式架构、多区域部署等。管理这种复杂性需要专业的 SRE 能力。 ## 4. 人才需求的变化 传统的"全栈开发者"模型面临挑战。市场更需要能够： - 设计可扩展系统 - 建立监控告警体系 - 实施自动化运维 - 管理生产环境事故 - 持续优化服务性能 # 五、SRE 与传统软件工程的对比 | 维度 | 传统软件工程 | SRE 思维 | |------|------------|---------| | 核心目标 | 构建功能 | 提供服务 | | 时间视野 | 项目交付 | 长期运营 | | 成功指标 | 功能完成度 | 可靠性、可用性 | | 错误处理 | 修复 bug | 预防和自动恢复 | | 系统边界 | 单个应用 | 端到端服务链路 | | 变更管理 | 定期发布 | 渐进式发布、快速回滚 | # 六、给工程师的建议 ## 1. 从编码能力向系统能力拓展 不要只关注编写代码的效率，更要关注： - 系统的可观测性 - 故障的检测和响应 - 变更的风险控制 - 容量和性能规划 ## 2. 培养服务意识 将每个功能视为一个服务，思考： - 这个服务如何长期稳定运行 - 如何监控其健康状况 - 出问题时如何快速恢复 - 如何防止级联故障 ## 3. 学习 SRE 核心实践 - 错误预算管理 - 服务等级目标（SLO）设定 - 事故响应流程 - 变更管理策略 - 自动化运维工具链 # 七、总结 软件工程的未来不在于编写代码的能力，而在于运营卓越的能力。当 AI 让编码变得廉价时，能够长期稳定运行服务的工程师和组织将脱颖而出。 SRE 不是运维的别称，而是一种工程哲学：将运营本身视为工程问题，用系统化、自动化、数据驱动的方法来解决。 未来的软件工程师需要同时具备： 1. 编码能力（变得相对容易） 2. SRE 能力（变得愈发重要） 这意味着职业生涯的发展方向应当从"构建者"向"运营者"拓展，从"项目交付"向"服务负责"转型。 *** ## 参考资料 1. [The future of software engineering is SRE](https://swizec.com/blog/the-future-of-software-engineering-is-sre/) 最后修改：2026 年 01 月 26 日 © 允许规范转载 赞 如果觉得我的文章对你有用，请随意赞赏