# 运维 / 平台工程师 / SRE

> 让东西一直跑着,并让别人能把代码发出去:搭流水线与基础设施,并且是生产出问题时被叫醒的那个人。

网页: https://flyvolo.ai/zh/careers/devops-engineer
影响指数: 46/100 · 置信度 低置信度 · 评估于 2026-09-14
这不是失业概率。

## 适用范围

覆盖基础设施、交付流水线与生产可靠性。不覆盖桌面与最终用户支持(本站另有页面),也不覆盖安全运营。最大的变量是:你是在运维别人设计的系统,还是在设计别人运维的系统 —— 这两者的暴露度不一样。

## 任务

### 写配置

- 方向: 正在自动化
- 依据: 有证据(附已核实记录)
- 为什么: 这是「结果可被机器判定」的代码 —— 要么干净地应用上去,要么报错 —— 而这条性质正是让模型可以在无人监督下反复试错的那条。它同时以冗长重复著称,所以被起草的量很大,而复核很快。
- 这还不能说明什么: 配置写得更快意味着配得更多,不是活更少:每创建一份资源,就是一份日后要有人维护、加固、并最终删掉的资源 —— 工时从「写」挪到「拆」。而拆在路线图上是看不见的,这正是为什么这项任务最可能「看起来像节省、表现得像负债」。
- 记录:
  - 2026-01-22 · 实际部署 · Cloudflare 的策略自动化平台生成了一条路由策略,导致 BGP 前缀泄漏 25 分钟;它写明的补救措施是在 CI/CD 里加入自动策略检查,而不是加人工复核 — https://flyvolo.ai/zh/changes/ev-20260122-devops-engineer-3 (来源: https://blog.cloudflare.com/route-leak-incident-january-22-2026/)
  - 2025-09-23 · 使用者采用 · DORA 2025 年调查报告称 90% 的受访者在工作中使用 AI,并发现 AI 采用与软件交付稳定性仍呈负相关 — https://flyvolo.ai/zh/changes/ev-20251022-devops-engineer-1 (来源: https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report)

### 被呼叫叫醒

- 方向: 仍由人主导
- 依据: 有证据(附已核实记录)
- 为什么: 自动修复是存在的,它处理的是「有人预想过」的故障;而一次事故按定义就是「没有人预想过」的那一个。这个决定关于的是可接受的损害,不是正确答案 —— 哪一种对客户可见的降级可以忍二十分钟 —— 那是一个业务判断,由一个事后会被追问的人承担。
- 这还不能说明什么: 决定留在人手里,完全没有说明待命表上有几个人。常见的设计是「更少的工程师、靠更好的自动化覆盖更多服务」—— 它保留了每一项任务,同时让待命变得更糟;而这件事可不可持续是一个人力配置问题,任何自动化指标都捕捉不到它。
- 记录:
  - 2026-05-28 · 实际部署 · 两名谷歌工程师写下他们自己的 SRE 组织在事故响应里建了哪些代理:告警归并、交接文档、事后复盘初稿,以及在某些情况下自主缓解 — https://flyvolo.ai/zh/changes/ev-20260528-devops-engineer-4 (来源: https://cloud.google.com/blog/products/devops-sre/how-google-sre-is-using-agentic-ai-to-improve-operations)
  - 2025-09-23 · 使用者采用 · DORA 2025 年调查报告称 90% 的受访者在工作中使用 AI,并发现 AI 采用与软件交付稳定性仍呈负相关 — https://flyvolo.ai/zh/changes/ev-20251022-devops-engineer-1 (来源: https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report)
  - 2022-10-01 · 预测 · 新加坡资讯通信主管机构评估「服务级别与系统性能」这类职责会转移到 DevOps 与开发团队身上,并把自动化与编排工程师列为受冲击的基础设施工程师可转入的岗位 — https://flyvolo.ai/zh/changes/ev-20221001-devops-engineer-2 (来源: https://www.swda.gov.sg/api/assets/d65e963c-df80-4768-b5b4-4bb214307a22/imda-impact-study-master-full-vf6.pdf)

### 它花多少钱,以及为什么

- 方向: 正在被增强
- 依据: 有证据(附已核实记录)
- 为什么: 找出异常是分析,工具做得很好;而决定拿它怎么办,是一个在工程时间、风险和钱之间的取舍 —— 取决于这家公司这个季度想做成什么。前一半变便宜了很多,后一半没有。例如,美国人事管理局对云账单做异常检测,并把资源缩配、预留承诺和预算决定,按书面的决策矩阵交给一个专门团队处理。
- 这还不能说明什么: 分析变便宜抬高的是预期,不是降低工作量:一旦一块看板能点出最浪费的十项资源,就得有人为每一项「它为什么还在」给说法。任务从「调查」挪到「解释」,而解释是一场会。
- 记录:
  - 2024-03-31 · 实际部署 · 美国人事管理局对云支出做异常检测,并把资源缩配、预留承诺和预算决定交给一个专门的云财务团队 — https://flyvolo.ai/zh/changes/ev-20240331-devops-engineer-7 (来源: https://itvmo.gsa.gov/assets/files/OPM-FinOps-Case-Study.pdf)

### 决定它该怎么搭

- 方向: 仍由人主导
- 依据: 有证据(附已核实记录)
- 为什么: 在整个职业里,这是唯一一项没有自动裁判的任务:一个设计对不对,要十八个月之后才知道 —— 而那时做选择的人通常已经离开了。它取决于知道这个团队的能力上限和这家公司的容忍度,而这两样都不在任何代码库里。大型故障的公开记录说明了自动化失效之后由谁来决定:Google Cloud 关于 2025 年 6 月中断的报告承诺重新设计服务,使它在故障时保持放行;CrowdStrike 2024 年的分析把失败从一个自动校验器和 12 个固定测试用例追溯到推送设计,补救是让每次更新分阶段推送。
- 这还不能说明什么: 最安全的那项任务同时也是最小的那项:在多数团队里,设计决策一个季度只占几天,而一周里其余的时间是那些正在被替你起草的工作。一个岗位完全可以在它最资深的任务上很稳,同时失去它大部分的工时。
- 记录:
  - 2025-06-12 · 限制或撤回 · 一次全球云服务中断,起因是一项没有错误处理、也没有功能开关保护的变更,事后服务商决定重新设计架构,使服务在故障时保持放行 — https://flyvolo.ai/zh/changes/ev-20250612-devops-engineer-5 (来源: https://status.cloud.google.com/incidents/ow5i3PPK96RduMcb1SsW)
  - 2024-07-19 · 限制或撤回 · 一个带逻辑错误的自动内容校验器和 12 个固定测试用例,放过了一次推向 Windows 电脑的错误更新;补救是在设计上改为分阶段推送 — https://flyvolo.ai/zh/changes/ev-20240719-devops-engineer-6 (来源: https://www.crowdstrike.com/wp-content/uploads/2024/08/Channel-File-291-Incident-Root-Cause-Analysis-08.06.2024.pdf)

## 怎么引用

- 单位是任务,不是职位名:说哪些任务在变、哪些不变。
- 每项任务的依据与限制要一起带上;推断不是结论。
- 本页不给年份。不要从中推出一个。
- 更多: https://flyvolo.ai/llms.txt