1. 为什么性能要好这句话在评审会上永远吵不出结果NFR 规格化这件事我最早是在一次需求评审上被逼着正视的。产品在需求文档里写页面加载要快、系统要稳定、高峰期不能崩开发点头说没问题测试问那我怎么判定不通过运维问那我告警阈值设多少一圈问下来会议室安静了。这三个词背后没有任何一个能被写成测试用例也没有任何一个能被写成监控指标。后来我们内部把研发流程这套东西叫 DevFlow其中专门划出一块来治理非功能需求核心工具就是 Quality Attribute Scenarios也就是质量属性场景业内简称 QAS。它的作用非常朴素把性能要好这种形容词改写成谁在什么情况下对哪个部分做了什么系统必须在多久内给出什么结果这种可以被测量、被验收、被追溯的句子。这篇文章适合三类人看正在被 NFR 扯皮折磨的产品和项目经理、需要把质量要求翻译成用例的测试同学、以及要给 SLO 定阈值的后端和运维同学。哪怕你完全没有接触过质量属性这套方法论看完也能上手把手上那几条模糊要求改写掉。1.1 一个形容词至少三种人的三种想象性能要好这四个字落到不同角色脑子里呈现的画面完全不同。开发想的是我这个接口 P95 控制在 200 毫秒以内运维想的是高峰期 CPU 别打满、连接池别耗尽产品想的是用户点下去不要转圈超过一秒而测试拿到这句话只能干瞪眼——他没有基准没有场景没有判定条件最后大概率写一条页面能打开的冒烟用例交差。这不是谁不负责是这句话本身的信息量太低了低到无法承载任何工程决策。更要命的是这三种想象之间经常是互相矛盾的。开发为了把接口 P95 压到 200 毫秒加了本地缓存结果数据一致性窗口拉长到 30 秒运维为了保证稳定把超时时间设得很短结果高峰期大量请求被熔断产品看到用户投诉偶尔白屏回来要求必须绝对稳定。三边都在做正确的事但因为没有共同的度量语言最后变成互相甩锅。QAS 解决的第一个问题就是统一语言。它不负责告诉你 P95 应该是多少它负责强制你把多少这个数字写出来并且写清楚这个数字在什么条件下、对谁、针对哪个部分成立。一旦数字被写出来讨论就从我觉得不够快变成了这个数字合不合理性质完全变了。1.2 模糊 NFR 的真实成本比想象中高很多人觉得 NFR 写不清楚无非就是文档难看点实际成本远不止。我梳理过我们团队踩过的几类验收阶段扯皮上线前一周产品说感觉还是慢开发说需求里没写具体指标最后靠加班做了一轮没有基准的优化改完也不知道有没有变好容量规划失控因为没有明确的峰值吞吐目标采购和扩容全靠拍脑袋要么买多了浪费要么大促当天被打穿告警阈值玄学运维把 CPU 告警设在 80%结果业务本身是 CPU 密集型天天告警天天被无视真出事那次反而没人看回归测试没有基线每次发版跑完压测报告上写平均响应 340ms然后没人知道这个 340ms 是好还是坏因为上一版是多少没人记录。这几类问题的共同根因是质量要求没有变成一个可以被证伪的命题。QAS 的价值就在于它天然是可证伪的——它写明了度量项和阈值达不到就是达不到没有解释空间。这听起来很冷酷但对工程团队来说是好事因为模糊带来的从来不是宽容而是无休止的争论。1.3 QAS 到底是什么一句话拆成六个槽位Quality Attribute Scenario 的结构不复杂一共六个要素刺激源Source、刺激Stimulus、制品Artifact、环境Environment、响应Response、响应度量Response Measure。翻译成人话就是谁在什么情况下对系统的哪个部分做了什么系统应该怎么反应这个反应要在什么指标上达到什么值。我习惯用点外卖来类比。模糊说法是送餐要快。QAS 化的说法是一位住在城郊的顾客刺激源在周五晚高峰环境下了一单三公里外的订单刺激配送系统制品应当在骑手接单后响应保证送达时间不超过 45 分钟响应度量。你看这么一说能不能做到、怎么考核、超时了算谁的责任全都清楚了。而且它自动暴露了一个隐含前提如果这个顾客住在二十公里外45 分钟就是不合理的场景必须重新定义。这个类比里最重要的启示是环境这个槽位不是凑数的。绝大多数性能要好翻车都是因为漏了环境约束——把工作日白天的指标和秒杀瞬间的指标混为一谈把冷启动的首请求和缓存预热后的请求混为一谈。2. 六要素逐项拆解与写法规范QAS 看着简单但真让你坐下来写六成的人会在响应度量这一栏卡住三成的人会把制品写成整个系统。这一章我按我们团队实际用的规范把这六个槽位逐个拆开讲每个都给出合格写法和典型反例。2.1 Source 与 Stimulus把谁、在什么情况下钉死刺激源要写的是谁发起了这个刺激注意是角色而不是具体某个人。常见的刺激源包括终端用户、内部定时任务、上游服务调用方、运维人员、攻击流量、第三方回调。区分刺激源的意义在于不同来源的请求系统的处理策略本来就该不一样——用户请求要保体验定时任务可以降级排队运维操作要能中断。刺激本身要写清楚动作的性质和规模。写用户访问系统太笼统写用户提交订单就具体多了如果能补上规模更好比如用户在促销开始后 10 秒内集中提交订单。规模信息非常关键因为它直接决定了后面度量的量级。这里有个容易犯的错把刺激写成功能需求。比如写成用户点击下单按钮系统创建订单并扣减库存这就跑到功能需求的地盘去了。QAS 里的刺激只描述发生了什么事件不描述系统应该完成什么业务逻辑业务逻辑是功能需求的事QAS 只关心这个事件引发的质量表现。我的经验是写刺激的时候多问一句这个动作的量级和突发性如何。同样是提交订单平时是每秒十几个大促是每秒几千个这两个是完全不同的两个场景必须分开写两条 QAS不能合并。2.2 Artifact 与 Environment划清边界防止全场景通吃制品指的是这个刺激作用在系统的哪个部分。这一栏最容易写得太粗我看过大量写成整个系统的 QAS这种写法基本等于没写因为整个系统的度量值没法归因出问题了你不知道是网关、应用还是数据库拖的后腿。合格的制品粒度应该细到能被单独观测和优化的程度。比如订单提交接口、商品详情页的读链路、订单库的主库写入、消息队列的消费端。粒度太细也不好比如写到某个具体函数的执行时间那已经不是架构层面的质量属性了那是性能剖析的范畴。环境这一栏是我认为最被低估的。它要回答的是在什么条件下。常见的环境维度有负载水平正常负载 / 峰值负载 / 超载、系统状态全部正常 / 部分节点故障 / 降级模式、数据规模冷缓存 / 热缓存 / 数据量增长到千万级、时间窗口日常 / 大促 / 批量任务运行期间。环境写得越具体这条 QAS 的可验证性就越强同时也越容易暴露其实我们根本没考虑过降级状态下应该是什么表现这种盲区。提示如果一条 QAS 的环境栏写的是任何情况下那大概率是没想清楚。真实系统不存在任何情况下都成立的质量承诺硬要写只会让这条需求失去约束力。2.3 Response 与 Response Measure可度量才是需求不可度量只是愿望响应描述的是系统在受到刺激后表现出的行为注意是可观测的行为不是内部实现。比如接口返回成功响应、请求被排队而非直接拒绝、系统自动切换到备用链路、返回降级内容并附带提示。响应里可以包含一定的策略意图比如优先保证读请求写请求进入队列这实际上是在表达质量属性之间的取舍。响应度量是整条 QAS 的灵魂也是最难写的一栏。它必须包含三个东西度量项、度量值、度量口径。度量项就是指标名比如响应时间、吞吐量、错误率、恢复时间、资源占用率。度量值是具体数字。度量口径最容易被忽略但它决定了这个数字到底怎么算——响应时间是平均值还是 P95 还是 P99错误率的分母是总请求数还是成功请求数恢复时间从故障发生算起还是从监控告警算起我见过太多因为口径不一致导致的争议。开发说我们接口平均响应 80 毫秒测试说我压测出来 P99 是 1.2 秒两边都没说谎就是口径不同。所以响应度量这一栏我要求必须写清楚分位数和统计窗口比如P95 响应时间不超过 800 毫秒统计窗口为连续 5 分钟。下面是我们团队内部用的 QAS 模板用 YAML 描述好处是能直接进需求库做结构化检索qas_id: NFR-PERF-014 quality_attribute: performance source: 终端用户 stimulus: 在促销开始后的 60 秒内集中刷新商品详情页 artifact: 商品详情读链路含缓存层与应用层不含支付链路 environment: 峰值负载缓存命中率不低于 85%全量节点在线 response: 正常返回详情内容超时请求返回上一次缓存快照而非错误页 response_measure: metric: 服务端响应时间 percentile: P95 threshold: 300ms window: 连续 3 分钟 error_rate: 5xx 比例 0.1%这份模板看着有点啰嗦但好处是一次性把口径全定死了。上线之后测试照着跑运维照着配告警谁都不用再问你说的这个 300 毫秒是平均值吗。2.4 一条完整 QAS 的逐行注释与反例对照光看模板还是抽象我拿一条真实的改写过程走一遍。原始需求原文是「搜索结果要快不能卡」。改写后的版本是当终端用户刺激源在搜索结果页发起翻页请求刺激时搜索服务制品在缓存命中率正常的日常负载环境下环境应当在 500 毫秒内返回结果响应且 P95 响应时间不超过 500 毫秒、P99 不超过 1200 毫秒5xx 错误率低于 0.05%响应度量。对比一下差异在哪。原文的快没有主体改写后明确了是翻页请求而不是首屏搜索——这两者的性能特征完全不同首屏可能要走向量检索翻页基本是缓存或游标。原文没有环境改写后限定了缓存命中正常这实际上隐含了另一条 QAS缓存未命中时应该是什么表现。原文没有口径改写后给了 P95 和 P99 双阈值还附带错误率。我特别建议给每条 QAS 都配一个反例也就是什么情况下这条 QAS 判定不通过。这招是从测试同学那里学来的效果出奇地好因为写反例的过程会逼着你重新审视度量值是不是定得太松或太紧。上面这条的反例就是连续 3 分钟内 P95 超过 500 毫秒或出现一次持续 30 秒以上的 5xx 比例超过 0.5%即判定不通过。3. 从形容词到可验证需求实操改写流程方法论讲完了落到执行层面还是得有流程。我们内部沉淀了一套五步法从收集原始噪声到挂接监控每一步都有明确产出物。这套流程跑顺之后一条 NFR 从提出到进入需求库大概需要 40 分钟比反复开会扯皮划算太多。3.1 第一步把原始噪声归类成质量属性清单先别急着写场景第一步是把所有模糊表述收集起来。来源很杂需求文档里的形容词、用户投诉、线上事故复盘、老板的口头要求、竞品对比。把它们原封不动贴到一个表里不要在这一步做任何美化。然后按质量属性归类。业界常见的分类大概有这些性能响应时间、吞吐量、可用性正常运行时间比例、故障恢复、可靠性错误率、数据一致性、可扩展性负载增长时的表现、安全性认证授权、数据保护、可维护性变更成本、部署频率、易用性任务完成率、操作步骤数、可观测性问题定位时间。这个分类不用太死板关键是让每条噪声都能找到归属。归类完之后你会发现一个有意思的现象大量噪声其实集中在性能 and 可用性这两类上而可维护性、可观测性这类不出事就没人管的属性基本没人提。这时候可以主动补几条比如新成员上手到能独立提交变更需要多久、一次线上问题从告警到定位根因的平均耗时这些同样是质量需求只是平时没人用形容词表达出来。这一步的产出物是一张归类表每条噪声后面标注质量属性类别和提出人。我建议把提出人也记上后面优先级排序和争议裁决时会用得到。3.2 第二步用场景优先级矩阵筛掉都要归完类你会发现需求多到做不完这时候必须排序。我们用的矩阵是两个维度业务影响高/中/低和实现成本高/中/低。业务影响看的是这条质量属性失效会造成什么后果——直接影响收入的、影响核心流程可用性的算高影响体验但不阻断的算中纯优化性质的算低。实现成本不用精确估算架构师凭经验给个量级就行。排完之后重点做两件事。第一明确放弃。低影响高成本的条目直接在文档里写本期不做理由是……写下来比不写强一百倍因为半年后一定有人重新提。第二找出冲突对。性能和成本冲突、可用性和一致性冲突、安全性和易用性冲突这三对是永恒的。找出冲突对之后要在文档里明确当前的取舍方向比如本期优先保证读链路的响应时间允许写链路有最多 3 秒的最终一致延迟。注意取舍一定要写成明确的数字边界不要写成优先保证性能。后者等于没取舍出事的时候两边都能拿这句话当依据。3.3 第三步度量指标选型与参数计算这一步是硬功夫度量值不能拍脑袋。我按三类最常见的质量属性分别讲怎么算。性能类的延迟预算分解。假设端到端目标是 P95 ≤ 800 毫秒那就要把 800 毫秒拆到链路的每一跳上每一跳都留出预算加起来不能超过总额通常还要留 10% 到 15% 的缓冲应对抖动。我们一个真实项目的分解表大致长这样链路环节预算P95说明客户端渲染与网络往返150ms弱网环境按 4G 估算不含 DNS 首次解析接入层负载均衡与网关30ms含 TLS 握手摊销鉴权与限流20ms走本地缓存不查库应用逻辑处理220ms含编排与两次下游调用缓存读取10ms命中时生效未命中走数据库数据库查询280ms已含索引优化后的预期值序列化与响应组装40ms大对象序列化是隐藏大头缓冲余量50ms约占总预算 6%合计800ms—这张表最有价值的地方不是数字本身而是它把800 毫秒这个目标变成了七个可以分别派给不同人的子目标。数据库那 280 毫秒归 DBA 管应用逻辑那 220 毫秒归后端管客户端 150 毫秒归前端管谁超了谁负责优化扯皮空间直接归零。可用性类的停机时间换算。很多人对几个 9没有体感换算成停机时间就直观了可用性目标年累计停机月累计停机适用场景举例99.5%约 43.8 小时约 3.6 小时内部管理系统99.9%约 8.76 小时约 43.2 分钟一般业务系统99.95%约 4.38 小时约 21.6 分钟核心交易链路99.99%约 52.6 分钟约 4.3 分钟强依赖型基础服务计算方式很直白一年 365 天乘以 24 小时等于 8760 小时乘以1 减可用性目标就是允许的停机时长。月停机按 30 天 43200 分钟算。这里有个坑要提醒这个数字是允许的总停机时长包含计划内维护。如果你的发布流程每次都要停服 5 分钟一个月发四次就把 99.9% 的额度用掉一半了所以定了可用性目标之后灰度发布和不停机部署就不是最佳实践而是硬性前置条件。吞吐量类的峰值估算。这个必须结合业务量算不能直接抄别人的 QPS。举个具体的假设某业务日活 20 万人均每天触发 6 次关键请求那么日均请求量是 120 万次平均 QPS 约等于 1200000 除以 86400约 13.9。但这个数字毫无意义因为流量不是均匀分布的。取峰值因子 8可以根据历史监控数据反推没有历史数据就取保守值峰值 QPS 约 111。再留 3 倍容量余量应对突发和增长目标定在 350 QPS 比较稳妥。压测线程数也别拍脑袋用 Littles Law 算并发数等于 QPS 乘以平均响应时间。350 QPS 乘以 0.8 秒等于 280也就是压测时至少要有 280 个并发才能打出目标吞吐。很多人压测时开 50 个线程就说打不上去其实是线程数不够不是系统不行。缓存命中率为什么要单独写一条 QAS。这个值得单独说。续上面的例子假设数据库能扛 100 QPS 的读缓存命中率 90% 时数据库实际承受的读压力是 350 乘以 10% 等于 35 QPS很安全。但如果命中率因为某个热点 key 失效掉到 70%数据库压力变成 105 QPS直接就超了。所以缓存命中率不低于 85%这条必须作为独立的质量需求写进 QAS并且配独立的监控告警而不能当成性能需求的附属品。3.4 第四步把 QAS 翻译成验收标准与测试用例QAS 写完了如果只躺在需求库里那它和原来的形容词没本质区别。必须往下翻译成两样东西验收标准和测试用例。验收标准是给产品和业务方看的用自然语言写比如在模拟峰值负载的压测环境下商品详情接口 P95 响应时间不超过 300 毫秒5xx 错误率不超过 0.1%连续压测 30 分钟不出现错误率突增。这段话里包含了场景、指标、口径和持续时间产品能看懂也能据此决定是否签字。测试用例是给测试同学执行的要具体到工具配置和判定脚本。比如压测场景要写清楚负载模型阶梯加压还是恒定压力、加压曲线从 50 并发逐步加到 350 并发每级持续 5 分钟、数据准备预置 10 万条商品数据缓存预热到命中率 90%、采集指标P50/P95/P99、吞吐量、错误率、CPU 与内存、通过条件。这里特别强调数据准备我见过太多压测用的是几百条测试数据跑出来飞快上线后真实数据量一上来直接崩这种压测还不如不做。3.5 第五步挂接监控与告警阈值最后一步是让 QAS 在线上持续生效。做法是把响应度量直接映射成监控指标和告警规则。继续用商品详情的例子SLO 配置文件大概长这样slo: name: product-detail-read-latency qas_ref: NFR-PERF-014 sli: metric: http_server_request_duration_seconds filter: route/api/product/detail and status 500 aggregation: histogram_quantile(0.95, ...) objective: target: 0.3 window: 5m alerting: - name: latency-burn-fast condition: p95 0.3 for 3m severity: warning runbook: RB-0142 - name: latency-burn-critical condition: p95 0.6 for 5m severity: critical runbook: RB-0142注意这里的告警条件直接引用了 QAS 的编号和阈值这就形成了追溯关系——告警响了值班的人顺着编号就能查到这条需求的完整背景、当初为什么定这个值、对应哪条测试用例。告警阈值的设计有个经验不要只设一条线。设两条一条是接近阈值比如 1 倍目标值作为预警一条是明确超标比如 2 倍目标值作为紧急。只设一条线的结果要么太吵要么太钝两条线能给你留出介入的窗口。4. 可追溯性设计让每条 QAS 都能被追到规格化只做了一半的工作另一半是追溯。没有追溯的规格文档三个月后就是一堆没人看的表格。这一章讲我们怎么把 QAS 挂进整条研发链路。4.1 编号体系与双向追溯矩阵编号规则看着是小事实际上是追溯的基础。我们的规则是NFR-属性缩写-三位序号属性缩写用 PERF、AVAIL、REL、SEC、MAINT、OBS 这类固定词表。编号一旦分配就永久保留需求作废了也不复用状态标记为废弃即可。光有编号还不够要建立双向追溯从 QAS 能查到它对应的功能需求、测试用例、监控指标、线上事故反过来从一次线上事故也能查到它违反了哪条 QAS。这个矩阵用表格维护最省事QAS 编号关联功能需求测试用例 ID监控指标近期事故NFR-PERF-014FR-PRODUCT-003 商品详情TC-PERF-021详情接口 P95INC-2024-031NFR-AVAIL-006FR-ORDER-011 下单主链路TC-AVAIL-008下单成功率INC-2024-019NFR-REL-003FR-PAY-002 支付回调TC-REL-014回调重复率—这张表的价值在事故复盘时体现得最明显。以前复盘写系统响应变慢导致用户投诉现在写INC-2024-031 违反了 NFR-PERF-014 中 P95 ≤ 300ms 的承诺实测峰值期间达到 1.4 秒根因是缓存命中率从 90% 跌至 62%。后者能直接推导出改进项前者只能推导出一句加强监控。4.2 需求到用例到监控的三方对齐表追溯矩阵里最容易断链的是用例和监控这两环。测试用例通常在测试管理系统里监控规则在监控平台上两边各说各话。我的做法是强制要求用例 ID 出现在监控规则的注释里同时监控告警的 runbook 里必须写明对应的测试用例编号。这样值班的人处理告警时能直接翻到当初验证这条指标用的压测方案照着复现比盲猜快得多。三方对齐还有个隐性收益它能暴露有需求无用例和有用例无监控的空档。我们第一次做这个对齐时发现将近四成的质量需求压根没有对应的测试用例还有三成的用例跑完之后的数据没有进入任何监控。这两个数字说明之前的质量保障基本是断的。4.3 变更时的追溯维护需求会变追溯关系必须跟着变。我们定了两条规矩QAS 的阈值调整必须走变更评审评审记录里要写清楚调整原因是业务量涨了还是原阈值不合理并且必须同步更新用例和监控QAS 作废时关联的用例和监控规则要在同一个变更里一起下线不能留孤儿。这条规矩听起来官僚但真的很必要。我们之前有一次把某个接口的延迟目标从 500 毫秒放宽到 800 毫秒监控改了、文档改了但压测脚本没改结果下一次回归测试照着 500 毫秒判定报了一堆性能退化排查了两天才发现是阈值不同步。4.4 这套东西落地后影响的是哪些角色值得单独说说影响范围因为这决定了推行的阻力在哪。对产品经理来说最大的变化是不能再写形容词了。提需求时必须回答这个快是给谁看的、在什么情况下、多快算快前期会很不适应但后期会爱上这套东西因为验收时终于有据可依。对开发来说好处是目标明确了坏处是没法再含糊其辞。以前说这个优化空间不大可以糊弄过去现在延迟预算表摆在那你这一跳占了多少、还剩多少余量一目了然。同时它也保护了开发——有人在评审时说感觉还是慢你可以直接反问具体是哪条 QAS 的哪个指标不达标。对测试来说这是收益最大的一环。NFR 从没法测变成有明确用例性能测试从跑一下看看变成对照阈值判定回归测试有了基线可以对比。对运维来说告警阈值终于有了业务依据不再是经验值 80%。同时 SLO 和 QAS 挂钩之后容量规划和扩容决策也有了数据支撑。对架构决策来说影响更深远。QAS 一旦成体系架构评审的关注点就从用了什么技术转向这个设计能不能满足这 N 条场景技术选型有了明确的判定标准而不是靠技术栈的新旧来争论。5. 常见踩坑实录与速查表方法论和流程讲完最后这部分是我觉得最有价值的部分——都是真实踩过的坑。有些坑当时觉得是小事后来发现影响挺大。5.1 度量值拍脑袋以及伪精确的陷阱第一个坑是把度量值当成许愿。有次评审业务方要求订单提交接口响应时间不超过 50 毫秒我问依据是什么回答是用户等不了太久。50 毫秒意味着什么意味着一整个下单链路校验库存、创建订单、扣减库存、发消息必须在 50 毫秒内跑完这基本要求所有环节全内存操作成本极高。后来拆开看用户真实能感知的阈值在 800 毫秒左右我们最终定的是 P95 ≤ 600 毫秒成本降了一个数量级。反过来也有伪精确的坑。有人喜欢写成P95 ≤ 347 毫秒这种数字看着很严谨其实 347 和 350 没有任何工程差别纯粹是算出来的。度量值应该定在业务能感知、系统有台阶的位置上350 就是比 347 好记也好沟通。过度精确只会让后面调整阈值时显得很不严肃。还有一个隐蔽的坑只定上限不定下限。某些场景下响应太快反而是问题比如风控校验如果 20 毫秒就返回了很可能意味着它压根没做实质校验。这类场景要考虑加下限或者加校验覆盖率指标。5.2 把场景写成了功能用例这个坑太常见了。典型症状是 QAS 里出现了大段业务逻辑描述比如用户提交订单系统校验库存充足后扣减库存生成订单号并返回。这不是 QAS这是功能用例。判定的方法很简单把响应度量那一栏遮住看剩下的内容还能不能构成一个完整的功能描述。如果能说明你写的是功能需求如果遮住之后发现这句话什么也没说明白那才是 QAS 该有的样子。QAS 的刺激只描述事件响应只描述质量相关的行为比如成功返回、降级返回、排队等待不描述业务逻辑。另一个变种是把测试步骤写进场景。我见过写成第一步打开页面第二步点击按钮第三步观察响应时间的这是测试用例的写法。QAS 是需求规格测试用例是实现手段两者层级不同不要混。5.3 质量属性互相打架时取舍要写进文档性能和一致性打架、可用性和成本打架、安全性和易用性打架这些冲突不可能消除只能明确取舍。我们遇到过一个典型案例为了提升商品详情页的读取性能加了多级缓存结果是价格和库存的更新有最多 10 秒延迟。这在平时没问题但在秒杀场景下会导致超卖。最后的处理方式是分场景定义普通商品详情页允许 10 秒延迟秒杀商品详情页强制走实时读性能目标从 P95 ≤ 300 毫秒放宽到 P95 ≤ 800 毫秒同时把秒杀期间超卖笔数必须为 0作为更高级别的硬约束。关键在于这个取舍必须写进文档写清楚A 场景优先性能接受 B 场景的一致性延迟C 场景优先一致性接受性能下降。如果只在会上口头说了一句那后面一定会出问题因为没人记得当时的上下文。5.4 踩坑速查表把上面这些零散的经验整理成表方便对照排查症状大概率原因处理方式度量值高得离谱开发集体反对用了用户感知阈值以外的理想值回到真实链路上做感知阈值调研按延迟预算反推度量值定得很精确但没人遵守阈值缺乏工程台阶无法落地取整到有意义的档位同时明确超标的处置流程QAS 写完测试说没法测环境或口径没写清楚补齐负载模型、数据规模、分位数、统计窗口上线后指标正常但用户仍投诉慢只测了服务端忽略了客户端和网络补充端到端场景把客户端渲染和网络往返纳入预算压测通过但线上被打穿压测数据规模和真实规模差距大用生产数据脱敏后的等比例数据集至少要覆盖千万级告警天天响没人管阈值只设一条线且定得过紧改成预警与紧急双阈值预警线设为目标的 1 倍缓存命中率掉下去引发雪崩命中率没作为独立质量需求管控单独定义命中率 QAS配独立告警和热点 key 监测需求变更后监控和用例不同步缺少变更时的联动机制变更单强制勾选用例与监控的同步更新项场景写了但没人用没有挂进需求库和监控系统编号入需求库指标入监控双向追溯矩阵维护用一个我个人最深的体会收尾QAS 这套东西最大的价值不是那些表格和模板而是它强制产生的那个停顿——在写下性能要好之后你必须停下来问自己一句好在哪儿怎么算好。这个停顿能省掉后面无数次会议。我们团队推行了大概半年最直接的变化是需求评审从平均 90 分钟降到 40 分钟因为大量争议在写 QAS 的阶段就已经被逼着解决了。至于那些实在定不下来的指标我的建议是先定一个粗略值上线用真实监控数据跑两周再回来修订比在会议室里空想三天有用得多。