1. “专家”不是头衔，而是一组可观察行为
面试官与评委很少根据你知道多少名词打分，而是看你是否能在模糊问题里划清边界、提出假设、给出可验证路径。 DevOps 专家常见画像包含：深度（CI/CD、K8s、观测、安全链至少两条能打穿）、 广度（能把依赖与风险连成系统图）、影响力（推动标准、降低他人摩擦）、 可靠性意识（SLO、错误预算、应急）与成本意识（FinOps 思维）。
自检：你能用一张图 + 三个数字讲清楚去年最重要的交付吗？若不能，故事还没“上岸”。
2. 能力模型：π 形技能与影响力阶梯
T 形是一专多能；π 形是双主干（例如平台工程 + SRE）；再往上，“梳子形”是多条深沟——适合架构/负责人。 晋升时别堆技能清单，而要展示主轴 + 可迁移的方法论：你如何定义问题、如何做实验、如何把成功复制给团队。
图 1：π 形不是“多报几个技能”——而是两条能独立交付的主干 + 跨域协作的底盘。
3. 面试答题框架：先对齐问题，再讲故事
听到开放题（“讲讲你做过的 GitOps”），先用 20 秒澄清：规模、约束、你的角色。 主体用情境—任务—行动—结果（STAR），但 DevOps 版要加一层技术纵深：关键接口、失败模式、你如何观测与回滚。 永远补一句量化：时间、成本、缺陷率、MTTR、部署频率变化——否则故事像小说。
// English outline you can reuse in interviews (STAR + engineering depth)
// S — Situation: team size, traffic, regulatory constraint, incident context
// T — Task: what success metric was agreed (SLO, lead time, cost)
// A — Action: your decisions; alternatives rejected; tools are secondary
// R — Result: before/after numbers; what you would improve next
// + Failure: one honest postmortem lesson (shows maturity)图 2：好答案像流水线——每一步都有产出；坏答案是跳到第 4 步开始背 kubectl。
4. 高频题型的应对策略
| Prompt style | What they probe | Strong response pattern |
|---|---|---|
| System design (CD) | boundaries, failure modes | draw data plane + control plane; cite GitOps + policy |
| Incident story | blameless process | timeline, mitigation, comms, permanent fix, metrics |
| Conflict / priority | stakeholder skill | framework: risk × urgency; document decision |
| Security vs velocity | judgment | shift-left + guardrails + exception path audited |
5. 晋升材料：从“我做了什么”到“世界因何变好”
评委在读晋升包时寻找：范围（跨团队？产品线？）、模糊性（你是否定义了问题）、 杠杆（平台化、制度、文档是否减少他人工作）、证据（指标、复盘链接、外部认可）。 用对比表呈现 before/after；附上关键设计文档或 ADR链接，比长段自夸更有说服力。
图 3：晋升叙事要从“交付物”爬到杠杆再爬到方向——与职级期望对齐。
6. 练习建议：把本教程变成你的案例库
回头翻阅本模块各章：每个主题准备一个两分钟故事 + 一个一分钟失败教训。 找同伴做模拟面试并录音：听自己是否用了模糊词（“优化了很多”），替换为数字与主语清晰的责任边界。
7. 本章清单
- 能用维度化能力模型自检：深度、广度、影响力、可靠性、成本。
- 掌握 STAR + 技术纵深 + 指标的答题结构。
- 能识别面试红旗与绿旗，针对系统设计/事故/冲突题型有套路。
- 晋升材料突出范围、杠杆与证据，而非形容词堆叠。
- 下一章：团队与组织——DORA、流程改造与文化建设。