先说我自己的样本：37 份 JD、12 场面试，DevOps 早就不是一个岗位
2024 年 3 月到 6 月，我一边上班一边面了 12 家公司，有 70 人的 SaaS、300 人的跨境电商、两家云原生创业公司。顺手把 37 份 DevOps/平台工程/SRE 的 JD 丢进表格里数关键词：CI/CD 出现 35 次，Kubernetes 32 次，Terraform 28 次，云厂商 30 次，监控告警 24 次，脚本 27 次，安全 13 次，平台工程 11 次。面试里 8 家问 K8s，6 家让我现场设计流水线，5 家问故障排查，4 家追 Terraform state，3 家问云成本。
我的独立观点可能有点刺耳：DevOps 工程师的核心产出不是 YAML、不是 Jenkinsfile、也不是几套 Helm chart，而是把“从代码合并到用户可用”的等待时间，和“生产故障到恢复”的时间压下去。你写 800 行 K8s manifest，如果发布还要等 40 分钟、回滚靠人登机器，那不叫 DevOps，叫用新工具做传统运维。
四个角色别混为一谈，我面试时踩过坑
| 角色 | 典型目标 | 常用指标 | 容易踩的坑 |
|---|---|---|---|
| 传统运维 | 机器别挂 | 可用性、工单量 | 把变更当风险，审批链太长 |
| DevOps 工程师 | 加速交付且可恢复 | DORA 四指标、SLO | 变成工具链管理员，所有流水线都自己写 |
| SRE | 用工程手段控制可靠性 | SLO、错误预算、MTTR | 只盯可用性，忽略交付速度 |
| 平台工程 | 给开发者铺黄金路径 | 开发者等待时间、采用率、NPS | 做了一堆没人用的门户 |
我面过一家 300 人公司，JD 写 DevOps，进去后 70% 时间在修 Jenkins 插件冲突，30% 在帮开发改 Dockerfile。二面我问：你们有 SLO 吗？面试官说“监控大盘有 CPU 和内存”。那一刻我知道这不是我要的岗位。另一个极端是创业公司，只有 3 个环境、8 个服务，却上了两个 K8s 集群，结果没人会排查 CoreDNS，发布窗口全靠创始人手动点。
所以我现在的判断标准很土：问三个数字。一天部署几次？变更失败率多少？MTTR 多少？答不上来，说明 DevOps 还停留在工具采购阶段。答得出来，哪怕没有 K8s，也值得聊。
如果让我带一个 8 人后端团队，4 周只做这些
第 1 周做资产盘点，不写代码。把 8 个服务、3 套环境、6 个定时任务、4 个数据库、2 个缓存列清楚。每个服务标记负责人、语言版本、部署方式、回滚命令。Go 服务记 1.22，Node 记 20，Postgres 记 15，Redis 记 7.2。没有负责人就写“未知”，别假装有。
第 2 周只铺一条黄金路径。CI 用 GitLab CI 或 GitHub Actions 都行，阶段固定为 lint、test、build、scan、deploy。缓存 key 用 go-$CI_COMMIT_REF_SLUG，不要带 commit SHA，否则基本不命中。Runner 从 2C4G 升到 4C8G，并发从 1 调到 3。我们那条 Go 流水线从 14 分钟降到 5 分 40 秒，p95 是 4 分 12 秒。镜像用 Trivy 扫，CVSS >=7.0 直接阻断，镜像体积压到 300MB 以下，非 root，只读 rootfs。
第 3 周加可观测性，别一上来搭 20 块大盘。先给一个核心接口定 SLO 99.9%，月度错误预算 43 分 12 秒。Prometheus 告警分两级：burn rate >14.4 且窗口 1 小时，发 page；burn rate >6 且窗口 6 小时，发 ticket。K8s 里 CPU requests 100m、limits 500m，内存 requests 128Mi、limits 256Mi 只适合小服务；Java 服务要把 -XX:MaxRAMPercentage=75 写上，否则 limits 256Mi 很容易 OOMKilled。HPA 设 min 2、max 10、target CPU 65%，PDB 设 minAvailable 1。
第 4 周做回滚演练。Argo CD 用 automated、prune true、selfHeal true，retry limit 5、backoff 5s，sync timeout 180s。数据库迁移用 expand-contract：先加列、双写、回填，再切读，最后删旧列。回滚命令写进 runbook：kubectl rollout undo deployment/foo --to-revision=3。演练一次，把 MTTR 从 42 分钟压到 11 分钟。做不到 11 分钟也别编，先记录真实值。
面试被问“怎么做 CI/CD”，我现在的答法
别背“持续集成是频繁合并代码”。我会先反问：你们一天部署几次？变更失败率多少？回滚谁做？然后讲一个我自己的项目。S：8 个 Go 服务，Jenkins 单节点，构建 14 分钟，每周发 2 次。T：目标 p95 小于 6 分钟，失败率低于 15%。A：升 runner 到 4C8G，加 Docker layer cache 和 go mod cache，测试并行 4，Trivy 只扫变更镜像，Argo CD 自动同步。R：p95 4 分 12 秒，部署频率从每周 2 次到每天 1.8 次，失败率从 22% 降到 9%，MTTR 从 42 分钟到 11 分钟。
这套答法比“熟悉 Kubernetes、Docker、Jenkins”有用，因为面试官能继续追问：为什么失败率不是 0？因为数据库迁移和第三方支付回调就是会出问题，目标不是 0，而是可恢复。为什么不用蓝绿？因为 8 个服务里 3 个有状态，蓝绿成本高于滚动加 PDB。为什么 Argo CD 开 selfHeal？因为有人手动改过 prod 的 replica，结果 HPA 和 Git 状态打架。
最后说点得罪人的
如果你现在只会写 Dockerfile 和 kubectl apply，别急着背 CKAD。花 2 周把一条流水线的 p95 等待时间从 18 分钟压到 6 分钟，比多考一张证有用。再花 1 周给一个服务加 SLO 和 burn rate 告警，最后写一份回滚 runbook 并真的演练一次。CKA 我考过，但真正让我拿到 offer 的，是一次 OOMKilled 排查和一次数据库迁移回滚方案。
DevOps 工程师的“深”，不是 YAML 写得长，也不是能背出 30 个 CNCF 项目。是你敢在事故群里说：先回滚到 revision 3，数据库迁移已经兼容旧代码，11 分钟后恢复。然后第二天把这次故障变成一条自动化检查、一个告警阈值、一段 runbook。工具会换，K8s 会换，Jenkins 会死，但这个循环不会。