很多系统功能都能正常演示，上线后却频繁超时、难以扩容、无法审计或成本失控，根本原因往往不是功能缺失，而是非功能需求没有被明确设计和验证。
一、什么是非功能需求
功能需求回答系统提供什么能力，非功能需求定义这些能力应达到的质量水平。它们必须可量化、可测试，并且与业务重要性一致。
二、可靠性与可用性
可用性不能只写“高可用”，而应确定统计周期、成功标准和允许排除的维护时间。例如月度可用性 99.9% 大约允许 43 分钟不可用，99.99% 只允许约 4 分钟，所需架构和成本完全不同。
可靠性设计应包含：
消除或接受哪些单点；
故障检测、隔离和自动恢复机制；
跨节点、可用区或地域的冗余范围；
备份、恢复和容灾演练；
依赖服务不可用时的降级策略。
三、性能与容量
性能目标应区分平均值和长尾指标。常见指标包括 QPS、并发连接、P95/P99 响应时间、错误率、队列延迟和批处理完成时间。
性能设计需要明确测试场景、数据规模、冷启动、峰值持续时间和依赖服务限制。不要用单接口实验室结果代替完整业务链路压测。
四、可扩展性
可扩展性不仅是增加机器，还包括：
计算层能否水平扩展；
状态是否可以外置或分片；
数据库和缓存的容量上限；
消息队列能否通过分区扩展；
网络、连接数和第三方配额是否成为瓶颈；
扩容过程是否自动且可观测。
应提前定义扩容触发条件，而不是等系统接近极限才行动。
五、安全性
安全需要覆盖身份、权限、网络、数据、软件供应链和审计：
统一身份认证和最小权限；
服务间身份与加密；
数据分类、传输加密和静态加密；
Secret 与证书生命周期管理；
镜像、依赖和制品来源验证；
高风险操作审计及日志保护；
漏洞修复和事件响应流程。
安全控制本身也会增加延迟、组件和运维成本，需要在风险基础上做取舍。
六、可维护性与运营卓越
一个系统如果只能由少数人手工维护，就不具备良好的可持续性。可维护性包括：
基础设施和配置代码化；
标准化构建、测试、发布和回滚；
指标、日志、链路追踪和事件关联；
Runbook、值班和升级流程；
变更审计、配置漂移检测和容量趋势；
明确的服务所有者和责任边界。
七、数据质量与一致性
应明确哪些数据必须强一致，哪些允许最终一致；重复消息、并发写入和跨系统补偿如何处理；数据保留、删除、归档和恢复如何执行。不要用一个“分布式事务”术语掩盖真正的业务一致性规则。
八、成本与可持续性
成本不仅是云账单，还包括软件许可、网络流量、备份、监控、人工维护和停机损失。设计阶段应建立单位成本，例如每订单、每用户或每 GB 数据的成本，并关注闲置、过度冗余和工具重复建设。
九、如何写成可验收指标
一个完整的非功能需求应包含指标、统计方法、负载条件和验证方式。例如：
在每秒 2000 个订单请求、数据库数据量 5TB 的情况下，创建订单接口 P95 小于 300ms，错误率低于 0.1%，并能在单个应用节点故障后 60 秒内恢复目标容量。
这种描述才能指导容量设计、压测和验收。
非功能需求检查表
是否定义 SLI、SLO 和测量周期；
是否明确 RPO、RTO 和恢复责任；
是否包含峰值容量与增长预测；
是否覆盖安全、审计和数据生命周期；
是否考虑发布、升级和依赖失败；
是否建立成本模型；
每项指标是否有验证方法。
总结
非功能需求决定系统能否长期稳定运行，也是架构设计真正产生差异的地方。架构师的任务不是把所有指标做到最高，而是根据业务价值和风险，找到可靠性、安全、性能、成本和复杂度之间可以解释、可以验证的平衡。