3. 非功能性需求：性能指标定义、可用性SLA设计、安全性基线制定
聊完了功能需求，咱们得聊聊更「要命」的东西——非功能性需求。
说实话，我见过太多项目，功能做得花里胡哨，一上线就崩。为什么？因为性能、可用性、安全性这些「隐形」的东西，没人重视。你想想看，用户点个按钮等5秒才响应，谁还用？
这一章，我就把这三个核心维度掰开揉碎了讲。全是实战经验，没有废话。
3.1 性能指标定义：别拍脑袋，要量化
性能指标不是「快」或「慢」这种模糊词。你得把它变成数字。
我个人习惯，先定义三个核心维度：
- 响应时间：从用户发起请求到收到完整响应的时间。一般分三档：
P50（中位数）、P95（95分位）、P99（99分位）。 - 吞吐量：单位时间内系统能处理的请求数。常用单位是
TPS（每秒事务数）或QPS（每秒查询数）。 - 资源利用率：CPU、内存、磁盘IO、网络带宽的使用率。别超过80%，否则容易雪崩。
实战案例：我在做一个电商秒杀系统时，定的指标是：
- P99响应时间 ≤ 200ms
- TPS ≥ 10000
- CPU利用率 ≤ 75%
这些数字不是瞎编的。我们压测了3轮，才定下来。
为什么P99比平均值重要？
平均值会骗人。比如100个请求，99个1ms，1个10s，平均值才100ms，看着挺好。但那个倒霉的用户已经骂娘了。P99才能反映真实体验。
3.2 可用性SLA设计：99.9%和99.99%差在哪？
可用性SLA，说白了就是「系统一年能挂多久」。
| 可用性等级 | 年停机时间 | 典型场景 |
|---|---|---|
| 99% | 87.6小时 | 内部工具、测试环境 |
| 99.9% | 8.76小时 | 普通业务系统 |
| 99.99% | 52.56分钟 | 金融、电商核心交易 |
| 99.999% | 5.26分钟 | 电信、医疗、航空 |
嗯，这里要注意。99.99%看起来只比99.9%多了0.09%，但停机时间从8.76小时缩到了52分钟。代价呢？架构复杂度翻倍，成本至少涨3倍。
我曾经帮一个客户做SLA设计。他们一开始拍脑袋说要「5个9」。我问：你们一年能接受的停机时间是多少？答：半天以内。我说那99.9%就够了，别花冤枉钱。
我的建议：SLA不是越高越好。先问业务方两个问题：
- 系统挂了，每分钟损失多少钱？
- 你们愿意为「不挂」花多少钱？
算清楚这笔账，再定SLA。
3.3 安全性基线制定：别等被黑了再补
安全性这事儿，我吃过亏。以前有个项目，上线第二天就被拖库了。为什么？密码明文存储，连个哈希都没做。
从那以后，我定了个规矩：安全性基线必须在架构设计阶段就定好，不能等开发完了再「加」。
我一般会定这么几条底线：
- 认证与授权：所有接口必须鉴权。别信「内网就安全」这种鬼话。
- 数据加密：传输层用HTTPS，存储层敏感字段（密码、身份证、手机号）必须加密或脱敏。
- 防注入：所有SQL查询必须用参数化，禁止拼接字符串。
- 日志审计：所有操作记录日志，包括谁、什么时间、做了什么。方便事后追溯。
- 最小权限原则：每个服务、每个用户只给够用的权限，不多给。
避坑指南：我曾经见过一个团队，把数据库密码直接写在代码里，还提交到了GitHub。结果被爬虫扫到，数据库被删了。所以，密码、密钥必须放在配置中心或密钥管理服务里，代码里只留占位符。
3.4 知识体系总览
下面这张图，是我自己总结的非功能性需求核心逻辑。你看一眼，心里就有谱了。
你看，性能、可用性、安全性，这三者不是孤立的。你为了性能做缓存，可能影响数据一致性（安全性）；你为了可用性做多活，可能增加延迟（性能）。所以，得一起考虑，互相权衡。
好了，这一章就到这里。记住：非功能性需求不是「锦上添花」，而是「雪中送炭」。你前期多花一天定义清楚，后期能少加一个月的班。