每次上线前我都习惯把功能需求清单从头到尾过一遍确认每个按钮、每个流程都按文档实现了。但真正让我半夜爬起来处理线上事故的从来不是某个功能没做对而是那些根本没写进文档里的东西——并发一上来系统就卡死、数据量涨到百万级查询慢得像蜗牛、高峰期服务直接无响应。这些就是软件非功能需求要回答的问题。它不关心系统“做什么”而关心系统“做得怎么样”跑得快不快、稳不稳、安不安全、扛不扛得住。功能需求决定了系统的下限非功能需求决定了系统的上限。这篇文章想把我这些年跟 NFR 打交道的经验做一个系统梳理聊聊性能、安全、可用性这些指标到底怎么定、怎么测、怎么写进文档还能真正落地适合正在负责需求分析、架构设计或者项目管理的朋友参考。1. 一款“功能齐全”的系统为什么会在一夜之间崩掉1.1 事故现场的复盘功能验收全通过线上却撑不住有个项目让我印象特别深当时是一个面向公众的信息查询系统从需求文档到测试用例功能覆盖做得相当完整。登录、查询、导出、权限控制每个模块的测试结果都是“通过”业务方很满意项目按期上线。上线第三天的晚高峰系统开始大面积超时。监控面板上的平均响应时间从 200 毫秒飙升到 6 秒数据库连接池被打满很多用户直接看到白屏。领导问的第一句话是“你们不是测过性能吗”查了下压测记录确实测过但当时用的是 20 个并发用户、10 万条测试数据。而生产环境是 800 并发、300 万条数据还叠加了全文搜索和多条件组合过滤。问题就出在需求的源头——性能需求被写成了一句“系统应保证在高并发下稳定运行”没有量化指标没有数据规模没有并发模型。开发和测试各自理解开发觉得“能跑就行”测试按“随手填的数字”做验收入库。上线前没人能说清系统到底能扛多大压力因为没人定义过“多大”是多少。1.2 非功能需求到底是什么那些“看不见”的约束条件非功能需求Non-Functional Requirements简称 NFR描述的是系统的质量属性、约束条件和运行环境特性。功能需求回答“系统做什么”比如“用户可以用账号密码登录”非功能需求回答“这个登录过程应该在 1 秒内完成并且连续 10000 次登录尝试不能出现 1 次失败”。常见的 NFR 包括以下几类按照项目特点会有侧重类别关注点典型问题性能响应时间、吞吐量、并发能力单个请求多久返回系统每秒能处理多少请求可用性系统持续提供服务的能力全年可用时间占比多少故障后多久恢复安全性数据保护、访问控制、审计追溯敏感数据是否加密谁能访问什么操作是否有日志可维护性代码可读、模块化、可扩展新增一个功能需要改多少模块可移植性跨平台、跨环境部署能力能否在不同操作系统、容器环境运行兼容性与周边系统的协同能力能否和不同浏览器的多个版本正常兼容这些属性往往不是独立的相互之间还有制约关系。强调安全性会增加复杂度过度追求性能可能牺牲可维护性。写需求的人要做的不是把所有 NFR 都堆上去而是根据业务背景找出真正关键的少数几条给出可度量的定义。1.3 为什么 NFR 总是被拖到最后一刻才想起来我观察下来NFR 被忽视主要有三个原因。第一个原因是抽象。功能需求可以画原型、写用例看得见摸得着NFR 往往是一句“系统要稳定可靠”没经验的人不知道该怎么拆。第二个原因是验收难。功能测试可以点点点性能和安全测试需要环境、工具和专门的方法。第三个原因是“以后再说”心态——项目周期紧时最先砍掉的就是压测、安全评审这些“非必须”活动。但这笔账迟早要还的。架构设计已经定型、代码已经堆积、测试环境已经搭好之后再回头补性能和安全改动成本是指数级上涨的。我就见过一个系统因为上生产后数据量涨到一定程度数据库索引设计不合理开发被迫连续加班两周重写查询逻辑。如果这个数据量在需求阶段就做了预估完全可以避免。2. 性能需求与容量估算不能写“响应要快”这种废话2.1 性能指标怎么定从用户感知到技术度量很多人写性能需求时提“响应要快”“系统要流畅”这种表述无法测试也无法验收。真要落地得把用户感受到的“快”翻译成技术团队能测量的指标。我常用的几个基础指标响应时间Response Time从发出请求到收到完整响应的时间通常用平均响应时间和 P95/P99 响应时间两个数字来描述。P99 的意思是 99% 的请求都在这个时间之内完成比平均值更能反映恶劣情况下的体验。吞吐量Throughput单位时间内系统处理的请求数量常用 TPS每秒事务数或 QPS每秒查询数表示。并发用户数Concurrent Users同一时间正在和系统交互的用户数。注意“并发用户”不等于“在线用户”在线用户里可能只有一部分在真正操作。举个例子某系统的登录接口我会写成“在 500 并发用户下登录请求的 P95 响应时间不超过 1.5 秒P99 不超过 3 秒吞吐量不低于 300 TPS。”这样测试团队就有了明确的通过标准。2.2 并发用户数、吞吐量、TPS 的估算方法估算承载规模是性能需求的核心。很多项目的性能目标拍脑袋定定高了增加成本定低了上线就崩。这里分享一套我从业务指标倒推技术指标的估算逻辑。假设要做一个电商下单系统已知运营给出的业务预期是日均订单 20 万。这里的关键是找到“高峰时段”和“高峰占比”。一般电商业务的流量有明显的波浪特征假设晚 8 点到 10 点是高峰占全天订单量的 60%那么高峰期的订单量是 12 万分布在 7200 秒内每秒订单量大约是 17 笔。但下单不是一个孤立操作。用户从浏览商品到提交订单期间涉及商品查询、库存校验、优惠计算、订单写入、支付回调等一系列请求。我一般按下单操作的 8 到 10 倍估算后端请求量也就是说每秒会产生 136 到 170 个后端请求。如果还要叠加搜索、推荐、购物车等操作总量还要再乘上 2 到 3 倍得到接近 400 QPS 的峰值压力。再加上 30% 到 50% 的冗余量性能目标就可以定为“峰值压力 600 QPS 下核心接口 P95 响应时间不超过 2 秒”。这个方法是粗粒度估算但至少让需求有了量化依据。有了这个数字架构师才能判断需要几台应用服务器、数据库要什么规格、缓存要不要上、消息队列怎么选。2.3 一个可落地的性能验收标准长什么样光有估算还不够还要把性能需求写进验收标准让测试有明确的执行依据。我常用的写法是列一张性能指标需求表每个接口都对应一组明确的数值接口典型场景峰值并发基线响应时间峰值响应时间目标吞吐量商品检索晚高峰用户搜索800P95 0.5sP95 2s400 QPS购物车查询加购状态轮询500P95 0.3sP95 1s200 QPS订单提交限时折扣抢购300P95 1sP95 3s100 TPS支付结果回调支付渠道通知200P95 0.8sP95 2.5s50 TPS有了这张表测试团队就可以在压测环境里按 1 倍、1.5 倍、2 倍峰值逐步加压观察系统在哪个压力点开始出现性能拐点是响应时间超标还是错误率上升。压测报告里必须包含 P95/P99 响应时间、TPS 曲线、错误率、CPU/内存/数据库连接等资源使用情况。这样才能回答“系统到底能不能扛住高峰期”而不是“系统在测试环境下跑得挺溜”。这类压测工具的选择上JMeter 是最常见的开源方案适合模拟 HTTP 协议接口压力遇到复杂协议或移动端接口可以考虑 Locust 用 Python 编写压测脚本可扩展性更强。基础流量摸底用 JMeter 足够复杂链路压测用 Locust 更灵活。3. 安全非功能需求从威胁建模到合规约束3.1 威胁建模把攻击面摊开来看安全需求最大的误区是写得“全而空”。常见的模板是“系统应具备完善的安全防护能力”“应采用加密技术保障数据安全”但“完善”是什么标准“加密”用 AES-256 还是 RSA 2048这些不写清楚开发就会按照自己理解选实现方案测试也不知道该验证到什么程度。我现在的做法是拿到项目后先做一轮轻量级威胁建模把系统当成一个攻击目标来审视正向走一遍“谁可能从哪里进来通过什么手段拿到什么资产”。思路就是四步走。第一步梳理资产找出系统里值钱的东西用户个人信息、交易数据、支付凭证、业务密钥。第二步识别入口注册登录、文件上传、接口调用、第三方回调都是可能的突破点。第三步分析攻击手段针对每个入口想可能的攻击路径比如暴力破解弱口令、注入恶意参数、越权访问他人数据、上传恶意文件。第四步针对每个风险制定控制措施明确用什么技术手段应对。做完威胁建模安全需求就不是一句空话而是一组可验证的控制措施列表。例如“文件上传接口应校验文件类型和内容仅允许指定扩展名且需通过安全扫描后才能访问”“所有涉及用户身份的操作应记录审计日志日志内容至少包含时间、操作者、操作类型、操作对象和处理结果”。3.2 数据保护与隐私合规不是安全部门的独角戏数据保护类的 NFR 往往和合规要求强相关尤其是涉及个人信息和金融数据的系统。这里的合规要求不同地区、不同行业差异很大需要在项目开始前对照适用的法规和监管规范逐条梳理形成一张需求对照表每一条都要能追溯到具体的技术控制措施。比如哪些字段属于敏感数据必须加密存储哪些场景需要使用加密传输数据留存期限是多少天过期后如何安全销毁用户行使数据访问、更正、删除权利时系统需要在多长时间内响应这些问题必须在需求阶段给出明确答案而不是让开发者在实现时自由发挥。还有一类容易被忽略的是测试数据。联调环境和测试库经常直接拷贝生产数据导致敏感信息在非生产环境中泄露。这类问题属于数据安全需求的一部分应该在 NFR 中明确规定所有进入测试环境的数据必须经过脱敏处理脱敏规则应覆盖姓名、手机号、身份证号、银行卡号等低纬度高价值字段。3.3 安全测试怎么在项目周期里安排安全需求写了不测等于没写。但安全测试不是等到上线前做一次渗透测试就完事需要在项目周期的不同阶段安排对应的验证活动。开发阶段可以做静态代码扫描工具能自动发现常见的注入漏洞、弱加密算法、危险函数调用等代码层问题。联调阶段可以做依赖安全检查排查第三方组件和开源库的已知漏洞这类问题在很多项目里最致命——业务代码写得再安全一个过时的日志组件就能让整个系统受影响。上线前需要做一次针对性的渗透测试重点验证威胁建模阶段识别出的高风险路径包括认证绕过、越权访问、敏感信息泄露等场景。安全漏洞的修复也和普通缺陷不同不能只看“功能正确”还要评估漏洞的利用路径和影响范围。我给团队定的要求是高危漏洞必须当天确认影响面3 个工作日内完成修复和复测中危漏洞纳入最近迭代排期低危漏洞记录在册统一规划修复。有了这个节奏安全需求才能真正闭环。4. 可用性与可靠性SLA、故障恢复与冗余设计4.1 可用性的计算公式99.9% 到底一年能坏多久可用性需求是所有 NFR 里最经常被当作摆设的。很多需求文档写“系统可用性应达到 99.99%”但没人问过“99.99%”背后对应的故障时长是多少也没人验证过系统架构到底能不能支撑这个目标。可用性的计算公式其实很简单可用性 正常服务时间 / 总时间 × 100%。一年按 8760 小时计算我把不同可用性等级对应的年故障时长列在这里99%每年停机 87.6 小时约 3.6 天99.9%每年停机 8.76 小时99.95%每年停机 4.38 小时99.99%每年停机 52.6 分钟99.999%每年停机 5.26 分钟看清这些数字之后很多不切实际的可用性目标会自我修正。要达到 99.99%单靠一套系统根本不可能必须依赖多节点冗余、自动故障转移、完善的监控告警和演练成熟的应急预案。如果写需求时不知道架构能达到的量级就很容易定出架构成本和业务预期完全不匹配的目标。4.2 MTTR、MTBF 与故障演练别等出事了再学可用性不能只盯着“全年不坏”还要看“坏了能不能快速修好”。这就引出了两个关键指标MTBF平均故障间隔时间和 MTTR平均修复时间。MTBF 反映系统的稳定性MTTR 反映团队的应急能力。要在需求阶段明确核心服务故障的响应时间目标是多少恢复时间目标是多少从发现故障到恢复服务最长允许多久指标定义清楚了还要验证团队真的能在规定时间内恢复。我见过的有效做法是定期做故障演练——人为制造节点宕机、网络分区、依赖服务超时看系统能否自动切换也看团队能否按预案快速恢复。第一次演练往往手忙脚乱做过几次之后该优化的优化该补文档的补文档应对真实事故的底气完全不一样。故障演练可以把恢复动作写成操作手册内容包括故障场景描述、影响范围评估、第一次响应动作、升级路径、具体恢复步骤、事后复盘要求。手册不追求面面俱到关键是紧急情况下能照着做每个操作都要有人验证过。4.3 冗余、降级与兜底可用性靠的不只是堆机器提升可用性最常见的手段是加冗余但冗余不是万能药。堆了双机热备如果没做会话同步和状态一致性设计切换时照样丢数据做了集群如果数据库只有一个单点应用层再冗余数据库一坏全站瘫。真正想在需求阶段把可用性做扎实要围绕几件事设计每个关键组件是不是存在单点故障发生时流量能否自动转移依赖的下游服务没有响应时系统是否有降级方案部分功能不可用时核心业务还能不能继续这就像出门带伞不是为了跟暴雨硬拼而是为了让小雨天不至于太狼狈。降级方案也一样在极端情况下降级非核心功能比如暂时关闭评论、暂缓生成报表保住核心链路比如支付、下单、查询持仓持续可用要比“坚守完整功能”的完美主义更实际。我在可用性需求里通常会加上一条降级预案要求系统必须支持对核心链路上非必需依赖的开关控制当依赖的第三方服务连续失败次数达到阈值时自动触发降级确保核心功能不受影响依赖恢复后系统应自动回到完整功能状态。这类需求明确了“什么能砍、什么必须保”在事故中能起决定性作用。5. 往需求文档里写 NFR 的实操模板与避坑清单5.1 每一条 NFR 必须满足的三条检验标准很多团队不是不写 NFR而是写了等于没写。我判断一条 NFR 是否合格会用三个标准来检验。第一它必须是可度量的。描述里必须有数字、单位、条件和测量方法。“系统应该支持大量用户并发请求”不可度量“系统在 800 并发用户、300 万数据量的条件下核心查询接口 P95 响应时间不超过 2 秒”才是可度量的。第二它必须是可验证的。有了量化指标还不够还要有对应的测试方法和验收条件。性能达标怎么压测安全漏洞标准是什么故障恢复目标怎么验证这些都需要在定义阶段给出明确的执行路径。第三它必须能追溯到业务价值。如果一条 NFR 无法解释“为什么需要这个指标”那它大概率是拍脑袋写出来的。不过度设计就是节约成本写需求的人要能说清楚每个数字背后的业务驱动因素。如果为了“显得专业”堆砌指标最后只会增加开发和测试成本对业务毫无帮助。5.2 需求评审阶段最容易放过的 NFR 漏洞需求评审时大家盯功能讲得热火朝天NFR 往往几句话就过完了。我梳理了几个常见漏洞评审时建议逐一对照检查。数据规模没写。很多系统上线后出问题都是因为需求阶段没预估数据量导致设计容量和实际负载差距悬殊。至少在需求中明确首年数据量级、年增长率、最大单品数据规模这些直接影响索引设计、分库分表方案和存储选型。第三方接口的性能和可用性没写。外部服务的响应时间、超时设置、重试策略、熔断阈值都要有明确规定。选型约束写死导致实现成本暴涨。比如完全禁止使用某种数据库但没有给出理由。过度限制会伤害技术方案合理性评审时要追问一句“为什么”。只有正常场景没有异常场景。限流触发时返回什么提示下游超时怎么处理数据重复提交怎么识别这些异常路径的 NFR 往往容易被忽略。评审流程上也建议设置“NFR 强制检查点”在需求评审完成之前必须一条条对照 NFR 清单打勾确认未确认项要明确责任人。这里不需要增加额外流程只要把检查点挂到现有评审环节里就能起作用。5.3 我踩过的一个发布前才改写性能架构的坑分享一个真实踩坑经历某项目已经进入 UAT 阶段产品功能全部完成业务方准备验收。联调过程中偶然发现一个高频查询接口在 10 万数据量下响应速度已经超过 4 秒而生产预期是千万级数据量和数百并发。查了代码才发现表结构设计时没有按查询模式创建组合索引多表关联查询在数据量增长后成本成倍上升。这个问题的根源在产品设计早期没有做容量评估。开发同学按“功能正确”标准实现索引优化和查询优化被视为“以后再说”的事。结果发布前一周DBA 临时补索引、重写 SQL、调整缓存策略项目延期两周上线质量也很勉强。这次教训之后我给自己定了个规矩需求阶段的数据量级评估和核心查询路径的性能预估必须和功能需求同步完成产品经理和架构师一起签字确认不允许把性能工作拖到开发完成之后。把性能需求当成一等公民而不是版本临时辅导项系统才不会上线就翻车。5.4 一个可以直接拿来改的 NFR 章节模板最后分享一个我在项目里惯用的 NFR 模板骨架覆盖了大多数业务系统需要明确的指标项。使用时不要求所有条目都填满但要针对项目特点给每个适用条目填上量化指标。性能与容量峰值并发用户数____目标吞吐量QPS/TPS____核心接口 P95 / P99 响应时间____ / ____首年预估数据量级____ 条年增长率____%压力测试基准环境规格____安全与合规敏感数据清单及加密存储要求____传输加密协议与最低版本____认证与会话管理要求有效期、锁定策略____审计日志内容与留存时间____测试环境数据脱敏要求____可用性与恢复目标可用性年停机时长____RTO恢复时间目标____RPO数据恢复点目标____故障演练频率____降级方案覆盖的核心功能____可维护性与可扩展性新增标准业务接口的平均开发工时上限____部署升级的停机时间限制____模块化与复用性要求____兼容性需支持的浏览器及版本____需兼容的操作系统____模板用多了之后我总结出一个原则NFR 的关键不是“写得多”而是“每条都有验收标准”。宁可只有七八条真正量化过的指标也不要四五十句正确但没用的空话。写这块内容的时候我在想可能有些团队看完整篇还是觉得无从下手这很正常。NFR 是一项需要持续积累的能力不是看一篇文章就能立刻练成。我的建议是先从手头项目挑最重要的一类指标开始比如性能或安全把它彻底量化、可测、落地跑完一个版本后再扩展到其他领域。我在实际项目中被问得最多的几个问题往往都和“怎么定这个数值”有关。没有通用的标准答案每个系统都有自己的业务背景和承载极限。真正有效的方法是从数据推算、从竞品对标、从历史故障中收集证据然后敢于在需求评审时对这个数字负责。这也是一种可以培养的判断力。 
长河君 · 2026/10/10 22:47:13 · 阅读 1.2k 非功能需求实战：性能、安全与可用性的量化落地
每次上线前我都习惯把功能需求清单从头到尾过一遍确认每个按钮、每个流程都按文档实现了。但真正让我半夜爬起来处理线上事故的从来不是某个功能没做对而是那些根本没写进文档里的东西——并发一上来系统就卡死、数据量涨到百万级查询慢得像蜗牛、高峰期服务直接无响应。这些就是软件非功能需求要回答的问题。它不关心系统“做什么”而关心系统“做得怎么样”跑得快不快、稳不稳、安不安全、扛不扛得住。功能需求决定了系统的下限非功能需求决定了系统的上限。这篇文章想把我这些年跟 NFR 打交道的经验做一个系统梳理聊聊性能、安全、可用性这些指标到底怎么定、怎么测、怎么写进文档还能真正落地适合正在负责需求分析、架构设计或者项目管理的朋友参考。1. 一款“功能齐全”的系统为什么会在一夜之间崩掉1.1 事故现场的复盘功能验收全通过线上却撑不住有个项目让我印象特别深当时是一个面向公众的信息查询系统从需求文档到测试用例功能覆盖做得相当完整。登录、查询、导出、权限控制每个模块的测试结果都是“通过”业务方很满意项目按期上线。上线第三天的晚高峰系统开始大面积超时。监控面板上的平均响应时间从 200 毫秒飙升到 6 秒数据库连接池被打满很多用户直接看到白屏。领导问的第一句话是“你们不是测过性能吗”查了下压测记录确实测过但当时用的是 20 个并发用户、10 万条测试数据。而生产环境是 800 并发、300 万条数据还叠加了全文搜索和多条件组合过滤。问题就出在需求的源头——性能需求被写成了一句“系统应保证在高并发下稳定运行”没有量化指标没有数据规模没有并发模型。开发和测试各自理解开发觉得“能跑就行”测试按“随手填的数字”做验收入库。上线前没人能说清系统到底能扛多大压力因为没人定义过“多大”是多少。1.2 非功能需求到底是什么那些“看不见”的约束条件非功能需求Non-Functional Requirements简称 NFR描述的是系统的质量属性、约束条件和运行环境特性。功能需求回答“系统做什么”比如“用户可以用账号密码登录”非功能需求回答“这个登录过程应该在 1 秒内完成并且连续 10000 次登录尝试不能出现 1 次失败”。常见的 NFR 包括以下几类按照项目特点会有侧重类别关注点典型问题性能响应时间、吞吐量、并发能力单个请求多久返回系统每秒能处理多少请求可用性系统持续提供服务的能力全年可用时间占比多少故障后多久恢复安全性数据保护、访问控制、审计追溯敏感数据是否加密谁能访问什么操作是否有日志可维护性代码可读、模块化、可扩展新增一个功能需要改多少模块可移植性跨平台、跨环境部署能力能否在不同操作系统、容器环境运行兼容性与周边系统的协同能力能否和不同浏览器的多个版本正常兼容这些属性往往不是独立的相互之间还有制约关系。强调安全性会增加复杂度过度追求性能可能牺牲可维护性。写需求的人要做的不是把所有 NFR 都堆上去而是根据业务背景找出真正关键的少数几条给出可度量的定义。1.3 为什么 NFR 总是被拖到最后一刻才想起来我观察下来NFR 被忽视主要有三个原因。第一个原因是抽象。功能需求可以画原型、写用例看得见摸得着NFR 往往是一句“系统要稳定可靠”没经验的人不知道该怎么拆。第二个原因是验收难。功能测试可以点点点性能和安全测试需要环境、工具和专门的方法。第三个原因是“以后再说”心态——项目周期紧时最先砍掉的就是压测、安全评审这些“非必须”活动。但这笔账迟早要还的。架构设计已经定型、代码已经堆积、测试环境已经搭好之后再回头补性能和安全改动成本是指数级上涨的。我就见过一个系统因为上生产后数据量涨到一定程度数据库索引设计不合理开发被迫连续加班两周重写查询逻辑。如果这个数据量在需求阶段就做了预估完全可以避免。2. 性能需求与容量估算不能写“响应要快”这种废话2.1 性能指标怎么定从用户感知到技术度量很多人写性能需求时提“响应要快”“系统要流畅”这种表述无法测试也无法验收。真要落地得把用户感受到的“快”翻译成技术团队能测量的指标。我常用的几个基础指标响应时间Response Time从发出请求到收到完整响应的时间通常用平均响应时间和 P95/P99 响应时间两个数字来描述。P99 的意思是 99% 的请求都在这个时间之内完成比平均值更能反映恶劣情况下的体验。吞吐量Throughput单位时间内系统处理的请求数量常用 TPS每秒事务数或 QPS每秒查询数表示。并发用户数Concurrent Users同一时间正在和系统交互的用户数。注意“并发用户”不等于“在线用户”在线用户里可能只有一部分在真正操作。举个例子某系统的登录接口我会写成“在 500 并发用户下登录请求的 P95 响应时间不超过 1.5 秒P99 不超过 3 秒吞吐量不低于 300 TPS。”这样测试团队就有了明确的通过标准。2.2 并发用户数、吞吐量、TPS 的估算方法估算承载规模是性能需求的核心。很多项目的性能目标拍脑袋定定高了增加成本定低了上线就崩。这里分享一套我从业务指标倒推技术指标的估算逻辑。假设要做一个电商下单系统已知运营给出的业务预期是日均订单 20 万。这里的关键是找到“高峰时段”和“高峰占比”。一般电商业务的流量有明显的波浪特征假设晚 8 点到 10 点是高峰占全天订单量的 60%那么高峰期的订单量是 12 万分布在 7200 秒内每秒订单量大约是 17 笔。但下单不是一个孤立操作。用户从浏览商品到提交订单期间涉及商品查询、库存校验、优惠计算、订单写入、支付回调等一系列请求。我一般按下单操作的 8 到 10 倍估算后端请求量也就是说每秒会产生 136 到 170 个后端请求。如果还要叠加搜索、推荐、购物车等操作总量还要再乘上 2 到 3 倍得到接近 400 QPS 的峰值压力。再加上 30% 到 50% 的冗余量性能目标就可以定为“峰值压力 600 QPS 下核心接口 P95 响应时间不超过 2 秒”。这个方法是粗粒度估算但至少让需求有了量化依据。有了这个数字架构师才能判断需要几台应用服务器、数据库要什么规格、缓存要不要上、消息队列怎么选。2.3 一个可落地的性能验收标准长什么样光有估算还不够还要把性能需求写进验收标准让测试有明确的执行依据。我常用的写法是列一张性能指标需求表每个接口都对应一组明确的数值接口典型场景峰值并发基线响应时间峰值响应时间目标吞吐量商品检索晚高峰用户搜索800P95 0.5sP95 2s400 QPS购物车查询加购状态轮询500P95 0.3sP95 1s200 QPS订单提交限时折扣抢购300P95 1sP95 3s100 TPS支付结果回调支付渠道通知200P95 0.8sP95 2.5s50 TPS有了这张表测试团队就可以在压测环境里按 1 倍、1.5 倍、2 倍峰值逐步加压观察系统在哪个压力点开始出现性能拐点是响应时间超标还是错误率上升。压测报告里必须包含 P95/P99 响应时间、TPS 曲线、错误率、CPU/内存/数据库连接等资源使用情况。这样才能回答“系统到底能不能扛住高峰期”而不是“系统在测试环境下跑得挺溜”。这类压测工具的选择上JMeter 是最常见的开源方案适合模拟 HTTP 协议接口压力遇到复杂协议或移动端接口可以考虑 Locust 用 Python 编写压测脚本可扩展性更强。基础流量摸底用 JMeter 足够复杂链路压测用 Locust 更灵活。3. 安全非功能需求从威胁建模到合规约束3.1 威胁建模把攻击面摊开来看安全需求最大的误区是写得“全而空”。常见的模板是“系统应具备完善的安全防护能力”“应采用加密技术保障数据安全”但“完善”是什么标准“加密”用 AES-256 还是 RSA 2048这些不写清楚开发就会按照自己理解选实现方案测试也不知道该验证到什么程度。我现在的做法是拿到项目后先做一轮轻量级威胁建模把系统当成一个攻击目标来审视正向走一遍“谁可能从哪里进来通过什么手段拿到什么资产”。思路就是四步走。第一步梳理资产找出系统里值钱的东西用户个人信息、交易数据、支付凭证、业务密钥。第二步识别入口注册登录、文件上传、接口调用、第三方回调都是可能的突破点。第三步分析攻击手段针对每个入口想可能的攻击路径比如暴力破解弱口令、注入恶意参数、越权访问他人数据、上传恶意文件。第四步针对每个风险制定控制措施明确用什么技术手段应对。做完威胁建模安全需求就不是一句空话而是一组可验证的控制措施列表。例如“文件上传接口应校验文件类型和内容仅允许指定扩展名且需通过安全扫描后才能访问”“所有涉及用户身份的操作应记录审计日志日志内容至少包含时间、操作者、操作类型、操作对象和处理结果”。3.2 数据保护与隐私合规不是安全部门的独角戏数据保护类的 NFR 往往和合规要求强相关尤其是涉及个人信息和金融数据的系统。这里的合规要求不同地区、不同行业差异很大需要在项目开始前对照适用的法规和监管规范逐条梳理形成一张需求对照表每一条都要能追溯到具体的技术控制措施。比如哪些字段属于敏感数据必须加密存储哪些场景需要使用加密传输数据留存期限是多少天过期后如何安全销毁用户行使数据访问、更正、删除权利时系统需要在多长时间内响应这些问题必须在需求阶段给出明确答案而不是让开发者在实现时自由发挥。还有一类容易被忽略的是测试数据。联调环境和测试库经常直接拷贝生产数据导致敏感信息在非生产环境中泄露。这类问题属于数据安全需求的一部分应该在 NFR 中明确规定所有进入测试环境的数据必须经过脱敏处理脱敏规则应覆盖姓名、手机号、身份证号、银行卡号等低纬度高价值字段。3.3 安全测试怎么在项目周期里安排安全需求写了不测等于没写。但安全测试不是等到上线前做一次渗透测试就完事需要在项目周期的不同阶段安排对应的验证活动。开发阶段可以做静态代码扫描工具能自动发现常见的注入漏洞、弱加密算法、危险函数调用等代码层问题。联调阶段可以做依赖安全检查排查第三方组件和开源库的已知漏洞这类问题在很多项目里最致命——业务代码写得再安全一个过时的日志组件就能让整个系统受影响。上线前需要做一次针对性的渗透测试重点验证威胁建模阶段识别出的高风险路径包括认证绕过、越权访问、敏感信息泄露等场景。安全漏洞的修复也和普通缺陷不同不能只看“功能正确”还要评估漏洞的利用路径和影响范围。我给团队定的要求是高危漏洞必须当天确认影响面3 个工作日内完成修复和复测中危漏洞纳入最近迭代排期低危漏洞记录在册统一规划修复。有了这个节奏安全需求才能真正闭环。4. 可用性与可靠性SLA、故障恢复与冗余设计4.1 可用性的计算公式99.9% 到底一年能坏多久可用性需求是所有 NFR 里最经常被当作摆设的。很多需求文档写“系统可用性应达到 99.99%”但没人问过“99.99%”背后对应的故障时长是多少也没人验证过系统架构到底能不能支撑这个目标。可用性的计算公式其实很简单可用性 正常服务时间 / 总时间 × 100%。一年按 8760 小时计算我把不同可用性等级对应的年故障时长列在这里99%每年停机 87.6 小时约 3.6 天99.9%每年停机 8.76 小时99.95%每年停机 4.38 小时99.99%每年停机 52.6 分钟99.999%每年停机 5.26 分钟看清这些数字之后很多不切实际的可用性目标会自我修正。要达到 99.99%单靠一套系统根本不可能必须依赖多节点冗余、自动故障转移、完善的监控告警和演练成熟的应急预案。如果写需求时不知道架构能达到的量级就很容易定出架构成本和业务预期完全不匹配的目标。4.2 MTTR、MTBF 与故障演练别等出事了再学可用性不能只盯着“全年不坏”还要看“坏了能不能快速修好”。这就引出了两个关键指标MTBF平均故障间隔时间和 MTTR平均修复时间。MTBF 反映系统的稳定性MTTR 反映团队的应急能力。要在需求阶段明确核心服务故障的响应时间目标是多少恢复时间目标是多少从发现故障到恢复服务最长允许多久指标定义清楚了还要验证团队真的能在规定时间内恢复。我见过的有效做法是定期做故障演练——人为制造节点宕机、网络分区、依赖服务超时看系统能否自动切换也看团队能否按预案快速恢复。第一次演练往往手忙脚乱做过几次之后该优化的优化该补文档的补文档应对真实事故的底气完全不一样。故障演练可以把恢复动作写成操作手册内容包括故障场景描述、影响范围评估、第一次响应动作、升级路径、具体恢复步骤、事后复盘要求。手册不追求面面俱到关键是紧急情况下能照着做每个操作都要有人验证过。4.3 冗余、降级与兜底可用性靠的不只是堆机器提升可用性最常见的手段是加冗余但冗余不是万能药。堆了双机热备如果没做会话同步和状态一致性设计切换时照样丢数据做了集群如果数据库只有一个单点应用层再冗余数据库一坏全站瘫。真正想在需求阶段把可用性做扎实要围绕几件事设计每个关键组件是不是存在单点故障发生时流量能否自动转移依赖的下游服务没有响应时系统是否有降级方案部分功能不可用时核心业务还能不能继续这就像出门带伞不是为了跟暴雨硬拼而是为了让小雨天不至于太狼狈。降级方案也一样在极端情况下降级非核心功能比如暂时关闭评论、暂缓生成报表保住核心链路比如支付、下单、查询持仓持续可用要比“坚守完整功能”的完美主义更实际。我在可用性需求里通常会加上一条降级预案要求系统必须支持对核心链路上非必需依赖的开关控制当依赖的第三方服务连续失败次数达到阈值时自动触发降级确保核心功能不受影响依赖恢复后系统应自动回到完整功能状态。这类需求明确了“什么能砍、什么必须保”在事故中能起决定性作用。5. 往需求文档里写 NFR 的实操模板与避坑清单5.1 每一条 NFR 必须满足的三条检验标准很多团队不是不写 NFR而是写了等于没写。我判断一条 NFR 是否合格会用三个标准来检验。第一它必须是可度量的。描述里必须有数字、单位、条件和测量方法。“系统应该支持大量用户并发请求”不可度量“系统在 800 并发用户、300 万数据量的条件下核心查询接口 P95 响应时间不超过 2 秒”才是可度量的。第二它必须是可验证的。有了量化指标还不够还要有对应的测试方法和验收条件。性能达标怎么压测安全漏洞标准是什么故障恢复目标怎么验证这些都需要在定义阶段给出明确的执行路径。第三它必须能追溯到业务价值。如果一条 NFR 无法解释“为什么需要这个指标”那它大概率是拍脑袋写出来的。不过度设计就是节约成本写需求的人要能说清楚每个数字背后的业务驱动因素。如果为了“显得专业”堆砌指标最后只会增加开发和测试成本对业务毫无帮助。5.2 需求评审阶段最容易放过的 NFR 漏洞需求评审时大家盯功能讲得热火朝天NFR 往往几句话就过完了。我梳理了几个常见漏洞评审时建议逐一对照检查。数据规模没写。很多系统上线后出问题都是因为需求阶段没预估数据量导致设计容量和实际负载差距悬殊。至少在需求中明确首年数据量级、年增长率、最大单品数据规模这些直接影响索引设计、分库分表方案和存储选型。第三方接口的性能和可用性没写。外部服务的响应时间、超时设置、重试策略、熔断阈值都要有明确规定。选型约束写死导致实现成本暴涨。比如完全禁止使用某种数据库但没有给出理由。过度限制会伤害技术方案合理性评审时要追问一句“为什么”。只有正常场景没有异常场景。限流触发时返回什么提示下游超时怎么处理数据重复提交怎么识别这些异常路径的 NFR 往往容易被忽略。评审流程上也建议设置“NFR 强制检查点”在需求评审完成之前必须一条条对照 NFR 清单打勾确认未确认项要明确责任人。这里不需要增加额外流程只要把检查点挂到现有评审环节里就能起作用。5.3 我踩过的一个发布前才改写性能架构的坑分享一个真实踩坑经历某项目已经进入 UAT 阶段产品功能全部完成业务方准备验收。联调过程中偶然发现一个高频查询接口在 10 万数据量下响应速度已经超过 4 秒而生产预期是千万级数据量和数百并发。查了代码才发现表结构设计时没有按查询模式创建组合索引多表关联查询在数据量增长后成本成倍上升。这个问题的根源在产品设计早期没有做容量评估。开发同学按“功能正确”标准实现索引优化和查询优化被视为“以后再说”的事。结果发布前一周DBA 临时补索引、重写 SQL、调整缓存策略项目延期两周上线质量也很勉强。这次教训之后我给自己定了个规矩需求阶段的数据量级评估和核心查询路径的性能预估必须和功能需求同步完成产品经理和架构师一起签字确认不允许把性能工作拖到开发完成之后。把性能需求当成一等公民而不是版本临时辅导项系统才不会上线就翻车。5.4 一个可以直接拿来改的 NFR 章节模板最后分享一个我在项目里惯用的 NFR 模板骨架覆盖了大多数业务系统需要明确的指标项。使用时不要求所有条目都填满但要针对项目特点给每个适用条目填上量化指标。性能与容量峰值并发用户数____目标吞吐量QPS/TPS____核心接口 P95 / P99 响应时间____ / ____首年预估数据量级____ 条年增长率____%压力测试基准环境规格____安全与合规敏感数据清单及加密存储要求____传输加密协议与最低版本____认证与会话管理要求有效期、锁定策略____审计日志内容与留存时间____测试环境数据脱敏要求____可用性与恢复目标可用性年停机时长____RTO恢复时间目标____RPO数据恢复点目标____故障演练频率____降级方案覆盖的核心功能____可维护性与可扩展性新增标准业务接口的平均开发工时上限____部署升级的停机时间限制____模块化与复用性要求____兼容性需支持的浏览器及版本____需兼容的操作系统____模板用多了之后我总结出一个原则NFR 的关键不是“写得多”而是“每条都有验收标准”。宁可只有七八条真正量化过的指标也不要四五十句正确但没用的空话。写这块内容的时候我在想可能有些团队看完整篇还是觉得无从下手这很正常。NFR 是一项需要持续积累的能力不是看一篇文章就能立刻练成。我的建议是先从手头项目挑最重要的一类指标开始比如性能或安全把它彻底量化、可测、落地跑完一个版本后再扩展到其他领域。我在实际项目中被问得最多的几个问题往往都和“怎么定这个数值”有关。没有通用的标准答案每个系统都有自己的业务背景和承载极限。真正有效的方法是从数据推算、从竞品对标、从历史故障中收集证据然后敢于在需求评审时对这个数字负责。这也是一种可以培养的判断力。