4. 非功能需求：性能、可靠性与安全性
好，咱们聊完了功能需求，也就是系统“能干什么”。但一个PIS系统能不能真正用起来，能不能让乘客满意、让业主放心，关键还得看非功能需求。说白了，就是系统“好不好用”、“稳不稳”、“安不安全”。
我个人习惯，在需求阶段就把非功能需求写死。不然等交付了再补，成本翻倍不说，还可能推倒重来。今天咱们就掰开揉碎，讲讲性能、可靠性和安全性这三座大山。
4.1 性能需求：别让乘客等出“火气”
性能需求，核心就两个词：响应时间和并发量。你想想看，早高峰的地铁，几千人同时刷手机看下一班车几点到，系统要是卡个几秒，那体验得多糟糕。
4.1.1 响应时间：快，是硬道理
响应时间，指的是从用户发起请求到系统给出反馈的时间。对于PIS系统，我一般这么分：
- 实时信息（如到站时间、列车延误）： 要求 < 1秒。这个必须快，慢了乘客会焦虑。
- 查询类信息（如线路图、换乘指引）： 要求 < 3秒。可以稍微慢一点，但别超过5秒。
- 视频播放（如广告、新闻）： 启动时间 < 2秒，播放过程不能有卡顿。
我踩过的坑： 有一次，某线路的PIS系统在早晚高峰时，到站信息延迟了5秒。结果乘客都下车了，屏幕才显示“列车即将进站”。业主直接投诉到我们CEO那里。后来查原因，是后台数据库的查询语句没加索引，数据量一上来就慢。所以，响应时间的优化，要从架构设计就开始考虑。
4.1.2 并发量：扛得住“人山人海”
并发量，就是系统同时能处理多少请求。PIS系统的并发场景很典型：
- 车站级并发： 一个车站可能有几十块屏幕，同时请求数据。
- 线路级并发： 一条线路几十个车站，同时请求。
- 全网级并发： 节假日、大型活动，全城所有线路同时请求。
我建议，设计时按峰值并发量的1.5倍来预留资源。比如，预测高峰期有1000个终端同时请求，那系统就要能扛住1500个并发。
怎么算？举个例子：
假设：
- 每个车站有20块屏幕
- 每条线路有30个车站
- 高峰期有5条线路同时运行
那么，并发终端数 = 20 * 30 * 5 = 3000个
每个终端每5秒请求一次数据，那么：
系统每秒需要处理的请求数 = 3000 / 5 = 600 QPS（每秒查询数）
设计目标：系统能稳定处理 600 * 1.5 = 900 QPS我的经验： 别只看QPS，还要看响应时间的稳定性。有些系统平时响应快，一上并发就崩。我习惯用压测工具（比如JMeter）模拟真实场景，看看系统在90%负载下的响应时间是否还在可接受范围内。
4.2 可靠性需求：系统不能“掉链子”
可靠性，说白了就是系统能稳定运行多久，以及出问题了能不能快速恢复。PIS系统是面向公众的，一旦故障，影响面很大。我见过因为PIS系统故障，导致整条线路运营混乱的案例。
4.2.1 MTBF：平均无故障时间
MTBF（Mean Time Between Failures），就是系统平均能连续运行多长时间不出故障。这个指标，业主通常会在招标文件里写死。
| 设备类型 | MTBF要求（小时） | 换算成年 |
|---|---|---|
| 车站服务器 | ≥ 50,000 | 约5.7年 |
| 车载控制器 | ≥ 30,000 | 约3.4年 |
| LCD显示屏 | ≥ 20,000 | 约2.3年 |
| 网络交换机 | ≥ 100,000 | 约11.4年 |
嗯，这里要注意：MTBF是统计值，不是单个设备的寿命。我见过有人拿这个指标去跟业主承诺“保证5年不坏”，这是不对的。MTBF高，只说明故障概率低，不代表不会坏。
4.2.2 MTTR：平均修复时间
MTTR（Mean Time To Repair），就是系统出故障后，平均需要多久能修好。这个指标，直接决定了系统的可用性。
我一般把MTTR拆成三部分：
- 故障发现时间： 系统有没有自动告警？还是等乘客投诉了才知道？
- 故障定位时间： 是硬件坏了？软件bug？还是网络断了？
- 故障修复时间： 换备件要多久？重启服务要多久？
我曾经... 遇到过一个项目，MTTR要求是30分钟。但实际执行时，光是定位故障就花了20分钟。后来我们做了两件事：一是加了全面的监控告警系统，故障一发生就自动通知运维人员；二是做了一键恢复脚本，常见故障点（比如服务进程挂了）直接自动重启。最终把MTTR降到了15分钟以内。
4.2.3 可用性计算
MTBF和MTTR结合起来，就是系统的可用性：
可用性 = MTBF / (MTBF + MTTR) * 100%
举个例子：
MTBF = 50,000小时（约5.7年）
MTTR = 2小时
可用性 = 50000 / (50000 + 2) * 100% ≈ 99.996%
这个数字，意味着一年内系统不可用时间不超过 0.35小时（约21分钟）。注意： 可用性99.9%和99.99%看起来只差一点点，但实际运维成本差很多。99.9%意味着一年可以宕机8.76小时，而99.99%只有0.876小时。业主往往只看到数字，看不到背后的投入。我建议在方案里把实现成本也写清楚，让业主自己权衡。
4.3 安全性需求：别让系统“裸奔”
安全性，以前在PIS系统里不太受重视。但自从发生过几起黑客通过PIS系统入侵地铁控制网络的事件后，业主们现在都学乖了。安全性需求，主要分两块：数据加密和访问控制。
4.3.1 数据加密：信息在“保险箱”里传输
PIS系统里，哪些数据需要加密？我列一下：
- 乘客个人信息： 比如通过APP查询的行程记录、支付信息（如果有）。
- 运营敏感数据： 比如列车时刻表、调度指令、应急预案。
- 系统管理数据： 比如管理员账号密码、系统配置参数。
加密怎么做？我建议分两层：
- 传输层加密： 所有网络通信都走HTTPS/TLS。别用HTTP明文传输，那是给自己挖坑。
- 存储层加密： 数据库里的敏感字段（比如密码、身份证号）要加密存储。我习惯用AES-256算法，密钥单独管理。
我的习惯： 密码绝对不能明文存！一定要用哈希算法（比如bcrypt）加盐处理。我见过一个项目，数据库被拖库后，所有管理员密码都是明文，那场面...简直灾难。
4.3.2 访问控制：谁可以做什么
访问控制，就是规定谁可以访问什么资源、做什么操作。PIS系统的用户角色，我一般这么分：
| 角色 | 权限范围 | 典型操作 |
|---|---|---|
| 系统管理员 | 全部权限 | 配置系统参数、管理用户、查看所有日志 |
| 运营管理员 | 运营相关 | 发布列车时刻表、编辑应急信息、查看运营数据 |
| 维护工程师 | 设备相关 | 查看设备状态、重启设备、更新固件 |
| 普通操作员 | 只读+简单操作 | 查看实时信息、切换显示模式 |
你想想看，如果每个车站的普通操作员都能修改系统配置，那不乱套了？所以，最小权限原则一定要坚持。每个角色只给完成工作所需的最小权限。
我踩过的坑： 有一次，一个项目的访问控制做得太粗，所有运维人员都是“超级管理员”权限。结果一个实习生误操作，把整条线路的PIS系统配置全删了。恢复数据花了整整一天。从那以后，我坚持权限必须细化到“按钮级别”，并且所有敏感操作都要有二次确认和操作日志。
4.3.3 其他安全措施
除了加密和访问控制，还有几个点不能忽视：
- 审计日志： 谁在什么时间做了什么操作，都要记录下来。出了问题可以追溯。
- 网络隔离： PIS系统网络要和运营控制网络物理隔离或逻辑隔离。别让PIS成为攻击跳板。
- 定期安全扫描： 我建议每季度做一次渗透测试，每年做一次全面的安全审计。
特别提醒： 很多PIS系统会用到第三方组件（比如开源库、SDK）。这些组件可能有已知漏洞。我习惯在项目启动时就建立第三方组件清单，并定期检查是否有安全更新。别等到被攻击了才想起来补漏洞。
好了，非功能需求这块，咱们就聊到这儿。性能、可靠性、安全性，这三者其实是相互关联的。比如，为了提升可靠性，你可能要做冗余部署，这就会增加成本；为了提升安全性，你可能要加解密，这就会影响性能。所以，实际项目中，一定要根据业主的预算和实际场景，找到一个平衡点。
下一章，咱们聊聊怎么把这些需求转化成具体的系统架构设计。到时候见。