软件工程的未来是 SRE 技术分析

一、概述

1. 背景

随着 AI 编码助手和无代码平台的兴起，代码编写的门槛大幅降低。然而，真正的工程挑战不在于编写代码，而在于长期稳定地运行服务。

2. 核心观点

当代码变得廉价时，运营卓越能力成为竞争壁垒。任何人都可以构建一个演示版本，但要让服务长期稳定运行需要真正的工程能力。

3. 关键论点

SRE（Site Reliability Engineering，站点可靠性工程）将成为工程领域最热门的职位。人们热衷于编写全新代码，但很少有人愿意承担运行服务的责任。

二、问题分析

1. 代码编写的现状

A. 编写代码变得容易

现代开发工具和 AI 辅助让编写代码的门槛大幅降低。一个会计人员通过 Google 搜索、无代码工具和电子表格宏就能构建工具，将每周 10 小时的工作缩减到 1 小时。

B. 演示版本的陷阱

构建一个能工作的演示版本很容易，大约只需要完成 90% 的工作。但真正重要的是剩余的 190%。

2. 运维的隐形负担

A. 边缘案例的持续涌现

每个新周期都会发现新的边缘情况，需要不断修补。

B. 技术债务的累积

业务规则不断变化，时区和夏令时等问题让系统变得脆弱。

C. 维护者的困境

创建者被自己构建的系统束缚，无法休假，无法培训他人接手，系统永远无法完美运行。

3. Feynman 的"计算机疾病"

物理学家理查德·费曼将这种现象称为"计算机疾病"：人们沉迷于自动化和修补，却忘记了这并非必需。有趣的部分是自动化，不有趣的部分是提供服务。

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. 可靠性工程的关键问题

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 与传统软件工程的对比

六、给工程师的建议

1. 从编码能力向系统能力拓展

不要只关注编写代码的效率，更要关注：

• 系统的可观测性
• 故障的检测和响应
• 变更的风险控制
• 容量和性能规划

2. 培养服务意识

将每个功能视为一个服务，思考：

• 这个服务如何长期稳定运行
• 如何监控其健康状况
• 出问题时如何快速恢复
• 如何防止级联故障

3. 学习 SRE 核心实践

• 错误预算管理
• 服务等级目标（SLO）设定
• 事故响应流程
• 变更管理策略
• 自动化运维工具链

七、总结

软件工程的未来不在于编写代码的能力，而在于运营卓越的能力。当 AI 让编码变得廉价时，能够长期稳定运行服务的工程师和组织将脱颖而出。

SRE 不是运维的别称，而是一种工程哲学：将运营本身视为工程问题，用系统化、自动化、数据驱动的方法来解决。

未来的软件工程师需要同时具备：

1. 编码能力（变得相对容易）
2. SRE 能力（变得愈发重要）

这意味着职业生涯的发展方向应当从"构建者"向"运营者"拓展，从"项目交付"向"服务负责"转型。

参考资料

1. The future of software engineering is SRE