平台工程与 FinOps¶

平台工程为何要按“产品”而非“共享运维队”建设？¶

技术说明

平台工程面向内部开发者提供可复用能力与自助接口，目标是降低认知负担、缩短价值流并提高安全/可靠默认值。按产品建设意味着有清晰用户细分、问题发现、路线图、SLO¹、文档、支持和反馈闭环；平台不是把所有基础设施集中接单，也不是强迫团队使用唯一技术。先识别高频摩擦和共同需求，提供有意见的 Golden Path²，同时允许有治理的逃生口。

平台边界通常覆盖模板、CI/CD、运行环境、身份、可观测和服务目录，但所有权需清晰：平台保证抽象和控制面，应用团队保证业务配置与运行。衡量采用、任务成功、交付流、可靠性和满意度，不能只看创建了多少集群。平台变更需兼容、版本化和迁移支持，因为内部 API 一样会形成依赖。

实践经验

某“平台团队”80% 时间处理 YAML 工单，服务上线仍需两周。工单数据表明权限、流水线和监控配置高度重复。团队访谈用户后先产品化最常见 Web 服务路径，提供自助预览与明确责任边界；特殊数据库仍走专家评审。初期采用率不高，原因是错误信息差而非功能不足，于是优先修复体验。长期以任务完成时间、失败率和留存验证价值，而不是要求行政强制迁移。

面试回答要点

内部开发者平台（IDP）的参考架构如何划分？¶

技术说明

IDP³ 通常含体验层（门户、CLI/API）、服务目录与身份层、工作流编排层、能力提供者（代码仓库、CI/CD、云、Kubernetes、数据库、可观测）以及策略/审计层。门户不直接持有所有管理员密钥，而以调用者身份和受控工作流请求底层 API；资源状态以权威系统为准，目录保存元数据和关系，避免复制成第二套配置真相。

工作流采用异步、幂等和可续跑步骤，每步输出状态、审计和补偿操作；长任务不能依赖浏览器会话。平台 API 版本化，底层供应商差异由适度抽象封装，但不要设计最小公分母。控制面按关键程度做 HA、队列、灾备与限流；平台故障不应影响已运行服务的数据面，只影响新建/变更。

实践经验

某门户同步调用十多个云 API，任一步超时便让用户重试并重复创建资源。团队先用资源标签找出孤儿并冻结高风险动作，随后改成有工作流 ID 的异步状态机，每步幂等、失败可补偿。引入队列增加最终一致性和状态复杂度，因此 UI 明确显示进行中/需人工处理，且平台 SLO 分开衡量提交接受和完成时长。

面试回答要点

Golden Path 应如何设计，既提高标准化又不扼杀差异？¶

技术说明

Golden Path 是针对一类工作负载的推荐端到端路径，包含代码模板、构建、测试、部署、身份、可观测、SLO、runbook 和生命周期，而非一次性脚手架。它把安全与可靠默认值编码到模块和工作流，并持续接收升级；生成后完全复制、无人维护的仓库会迅速漂移。应按 Web API、事件消费者、定时任务等用户场景分别设计，不追求一个模板覆盖全部。

路径需“容易进入、容易理解、可升级、可退出”：文档说明支持边界，扩展点与 escape hatch 有风险评审和 owner。通过版本化模块、批量 PR 或集中运行时能力传播修复，破坏性升级给兼容窗口。衡量首次上线时间、模板升级覆盖、偏离原因、支持请求和运行结果；大量绕过通常是产品信号，不应只加惩罚。

实践经验

某统一模板强制所有服务使用相同数据库和扩缩策略，数据任务普遍 fork 后失去安全更新。团队分析偏离原因，将模板拆为 API/worker/batch 三条路径，共享身份和观测模块，并提供版本升级机器人。分支增多增加维护成本，因此只支持高频场景，长尾由评审路径处理。之后以升级采纳率和故障率验证，而非模板创建数量。

面试回答要点

服务目录与 Backstage 类门户怎样避免成为过时 CMDB？¶

技术说明

服务目录记录组件、API、资源、owner、生命周期、依赖、SLO、runbook 和文档关系，核心价值是发现、责任和自动化上下文。元数据尽量从代码清单、云标签、Kubernetes、CI 与可观测系统自动摄取，人工字段设 owner 与校验；不要把瞬时运行状态全部复制进目录。Backstage⁴ 类门户可作为统一入口和插件框架，但权威数据仍在相应源系统，避免退化成过时的 CMDB⁵。

建立实体 schema、唯一标识、关系类型和生命周期，防止同一服务多个名字。用 freshness、无 owner 实体、孤儿资源、链接失败和覆盖率衡量质量；离职/组织变更自动同步。目录变更走代码评审或受控 API，权限避免插件获得全局管理员。先解决搜索和 owner 两个高价值问题，再逐步扩展评分卡与自助。

实践经验

某目录上线半年后 30% owner 无效，事故时仍靠群聊找人。团队将组织目录、仓库 CODEOWNERS 与生产资源做对账，先标出关键服务孤儿并指定临时责任人；长期自动同步团队、给 stale 实体工单，并在部署时校验 owner。自动同步会覆盖临时组织关系，因此允许有期限的人工 override，且展示来源和最后更新时间。

面试回答要点

如何设计安全、可靠的自助基础设施工作流？¶

技术说明

自助不是把云管理员权限交给开发者，而是让用户提交声明式意图，平台执行预览、策略、审批、创建和验证。输入使用受约束 schema，展示预计资源、权限、成本和破坏性变化；工作流身份按动作短期授权。步骤幂等、可重试、有超时和补偿，生成资源带 owner、环境、成本中心和工作流 ID，便于审计与清理。

低风险标准资源可自动批准，高成本、生产数据或公网暴露走条件审批。删除默认软删除/等待期，备份与依赖检查后执行。并发请求需锁/去重，底层 API 限额用队列和退避。验收不仅是 API 成功，还包括健康、策略、可观测和目录登记。平台失败提供明确状态和人工接管，不让用户重复点击制造更多资源。

实践经验

某自助数据库按钮超时后用户连点三次，创建三个付费实例。账单标签和审计显示请求缺少幂等键。团队先锁定页面、标记并回收两个空实例，随后引入 request ID、异步状态和预估月成本，完成后自动连通性验证。软删除延长资源存续会有短时费用，但显著降低误删风险；到期由工作流自动回收。

面试回答要点

平台 API 应如何设计和治理？¶

技术说明

平台 API 抽象稳定的用户意图，如“需要具备某 SLO 的托管数据库”，而不是简单透传供应商数百参数。资源模型包含 spec/status、条件、owner 和操作 ID，长操作返回异步任务；幂等键、乐观并发和声明式 reconcile 处理重试。抽象需保留关键能力差异，通过 profiles/扩展字段表达，过度统一会让用户绕过平台。

API 有明确版本、兼容政策、弃用遥测和迁移工具；错误使用机器码与可执行建议。认证基于企业身份，授权同时检查租户、环境、资源和动作，所有变更审计。设置配额、速率限制和公平队列，防单团队压垮控制面。契约测试覆盖底层 provider 升级，SLO 分开定义接收、调和完成和状态新鲜度。

实践经验

某平台把云 provider 参数原样暴露，供应商升级字段后数百客户端失败。团队先固定旧版本并提供转换层，随后收敛为少数工作负载 profile、对高级用户保留受控扩展。抽象减少灵活性，因此记录 escape hatch 使用量并据此演进 API；弃用前通过调用遥测找到真实消费者，而不是发一封通知就删除。

面试回答要点

多租户平台如何做隔离和公平性？¶

技术说明

先按威胁和噪声风险选择隔离层级：命名空间/项目适合同组织低风险租户，节点池/账号/集群适合高合规或不可信工作负载。身份、网络、计算、存储、密钥、日志和控制面权限都需隔离；只有 namespace 没有默认拒绝网络/RBAC/配额并不构成完整边界。敏感租户加密密钥和备份也要独立。

公平性通过配额、LimitRange、优先级、公平队列、每租户并发/速率和成本预算实现；同时保留平台系统容量。共享集群调度需防抢占和热点，按租户观测使用、拒绝、排队与 SLO。例外和借用容量应有时限，防临时扩额永久化。更强隔离增加成本和运维，应按数据/攻击者模型分层而非全员独立集群。

实践经验

某批处理租户提交数万任务，占满 API Server 与节点，在线服务无法扩容。团队先暂停该队列、保留关键优先级容量并限速提交；长期为租户设置并发、API 公平队列、资源配额和独立批处理节点池。硬配额降低闲置资源利用率，因此允许在不影响保障容量时弹性借用，并在饱和时可抢回，规则对租户透明。

面试回答要点

平台护栏如何兼顾安全、可靠性和开发者体验？¶

技术说明

护栏把不可接受风险设为硬约束，把推荐实践做成默认值和反馈。分层为：组织级不可绕过基线、平台默认配置、团队可调范围与有审批例外。规则在最早可提供准确信息的阶段反馈，例如 IaC 计划预览成本与策略，部署准入兜底，运行时检测漂移；只在最后阻断会浪费开发时间。

每次拒绝提供规则理由、影响、修复示例和支持入口；策略先观察命中与误报，再 warn/enforce。例外精确到资源和期限，并自动提醒。护栏自身有版本、测试、SLO 和回滚，防错误策略全局阻断。通过任务成功率、绕过、误报、修复耗时和事故下降衡量，而非规则数量。

实践经验

某强制资源限制规则没有考虑启动峰值，多个 Java 服务被 OOM，团队转向复制超大默认值。平台分析使用数据后按工作负载 profile 给建议范围，先在 PR 显示模拟结果，再对极端值阻断。默认更合理后例外下降；代价是维护 profile 和基线压测，但相比所有团队自行猜测，总体认知负担更低。

面试回答要点

平台自身的 SLO 与可观测性如何设计？¶

技术说明

平台要按用户旅程定义 SLI：门户/API 请求成功只是入口，更重要的是“创建环境在目标时间内完成”“部署状态在限定时间收敛”“凭证按时签发”。异步工作流分别测接受率、完成成功率、端到端时长、队列年龄和状态新鲜度；底层 provider 故障是否计入由用户结果决定，不应轻易排除。按租户、区域和能力下钻，但 SLO 聚合避免高基数。

控制面 metrics/logs/traces 以 workflow ID、资源 ID 和变更版本关联，记录每步重试/补偿。平台故障不应拖垮已运行数据面，需监控这种隔离。告警基于 burn rate 和积压年龄，runbook 包含暂停高风险工作流、限流和人工接管。对用户公布状态、影响与替代路径，平台团队也执行误差预算策略。

实践经验

某平台 API 99.99% 成功，但资源创建常卡在 provider 配额，用户实际等待数小时。工单与工作流时间线证明入口 SLI 失真。团队先暴露队列位置、暂停会失败的区域请求并申请配额，随后将“30 分钟内可用”设为核心 SLI，按步骤 trace。更严格 SLO 会暴露底层依赖问题，但这正是平台承诺；无法控制的能力则明确较低等级和降级路径。

面试回答要点

如何衡量平台采用、开发者体验和业务价值？¶

技术说明

采用指标包括目标用户覆盖、激活、关键路径使用、留存和退出原因；体验可用任务成功率、完成时间、等待、支持触点和定性访谈；结果则观察变更前置时间、失败/恢复、可靠性和安全覆盖。DORA 当前五项适合按应用看趋势，不能把平台上线后的相关变化直接当因果，也不宜跨团队排名。结合前后对照、分阶段推广和用户分群提高解释力。

“门户登录数”“模板创建数”是活动，不等于价值。建立少量北极星任务，例如新服务首次安全上线或常规发布，无需追踪个人生产率。调查保持匿名、低频和可行动，数据治理明确用途与访问，防止监控开发者。平台路线图用摩擦、风险和影响排序，并公开哪些反馈已采取行动。

实践经验

某平台宣布 90% 采用，实际统计的是登录，半数团队仍在门户外部署。团队通过部署来源、任务漏斗和访谈重建口径，发现数据库申请环节是主要流失点；优先改造后完成时间下降。更真实的采用率短期大幅降低，但让投资方向可验证。没有把个人点击或提交数用于绩效，避免团队为了指标改变无意义行为。

面试回答要点

云成本分摊、标签和共享成本应怎样治理？¶

技术说明

成本分摊需建立业务、产品、环境、owner 与成本中心等维度，优先从账号/订阅、项目、资源标签和 Kubernetes 元数据自动映射。标签在创建时强制且受控词典，修改留历史；对无法直接标记的网络、支持、共享集群等成本制定透明规则，可按使用量、预留容量、请求数或固定比例分摊。分摊目标是决策，不是追求数学上绝对精确。

同时区分 direct、shared、unallocated 与 amortized costs，将承诺折扣/预付摊销到使用周期，避免某月异常。质量指标包括可分配率、未知 owner、标签延迟和规则版本。showback 先建立信任，再按组织成熟度 chargeback；规则变化需回算影响和沟通。不能用成本中心标签承载敏感数据。

实践经验

某共享 Kubernetes 集群全部成本记在平台团队，业务认为平台“过贵”且无优化动力。团队先按 namespace 的 CPU/内存请求与实际使用分展示，再将控制面和闲置作为透明共享池；季度调整权重。按 request 分摊会奖励过低 request，按 usage 又无法反映预留保障，因此两者混合并公开公式。争议减少后再引入预算，而非一开始直接内部扣费。

面试回答要点

Rightsizing 与自动扩缩容如何避免只省钱不保 SLO？¶

技术说明

Rightsizing⁶ 基于一段代表性周期的利用率、峰值、尾延迟、throttling、OOM、队列和容灾容量，而不是按平均 CPU 砍规格。Kubernetes request 决定调度和成本分摊，limit 可能造成 CPU throttling/内存 OOM；建议需按工作负载类型和季节分位数给出，并保留 N-1、发布和增长余量。数据库、缓存等有状态资源还受 IOPS、连接和恢复时间约束。

HPA/VPA/集群扩容反应时间不同：HPA 依赖有效领先指标和启动时间，VPA 改 request 可能重启 Pod，节点扩容受云供应限制。先推荐、后小批自动执行，设 SLO/错误率回滚。跟踪单位请求成本、浪费、拒绝和性能回归，避免节省转移到值班或下游。关键服务保留最小预热容量。

实践经验

某批量 rightsizing 按七天平均把内存 request 减半，月末任务 OOM 并重试放大费用。团队先恢复旧规格、暂停自动建议，随后用 35 天窗口、工作负载日历和 p99 峰值重算。长期建议展示置信度和预计风险，生产先 5% 灰度。保留余量看似降低节省比例，却减少重试与事故后的总成本，按单位成功任务成本验收。

面试回答要点

承诺折扣、预留与 Spot/抢占式资源如何组合？¶

技术说明

先以稳定可预测的基线负载购买承诺/预留，以按需覆盖不确定峰值，以 Spot⁷ 承载可中断、可检查点、可重试的弹性任务。承诺范围、期限、付款、实例灵活性和可转让性因云产品不同，需以当前官方条款和实际利用建模；把预测增长全部提前锁定会产生闲置，折扣率高不等于节省。

Spot 应跨实例类型/区域分散，监听中断通知，优雅 drain、checkpoint 并限制同时中断；关键在线服务保留按需最低容量，扩容不能完全依赖 Spot。衡量 commitment utilization/coverage、净节省、机会成本、中断率、恢复时间和任务成功成本。采购由 FinOps⁸、工程与财务共同滚动评审，而非年度一次决策。

实践经验

某团队将全部异步计算迁到单一 Spot 类型，市场紧张时容量同时回收，积压突破 SLA。团队先用按需恢复最低吞吐、暂停低优先级任务，随后建立多池、多区和 checkpoint，基线用承诺覆盖。多样化会降低单一规格效率，却显著提高供应韧性；以完成任务总成本和截止达成率评估，而非只看每小时单价。

面试回答要点

如何用单位经济性和成本异常检测指导架构决策？¶

技术说明

单位经济性⁹把技术成本与业务产出关联，如每成功订单、每活跃租户、每 GB 处理或每百万 token 成本。分子应包含可解释的直接与共享成本，分母使用稳定、可审计的业务事件，并区分规模增长与效率变化。总账单上涨若单位成本下降可能健康，反之流量持平而单位成本升高更值得排查。定义、来源和规则需版本化。

异常检测先按服务/账户/维度建立季节性基线，再结合绝对金额、变化率和业务量过滤；新服务/迁移需标注事件。告警交给有 owner 且能行动的团队，附主要成本驱动、变更和建议，不为几元波动分页。验证节省时看业务 SLO、质量和碳/人力等转移成本，防止“关监控省钱”制造更大风险。

实践经验

某推理服务账单涨 40%，业务量也涨 35%，总额告警缺乏结论。按每千成功请求和 token 归一后发现输出 token 变长使单位成本仍升 18%，关联到提示模板变更。团队先限制异常输出并回滚模板，长期将成本、质量和延迟一起做实验门禁。限制 token 可能降低回答质量，因此通过离线评测和用户指标验证，而非只优化费用。

面试回答要点

平台能力 Build vs Buy 如何决策并管理供应商锁定？¶

技术说明

决策从差异化价值、能力成熟度、合规/数据边界、集成复杂度、可用性、人才和时间到价值出发。比较三到五年 TCO：许可/云消费、实施、运维、升级、迁移、停机、人员和机会成本，而非只比报价与自建服务器。核心差异化控制面可自建，通用商品能力倾向采购；现实常为组合方案。

供应商评估包含 SLO/支持、数据导出、API、身份、审计、加密、区域、容量、价格变更和退出条款。降低锁定不是禁止专有能力，而是识别高迁移成本点：保持制品/配置/遥测可导出、边界接口、数据备份和定期退出演练。抽象层也有维护成本，只有真实需要时构建。

实践经验

某团队自建日志平台两年，工程时间多数耗在升级与容量，查询体验仍差。TCO 复盘后选择托管后端，但保留 OTel/对象存储原始归档和导出测试；核心脱敏与路由由自有 Collector 控制。托管降低运维却增加消费成本，因此设摄入预算与退出水位。没有为“多云中立”重写所有查询，只保护高价值数据与采集边界。

面试回答要点