面试 · 系统串联题

一题炸开成知识树。 这类题凌驾于 1-5 类题型之上，单独成档。1-5 类考的是「点」——概念解释考一个概念、对比辨析考一组区分、原理追问考一个机制、场景排查考一次排障、方案设计考一次选型；锚点题考的是「线」：一句主问题串起横跨多个阶段（提交→CI→制品→CD→GitOps→可观测→安全→IaC）的一整条链路，考官从任意一个环节都能往下钻 4-5 层，一路追问决定这轮面试的深度和你的段位。

怎么用这份档： 先用 1-5 类把「点」吃透，再用锚点题把点串成网。每道锚点题的「考官追问链」会下钻到 1-5 类的具体题目，已标注交叉引用（如「见 1-概念解释型·子类1·题目2」），顺着追问链把相关的点复习一遍，就能把一棵知识树连根拔起。锚点题往往是面试开场题（「讲讲你们的 CI/CD 流程」「线上出过什么事故」），答得有骨架、能主动往深处引，就掌握了这轮的节奏。

技术基准（2026-07 校准）： GitOps 推拉模式、ArgoCD 3.x（server-side diff 已成默认）、Cosign keyless（Fulcio 短时证书 + Rekor v2）、SLSA v1.2（build track L1-L3）、Terraform BSL 1.1（IBM 2025-02 完成收购、license 未变）与 OpenTofu（MPL、CNCF sandbox、已成多数引擎）、Prometheus 3.0（原生 OTLP）+ OpenTelemetry（2026 事实标准）。

锚点题 1：一行代码从提交到上线，完整经过哪些环节？每个环节的质量门禁是什么？#

为什么是锚点题：这是 DevOps 的「总题」。几乎每场 DevOps / SRE / 平台工程面试都会以某种变体开场（「讲讲你们的 CI/CD 流程」）。它一句话能把整个交付链路考完，考官顺着任何一个环节都能继续钻，是判断你「用过工具」还是「理解体系」的分水岭——答得有分层有门禁 = 有全局观，答成一堆工具名罗列 = 只摸过局部。

会串出的知识点地图（按环节分层）：

• 源码层：分支策略（GitHub Flow / trunk-based）、PR/MR、分支保护、CODEOWNERS、pre-commit 钩子、commit 签名（GPG/SSH signing）
• CI 层：触发器、构建、单测/集成测、代码扫描（SAST/lint）、依赖扫描（SCA）、覆盖率门禁、质量门（SonarQube quality gate）
• 制品层：Dockerfile 多阶段构建、镜像 tag 策略（禁 latest）、镜像扫描（Trivy）、镜像签名（Cosign keyless）、SBOM 生成、推私有仓（Harbor / ECR）
• CD 层：GitOps（改 image tag → git push）、ArgoCD 同步、渐进式发布（蓝绿 / 金丝雀）、Argo Rollouts、AnalysisRun 自动分析
• 运行时/验证层：健康检查、金丝雀指标分析、可观测验证（SLO / 错误预算）、准入控制（验签拦截）
• 治理面：环境晋级（QA→PRE→PROD）、审批门、DORA 指标度量

考官追问链：

1. （现象）「你说 CI 通过就能部署，那 CI 里具体跑哪些检查？覆盖率门禁卡多少合理？」→ 测试金字塔、增量覆盖率 vs 全量覆盖率、门禁卡太死反而逼人绕过。
2. （机制）「镜像从构建到进集群，怎么保证跑的就是 CI 构建的那个、没被人换掉？」→ 引出签名 + 验签 + digest 固定（不可变 tag / 按 digest 部署），直接串到锚点题 5。
3. （边界）「CI 通过 ≠ 上线成功，从 git push 到 Pod 真正 Ready 中间还会挂在哪？」→ ArgoCD sync 失败、镜像拉取失败、readiness 不过、金丝雀被 abort，串到锚点题 4 和「4-场景排查型·子类1」。
4. （治理）「这套链路你怎么度量它健康不健康？」→ DORA 四指标 + 可靠性，lead time 拆解到每个环节耗时。
5. （区分度）「哪个环节最容易被跳过 / 走捷径？出过什么事？」→ 紧急上线绕过审批直连集群、门禁误报多到形同虚设、hotfix 不走流程。

参考答题骨架：

我按 提交 → 集成 → 制品 → 部署 → 验证 五段讲，每段有进入下一段的门禁。 ① 提交：feature 分支 + PR，main 分支保护禁直推，PR 触发 CI 且必须绿 + 至少一人 review 才能合。 ② 集成（CI）：构建 → 单测/集成测 → SAST + 依赖扫描 → 覆盖率门禁。门禁不过不产出制品。 ③ 制品：多阶段 Dockerfile 构建瘦镜像 → Trivy 扫描（critical 卡死）→ Cosign keyless 签名 + 生成 SBOM → 推 ECR/Harbor，tag 用 commit短hash-时间戳（禁 latest），全环境复用同一镜像 digest。 ④ 部署（CD）：CI 不碰集群，只改 GitOps 仓库的 image tag 并 push；集群内 ArgoCD 拉取并 sync；核心服务走 Argo Rollouts 金丝雀，AnalysisRun 跑指标自动判断继续还是回滚。 ⑤ 验证：准入控制器验签拦截未签名镜像；金丝雀期观测错误率/延迟/饱和度，达标才全量。 晋级用 QA 自动 → PRE/PROD 人工审批，schema 变更单独做兼容检查；最后用 DORA 度量整条链路。

（这套流程的完整仓库目录结构和 deploy.py 落地版见「5-方案设计型·子类1·题目1」。）

踩坑 / 加分点：

• 一次构建、多环境晋升同一镜像 digest——绝不各环境各构建一次，否则「测过的」和「上线的」不是同一个二进制。
• 门禁不能只加不管误报：SAST/SCA 误报多了开发会集体 # nosec，门禁形同虚设 → 要维护 baseline / 白名单 + 定期治理。
• CI 与 CD 的边界 = 谁持有 kubeconfig（呼应 GitOps 四公理，见「1-概念解释型·子类1·题目2」），CI 直接 kubectl apply 是 CIOps 不是 GitOps。
• lead time 要拆到「PR 等 review 的时间」——很多团队工具全上了，瓶颈却是 review 排队 3 天（Lean 浪费），呼应 CALMS 的 L。
• 加分：提 SLSA build track（provenance 从 L1 到 L3），说清你们的流水线达到哪一级、gap 在哪。

锚点题 2：一次部署上线后线上出故障，你怎么快速止血 + 定位 + 让它不再发生？#

为什么是锚点题：直接考事故处理能力，是 SRE / 高级 DevOps 的核心区分度题。它同时考「急」（止血速度）和「稳」（根因 + 预防），一眼看出你是「手忙脚乱型」还是「有 playbook 型」。而且它天然串起回滚机制、可观测定位、无指责复盘，一题打通「救火 → 防火」。

会串出的知识点地图：

• 止血层：回滚手段（kubectl argo rollouts undo / GitOps git revert / 金丝雀 abort / feature flag 关开关 / 扩容 / 限流 / 熔断）、「止血优先于定位」原则
• 定位层：三支柱（metrics 发现异常 → trace 定位服务 → log 看细节）、变更关联（最近 deploy 的 diff）、对比法（金丝雀 vs baseline）
• 根因层：5 Why、「新代码 bug vs 配置/密钥 vs 依赖/容量」三类根因分流
• 预防层：补门禁（加测试/扫描）、加金丝雀 + 自动分析、加告警（SLO burn rate）、加混沌演练
• 文化层：无指责复盘（blameless postmortem）、行动项闭环、错误预算

考官追问链：

1. （现象）「半夜告警说错误率飙升，你第一步做什么？」→ 先止血不定位：先回滚 / 关流量恢复用户，再慢慢查（区分「先救人还是先验尸」）。
2. （机制）「你说回滚，GitOps 下怎么回滚？git revert 和 rollout undo 有什么区别？」→ revert 走 Git 有审计但稍慢、undo 快但会与 Git 漂移（呼应锚点题 4）；还要讲 ArgoCD selfHeal 会不会把你手动 undo 又拉回去。
3. （边界）「如果回滚了还没好呢？」→ 说明不是这次发布的问题，转向依赖 / 容量 / 上游：看 trace 找到底哪个服务，是不是下游 DB 慢 / 限流 / 证书过期 / DNS。
4. （治理）「查到根因后，怎么保证同样的问题不再发生？」→ 不是「下次小心」，是补门禁 / 加金丝雀 / 加告警——把教训固化进流水线。
5. （区分度）「复盘会上你怎么写？谁背锅？」→ blameless，对事不对人，产出可验证的 action item 并跟踪关闭。

参考答题骨架：

我分四步：止血 → 定位 → 根因 → 固化，顺序不能乱。 ① 止血（分钟级）：先恢复用户，不纠结原因。金丝雀期就 abort；已全量就 rollout undo 或 GitOps revert 回上个已知好版本；若是流量/容量问题就限流 + 扩容。同时拉起 incident channel。 ② 定位（并行）：metrics 看哪个服务的哪个 SLI 崩了（错误率/延迟/饱和度）→ trace 定位到调用链哪一跳变慢/报错 → log 看具体异常。同时看「最近有什么变更」——90% 的线上故障是变更引起的，先看最近 deploy 的 diff。 ③ 根因：区分是新代码 bug、配置/密钥错、还是依赖/容量。用 5 Why 挖到系统性原因（为什么测试没拦住？为什么没灰度？）。 ④ 固化：把根因转成门禁——缺测试就补用例、没灰度就上金丝雀 + 自动分析、发现太晚就加 SLO burn-rate 告警。最后 blameless 复盘，action item 挂 owner 和 deadline。

（回滚的具体命令和 GitOps revert vs rollout undo 的漂移问题见「4-场景排查型」和本档锚点题 4；三支柱定位链路见锚点题 8。）

踩坑 / 加分点：

• rollout undo 后 ArgoCD selfHeal 会把 image tag 又拉回故障版本——真正止血要同时改 Git（revert）或临时 disable auto-sync，否则「回滚了又被拉回来」。
• DB schema 变更引起的故障，回滚代码不解决问题——加了非空列、删了字段，代码回滚了但 DB 已变；必须走 expand/contract 双写迁移（呼应 schema check pre-warning/post-fail）。
• 止血时最忌「边查边不回滚」，用户在流血你在验尸——MTTR 里最大的浪费是「舍不得回滚想直接修」。
• 加分：讲 SLO 错误预算——这次故障烧了多少预算、烧光了要冻结发布，把可靠性变成可量化的闸。
• 加分：区分「回滚能解决的」（新版本 bug）和「回滚不能解决的」（依赖挂 / 容量 / 证书过期 / DNS），后者回滚只会浪费时间。

锚点题 3：怎么设计一套多环境（dev/staging/prod）的配置与密钥管理？#

为什么是锚点题：几乎所有真实系统都有多环境，「配置和密钥怎么管」是必然要回答的工程问题，高频且高杠杆。它区分「把密钥写进 ConfigMap / 代码」的新手和「分层 + 外部密钥源 + 晋级审计」的成熟工程师。一题串起配置分层、密钥方案选型、环境一致性、以及 GitOps 里「密钥不能明文入 Git」的经典矛盾。

会串出的知识点地图：

• 配置分层：Kustomize base + overlay / Helm values 分层（values.yaml + values-{env}.yaml）；哪些该共享、哪些该按环境覆盖
• 密钥方案：K8s Secret 只是 base64 不是加密 → Sealed Secrets（非对称加密、密文可入 Git）/ SOPS（文件级值加密 + KMS/age）/ External Secrets Operator（从 AWS SM / Vault 同步）/ Vault（重型、动态密钥）
• GitOps 与密钥的矛盾：GitOps 要一切入 Git，但明文密钥不能入 Git → SealedSecrets/SOPS 让密文可入 Git、ESO 让 Git 里只存引用
• 环境一致性：配置漂移防治、「在我这好好的」、dev/prod 差异最小化
• 晋级 / 治理：同一制品多环境晋升、审批 + 审计、密钥轮转、最小权限 RBAC

考官追问链：

1. （现象）「K8s 的 Secret 安全吗？直接 kubectl create secret 有什么问题？」→ base64 不是加密、etcd 里默认明文、进 Git 就等于泄露。
2. （机制）「GitOps 要求一切入 Git，密钥怎么入 Git 又不泄露？」→ 三条路：SealedSecrets（密文入 Git、controller 私钥解）、SOPS（值加密）、ESO（Git 只存引用、运行时拉），讲各自的 trust 边界。
3. （边界）「ESO / Sealed Secrets 各自的失效场景？」→ SealedSecrets 私钥丢了所有密文作废、跨集群不通用；ESO 依赖外部 provider 可用性、provider 挂了同步失败；Vault 运维重。
4. （治理）「密钥轮转怎么做？谁能看 prod 密钥？怎么审计谁读过？」→ 外部 provider 做轮转 + 版本 + 访问审计，K8s 侧最小权限 RBAC，禁人肉 kubectl get secret prod。
5. （区分度）「怎么保证 dev 和 prod 的配置差异是『受控的』而不是『漂的』？」→ 差异集中在 overlay / values-env，base 共享；环境差异走 review，禁止手改集群。

参考答题骨架：

分三件事：配置分层、密钥外置、晋级审计。 ① 配置分层：Kustomize base + 各环境 overlay（或 Helm base values + values-{env}）。base 放全环境共享的（端口、探针、通用 env），overlay 只放差异（副本数、资源 quota、域名、环境标）。原则是「差异最小化，能共享的绝不各写一份」。 ② 密钥：K8s Secret 只是 base64，绝不明文入 Git。按团队现状选：

• 已有 AWS Secrets Manager / Vault → External Secrets Operator，Git 里只存 ExternalSecret 引用，运行时同步成真 Secret；密钥本体在外部 provider，天然有轮转 + 审计 + 版本。
• 轻量、想全存 Git → SealedSecrets（controller 公钥加密、密文安全入 Git、只有集群内私钥能解）或 SOPS + KMS。
• 需要动态 / 短期密钥（DB 临时凭据）→ Vault，但要接受它的运维成本（seal/unseal、HA/DR）。 ③ 晋级 + 审计：制品一次构建多环境晋升，配置随 overlay 变；PRE/PROD 配置改动走 PR review + 审批；密钥读取走外部 provider 的审计日志，K8s 侧 RBAC 最小权限。

（配置分层的仓库结构见「5-方案设计型·子类1·题目1」的 gitops 目录；Helm vs Kustomize 的取舍见「2-对比辨析型·子类1·题目3」。）

踩坑 / 加分点：

• K8s Secret 默认在 etcd 里明文存——要开 encryption at rest（KMS provider），否则拿到 etcd 备份 = 拿到所有密钥。
• SealedSecrets 的 controller 私钥是命门——私钥没备份 + 集群重建 = 所有密文永久作废；且密文绑定 namespace + name，改名就解不开。
• ESO 的坑：provider 侧改了密钥，K8s Secret 同步过来了但 Pod 不会自动重启用新值——要配 Reloader（如 Stakater Reloader）触发滚动更新。
• 别把「配置」和「密钥」混在一个机制里：非敏感配置用 ConfigMap / overlay 就行，硬塞进密钥系统只会增加复杂度。
• 加分：讲「环境一致性」——dev 用 mock、prod 用真实，配置结构必须一样只是值不同，否则 prod 才暴露的配置项就是定时炸弹。
• 加分：ESO 是 CNCF 项目（sandbox），2026 已是 K8s 外部密钥事实标准；Vault 被 IBM 收购（2025）不影响开源版，但要关注长期走向。

锚点题 4：GitOps 下线上状态和 Git 不一致（漂移）了，你怎么发现和处理？#

为什么是锚点题：GitOps 是现代 CD 的事实标准，「漂移」是 GitOps 独有且必然遇到的问题，考官用它验证你是「真跑过 ArgoCD」还是「只看过 PPT」。它串起 GitOps 四公理、reconcile 机制、selfHeal / ignoreDifferences、审计溯源、以及 HPA/Operator 造成的合法漂移辨析——层次极其丰富。

会串出的知识点地图：

• 漂移本质：期望状态（Git）vs 实际状态（集群）不一致；OutOfSync
• 发现机制：controller 持续 reconcile（默认约 3min 轮询 + webhook 触发）、diff 计算、UI/CLI 显示 OutOfSync 及 diff detail
• 处理策略：手动 sync / 自动 sync（automated）/ selfHeal（自动纠正漂移）/ prune（删 Git 里没有的）
• 合法漂移 vs 非法漂移：HPA 改 replicas、Operator 改状态、admission webhook 注入 sidecar → ignoreDifferences 忽略；人肉 kubectl edit → 纠正 + 追责
• 溯源：谁改的？K8s audit log / ArgoCD event / managedFields（server-side apply 的 field manager）
• 相关演进：ArgoCD 3.x 起 server-side diff 成默认，大幅减少 diff 误报

考官追问链：

1. （现象）「ArgoCD 显示 OutOfSync，怎么知道是哪个字段漂了、谁改的？」→ 看 diff detail（Git 期望 vs live）、看 managedFields 的 manager（kubectl-edit / hpa / argocd）、查 K8s audit log。
2. （机制）「selfHeal 开了它就自动纠回来了，为什么还要关心漂移？」→ selfHeal 会覆盖掉合法的运行时变更（HPA 扩的容被拉回、临时排障改的被冲掉），且掩盖了「有人在手改集群」这个信号。
3. （边界）「HPA 明明就该改 replicas，ArgoCD 天天报 OutOfSync 怎么办？」→ ignoreDifferences 忽略 spec.replicas（或 Git 里干脆不写 replicas）；区分「预期内的动态字段」和「真漂移」。
4. （治理）「怎么从制度上减少非法漂移？」→ 收走开发对 prod 的集群写权限、一切变更走 Git PR、selfHeal + 告警（漂移即告警，说明有人绕过流程）。
5. （区分度）「漂移引发过什么事？」→ 有人 kubectl 手改救火忘了回填 Git，下次 sync 被覆盖故障复现；或 selfHeal 把救火的紧急改动秒回滚。

参考答题骨架：

先讲为什么会漂：GitOps 的 controller 持续对比 Git（期望）和集群（实际），只要有人绕过 Git 直接改集群（kubectl edit / HPA / Operator / webhook 注入），就 OutOfSync。 发现：ArgoCD 每约 3 分钟 reconcile 一次（也可 webhook 即时触发），diff 出来标 OutOfSync，UI/CLI 能看到具体哪个字段、Git 值 vs live 值。3.x 起默认 server-side diff，大幅减少了以前 client-side diff 的误报。 处理分两类：

• 非法漂移（人肉手改）：手动 sync 拉回或开 selfHeal 自动纠回；关键是配告警——漂移本身就是「有人绕过流程」的信号，要追是谁改的（managedFields 的 field manager + K8s audit log）。
• 合法漂移（HPA / Operator / webhook 注入）：用 ignoreDifferences 显式忽略这些字段，或 Git 里干脆不管这些字段，否则天天误报会让人对告警脱敏。 治理：GitOps 落地后就该收走开发对 prod 的 kubectl 写权限，一切变更走 Git PR；selfHeal + prune 让集群严格收敛到 Git；紧急救火如非改集群不可，改完立刻回填 Git，否则下次 sync 复现故障。

（GitOps 四公理和「谁持有 kubeconfig」见「1-概念解释型·子类1·题目2」；漂移排查决策树见「4-场景排查型」。）

踩坑 / 加分点：

• selfHeal 是双刃剑：它纠正非法漂移，但也会把你救火时的紧急改动秒回滚——救火要么 disable auto-sync，要么直接改 Git。
• ignoreDifferences 滥用会掩盖真漂移——只忽略确定的动态字段（replicas / 注入的 sidecar），别图省事忽略一大片。
• HPA + Git 里写死 replicas = 打架：ArgoCD 把 replicas 拉回 3、HPA 又扩到 10，反复横跳——Git 里不要写 replicas，交给 HPA。
• managedFields 是溯源利器：server-side apply 记录了每个字段的 field manager，能看出「这个字段最后是 kubectl 人肉改的还是 argocd-controller 改的」。
• 加分：区分 ArgoCD 的 Sync status（跟 Git 比） 和 Health status（跟实际健康比）——这俩正交，OutOfSync 但 Healthy 很常见（如刚被 HPA 改过）。
• 加分：Flux 没有 selfHeal 这个开关概念，它默认就持续 apply（本质等价于 always selfHeal）；推拉都是 pull——顺带辨析 ArgoCD vs Flux。

锚点题 5：镜像供应链从构建到部署，怎么保证不被投毒？#

为什么是锚点题：供应链攻击（SolarWinds、xz backdoor）是近年安全最热的攻击面，DevSecOps 岗必问，普通 DevOps 岗也越来越常问。它区分「知道要扫镜像」的初级选手和「签名 + SBOM + 准入 + SLSA」的体系化选手。一题串起构建、扫描、签名、SBOM、准入控制、私有仓、SLSA 分级。

会串出的知识点地图：

• 构建期：多阶段构建（瘦镜像、不带编译工具链）、最小基础镜像（distroless / alpine）、base image 固定到 digest、可信构建环境（SLSA build L2/L3）
• 扫描：Trivy / Grype 扫 OS 包 + 语言依赖 CVE、扫 IaC/Dockerfile 配置、扫密钥泄露
• 签名：Cosign keyless（Fulcio 签发短时证书绑 OIDC 身份、Rekor 透明日志）vs 传统 key-based
• SBOM：syft 生成、格式（SPDX / CycloneDX）、作为 attestation 签名附加、用于漏洞回溯
• 溯源：SLSA provenance（谁构建的、从哪个 commit、什么流水线），build L1 → L3
• 准入控制：admission controller（Sigstore policy-controller / Kyverno）验签 + 验 attestation，拒绝未签名 / 身份不符 / 有 critical CVE 的镜像
• 私有仓：Harbor（自带扫描 + 签名验证 + 复制 + RBAC）、ECR

考官追问链：

1. （现象）「你怎么保证部署的镜像就是你 CI 构建的那个，中间没被替换？」→ 签名 + 验签：Cosign 对 digest 签名，集群准入时验签，digest 不可变。
2. （机制）「Cosign keyless 没有私钥，那签名靠什么？丢了怎么验？」→ Fulcio 用 OIDC 身份（如 GitHub Actions workflow identity）签发约 10 分钟的短时证书，签完即弃，签名 + 证书进 Rekor 透明日志；验签时验「是不是这个身份 + 这个 issuer 签的」。
3. （边界）「签了名就安全了？签名能防住 base image 本身被投毒吗？」→ 不能，签名只证明「是我构建的」不证明「内容干净」→ 需要 SBOM + 扫描 + 固定 base digest，纵深防御。
4. （治理）「怎么在集群层面强制『没签名 / 没扫过的镜像不许跑』？」→ admission controller（policy-controller / Kyverno）配 ClusterImagePolicy，验签 + 验 attestation + 验 identity，不满足直接拒绝创建 Pod。
5. （区分度）「你们做到了 SLSA 第几级？gap 在哪？」→ 讲 build L1（有 provenance）→ L2（托管构建平台生成、签名 provenance）→ L3（隔离、防篡改、签名密钥用户步骤不可见），说清现状和差距。

参考答题骨架：

我按「构建可信 → 内容可查 → 身份可证 → 准入可挡」四段讲，是纵深防御不是单点。 ① 构建可信：多阶段构建产出瘦镜像（不带编译工具链），base image 用 distroless 且固定到 digest 而非 tag；构建跑在托管平台（GitHub Actions / Cloud Build），朝 SLSA build L2/L3 走——provenance 由平台生成、构建间隔离、签名密钥用户步骤碰不到。 ② 内容可查：Trivy 扫 CVE（critical 卡门禁），syft 生成 SBOM（SPDX / CycloneDX），SBOM 作为 attestation 附加到镜像。 ③ 身份可证：Cosign keyless 签名——Fulcio 用流水线的 OIDC 身份签发短时证书，签名 + 证书写入 Rekor 公开透明日志，无长期私钥可泄露；provenance 和 SBOM 也一并签成 attestation。 ④ 准入可挡：集群装 Sigstore policy-controller 或 Kyverno，配策略「只有被指定身份签名、且带合规 attestation 的镜像才准跑」，否则拒绝创建 Pod。镜像统一走私有仓 Harbor（自带扫描 / 复制 / RBAC）。

（安全左移 + 右移的全景见「1-概念解释型·子类4·题目1」；镜像扫描/签名在流水线里的位置见本档锚点题 1。）

踩坑 / 加分点：

• 签名 ≠ 干净：Cosign 只证明「这个身份签的」，防替换不防投毒；base image 被投毒照样签得下去——必须配扫描 + SBOM + 固定 base digest。
• keyless 验签必须校验 identity + issuer：只验「有签名」没验「谁签的」等于没验，攻击者用自己的 GitHub 身份也能签——策略里要钉死 --certificate-identity 和 --certificate-oidc-issuer。
• Rekor v2 已 GA（2025-10，换成 Trillian-Tessera tile-based 后端），v1 有 1 年弃用期，Cosign v2.6+ 通过 TUF 分发的 TrustedRoot 自动切——面试提这个显示你跟得上生态。
• 固定 base image 用 tag（如 alpine:3.19）不够，tag 可变、可被重推——要 pin 到 alpine@sha256:... digest。
• 准入拦截别一上来 enforce：先 audit / warn 模式跑一段看误伤，再切 enforce，否则一开就全线 Pod 起不来。
• 加分：SLSA v1.0（2023）定义 build track，2026 已到 v1.2（build 分级不变）；能说清「provenance 是什么、L2 和 L3 差在哪（L3 要求签名密钥用户步骤不可访问 + 构建间隔离）」是硬核加分。

锚点题 6：CI 流水线越来越慢，你怎么系统性优化？#

为什么是锚点题：随团队和代码增长，流水线变慢是 100% 会发生的事，「怎么优化」高频出现且能体现你对 CI 各环节成本的理解深度。区分「加机器」的粗暴派和「分层缓存 + 并行 + 增量 + 分级」的体系派。

会串出的知识点地图：

• 诊断：per-stage timing 定位瓶颈在 build / test / deploy 哪段（先测量再优化）
• 构建加速：Docker layer 缓存（层顺序、变动少的放前面）、BuildKit + cache mount、依赖缓存（pip/npm/go mod）、远程构建缓存、多阶段构建减少重复
• 测试加速：测试分级（单测每次跑、集成/e2e 按需）、并行分片（sharding）、只跑受影响的测试（affected / 增量）、fail fast
• 并行与拆分：stage 并行、monorepo 只构建变更的服务（path filter / affected graph）
• 资源：runner 池扩容 / 自动伸缩、更快的机器、缓存命中率
• 制品：镜像瘦身减少推拉时间、跨境 registry 换本地 mirror
• 治理：给流水线设 SLO（如 P95 < 10min），持续监控

考官追问链：

1. （现象）「流水线从 5 分钟变 30 分钟，你先干嘛？」→ 先分 stage 测量定位是哪段慢，不要瞎猜瞎优化（呼应「4-场景排查型·子类1·题目1」）。
2. （机制）「Docker 构建慢，layer cache 为什么老失效？」→ 层顺序问题：COPY . . 放在装依赖之前，任何代码改动都让依赖层缓存失效 → 先 COPY 依赖清单装依赖、再 COPY 源码。
3. （边界）「测试太多跑不完，全并行行不行？」→ 并行受 runner 资源和测试间共享状态限制，且 e2e 不该每次全跑 → 分级 + 增量（只跑受影响的）。
4. （治理）「怎么防止它又慢回去？」→ 给流水线设时长 SLO 并监控，PR 里若显著拉长时长要 flag；缓存命中率作为指标。
5. （区分度）「加机器和优化流程，你先做哪个？」→ 加机器治标（贵、有并发上限），优化缓存 / 增量 / 分级治本；先测量找瓶颈再决定。

参考答题骨架：

原则：先测量定位，再对症下药，别一上来加机器。 ① 定位：分 stage 计时，看瓶颈在拉依赖 / 构建 / 测试 / 部署哪段。 ② 构建：BuildKit + 合理 layer 顺序（依赖清单先 COPY 并安装、源码后 COPY，让依赖层稳定命中缓存）+ cache mount 缓存 pip/npm/go mod；base image 用本地 mirror（跨境慢）。 ③ 测试：分级——单测每 PR 全跑且 fail fast，集成/e2e 按需或定时；大测试集并行分片；monorepo 只跑受影响服务的测试（affected graph）。 ④ 并行/拆分：无依赖的 stage 并行；monorepo 用 path filter 只构建变更的服务。 ⑤ 资源：runner 自动伸缩兜底峰值，但只在优化到位后再加。 ⑥ 治理：给流水线设 P95 时长 SLO + 缓存命中率监控，退化就告警。

（完整排查决策树见「4-场景排查型·子类1·题目1」，本题侧重优化策略的系统性取舍。）

踩坑 / 加分点：

• 最经典的坑：Dockerfile 里 COPY . . 放在 RUN pip install 之前，任何代码改动都让依赖层缓存失效——分两次 COPY 是第一优化。
• CN 构建机的特殊坑：# syntax=docker/dockerfile:1 和 --mount=type=cache 要访问 Docker Hub，境内构建机可能拉不到——呼应「5-方案设计型」的 CN 构建机坑。
• 缓存命中率是隐形指标：cache 存了但每次 key 都变（如 key 里带了时间戳）= 等于没缓存。
• 并行不是越多越好：runner 资源固定时过度并行会互抢 CPU 反而更慢；共享 DB 的测试并行会串数据。
• 加分：讲「流水线也是产品」，给它设 SLO、度量它对 DORA lead time 的贡献；慢流水线是最大的 Lean 浪费（呼应 CALMS 的 L）。
• 加分：远程 / 分布式构建缓存（sccache、BuildKit registry cache）让多 runner 共享缓存，比单机 cache 命中率高。

锚点题 7：Terraform/OpenTofu 的 state 是什么？多人协作和 state 漂移怎么治理？#

为什么是锚点题：IaC 是基础设施层的核心，而 state 是 Terraform / OpenTofu 一切行为的根基，「state 怎么管」必问。它区分「本地跑过 terraform apply」的入门和「remote backend + 锁 + 漂移治理 + 协作」的生产选手。一题串起 state 本质、远程后端、锁、漂移、import、协作、以及 2023 之后的 BSL / OpenTofu 生态变局。

会串出的知识点地图：

• state 本质：.tf 期望配置 + 云上真实资源的映射表（resource → 真实 ID/属性），plan = 期望 vs state vs 真实的三方 diff
• 远程后端：S3 + DynamoDB / GCS / Terraform Cloud、后端加密；为什么不能放本地 / Git
• 锁：state locking 防并发 apply 互相破坏（DynamoDB lock / 后端原生锁）
• 漂移：有人在云控制台手改（plan 会显示 drift）、检测（refresh / plan）、处理（import 纳管 / 改回 / 接受并更新 code）
• 协作：谁都能 apply 的混乱 → CI 里 plan（PR 展示）+ 审批后 apply（Atlantis / TF Cloud / CI）
• import：把手工建的资源纳入 state；import block（1.5+，可 plan 预览）
• 敏感数据：state 里含明文密钥 → 后端加密 + 访问控制
• 生态：Terraform BSL 1.1（2023-08，IBM 2025-02 收购未改 license）vs OpenTofu（MPL、Linux Foundation / CNCF sandbox、2026 已 v1.12.x 且是多数引擎、有 state 加密等独有特性）

考官追问链：

1. （现象）「terraform apply 前的 plan 到底在比什么？」→ 三方 diff：.tf 期望 vs state 记录 vs 云上真实；state 是它认识「哪些资源归我管」的唯一依据。
2. （机制）「state 为什么不能放本地或提交 Git？」→ 多人各一份必然冲突、含明文敏感值、无锁并发 apply 会互相覆盖 → remote backend + 锁 + 加密。
3. （边界）「有人在控制台手改了资源，terraform 会怎样？」→ plan 显示 drift，apply 会把它改回 .tf 的样子（可能误删手改的东西）；要么 import / 更新 code 承认变更、要么改回。
4. （治理）「团队 10 个人怎么协作不互相踩？」→ 禁本地 apply，PR 触发 plan 贴到 PR、审批后由 CI / Atlantis 统一 apply；state 上锁；按环境 / 模块拆 state 缩小爆炸半径。
5. （区分度）「你们用 Terraform 还是 OpenTofu？为什么？」→ 讲 2023 BSL 事件、OpenTofu 的 MPL 开源、2026 已是多数引擎且有独有特性（如 state 加密），说清选型理由。

参考答题骨架：

先讲 state 是什么：它是 .tf 声明的资源和云上真实资源之间的映射表。plan 做三方 diff——.tf 期望、state 记录、云上真实，据此算出「要创建 / 修改 / 删除什么」。没有 state，工具就不知道「这个资源是不是我管的」。 协作三件套： ① 远程后端：state 放 S3 + DynamoDB（或 GCS / TF Cloud），绝不放本地或 Git——多人冲突、含明文敏感值、无锁危险，后端要开加密。 ② 锁：apply 时上锁（DynamoDB / 后端原生），防两人同时 apply 把 state 写坏。 ③ CI 化协作：禁止本地 apply。PR 触发 plan 把变更贴到 PR 供 review，审批后由 CI（或 Atlantis / TF Cloud）统一 apply。 漂移治理：定期（或 PR 时）plan 检测 drift——有人控制台手改会显示出来。处理看情况：手改是对的就 import 纳管或更新 .tf 承认它；手改是错的就 apply 改回。按环境 / 模块拆分 state 缩小爆炸半径，避免一个巨型 state 全公司共用。 选型：2023 HashiCorp 把 Terraform 从 MPL 改成 BSL（2025 被 IBM 收购但 license 没变），社区 fork 出 OpenTofu（MPL、Linux Foundation、已进 CNCF sandbox）。2026 OpenTofu 已到 1.12.x、是多数新项目的引擎，还有 state 加密等 Terraform 没有的特性——新项目我会选 OpenTofu。

（声明式 vs 命令式 IaC、Terraform 为何比 Shell 好，见「1-概念解释型·子类1·题目3」。）

踩坑 / 加分点：

• state 里明文存密钥（如 RDS 密码、生成的私钥）——后端必须加密 + 严格 RBAC，拿到 state 文件 ≈ 拿到部分密钥。
• 巨型单体 state 是灾难：几百个资源一个 state，plan 慢、锁争用、一次误删爆炸半径巨大——按环境 / 模块 / 团队拆 state。
• apply 会把手改的资源改回去，容易误删线上手工加的东西——生产改动一律走代码，别手改；手改了要及时 import / 回填。
• state 锁卡死（apply 中途崩了锁没释放）——force-unlock 前要确认没人真在跑，否则并发写坏 state。
• 加分：讲 import block（1.5+）比老的 terraform import 命令好在能 plan 预览、可入代码 review。
• 加分：OpenTofu 的 state encryption 是它相对 Terraform 的实打实差异化特性，能答出来显示你跟进了 2024-2026 的生态分裂。
• 加分：drift 也可以主动做——定时 plan + 告警（类似 GitOps 漂移检测，但 IaC 层没有 selfHeal，需要人介入或 CI 自动 apply）。

锚点题 8：可观测性三支柱怎么在生产落地？出故障时你怎么用它们定位？#

为什么是锚点题：可观测性是运维 / SRE 的眼睛，「三支柱怎么落地」和「怎么用它们排障」高频必问。它区分「装了 Prometheus 看 CPU」的初级和「metrics/traces/logs 关联 + SLO + OTel 统一」的成熟选手。天然串起监控 vs 可观测、三支柱协作、OpenTelemetry、SLO，且直接接续锚点题 2 的故障定位。

会串出的知识点地图：

• 概念：监控（已知问题）vs 可观测（未知问题、能问任意问题）；分工——metrics 说「哪里不对」、traces 说「在哪一跳」、logs 说「为什么」
• Metrics：Prometheus（3.0 起原生 OTLP 接入、UTF-8 名、remote-write 2.0）、pull 模型、PromQL、RED / USE 方法、基数爆炸
• Traces：分布式追踪、trace_id / span、采样（头部 / 尾部）、Tempo / Jaeger
• Logs：结构化日志、Loki（label 索引不索引全文）、日志里带 trace_id 做关联
• OpenTelemetry：2026 事实标准，统一 instrument（SDK + auto-instrument）、OTLP 协议、Collector、用 correlation context（trace_id）把三支柱串起来
• 上层：SLI / SLO / 错误预算、告警（基于 SLO burn rate 而非裸阈值）、告警疲劳治理
• 栈：Prometheus + Loki + Tempo + Grafana + OTel Collector

考官追问链：

1. （现象）「监控和可观测性有啥区别？装了 Prometheus 就算可观测了吗？」→ 监控答已知问题（CPU 高不高），可观测能查未知问题（为什么这个特定用户的这个请求慢）；单有 metrics 不够，要能下钻。
2. （机制）「三支柱怎么配合定位一个『某接口偶发变慢』？」→ metrics 发现 P99 延迟升高（哪个服务）→ trace 定位慢在哪一跳（哪个下游 / DB）→ 用 trace_id 关联 log 看那次具体报了什么。
3. （边界）「traces 全采样存不下、logs 全存太贵，怎么权衡？」→ trace 尾部采样（只留慢的 / 错的）、log 分级 + 采样 + 短保留、metrics 控基数（别把 user_id 塞 label）。
4. （治理）「告警怎么设才不会又漏又吵？」→ 基于 SLO 的 burn-rate 告警而非裸阈值（CPU>80% 那种），多窗口多燃烧率；告警必须可执行，否则删掉。
5. （区分度）「为什么现在都上 OpenTelemetry？」→ 统一 vendor-neutral instrument、一次埋点到处送、三支柱共享 trace_id correlation，摆脱厂商锁定。

参考答题骨架：

先分清监控 vs 可观测：监控回答「已知的问题现在有没有」，可观测回答「任意没预设过的问题」。三支柱分工：metrics 说「哪里不对」、traces 说「在调用链哪一跳」、logs 说「具体为什么」。 落地： ① 采集统一走 OpenTelemetry（2026 事实标准）——SDK / auto-instrument 埋点，OTLP 送到 Collector，Collector 分流：metrics → Prometheus、traces → Tempo、logs → Loki，Grafana 统一看。关键是三者共享 trace_id 做 correlation。 ② Metrics 用 RED（请求率 / 错误率 / 延迟）盯服务、USE（利用率 / 饱和 / 错误）盯资源；Prometheus 3.0 起能原生收 OTLP。注意控基数——别把高基数维度（user_id / 请求 ID）塞进 label。 ③ Traces 用尾部采样只留慢的和错的，控成本。 ④ Logs 结构化 + 带 trace_id，用 Loki 按 label 索引。 ⑤ 上层建 SLI / SLO + 错误预算，告警基于 burn rate 多窗口，而不是裸 CPU 阈值。 排障时三支柱串起来：metrics 报警定位到服务 → trace 定位到慢 / 错的那一跳 → 用 trace_id 跳到对应 log 看根因。

（这套排障链路正是锚点题 2「定位」那一步的展开；SLO / 错误预算也是锚点题 2「固化」环节的告警来源。）

踩坑 / 加分点：

• 基数爆炸是 Prometheus 头号杀手：把 user_id / order_id 塞进 label，series 数百万，Prometheus OOM——高基数维度放 logs / traces，不放 metrics label。
• 「三支柱各存一套互不关联」是最常见的落地失败：logs 里没有 trace_id，出事时 metrics/trace/log 对不上号，还是靠人肉猜——correlation（统一 trace_id）才是可观测的灵魂。
• 告警疲劳：裸阈值告警（CPU>80%）半夜狂响但没人管——改 SLO burn-rate，只在真的要烧穿错误预算时叫醒人。
• 采样陷阱：头部采样（随机丢）会把偶发的慢请求也丢了，正好丢了你要查的——用尾部采样保留异常。
• 加分：讲 Prometheus 3.0（2024-11 首个大版本）原生 OTLP 接入，意味着 OTel 一套采集能直接喂 Prometheus，不用再维护两套。
• 加分：SLO 不只是告警，还是发布闸——错误预算烧光就冻结发布（呼应锚点题 2），把可观测和交付节奏挂钩。
• 加分：区分 metrics 的 pull（Prometheus 主动抓）和 push（OTLP / pushgateway），以及为什么 Prometheus 传统偏 pull（服务发现 + 目标健康即抓不到）。