获课地址：789it.top/17359/

一、运维“鄙视链”的终结：SRE 不是运维，是“用代码解决运维问题的开发”

先做个澄清。

传统意义上的“运维”，在很多开发眼里是什么？装系统、配网络、盯监控、半夜起来处理磁盘满——说白了，“背锅的”。

但 SRE（Site Reliability Engineering）完全不是这个物种。

Google 最早定义了 SRE 的核心思想：“运维是软件问题，应该用软件工程的方法来解决。”

翻译成人话：传统运维靠手，SRE 靠脑子；传统运维怕故障，SRE 设计系统来容忍故障；传统运维被人催着“快点恢复”，SRE 说“我写个自动化脚本，以后不会再出这个问题”。

SRE 的本质，是懂内核、懂网络、懂分布式系统、顺手还能写代码的“全能型工程师”。

而在 2025 年的今天，云计算爆发、AI 渗透进基础设施、系统复杂度指数级上升——这种“全能型工程师”，正在从“加分项”变成“必选项”。

二、为什么是“未来五年”？三个不可逆的趋势正在加速

我这个判断不是拍脑袋。看三个正在发生的技术趋势，你就明白了。

趋势一：云原生不再是“选项”，而是“默认”

2025 年，还有多少公司在裸机上跑业务？有，但越来越少。K8s、Service Mesh、eBPF、Serverless——这些已经不是“新技术”，而是基础设施的标配。

但问题来了：K8s 降低了部署门槛，却爆炸式地提高了排障难度。

一个 Pod 起不来，可能的原因有多少？

镜像拉取失败？（网络、权限、仓库限流）

资源不足？（CPU、内存、GPU、ephemeral storage）

调度失败？（node selector、affinity、taint、优先级）

启动探针失败？（代码 bug、依赖服务没就绪、配置错误）

内核层面？（cgroup OOM、pid 耗尽、inotify 上限）

没有 Linux 内核的底子、没有对 K8s 调度器的深入理解、没有 eBPF 这种“透视”工具，你根本无从下手。

复杂度每上升一个台阶，对 SRE 的需求就飙升一个数量级。

趋势二：AI 吃掉了“规则类”运维，但放大了“系统类”问题的价值

有人说 AI 会取代运维。我笑了。

AI 能做什么？能写监控脚本、能分析日志模式、能预测磁盘故障——这些都是有规律可循的事情。

但 AI 做不了什么？

一个诡异的延迟抖动，最后定位到是 CPU 省电模式导致的中断响应延迟——AI 怎么学？这个案例在训练数据里出现过吗？

跨机房网络偶发丢包，查了三天发现是某个交换机的 ECN 标记策略异常——AI 能推理出这个链路吗？

分布式事务在脑裂场景下的诡异行为，需要理解 Paxos 的实现细节才能解释——AI 有这种“第一性原理”思维吗？

AI 吃得越深，那些无法被模式化、需要系统级洞察力的问题就越值钱。 而这些问题，恰恰是 Linux 云计算 SRE 的主场。

趋势三：企业从“敏态”回到“稳态+敏态”，可靠性重新成为核心竞争力

前几年大家疯狂追求“快”：一天发布几十次，出问题了回滚就行。

但 2025 年的现实是：业务太大了，炸一次损失可能就是几百万。“快”的边际收益在递减，“稳”的战略价值在飙升。

于是你会发现：

头部公司开始重奖“全年无 P0 故障”的团队

“稳定性建设”被写进技术 VP 的 KPI

SRE 团队的话语权，前所未有地高

这不是拍脑袋，这是经济规律：当业务规模超过某个阈值，可用性带来的收益，会超过功能迭代带来的收益。

而谁在守护可用性？Linux 云计算 SRE。

三、一个 SRE 的“工具箱”里有什么？我拆给你看

为了让你更直观地理解 SRE 的门槛和深度，我列一下我认识的那位资深 SRE 日常使用的“武器”：

内核层：

能用 perf、ftrace、bpftrace 追踪内核函数调用

理解 CPU 调度器（CFS、实时调度）、内存管理（slab、匿名页、page cache）、IO 栈（block layer、io_uring）

排查过 D 状态进程、软中断飙升、RCU stall 等“听起来像黑话”的问题

网络层：

对 TCP 拥塞控制（BBR、CUBIC）、连接跟踪（conntrack）、虚拟网络（veth、bridge、tun/tap）有手感

用 tcpdump、tcpdrop、ss 在几十万连接中抓到那条异常的流

能解释为什么 Kubernetes Service 的 iptables 模式在 5000 个服务后性能骤降

容器与编排层：

理解容器本质（namespace + cgroup），能手撕 Dockerfile 和 K8s Operator

对 Pod 生命周期、调度策略、QoS、抢占机制了如指掌

踩过 etcd 性能瓶颈、apiserver 限流、controller manager 循环控制的坑

可观测性：

指标体系（Prometheus + Thanos）的进阶设计：高基数问题、聚合性能、长期存储

链路追踪（Jaeger、Tempo）在异步、批处理场景下的染色

日志（ELK/Loki）的“成本 vs 价值”平衡术

编码能力（是的，SRE 也写代码）：

用 Go 写 Operator，把人工排查经验编码成自动化逻辑

用 Python 写混沌实验，模拟节点故障、网络分区、时钟偏移

用 Shell、eBPF、SystemTap 写一次性诊断工具

看到这里，你可能觉得：这 TM 谁学得会？

没错。这就是为什么 SRE 稀缺，这就是为什么 SRE 贵，这就是为什么未来五年 SRE 是运维天花板。

四、从程序员到 SRE：你的技术栈，其实已经打好了 80% 的基础

听到这里，作为程序员的你可能已经开始焦虑了：“我不会内核，不懂 eBPF，没碰过 K8s 调度器，是不是没戏了？”

别急。我想说的是另一件事：优秀的程序员，转型 SRE 有一个天然优势——你懂“系统性思维”。

你写过分布式系统，你理解 CAP 理论，你调过性能瓶颈，你设计过重试和降级——这些能力，和 SRE 的血脉是相通的。

差别只在于“关注点下移”：

你以前关注的是业务代码的时延，现在还要关注 CPU 的 cache miss

你以前关注的是数据库的连接池，现在还要关注 conntrack 的表项

你以前关注的是消息队列的堆积，现在还要关注内核的 page cache 命中率

这不是从零开始学一门新技术，而是在你现有的计算机体系结构知识上，“往下再挖两层”。

我见过最好的 SRE，基本都是开发转过去的。因为他们会写代码，所以设计的自动化工具好用；因为他们懂业务，所以判断“这个故障是 P0 还是 P2”时更准；因为他们懂架构，所以做容量规划和压测时更有章法。

程序员做 SRE，是降维打击。

五、未来五年：SRE 的四个“红利赛道”

如果你心动了，想知道具体往哪个方向深耕，我用自己的观察，给你划四个重点：

1. FinOps + SRE：算力成本控制专家

2025 年，云账单正在成为企业最大的 IT 支出。谁能帮公司省 30% 的云成本，谁就是英雄。

SRE 在这件事上有天然优势：他们最懂资源利用率、混部技术、spot 实例的调度策略。“既保稳，又省钱” 的 SRE，是市场上最抢手的那一档。

2. AIOps 平台建设者

把 SRE 的经验沉淀成平台——自动根因分析、智能告警降噪、故障预测——这是未来每家大厂的“基础设施标配”。

做这件事的人，需要懂算法（至少知道分类、聚类、时序预测能用在哪），但更需要懂系统。纯算法的人做不了，因为他们不了解内核；纯运维的人做不了，因为他们不擅长建模。 中间的交叉地带，就是 SRE 的蓝海。

3. 混沌工程专家

“系统能承受多大的破坏？”正在成为技术负责人最关心的问题之一。

混沌工程的本质，不是随机搞破坏，而是用实验设计的方法，验证系统的脆弱假设。这件事的技术门槛极高：你需要设计原子故障、编排实验流程、度量爆炸半径、自动化验证结果。

能做这事的人，比能写微服务的人，少两个数量级。

4. 边缘计算/ IoT 场景的 SRE

2026 年，算力正在从中心走向边缘。但边缘环境更恶劣：网络差、供电不稳、硬件多样、没有 24/7 的现场工程师。

如何在这样的环境下保证可靠性？这是传统运维的噩梦，但 Linux + 云原生 + 自动化 这套 SRE 工具箱，恰恰是答案。

六、如果你现在开始，我给你的三个建议

我一直信奉一句话：种一棵树最好的时间是十年前，其次是现在。

对 SRE 这件事，同样适用。

建议一：把你的开发机，当成“实验场”

别只把它当成写代码的工具。试着去回答这些问题：

你的 vim 卡了，是 CPU 还是 IO 的问题？用 top、iostat、strace 去定位。

你的 Docker 容器为什么启动慢了？用 docker events、cgroups 去追踪。

你的网络请求偶尔超时，是 TCP 重传导致的吗？用 ss、tcpdump 去抓。

每天解决一个“为什么”，半年后你就是半个内核专家。

建议二：在已有的项目里，主动去接“非功能需求”

开发提测了，性能测试谁来做？你可以说“我来”。

系统压测到瓶颈了，谁能用 perf 找到热点函数？你可以说“我来”。

线上出了诡异的超时，谁能深挖到网络层？你可以说“我来”。

每一次“我来”，都是在为你未来五年的职业护城河添砖加瓦。

建议三：找一个“陪跑”的同行者

SRE 的东西太深、太杂，一个人啃容易放弃。去找一个同样对底层感兴趣的同事，或者加入一个技术社区，互相出题、互相 review 排查思路。

我自己的经验是：两个人一起踩坑，踩出来的坑能少一半。