系统、网络与交付实操¶

Linux 性能证据链：定位“CPU 不高但 API 很慢”¶

任务

给候选人一台受限容器/主机和一份 15 分钟监控快照：API¹ P99² 周期性升高，宿主机 CPU 约 45%。要求在 45 分钟内只读诊断，判断是 CPU热点、cgroup³限流、内存回收还是磁盘等待；提交证据、临时止血、永久修复和验证计划。不得重启、改 sysctl 或无限制抓包/profile⁴。

相关技术说明

标准路径先对齐时间与业务指标，再比较宿主机和cgroup。建议命令：date -Ins、uptime、vmstat 1 10、mpstat -P ALL 1 10、pidstat -u -r -d -w 1 10、iostat -xz 1 10；读取 cgroup v2 的 cpu.max、cpu.stat、memory.current、memory.events 和 memory.pressure。若允许，对目标 PID 做 30 秒受限 perf stat/profile，不做全节点长时采样。

答案应说明：平均 CPU 不能排除 quota 周期限流；load包含R/D；PSI⁵衡量资源停顿；%util 对并行设备不是简单容量比。证据矩阵至少列“假设—预期指标—实际观察—结论”，例如 P99尖峰与 throttled_usec 增量一致，而 PSI、await和major fault稳定，支持cgroup限流。

参考实现思路/命令

1. 记录限制与核数：nproc，读取 /proc/self/cgroup 后定位对应 cgroup 文件；不假设容器 /proc/loadavg 是局部值。
2. 采三组连续样本，计算每窗口 throttled_usec 增量/墙钟时间和 nr_throttled/nr_periods，与请求直方图时间对齐。
3. 以线程视角检查 pidstat -t；若热点不清，再做短采样并记录采样开销。
4. 排除替代假设：memory PSI、swap in/out、块设备 await、D状态、steal没有同步变化。
5. 给出止血优先级：暂停新发布→减少工作线程/关闭并行功能→有容量验证后扩副本或调整limit；每一步注明副作用和回滚触发器。

实践经验

复合生产落地中，最常见误区是看到节点空闲就移除所有 limit。标准答案应选择先降低应用并行或小范围扩容，因为全局取消限额会把问题转为邻居受扰；若上调limit，先检查节点可分配量、QoS和下游连接增长。永久方案是用生产相同配额压测，以每请求CPU、P99和throttling作为发布门禁，并在故障演练中验证自动暂停。

验收

• 能在 15 分钟内确定 cgroup层级和限制，最终结论至少有两类独立证据。
• 命令全为有界只读操作；输出包含时间戳和目标范围。
• 止血有顺序、容量校验、风险与回滚条件。
• 永久修复有可量化阈值，能说明如何排除替代根因。

评分（100 分）

• 证据链与时间对齐 30 分；Linux/cgroup机制 25 分；安全操作 15 分；止血与副作用 15 分；验证和长期改进 15 分。

常见错误

• 只报 top、load或平均 CPU，未读取 cgroup。
• 未观察增量就把累计 cpu.stat 当当前故障。
• 一上来重启、清缓存、取消limit，破坏现场或转移风险。
• perf 全节点无限时运行，既无范围也无开销评估。

网络故障实验：小请求成功、大请求超时且偶有 TLS 失败¶

任务

提供 client、gateway、server 三个隔离环境和可控故障网络。小 HTTP 请求成功，大响应在 TLS⁶ 握手后或传输中超时。候选人须在 60 分钟内判断 DNS⁷、PMTU、证书、路由或应用超时中的主因，输出端到端时序、最小修复和回归探测。禁止通过永久关闭证书校验或无限调大超时“解决”。

相关技术说明

标准答案先分阶段：dig @resolver/getent 验证解析；ip route get 确认选路；curl -v --trace-time 和 openssl s_client -servername 分解 TCP/TLS；用 tracepath 或带 DF 的不同尺寸探测验证路径MTU；在 client 与gateway两侧短时 tcpdump -nn -s 128 host <ip>，比较同一五元组的SYN、TLS record、大段重传和ICMP。

本题预置根因是隧道新增封装后有效 MTU⁸下降，同时 ICMP Packet Too Big/Fragmentation Needed 被策略阻断，形成 PMTUD⁹黑洞。握手可能因证书链较大而偶发受影响，大 body 更稳定复现。小包成功排除不了网络，调整 MSS 只覆盖 TCP 且有 CPU/包数代价；正确长期修复是统一 MTU 并允许必要 ICMP。

参考实现思路/命令

1. 固定域名、解析结果、源/目标IP和时间，使用 curl --resolve 隔离DNS但不跳过TLS身份验证。
2. openssl s_client -connect host:443 -servername host -brief 确认证书链、SNI和ALPN无独立错误。
3. tracepath <server>；按平台使用DF探测逐步增加payload，记录成功上限而非只做一次ping。
4. 双点抓包看到大TCP段重复、无相应ICMP，网关隧道接口MTU与物理接口相同，构成证据闭环。
5. 过渡可在明确边界做MSS clamp；永久调整overlay/underlay MTU与策略，并加入 1KiB、16KiB、1MiB 三尺寸HTTPS合成探测。

实践经验

复合生产场景中，最小止血可在边界设备做受控MSS clamp并灰度验证，不能在所有主机随意改MTU。它会增加包数且无法帮助UDP/QUIC，因此设撤除日期。长期变更先选一个隧道/可用区，观察重传、CPU与吞吐；回滚是恢复旧MTU和路由策略。抓包只保留头部、限时并控制访问，避免TLS前明文元数据泄露。

验收

• DNS、TCP、TLS和数据传输阶段均有独立结论，主因有双点包证据。
• 修复没有关闭TLS校验，不把超时提高当永久方案。
• 能计算封装开销并说明MTU与MSS差异。
• 回归覆盖不同协议载荷、双向路径和回退方案。

评分（100 分）

• 分层方法 20 分；抓包/时序证据 25 分；MTU机制 20 分；止血安全性 15 分；永久修复与监控 20 分。

常见错误

• 以ping小包成功断言网络正常，或只在一端抓包。
• 使用 curl -k 后把成功错误归因为证书。
• 永久依赖MSS clamp，却不修ICMP和底层MTU。
• 全包长时间抓取并上传，忽略生产数据安全。

编写可恢复的资产同步工具¶

任务

实现一个 Python 或 Go CLI¹⁰：从有 cursor 分页、429限流和偶发5xx的源 API 同步资产到支持资源版本的目标 API。要求 plan、apply、resume 三种模式，最大并发可配置，进程中断后可恢复；不得重复创建或误删。提交代码、测试、状态文件/schema、运行说明和风险清单。面试时可用伪服务，不要求真实云账号。

相关技术说明

工具把“抓取快照—计算差异—应用变更—对账”拆开。源分页跟随不透明 cursor并记录水位，目标更新使用幂等键和 If-Match/资源版本；创建后响应丢失时按幂等键查询，而不是再创建。重试只覆盖429、约定5xx和瞬时网络，遵循Retry-After、指数退避、全抖动与总deadline；401/403/schema错误进入永久失败。

状态库存 run ID、源快照版本、cursor、每资源期望哈希、目标操作ID、尝试次数和结果。并发采用有界worker/semaphore；默认禁止删除，删除需独立开关、上限、二次计划和保护标签。日志结构化且不含token，退出码区分完整成功、部分失败和输入错误。Python外部命令不得用字符串+shell=True；Go应让context贯穿请求和worker。

参考实现思路/命令

1. sync plan --source-env prod --out plan.json：拉取稳定快照，生成带输入hash和过期时间的不可变计划；计划只包含资源ID、版本与脱敏差异。
2. sync apply --plan plan.json --concurrency 20 --max-delete 0：验证环境/账户、签名或hash，先执行创建/更新，删除单独批次。
3. 每次目标调用带 Idempotency-Key: <run>:<resource>:<desired-hash> 和条件版本；保存operation ID后再等待结果。
4. sync resume --run <id> 只领取未完成/可重试单元；SIGTERM停止领新任务、等待短宽限并持久化检查点。
5. 测试覆盖多页插入、响应成功但连接断开、429+Retry-After、毒资源、两实例并发、状态文件损坏和dry-run零写入。

实践经验

复合生产落地中，先以“只报告”跑一周并人工抽样，再允许每次最多10个非关键更新，最后扩大；删除始终要求独立审批。API限流时自适应降低并发，避免固定重试形成波峰。状态数据库增加维护成本，但比本地临时JSON更适合多实例和审计；若题目采用本地文件，必须原子写入、校验和并明确只支持单实例锁。

验收

• 同一计划执行两次不产生额外副作用，超时未知可对账。
• 中断任意阶段后 resume 最终达到一致状态；并发任务无重复认领。
• 429遵从服务端退避，永久错误不无限重试，删除默认关闭。
• 最终报告输入/成功/跳过/死信数量并以独立查询验证目标。

评分（100 分）

• 幂等与并发正确性 30 分；错误/重试 20 分；恢复与状态模型 20 分；安全及删除保护 15 分；测试、可观测与文档 15 分。

常见错误

• offset分页且数据变化时无去重/快照，或把短页当结束。
• 先查后创建却无唯一约束，仍存在并发竞态。
• 捕获所有异常无限重试，连权限错误也轰炸API。
• dry-run仍获取写凭证，日志打印请求头或完整敏感响应。

构建“构建一次、金丝雀晋级”的安全流水线¶

任务

为一个容器化 API 设计并给出流水线配置骨架：公共仓库支持 fork PR；合并主干后构建一次，依次晋级测试、预发、生产；生产采用5%→25%→100%金丝雀并自动分析；数据库变更需兼容滚动；云部署用 OIDC。提交阶段图、权限矩阵、伪 YAML、回滚/中止逻辑和验收演练。

相关技术说明

信任域必须分开：fork PR只运行无秘密检查、用一次性runner且不能写受信缓存；主干由受信builder根据锁定依赖与基础镜像digest构建，生成SBOM、签名/provenance并推送不可变digest。后续环境仅晋级同一digest，OIDC trust policy绑定仓库、受保护分支/环境、audience和workflow，生产角色需要独立批准且会话短期。

生产控制器按generation串行部署，先验证registry复制和签名，再把5%代表性流量分给候选。分析需最小样本/观察窗，比较错误、P99、饱和与业务成功率；无数据不通过。DB使用expand/contract：先加兼容结构，代码双读/写或切读，回填对账后另一次发布contract。回滚选择上一digest并判断数据兼容，不执行现场重建。

参考实现思路/命令

stages: [untrusted-check, build, verify, stage, prod-canary]
build:
  if: protected_main
  outputs: [image_digest, sbom, provenance]
stage:
  needs: [build, verify]
  deploy: "${image_digest}"
prod-canary:
  environment: production
  oidc: {audience: cloud-prod}
  steps: [verify_digest, deploy_5, analyze, deploy_25, analyze, deploy_100]

上述仅是骨架：实现中模板与第三方action固定不可变SHA，image_digest来自注册表而非tag；每个波次有唯一release ID、超时、自动暂停和人工中止。分析任务查询基线与候选相同时间/流量分层；回滚控制器提交新generation指向上一已验证digest。

实践经验

复合生产落地中，先让流水线以“影子判定”运行，不自动阻断，收集两周误报后再启用门禁；首批金丝雀包含高成本租户而非纯随机。紧急break-glass允许缩短人工等待，但仍验证签名、记录digest和事后补检。金丝雀延长交付时间，使用风险评分让低风险配置走较短观察窗，高风险schema/依赖变更走完整波次。

验收

• 测试、预发和生产运行摘要完全一致，任意阶段可追到源码与构建身份。
• fork PR 无法获得生产OIDC、写受信缓存或控制发布环境。
• 候选错误/延迟越界或指标缺失时自动停止，不继续扩量。
• 回滚演练能在目标时间恢复且兼容schema；上一digest在所有区域可拉取。

评分（100 分）

• 供应链与runner隔离 25 分；不可变制品晋级 20 分；金丝雀统计/中止 20 分；数据库兼容/回滚 20 分；审计、演练与权衡 15 分。

常见错误

• 各环境重新构建，或用latest/prod tag作为发布身份。
• OIDC只验证issuer，不限制repo、branch和environment。
• 金丝雀只看Pod ready，样本不足/无指标仍自动通过。
• 回滚只改镜像，不考虑schema、flag、队列消费者和已写数据。