老王开了一家连锁餐厅，每一家新店开张前，他都会从上衣口袋里掏出一本磨得发亮的笔记本，逐项打勾：煤气阀门、灭火器位置、食材供应商资质、员工健康证……他常说，这二十年见过的倒闭餐厅，九成不是菜不好吃，而是开张前少打了一个勾。 AI 工程师上线一个模型，也是同样的道理——你训练时跑得再好的模型，上线那一刻，面对的是真实流量、真实数据、真实的责任。生产环境部署 checklist，就是 AI 世界的“老王的笔记本”：把部署架构、模型服务、数据安全、性能容量、回滚预案、监控告警、合规审计、上线评审这些维度的检查项一条条写下来，逐项核对，不凭感觉上线，不留盲区。

岗位关联

掌握生产环境部署 checklist，是 AI 工程师从“能调模型”走向“能扛生产”的分水岭——它帮你系统化地排查上线风险，避免每一个“没想到”变成凌晨三点的故障电话。

目录
  1. 可视化演示
  2. 部署架构审查
  3. 模型服务上线
  4. 数据安全守护
  5. 性能容量评估
  6. 回滚预案准备
  7. 监控告警体系
  8. 合规审计核查
  9. 上线评审放行
  10. AI 应用场景
  11. Python 演示
  12. 常见误区
  13. 面试题

可视化演示

本节配有交互动效（进入视口后自动加载，约 3KB）。

生产部署Checklist四维度 ——48项检查覆盖上线全链路 模型服务：健康检查/权重加载/GPU状态 数据安全：TLS加密/密钥管理/日志脱敏 性能容量：P99延迟/QPS/资源利用率 合规审计：ISO27001/等保2.0/审计日志 上线门槛：48项全通过 | 高风险项一票否决 | 回滚预案RTO<5min

部署架构审查

开餐厅第一步不是买菜，而是画厨房动线图。食材从后门进，经过洗菜区、切配区、灶台，到出菜口，这条路线一旦和垃圾清运路线交叉，卫生检查必挂。老王的分店图纸，他都要亲自改三遍：备用煤气管走哪、房顶消防通道留多宽、电闸分开几路。“布局错了，后期改一处要砸一面墙。”

部署架构审查就是 AI 系统的“厨房动线图”。上线前，把每个服务画成节点，把每次调用画成连线，然后像检查动线一样问：这幅图里有没有单点？是不是所有组件挂了都有替补？网络链路走得通吗？下游依赖都摸清了吗？

具体要检查三类问题：一是单点风险，例如数据库只有一主、负载均衡只有一台、某个可用区独占了全部副本；二是高可用设计，通常需要多副本加多可用区，让故障域相互隔离；三是服务依赖与网络链路，包括外网入口、内网调用、跨机房专线的带宽与超时配置，是否需要重试与熔断。

老王改图纸时常念叨：“多花一道墙的钱，换的是十年不砸墙。”部署架构审查就是这么一道墙：上线前多花几天梳理单点和依赖，换来的是生产环境里少熬几个通宵。

A=1−(1−a)n\displaystyle A = 1 - (1 - a)^n
一个可用率为 \(a\) 的组件，部署 \(n\) 个互为冗余的副本后，系统整体可用率 \(A\) 会大幅提升。比如 \(a=90\%\)、\(n=2\) 时，\(A=99\%\)。
  1. 单副本可用率\(a\) 表示单个组件能正常工作的概率，例如 0.9 意味着一年有 10% 的时间可能故障。
    a\displaystyle a
  2. 单副本故障率\(1-a\) 表示单个组件发生故障的概率，它是可用率的“反面”。
    1−a\displaystyle 1-a
  3. 全部故障概率\((1-a)^n\) 表示 \(n\) 个副本在故障域相互独立时，所有副本同时挂掉的概率。
    (1−a)n\displaystyle (1-a)^n
  4. 整体可用率用 1 减去全部故障概率，就是至少有一个副本存活、系统整体可用的概率。
    A=1−(1−a)n\displaystyle A = 1 - (1-a)^n

模型服务上线

新灶台买回来，老王从不直接大火爆炒。他先空烧十分钟，再倒一勺油滑锅，最后用小火炒一盘青菜试试火候。“要是上来就颠大勺，火苗子窜起来能把眉毛烧了。”

模型上线也一样，不能把训练好的模型文件往服务器一扔就完事。模型服务上线前要确认四件事：版本、配置、资源、接口。

版本管理指模型文件必须有唯一标识（版本号加哈希），线上推理和离线训练用同一个模型注册表；推理服务配置涉及批处理大小（batch_size）、超时时间、最大并发等参数；资源需求评估要结合模型大小和算子类型估算 GPU 显存与 CPU 内存；接口兼容检查则确保新老版本的输入输出 Schema 一致，避免上游调用方悄悄“踩空”。

试灶台看起来耽误时间，但它让老王摸清了这口锅的脾气——几秒能烧热、火苗稳不稳、会不会冒黑烟。模型服务上线前的版本、配置、资源、接口检查，就是在摸模型的脾气。摸清了，才敢把它交给第一批真实用户。

L=λ×W\displaystyle L = \lambda \times W
系统里同时排队的请求数 \(L\)，等于每秒到达的请求数 \(\lambda\) 乘以每个请求的平均处理时间 \(W\)。想控制排队长度，要么降低到达率，要么缩短处理时间。
  1. 到达率\(\lambda\) 表示客户端每秒发来的请求数量，是系统承受的外部压力。
    λ\displaystyle \lambda
  2. 平均处理时间\(W\) 表示一个请求从进来到离开的平均耗时（秒），反映单次服务的快慢。
    W\displaystyle W
  3. 队列中的请求数\(L\) 表示任意时刻系统中正在处理或排队等待的请求总数，决定了实例需要占用的并发槽位。
    L=λ×W\displaystyle L = \lambda \times W

数据安全守护

老王的食材仓库有一把锁，钥匙只有两把，一把在他身上，一把在店长手里。冰柜还配了发电机，每周五下午雷打不动地试一次断电切换。“食材就是餐馆的命，命丢了，菜做得再好也没人敢吃。”

对 AI 系统来说，用户数据和模型参数就是“食材”。数据安全维度要检查的，不是“有没有加密码”，而是覆盖全链路的四件事。

一是传输加密，客户端到服务端、服务到服务之间启用 TLS，防止数据在网络上被窃听；二是数据脱敏，日志、监控、调试输出里不能出现完整手机号、身份证号等敏感字段；三是权限控制，按最小权限原则分配账号和 API Key，谁需要谁申请，用后定期回收；四是备份恢复演练，不仅要每天备份，还要真的从备份里恢复一次数据，确认备份不是“心理安慰”。

老王常说，仓库的门不是锁给贼看的，是锁给自己看的——提醒自己这些食材有多金贵。数据安全检查项同理，不是为了应付审计，而是让团队对每一份用户数据心存敬畏。

R=P×I\displaystyle R = P \times I
每一项安全风险都可以量化成“发生概率 \(P\) × 影响程度 \(I\)”。上线前把风险清单过一遍，优先处理 \(R\) 值最高的项。
  1. 发生概率\(P\) 表示该风险事件发生的可能性，例如 0.01 表示每年有 1% 的概率发生。
    P\displaystyle P
  2. 影响程度\(I\) 表示风险发生后的损失等级，包括经济损失、用户信任下降和合规罚款。
    I\displaystyle I
  3. 风险值\(R\) 是两项相乘的结果，用于给所有风险排序，指导该优先修复哪个漏洞。
    R=P×I\displaystyle R = P \times I

性能容量评估

饭点一到，160 个座位的餐厅坐满，后厨出菜速度跟不上，客人等半小时就摔筷子走人。老王开新店前会做一道算术题：周边三公里有多少潜在客流，午市翻台率能到多少，厨师出菜速度是每分钟几份，然后决定招几个厨师、买几口锅。

这道算术题，对应 AI 系统的性能容量评估。上线前不测算，最容易出现的问题就是：营销活动一来，流量暴涨，服务直接打满，所有请求排队超时。

压测基线制定是第一步：用压测工具（如 wrk、Locust、k6）模拟预期峰值流量，记录 QPS、TP99 延迟、错误率三条曲线；瓶颈定位分析要区分 CPU 密集型、内存密集型还是 IO 密集型，针对性地扩 CPU、加内存或加副本；容量预估模型根据历史流量趋势和业务增长预期推算未来峰值；弹性伸缩策略决定是提前扩容（定时 HPA）还是实时扩容（指标 HPA），并留出缓冲余量。

老王的算术题不一定精确到小数点，但他从不错过“最忙的那顿饭”。性能容量评估要抓住的，就是那个最极端的流量场景——把它算明白，平时再大的风浪都能翻出安全区。

N=⌈QPSpeakQPSsingle⌉×(1+r)\displaystyle N = \left\lceil \frac{QPS_{peak}}{QPS_{single}} \right\rceil \times (1 + r)
需要的实例数等于峰值 QPS 除以单实例能扛的 QPS，向上取整后，再乘一个冗余系数 \(r\)（通常留 20%~50%）。
  1. 峰值 QPS\(QPS_{peak}\) 表示业务大促或高峰时段每秒的最大请求数，是容量设计的目标值。
    QPSpeak\displaystyle QPS_{peak}
  2. 单实例 QPS 上限\(QPS_{single}\) 表示压测测出的单个服务实例能稳定处理的 QPS。
    QPSsingle\displaystyle QPS_{single}
  3. 向上取整\(\lceil \cdot \rceil\) 保证算出来的实例数至少是 1 的整数倍，不能出现半台机器。
    ⌈QPSpeakQPSsingle⌉\displaystyle \left\lceil \frac{QPS_{peak}}{QPS_{single}} \right\rceil
  4. 冗余系数\((1+r)\) 是给突发流量和单实例故障留的余量，通常 \(r\) 取 0.2~0.5。
    (1+r)\displaystyle (1+r)

回滚预案准备

老王的每个店都配了灭火器和安全出口，每个月还搞一次消防演习：警铃一响，后厨人员 30 秒内从指定通道撤到门外集合。“消防演习看着没用，真着火时，能救命的是肌肉记忆，不是临场翻手册。”

版本上线出问题，就是系统的“着火”。回滚预案不是为了祈祷不出事，而是为了出事时不用临场想“怎么退回去”。

回滚流程设计要明确“谁决定回滚、谁执行、多久内完成”；数据兼容验证要回答一个扎心问题——新版本写入的数据，旧版本还读得了吗？如果数据库表结构变了，回滚脚本必须先把数据迁回去；灰度发布策略（金丝雀部署）让新版本先接收 5% 流量，观察指标正常再逐步放大；定期演练复盘则是真的在预发环境把回滚脚本跑一遍，测出真实回滚时间。

消防演习的意义，在于让每个店员都知道自己该站哪个位置。回滚预案演练的意义也一样——真出问题时，团队不是围在一起翻聊天记录找脚本，而是各自就位，30 秒内开始执行。

Trollback=Tdetect+Tdecide+Texecute+Tverify\displaystyle T_{rollback} = T_{detect} + T_{decide} + T_{execute} + T_{verify}
总回滚时间由四段组成：发现问题的检测时间、拍板决策时间、脚本执行时间、验证恢复后的时间。每一段都可以通过演练压缩。
  1. 检测时间\(T_{detect}\) 是从故障发生到监控告警触发的时间，依赖监控覆盖度和告警时效。
    Tdetect\displaystyle T_{detect}
  2. 决策时间\(T_{decide}\) 是从收到告警到负责人拍板“回滚”的时间，需要明确的决策人和流程。
    Tdecide\displaystyle T_{decide}
  3. 执行时间\(T_{execute}\) 是回滚脚本把版本和数据恢复到上一个状态的实际耗时。
    Texecute\displaystyle T_{execute}
  4. 验证时间\(T_{verify}\) 是回滚完成后，确认核心接口恢复正常、数据一致的时间。
    Tverify\displaystyle T_{verify}

监控告警体系

老王最得意的不是菜，而是他的服务员。老客人一进门，服务员能看出今天心情不好；客人吃第一口菜时微微皱眉，服务员已经在后厨门口等着反馈了。“好服务员不是等客人喊，而是提前看出不对劲。”

监控告警就是 AI 系统的服务员。它盯着的不只是“机器还活着吗”，而是系统“状态好不好、体验有没有变差”。

核心指标监控覆盖黄金四指标——QPS、错误率、延迟（P50/P99）、饱和度（CPU/内存/GPU 利用率）；日志采集分析把分散在多个实例的日志统一收集进 ELK 或 Loki，支持按 trace_id 串联一次请求的全链路；告警阈值设定要分级：P0（服务不可用立即叫醒）、P1（严重降级 15 分钟内响应）、P2（一般异常次日处理），避免阈值设得太敏感导致告警疲劳；值班响应机制要明确 on-call 排班、升级路径和故障恢复后的复盘。

服务员的价值不在“看见了”，在“及时说”。监控告警的指标、日志、阈值、值班，本质上是一整套“看见问题→传到该听的人→有人行动”的链路。链路通了，系统才是一个有感觉的活体，而不是一台闷头出错的机器。

SLO=Ttotal−TdowntimeTtotal×100%\displaystyle SLO = \frac{T_{total} - T_{downtime}}{T_{total}} \times 100\%
服务等级目标 SLO 是衡量系统稳定性的核心数字。例如 99.9% 的 SLO，意味着一年内故障时间不能超过 8.77 小时。
  1. 总时间\(T_{total}\) 是统计周期内的总时长，如 30 天对应 43200 分钟。
    Ttotal\displaystyle T_{total}
  2. 故障时间\(T_{downtime}\) 是该周期内服务不可用的累计时长，来自告警和故障记录。
    Tdowntime\displaystyle T_{downtime}
  3. 可用性比例两者相减再除以总时间，得到服务可用时间的占比。
    Ttotal−TdowntimeTtotal\displaystyle \frac{T_{total} - T_{downtime}}{T_{total}}
  4. 换算百分比乘以 100% 得到 SLO 数值，99.9% 意味着全年故障预算只有 8.77 小时。
    SLO=Ttotal−TdowntimeTtotal×100%\displaystyle SLO = \frac{T_{total} - T_{downtime}}{T_{total}} \times 100\%

合规审计核查

餐厅开张前，最难的不是装修，是办证：营业执照、食品经营许可证、消防验收、员工健康证，一样不能少。老王说：“这些证不是给检查的人看的，是给吃饭的人一个放心的理由。”

AI 系统上线也有它的“证”——数据合规。随着《个人信息保护法》等法规落地，采集什么数据、存多久、能不能出境，都成了硬性红线。

数据合规审查要确认隐私政策与数据使用范围一致、用户授权流程完整、数据存储地域符合法规；审计日志留存要求关键操作（模型发布、权限变更、数据导出）可追溯，留存时长满足监管要求；安全漏洞扫描要检查依赖库、基础镜像、开放端口是否有已知 CVE，并用自动化扫描工具纳入 CI 流水线；权限最小化则要周期性 Review 所有账号和密钥，及时回收离职员工和过期 Key 的权限。

老王把办证称作“给自己买个安心”。合规审计不是上线前的绊脚石，而是给用户、给监管、也给团队自己的一份安心——证明这套系统值得被信任。

C=NpassNtotal×100%\displaystyle C = \frac{N_{pass}}{N_{total}} \times 100\%
合规检查项的通过率，衡量的是整个系统的合规完成度。注意，合规不是“平均分”而是“一票否决”——关键项不过关，得分再高也不能上线。
  1. 合规检查项总数\(N_{total}\) 是当前阶段所有应满足的合规要求数量，来自法规和公司制度。
    Ntotal\displaystyle N_{total}
  2. 已通过项数\(N_{pass}\) 是审计中确认已达标的检查项数量。
    Npass\displaystyle N_{pass}
  3. 合规覆盖率两者相除乘以 100%，得到合规通过率，用于向管理层汇报进展。
    C=NpassNtotal×100%\displaystyle C = \frac{N_{pass}}{N_{total}} \times 100\%

上线评审放行

所有检查做完，老王会挑一个日子，把店长、主厨、领班叫到包间，桌上放着那份打勾的检查单。他一项一项念，所有人逐项确认，全部打勾后，他才会在一张红纸上写下“今日开张”。

上线评审就是这个“开张签字会”。它把 checklist 的检查结果汇总成一次正式的 Go/No-Go 决策，而不是某个人拍脑袋说“上吧”。

检查项打分给每个检查项分配权重，按通过情况计算加权总分；风险登记管理把未解决的已知风险记入清单，标明 owner 和缓解措施，允许“带风险上线”但必须“带风险可控”；放行条件确认明确硬性门槛：任何 P0 级别的未决问题、任何数据安全或合规相关的失败项，都构成一票否决；灰度上线决策则决定先放 5% 流量还是直接全量，通常新系统、大版本升级走灰度，小改动可加速。

老王签字前总要说一句：“今天不急着开，检查单上少一个勾都不开。”上线评审就是这句话的正式版本——它把“赶着上线”的冲动，按在 checklist 的最后一个勾上。全部打勾，才配拥有一次体面的剪彩。

Score=∑iwi×si∑iwi\displaystyle Score = \frac{\sum_{i} w_i \times s_i}{\sum_{i} w_i}
\(Score\) 是加权后的检查总分，\(w_i\) 是第 \(i\) 项的权重，\(s_i\) 是第 \(i\) 项的得分（0 或 1）。得分超过放行线且无关键失败项，才允许上线。
  1. 单项权重\(w_i\) 表示第 \(i\) 个检查项的重要程度，核心服务权重高，辅助项权重低。
    wi\displaystyle w_i
  2. 单项得分\(s_i\) 是该项的检查结果，通过记 1，不通过记 0。
    si\displaystyle s_i
  3. 加权得分分子是所有项的权重乘得分之和，分母是权重总和，得分范围落在 0 到 1 之间。
    ∑iwi×si∑iwi\displaystyle \frac{\sum_i w_i \times s_i}{\sum_i w_i}

AI 应用场景

大模型推理服务上线前的容量压测与弹性扩容

阶段：性能容量评估

解决的问题：智能客服 ChatBot 上线前，团队只知道“模型效果不错”，却不知道要买多少张 GPU 卡。传统做法是凭经验估算，结果上线第一天就被流量打满，所有对话请求排队超时。

具体案例：某智能客服团队用 k6 模拟 5000 并发压测，发现单实例 TP99 延迟从 200ms 飙升到 3s，定位为 GPU 显存不足导致 batch 排队。随后将推理实例扩容至 4 卡，并设置 GPU 利用率超过 85% 时自动扩容。上线后大促流量翻了 3 倍，系统依然稳定。

金融风控模型生产环境的安全合规审计

阶段：数据安全守护与合规审计

解决的问题：银行的风控模型要用客户交易数据训练和推理，监管要求数据不出域、操作可追溯。传统开发流程只关注模型 AUC，等到上线评审才发现日志里打印了明文身份证号，被迫延期整改。

具体案例：某银行风控模型上线前，审计脚本扫描出 3 处敏感字段泄漏（日志、调试输出、异常堆栈），立即整改为脱敏输出，并将模型发布、权限变更等关键操作接入审计日志系统，留存 180 天。合规检查全部通过后，才进入生产环境。

推荐系统大版本升级的回滚演练与灰度发布

阶段：回滚预案准备与上线评审放行

解决的问题：推荐系统升级排序模型，最怕“点击率不升反降”且无法快速恢复。传统做法是直接全量上线，出问题再紧急回滚，期间用户已经感受到了推荐质量的下降。

具体案例：某短视频团队上线新排序模型前，先在预发环境完整演练了一次回滚，实际耗时 9 分钟。正式上线采用 5% 灰度逐步放量，第 3 小时发现 CTR 下降 8%，立即触发回滚预案，15 分钟内全量切回旧版本，指标恢复正常。

Python 演示

python95 行
#!/usr/bin/env python3# -*- coding: utf-8 -*-"""生产环境部署检查清单:模拟AI服务上线前的自动检查与放行决策"""import random  class CheckItem:    """单个检查项:包含名称,权重和检查函数"""     def __init__(self, name, weight, check_func=None):        self.name = name        self.weight = weight        self.check_func = check_func        self.passed = False        self.detail = ""     def run(self):        if self.check_func:            self.passed, self.detail = self.check_func()        return self.passed  class DeployChecklist:    """部署检查清单:聚合所有检查项并给出放行结论"""     def __init__(self, min_score=0.8):        self.items = []        self.min_score = min_score        self._results = []     def add_item(self, item):        self.items.append(item)     def run_all(self):        self._results = []        for item in self.items:            ok = item.run()            status = "PASS" if ok else "FAIL"            print("[%s] %s: %s" % (status, item.name, item.detail))            self._results.append({                "name": item.name,                "passed": ok,                "weight": item.weight,            })        return self._results     def decision(self):        total_w = sum(r["weight"] for r in self._results)        passed_w = sum(r["weight"] for r in self._results if r["passed"])        score = passed_w / total_w if total_w else 0.0        has_veto = any(            r["name"] in ("数据安全", "合规审计") and not r["passed"]            for r in self._results        )        go = score >= self.min_score and not has_veto        print("加权得分: %.1f%% (放行线: %.0f%%)" % (score * 100, self.min_score * 100))        print("存在一票否决项: %s" % ("是" if has_veto else "否"))        print("最终结论: %s" % ("GO, 允许上线" if go else "NO-GO, 禁止上线"))        return go, score  def check_health():    return True, "所有实例心跳正常, 副本数>=2"  def check_perf():    # 模拟压测:15%概率不达标    ok = random.random() > 0.15    if ok:        return True, "压测QPS=5120, TP99=180ms"    return False, "压测QPS=5120, TP99=980ms超阈值"  def check_data():    ok = random.random() > 0.05    return ok, "TLS已开启, 日志无敏感字段"  def check_rollback():    return random.random() > 0.2, "回滚脚本演练通过, 耗时9分钟"  def check_audit():    return True, "漏洞扫描无高危CVE, 审计日志留存180天"  if __name__ == "__main__":    checklist = DeployChecklist(min_score=0.8)    checklist.add_item(CheckItem("架构审查", 3, check_health))    checklist.add_item(CheckItem("性能容量", 3, check_perf))    checklist.add_item(CheckItem("数据安全", 3, check_data))    checklist.add_item(CheckItem("回滚预案", 2, check_rollback))    checklist.add_item(CheckItem("合规审计", 3, check_audit))    checklist.run_all()    go, score = checklist.decision()
目的：实现一个生产环境部署检查清单框架，将架构、性能、数据安全、回滚、合规五类检查项聚合，通过加权打分和一票否决规则输出最终的 GO/NO-GO 放行结论。
  1. self.passed, self.detail = self.check_func()执行检查函数，把返回的是否通过和详情存入当前检查项。
  2. self._results.append({...})把每项检查结果记录到列表，供后面的放行决策计算使用。
  3. passed_w = sum(r["weight"] for r in self._results if r["passed"])只统计通过项的权重之和，作为加权得分的分子。
  4. has_veto = any(...)检查“数据安全”和“合规审计”是否存在失败项，实现一票否决逻辑。
  5. go = score >= self.min_score and not has_veto放行条件是两个条件同时满足：分数达标且没有否决项。
  6. random.random() > 0.15模拟压测结果的不确定性，提醒真实环境里每次压测都可能不同。

常见误区

误区压测的时候我只要把 QPS 测出来，看它到没到预期值，性能就算达标了。

正解QPS 只是性能的一个面。真实表现要看延迟分布（P50/P99）、错误率，以及系统在压力释放后能否恢复。就像餐厅不能只数“出菜份数”，还要看客人等多久、有没有上错菜、翻台后桌子能不能收拾干净。

为何常见：QPS 是仪表盘上最显眼的数字，直观易得，而 TP99 延迟和错误率需要二次分析，容易被忽略。

误区我上了 Prometheus 和 Grafana，配了十几个告警规则，系统应该已经很可观测了吧。

正解能“看到指标”不等于“看懂系统”。可观测性要回答“为什么出错”，需要指标、日志、链路追踪三者联动。光有告警而没有日志和 trace，就像服务员看到客人皱眉却不知道是哪道菜出了问题。

为何常见：部署监控工具是显性、可量化的工作，容易让人产生“做了就到位”的错觉。

误区回滚预案很简单，把上一个版本的 Docker 镜像留着，出问题重新部署一下就行了。

正解版本回滚只是一部分。更关键的是数据兼容性——新版本可能改了数据库表结构或消息格式，旧版本代码还能不能读新数据？还要验证下游依赖兼容、回滚后缓存和队列的清理，并且至少演练一次，否则脚本本身可能就是坏的。

为何常见：直觉上“换回旧版本”就是替换文件，但生产系统的状态（数据、依赖、流量）让回滚远不只是换文件。

误区我是算法工程师，数据合规、日志审计这些是安全团队和法务负责的，我只要把模型指标做好就行。

正解数据合规是“设计时”就要考虑的，不是“上线前”补做的。算法工程师决定采集什么特征、存哪些日志、调用什么外部接口，这些恰恰是合规风险的高发区。训练数据里的敏感字段、推理日志里打印的用户 ID，都要在代码里就拦截掉。

为何常见：大厂岗位分工细，安全团队和法务的存在让部分工程师觉得“有人兜底”，忽视了合规要从源头做起。

面试题

Q1. 生产环境部署checklist的首要目的是什么？

单选题 · easy

  • A.加速版本上线
  • B.取代自动化测试
  • C.系统排查上线风险← 正确答案
  • D.减少开发人员数量

答案：C。checklist 的核心价值是把上线风险系统化地列出来逐项排查，避免遗漏关键环节。它不直接加速发布，也不替代自动化测试，更不是为了减少人手，而是给上线决策提供完整的依据。

Q2. 高可用设计中“消除单点”的含义是什么？

单选题 · easy

  • A.只保留一个关键节点
  • B.关闭所有备份系统
  • C.使用单机部署降低成本
  • D.任何组件都有冗余替代← 正确答案

答案：D。消除单点指每个关键组件都应有冗余副本，单一组件故障时不至于拖垮整体。只保留一个节点、关闭备份或单机部署都会放大单点风险，与高可用目标背道而驰。

Q3. 依据Little's Law \(L=\lambda \times W\)，当平均响应时间W从0.2s增加到0.4s、到达率\(\lambda\)不变时，系统中请求数L会怎样变化？

单选题 · mid

  • A.L减少一半
  • B.L随之翻倍← 正确答案
  • C.L保持不变
  • D.L直接归零

答案：B。L 与 W 成正比，\(\lambda\) 固定时 W 翻倍则 L 翻倍。就像餐厅客人到达速率不变，但每桌用餐时间翻倍，大厅里同时用餐的人数自然翻倍。其余选项都与正比关系矛盾。

Q4. 回滚预案中“数据兼容性验证”主要解决什么问题？

单选题 · mid

  • A.旧版本能读新数据← 正确答案
  • B.新版本可读旧数据
  • C.回滚后数据不丢失
  • D.备份文件的加密

答案：A。回滚后跑的是旧版本代码，但数据库里可能已有新版本写入的数据，所以必须确认旧版本能读新数据。新版本读旧数据是上线前就该保证的；备份加密和数据不丢失属于日常备份策略，不是回滚兼容性的核心。

Q5. 监控告警阈值设置过低的直接后果是什么？

单选题 · mid

  • A.漏报真实系统故障
  • B.系统性能的提速
  • C.告警风暴引发疲劳← 正确答案
  • D.日志量的剧增

答案：C。阈值过低意味着很多正常波动也触发告警，值班人员会收到大量无效通知，逐渐麻木，反而漏掉真正的故障。漏报是阈值过高的问题；告警本身不改变系统性能也不影响日志量。

Q6. 性能容量评估时需要测量的核心指标包括哪些？

多选题 · mid

  • A.峰值QPS指标← 正确答案
  • B.TP99延迟统计← 正确答案
  • C.GPU资源利用率← 正确答案
  • D.代码行数统计

答案：ABC。压测基线要看吞吐（QPS）、长尾延迟（TP99）和资源饱和度（GPU/CPU 利用率）三者的联动。代码行数是软件工程度量，与运行时容量评估无关。

Q7. “金丝雀部署”的通常做法是什么？

单选题 · easy

  • A.少量用户先用新版本← 正确答案
  • B.全部流量切到新版本
  • C.新旧版本同时下线
  • D.只保留旧版本服务

答案：A。金丝雀部署把新版本先放给 5%~10% 的流量观察，指标正常再逐步放量，异常时可快速切回旧版。全量切换、同时下线或只留旧版都不符合“小流量验证”的核心思想。

Q8. 部署架构审查时需要重点排查的单点风险有哪些？

多选题 · hard

  • A.唯一数据库主节点← 正确答案
  • B.单可用区的部署← 正确答案
  • C.无备份的缓存节点← 正确答案
  • D.超出容量的缓存

答案：ABC。唯一数据库主节点、全部副本挤在同一可用区、缓存无备份，都是典型的单点或故障域集中问题。缓存容量超限属于容量规划问题，不是部署架构的单点风险。

Q9. 若数据安全检查项未通过，按加权放行规则\(Score=\sum(w_i s_i)/\sum w_i\)应如何处理？

单选题 · hard

  • A.将该检查项权重清零
  • B.忽略该项继续放行
  • C.一票否决直接阻止上线← 正确答案
  • D.用其他项分数弥补

答案：C。数据安全和合规属于一票否决项，权重再低、其他项分数再高也不能放行。权重清零等于假装问题不存在，忽略或用分数弥补都违背 checklists 的底线原则。

Q10. 生产环境数据安全的完整防护体系包括哪些方面？

多选题 · extreme

  • A.TLS传输层加密保护← 正确答案
  • B.日志中敏感信息脱敏← 正确答案
  • C.最小化权限访问控制← 正确答案
  • D.定期备份恢复演练← 正确答案

答案：ABCD。完整的数据安全防护必须覆盖传输（TLS）、存储与日志（脱敏）、访问（最小权限）和容灾（备份恢复演练）四个环节，缺一不可。这就像餐厅的食材安全要从运输、储藏、取用和应急四个环节分别把关。