前端部署与运维（SRE）练习册

通过练习掌握部署策略、可观测性和容灾能力。

---

难度分级

• 🟢 基础：理解概念。
• 🟡 进阶：能选择合适策略。
• 🔴 深入：能设计完整 SRE 体系。

---

一、选择题

第 1 题（🟢）

前端静态资源最适合长期缓存的是？

A. HTML
B. 带 hash 的 JS/CSS
C. API 响应
D. 用户上传图片

第 2 题（🟢）

金丝雀发布的特点是？

A. 一次性全量上线
B. 小范围验证后逐步扩大
C. 同时运行两套独立环境
D. 只给内部员工使用

第 3 题（🟡）

可观测性三大支柱不包括？

A. 日志
B. 指标
C. 链路追踪
D. 单元测试

第 4 题（🟡）

RTO 表示？

A. 恢复点目标
B. 恢复时间目标
C. 恢复资源目标
D. 恢复流量目标

第 5 题（🔴）

以下哪种方式最能降低前端发布风险？

A. 全量发布
B. 灰度发布 + 实时监控 + 一键回滚
C. 凌晨手动发布
D. 不做测试直接发布

第 6 题（🟢）

Docker 多阶段构建的主要目的是？

A. 减少镜像层数
B. 减小最终镜像体积
C. 加快构建速度
D. 支持多平台构建

第 7 题（🟢）

CDN 边缘节点缓存未命中时，请求会如何处理？

A. 直接返回 404
B. 回源到源站获取资源
C. 等待其他节点同步
D. 丢弃请求

第 8 题（🟡）

蓝绿部署中，"绿环境"的含义通常是？

A. 当前正在运行旧版本的稳定环境
B. 新版本的预发布环境
C. 开发测试环境
D. 灾备环境

第 9 题（🟡）

Kubernetes 中，哪个资源对象最适合管理前端应用的滚动更新？

A. Pod
B. Deployment
C. Service
D. Ingress

第 10 题（🟡）

SLA 99.99% 意味着每年的最大不可用时间约为？

A. 8.76 小时
B. 52.56 分钟
C. 5.26 分钟
D. 31.56 秒

第 11 题（🟡）

前端应用在进行灰度发布时，以下哪种分流策略粒度最细？

A. 按地域分流
B. 按用户 ID 哈希分流
C. 按设备类型分流
D. 按随机百分比分流

第 12 题（🔴）

当 CDN 服务整体故障时，以下哪种容灾手段最有效？

A. 等待 CDN 厂商修复
B. 切换 DNS 解析到备用 CDN 或直接回源
C. 刷新所有缓存
D. 增大源站带宽

第 13 题（🔴）

容器健康检查中，liveness probe 与 readiness probe 的区别是？

A. 两者无区别
B. liveness 检测容器是否运行，readiness 检测服务是否就绪
C. liveness 检测网络，readiness 检测磁盘
D. liveness 用于就绪，readiness 用于存活

第 14 题（🟢）

HTTP 缓存头 Cache-Control: no-cache 的含义是？

A. 完全不缓存
B. 缓存前必须向源站验证资源是否可用
C. 只缓存 1 秒
D. 只允许 CDN 缓存

第 15 题（🔴）

在零停机发布方案中，前端版本切换时出现用户会话不连续（token 或状态丢失），最可能的原因是？

A. CDN 缓存未刷新
B. 新旧版本前端的 localStorage 数据结构不兼容
C. 后端接口版本不匹配
D. DNS 解析延迟

---

二、场景分析题

第 16 题（🟡）

发布新版本后，部分用户反馈页面白屏。如何快速定位和处理？

第 17 题（🟡）

大促期间前端资源访问变慢，可能是哪些原因？如何优化？

第 18 题（🔴）

设计一个前端应用的回滚方案，要求 5 分钟内完成回滚。

第 19 题（🟡）

上线后监控发现新版本的 LCP 指标从 1.8s 劣化到 4.2s，但功能完全正常。作为 SRE 工程师，你的排查步骤是什么？

第 20 题（🟡）

前端灰度发布时，灰度用户组出现了 JS 报错率飙升（从 0.1% 升到 8%），但对照组平稳。如何处理？

第 21 题（🔴）

生产环境 CDN 证书过期，导致全站静态资源加载失败。你接到 P0 告警后，如何一步步恢复服务并止损？

第 22 题（🔴）

某次发布后，非灰度用户也看到了新版本页面，经排查是 CDN 缓存污染导致。请分析根因并提出长效预防方案。

第 23 题（🟡）

凌晨 3 点收到告警：前端核心页面转化率下降 30%。但错误监控无异常、性能指标正常。你的排查思路是什么？

---

三、设计/开放题

第 24 题（🟡）

为一个电商首页设计缓存策略，包括 HTML、JS/CSS、图片、API 数据。

第 25 题（🔴）

设计一套前端灰度发布系统，支持按用户 ID、地域、随机比例分流。

第 26 题（🔴）

设计前端监控告警体系，覆盖错误、性能、业务指标。

第 27 题（🔴）

设计一套完整的前端 CI/CD 部署流水线，包括代码提交、构建、测试、部署、监控全流程，并说明每个环节的关键质量门禁。

第 28 题（🔴）

设计一个多环境（开发/测试/预发/生产）的发布策略，要求实现环境间快速晋升（promotion），并保证生产环境的零停机。

---

参考答案

第 1 题

查看答案与解析

答案：B

带 hash 的 JS/CSS 文件名随内容变化，浏览器可长期缓存不变资源。HTML 不适合长期缓存（需要实时更新），API 响应动态变化不能长期缓存，用户图片非前端静态构建产物。

第 2 题

查看答案与解析

答案：B

金丝雀发布（Canary Release）先让小部分用户（金丝雀组）使用新版本，验证无问题后逐步扩大范围，最后全量上线。A 描述的是蓝绿部署的切换瞬间，C 描述的是 A/B 测试，D 描述的是内部预览。

第 3 题

查看答案与解析

答案：D

可观测性三大支柱是日志（Logging）、指标（Metrics）、链路追踪（Tracing），简称三大支柱（Three Pillars）。单元测试属于质量保障，不属于可观测性范畴。

第 4 题

查看答案与解析

答案：B

RTO（Recovery Time Objective）是恢复时间目标，指从中断到恢复服务可接受的最长时间。RPO（Recovery Point Objective）才是恢复点目标（数据丢失量）。

第 5 题

查看答案与解析

答案：B

灰度发布控制爆炸半径，实时监控及时发现异常，一键回滚快速止损。全量发布风险最高，凌晨手动发布缺乏自动化验证，不做测试直接发布不可接受。

第 6 题

查看答案与解析

答案：B

Docker 多阶段构建（Multi-stage Build）允许在同一个 Dockerfile 中使用多个 FROM 指令，将构建环境和运行环境分离。最终只将运行时需要的产物复制到最终镜像，大幅减小镜像体积。减少层数是附带效果但不是主要目的。

第 7 题

查看答案与解析

答案：B

CDN 边缘节点缓存未命中时，会向源站发起回源请求（Origin Pull），获取资源后在本地缓存并返回给用户。这个过程对用户透明，但会增加首次访问延迟。若源站不可用则可能返回 502/504。

第 8 题

查看答案与解析

答案：A

蓝绿部署中通常用"蓝"指代新版本环境，"绿"指代当前稳定运行的旧版本环境。切换时通过路由规则将流量从绿环境切到蓝环境，一旦新版本出问题可立即切回绿环境。部分团队的命名习惯可能相反，但核心理念是保留一个稳定兜底环境。

第 9 题

查看答案与解析

答案：B

Deployment 是 Kubernetes 中管理无状态应用的资源对象，原生支持滚动更新（RollingUpdate）策略，可配置 maxSurge（最大超出副本数）和 maxUnavailable（最大不可用副本数）。Pod 是基础单元，Service 负责网络暴露，Ingress 负责七层路由，都不直接管理更新策略。

第 10 题

查看答案与解析

答案：B

SLA 99.99% 即"四个九"，年不可用时间计算：365 * 24 * 60 * (1 - 0.9999) = 525,600 * 0.0001 = 52.56 分钟。A 是 99.9%（三个九），C 是 99.999%（五个九），D 是 99.9999%（六个九）。

第 11 题

查看答案与解析

答案：B

按用户 ID 哈希分流粒度最细，可以精确到每个用户，且同一用户始终落在同一分组，保证用户体验一致。按地域/设备只能粗粒度分组，随机百分比无法保证用户一致性（同一用户可能每次请求落在不同分组）。

第 12 题

查看答案与解析

答案：B

CDN 整体故障时，最有效的容灾手段是切换 DNS 解析到备用 CDN 或者直接指向源站（通过 DNS 故障切换或前置的流量调度层）。A 是被动等待，C 和 D 在 CDN 不可用时没有意义。生产环境应提前配置多 CDN 或多活的容灾架构。

第 13 题

查看答案与解析

答案：B

Liveness Probe 检测容器是否存活，失败时 K8s 会重启容器；Readiness Probe 检测容器服务是否就绪，失败时从 Service 端点中移除，不接收流量。两者的失败处理行为完全不同，不能混淆。

第 14 题

查看答案与解析

答案：B

Cache-Control: no-cache 并不是完全不缓存，而是"在使用缓存前必须向源站验证资源是否新鲜"（must-revalidate）。真正的"不缓存"应该用 no-store。这是一个常见的混淆点。

第 15 题

查看答案与解析

答案：B

零停机发布时用户会话不连续最常见的原因是前后端数据结构不兼容，特别是 localStorage 或 IndexedDB 中的数据格式在新版本中发生变化。例如旧版本存了 {token, user} 但新版本改为 {accessToken, userInfo}，导致解析失败。解决方案是做好数据迁移兼容或使用后端托管会话。

第 16 题

查看答案与解析

参考思路：

1. 查看错误监控系统（Sentry / 自建），定位白屏用户设备和浏览器分布。
2. 检查 CDN 是否刷新、资源是否返回 404（查看 Network 面板）。
3. 查看 JS 执行错误，可能的兼容性（ES6+ 语法在低端浏览器报错）。
4. 紧急措施：快速关闭灰度开关或切换到上一個稳定版本。
5. 修复后重新走灰度流程验证，通过后再全量。

第 17 题

查看答案与解析

参考思路：

• 原因排查：CDN 带宽打满、源站响应变慢（数据库/后端瓶颈）、资源体积膨胀、DNS 解析慢、HTTP 连接数受限。
• 优化措施：CDN 预热确保热点资源提前缓存、启用 HTTP/2 多路复用或 HTTP/3 QUIC、开启 Brotli 压缩（比 gzip 小 20%+）、Tree Shaking 和代码分割减小 JS 体积、关键资源内联或预加载。

第 18 题

查看答案与解析

参考思路：

• 前置条件：保留最近 N 个版本的构建产物（OSS/CDN 上版本化管理）。
• 回滚通道：通过配置中心或发布系统切换版本路由指向。
• 执行步骤：
  1. 触发回滚脚本，将 CDN 或网关的路由切回上一版本（< 1min）。
  2. CDN 刷新新版本资源缓存（可选，取决于路由策略）。
  3. 自动化验证：检查核心页面加载、JS 无报错、API 响应正常（< 2min）。
  4. 如果验证通过，确认回滚完成；如果失败，触发 P0 告警人工介入。
• 保障手段：部署系统保留回滚操作日志，支持多次回滚（v3 -> v2 -> v1）。

第 19 题

查看答案与解析

参考思路：

1. 排除噪声：确认 LCP 劣化是否由网络波动/特定地域/特定设备导致，查看分位值（P50/P75/P90/P99）。
2. 资源分析：检查新版本的首屏资源加载瀑布图，是否有新增的大体积资源或未优化的图片。
3. 代码变更：比对本次发布的 diff，看是否有影响首屏渲染的代码变更（如新增同步加载的第三方脚本）。
4. 后端排查：确认首屏接口的响应时间是否劣化，SSR 场景下更需要关注。
5. 兜底：如果短期无法修复，评估回滚或对受影响资源进行优化（图片压缩、懒加载调整、关键 CSS 内联）。

第 20 题

查看答案与解析

参考思路：

1. 立即止损：暂停灰度放量，保持当前灰度比例不变或直接回滚灰度组。
2. 错误分析：在监控系统中按版本/环境筛选 JS Error，聚合错误栈，定位报错代码。
3. 根因判断：检查是否源映射（sourcemap）上传正确，能否准确定位到源码行列。
4. 修复验证：修复后在预发环境回归，再次走灰度发布流程。
5. 事后复盘：补充灰度发布的质量门禁 — JS Error 率超过阈值自动熔断。

第 21 题

查看答案与解析

参考思路：

1. 第一步 — 止损：立即将 CDN CNAME 切到备用 CDN 或直接指向源站 OSS（提前备好 DNS 容灾策略），恢复静态资源加载。
2. 第二步 — 修复证书：重新申请并部署 SSL 证书到 CDN 平台，等待全球节点生效（通常 10-60 分钟）。
3. 第三步 — 验证：多地域、多运营商验证 HTTPS 正常，确认资源可加载。
4. 第四步 — 预防：证书到期前 30 天、15 天、7 天自动化告警；使用 ACME 协议（Let's Encrypt / Cert Manager）自动化续期。

第 22 题

查看答案与解析

参考思路：

• 根因分析：
  • 新旧版本资源在 CDN 上 URL 相同（未使用 hash 或 hash 未变化）。
  • 灰度路由规则在边缘节点层面生效，但 CDN 边缘节点缓存了另一个版本的资源，导致用户拿到错误的资源。
  • 不同版本的 index.html 被 CDN 缓存混用，引用了错误的 JS/CSS。
• 长效预防：
  1. 所有静态资源使用内容哈希命名（content hash），不同版本 URL 天然不同。
  2. HTML 设置 Cache-Control: no-cache, must-revalidate，确保每次回源验证。
  3. 灰度发布在前端网关或 CDN Edge Function 层做，不在 DNS/CDN 缓存层做。
  4. 使用版本化的部署目录（/v1.2.3/），切换时只需改写 index.html 的引用路径。

第 23 题

查看答案与解析

参考思路：

1. 业务看板排查：查看转化率漏斗各环节的流失率，定位具体是哪个步骤下跌（商品页 -> 加购 -> 下单 -> 支付）。
2. AB 对照组对比：如果此次没有灰度直接全量，查看上一版本的转化率趋势；如果有灰度，对比灰度组和对照组。
3. 前端交互排查：核心流程是否出现 UI 异常（按钮不可点击、表单校验变化、页面跳转逻辑变更）。
4. 后端接口排查：相关接口的调用量和成功率是否有变化，响应时间是否增加。
5. 第三方依赖排查：埋点 SDK、支付 SDK 等第三方服务是否正常。
6. 外部事件排查：是否有竞品活动、舆情事件影响用户行为。

第 24 题

查看答案与解析

参考策略：

• HTML：Cache-Control: no-cache 或 max-age=0，配合 ETag 协商缓存。确保入口永远最新。
• JS/CSS（带 hash）：Cache-Control: public, max-age=31536000, immutable。1 年长期缓存，hash 变化即失效。
• 图片/字体：Cache-Control: public, max-age=31536000。配合 CDN 缓存，图片可通过 WebP/AVIF 格式优化减少体积。
• API 数据：
  • 商品详情：Cache-Control: public, max-age=60，短缓存。
  • 购物车/用户相关：Cache-Control: no-store 或 private, max-age=0，禁止缓存。
  • 静态配置：Cache-Control: public, max-age=3600，1 小时缓存。
• 缓存层级：浏览器缓存 -> CDN 边缘节点缓存 -> 源站 OSS -> 应用层缓存。

第 25 题

查看答案与解析

参考设计：

• 架构组件：
  • 配置中心（Apollo / Nacos / 自建）存储灰度规则。
  • 流量网关/Edge Function 根据规则做分流。
  • 灰度控制面（Web UI）供运营和开发配置灰度策略。
• 分流方式：
  • 用户 ID 取模：hash(userId) % 100 < percentage，保证同一用户始终在同一分组。
  • 地域分流：维护地域白名单，指定省市优先灰度。
  • 设备/UA 分流：特定浏览器或系统版本先验证兼容性。
  • 随机比例：适合内部体验，不适合精确控制。
• 安全机制：
  • 灰度比例实时可调，支持一键全量或一键回滚。
  • 灰度组异常指标（JS Error、API 错误率、LCP）超过阈值自动熔断。
  • 灰度操作全量审计日志。

第 26 题

查看答案与解析

参考体系：

• 错误监控：
  • JS 运行时错误（window.onerror、unhandledrejection）。
  • 资源加载错误（PerformanceObserver、onerror）。
  • 接口错误（axios/fetch 拦截器，按状态码和超时分类）。
  • 数据上报：采样率（高频错误全量，低频错误 10%），支持 sourcemap 还原。
• 性能监控：
  • Web Vitals：LCP、FID/INP、CLS。
  • 传统指标：FP、FCP、DOMContentLoaded、首屏耗时。
  • 资源维度：JS/CSS/图片加载耗时、CDN 命中率。
  • API 维度：接口耗时、成功率、慢接口 TOP N。
• 业务监控：
  • PV/UV、页面跳转流程。
  • 核心转化率、白屏率、操作成功率。
  • 自定义埋点（购物车加购、下单、支付）。
• 告警分级：
  • P0（即时通知）：白屏率 > 5%、JS Error 率 > 3%、核心接口失败 > 10%。
  • P1（5 分钟）：LCP > 4s、CLS > 0.25、转化率下跌 > 20%。
  • P2（30 分钟）：PV 异常波动、第三方 SDK 加载失败。
• 告警渠道：短信/电话（P0）、企业微信/钉钉（P1）、邮件（P2）。

第 27 题

查看答案与解析

参考设计：

• 流水线阶段：
  1. 代码提交：Pre-commit Hook（ESLint + Prettier + 类型检查），Commit Message 规范校验。
  2. 单元测试：Jest/Vitest 运行，覆盖率门禁 >= 80%，失败阻断。
  3. 构建阶段：
     • 多环境配置注入（.env.development / .env.production）。
     • 代码分割 + Tree Shaking + 压缩。
     • 生成带内容 hash 的静态资源。
     • Docker 镜像构建（多阶段构建，nginx:alpine 作为运行基础镜像）。
  4. 质量门禁：
     • 构建产物大小对比，增量超过 10% 告警。
     • 安全检查（npm audit / Snyk / Trivy）。
     • Lighthouse CI 性能预算检查（LCP < 2.5s，TBT < 200ms）。
  5. 部署阶段：
     • 自动部署到测试环境，运行 E2E 测试（Playwright/Cypress）。
     • 部署到预发环境，进行回归验证。
     • 灰度发布到生产环境（5% -> 20% -> 50% -> 100%），每阶段观察 10 分钟。
  6. 监控验证：
     • 部署后自动运行冒烟测试（Smoke Test）。
     • 对比新版本的错误率和性能基线，异常自动回滚。
     • 发布报告自动同步到协作群。

第 28 题

查看答案与解析

参考设计：

• 环境规划：
  • 开发环境（Dev）：开发者自测，直接部署分支。
  • 测试环境（Staging）：合并到 develop 分支后自动部署，供 QA 测试。
  • 预发环境（Pre-prod）：从 release 分支部署，与生产环境配置一致，做最终验证。
  • 生产环境（Prod）：从 main/master 分支部署，走灰度发布流程。
• 环境晋升（Promotion）：
  • 每个环境都使用相同的构建产物（同一 Docker 镜像或同一份静态资源），仅配置文件不同。
  • 从 Stage 验证通过后，将镜像 tag 晋升到 Pre-prod（myapp:staging-123 -> myapp:preprod-123）。
  • 从 Pre-prod 验证通过后，晋升到 Production（myapp:preprod-123 -> myapp:prod-123）。
  • 镜像不可变（Immutable），晋升只是打 tag 和更新部署配置。
• 零停机保障：
  • Deployment 使用 RollingUpdate 策略（maxSurge: 25%, maxUnavailable: 25%）。
  • 配置 Readiness Probe，新 Pod 就绪后才接流量。
  • 配合 PDB（PodDisruptionBudget）确保最少可用 Pod 数。
  • 流量切完后观察 15 分钟，如果异常立即回滚 Deployment revision。
  • 前端静态资源版本化部署，新旧版本同时在线，通过网关路由控制。

---

标签：#deployment #sre #cdn #monitoring #kubernetes #docker

最后更新：2026-07-06