2022年1月4日9点，西安一码通再次坠机。这是 Pass在半个月内第二次失败。

一方面，软件开发商责任心强，开发出的系统可用性太差。另一方面，软件的需求者也需要写出明确的需求，这往往是产品经理的工作。具体来说，就是明确产品要求、验收标准、违约责任等。

否则，研发只要一句话——“产品经理没把需求定义清楚，责任不在我”。这样就可以推卸责任了。而我们把这些事情做好了，就能区分责任，明确义务，避免背锅。

这些任务涉及面很广，本文只讨论非功能性需求，即产品经理如何定义清晰的、全部编码的非功能性需求。

一码通的功能需求很简单，就是查询自己的记账、检测信息和个人健康信息。困难在于非功能性需求。我们用三千字来一一解释一下。

1. 需求全貌

有很多需求需要产品经理去明确。在我的《图解产品》一书中，我对这些需求进行了分类，并命名为+模型，具体来说：

产品经理需要将这些需求一一定义，才能写出一份全面的文档。下面我们重点讨论如何编写可用性、可靠性、性能和可支持性需求。这些内容在“产品图解”中有更多解释。

2、可靠性要求

可靠性定义了系统的稳健性。可靠性高，说明产品软硬件故障少，能够正常运行。这些故障往往严重影响用户的使用。

具体到西安一码通则需要明确四个指标，即：平均无故障时间（MTBF）、可靠性、维修响应时间、平均维修时间。

(1)平均无故障时间(MTBF)

这个时间是指产品经历故障所需的平均时间。例如，计算机的MTBF是15年，这意味着有的计算机在第一年就会出现故障，有的计算机在第30年就会出现故障。平均而言，他们会在第 15 年失败。一般情况下，可以利用经验数据和实验数据来粗略估计硬件的MTBF。

软件故障大多是由于软件bug造成的，因此很难估计MTBF值，有时会给出一个承诺值。

(2) 可靠性

软件故障的次数越少越好，但如果不幸发生故障，您希望故障时间尽可能短。这个指标就是可靠性。

如果可靠性为99.999%，则意味着一年内服务将中断5.26分钟。计算公式为（1-99.999%）×365×24×60，其中365×24×60为全年的分钟数。 。

估计这个值也很困难。按照惯例，制造商会承诺99.99%或99.999%的可靠性。

(3) 维护响应时间和平均维护时间

当产品出现故障时，往往需要维修，维修包括维修响应时间和平均维修时间。

(4) 维护响应时间

是指从发现故障到开始维修所需的时间。对于西安一码服务，可以要求开发商支持24/7随时响应，10分钟内即可开始维护。

(5)平均维护时间(MTTR)

虽然开发商可以快速响应，但修复需要时间，因此需要定义平均维护时间，其中包括运输途中的时间（如有必要）和到达现场修复的时间。这个指标也需要根据业务情况来定义。如有需要，必须在1小时内修复。

以上是平均无故障时间（MTBF）、可靠性、维修响应时间、平均维修时间指标的定义和推荐值。这些值大多无法准确给出，更多的是开发者对可靠性的承诺。

3. 可用性要求

可靠性是从系统角度看的，反映软件是否存在问题；可用性是从人的角度来看的，即人们认为产品是否可用。有时两者是同一件事，但有时却不是。

我之前负责的一个产品可靠性很差，软硬件一直出问题。不过，在某些情况下，并不会太大影响用户的使用，因为用户再次拨打电话或者重新连接网络仍然可以使用。

采用的方法是，当怀疑有问题时，系统会自动重启系统或者重启某个进程。所以从用户的角度来看，它的可用性是可以接受的；但从系统的角度来看，它的可靠性很差，系统总是坏掉。

当今的互联网系统大多采用分布式方式部署，从而最大限度地减少单点故障的影响并提高用户可用性。

西安一码通的可用性也需要明确界定。例如，当软件或硬件发生故障时，系统应尽可能支持一定的恢复方法，并且还要实现分布式部署。

不过从这次一码通失败来看，主要是性能问题。此时通过重启进程等手段无法解决问题。因此，有必要明确定义性能要求。

4、性能要求

性能需求首先要定义用户访问条件，然后定义系统的响应时间、新建数量、并发数和吞吐量。

1、用户访问状态

用户访问条件需要确认访问峰值次数、平均访问次数以及访问的服务。对于一码接入服务，需要根据历史数据进行估算。比如估计每天的访问高峰时间是10点到11点之间，同时有多少人在使用。它应该尽可能精确到每秒的峰值。

2. 响应时间、新建数量、并发数和吞吐量

明确用户访问情况后，还需要从软件角度定义性能指标。如果能够明确定义这些指标，就可以避免不恰当的软件架构设计。这些指标如下。

(1)响应时间

该指标反映了网站响应用户请求的速度，也就是我们日常所说的网络速度。影响响应时间的因素包括系统延迟、网络延迟和客户端延迟。一般情况下开发商可以给出回复时间。

（二）新创作数量

当每个用户使用One Code Pass查看信息时，系统将创建一个新的连接。该指标与用户访问指标类似。例如，您需要创建一个新的登录名和一个新的查询。这是两个新作品。有时一个查询需要多次新建，需要研发部门确认。

(3)并发数

定义访问系统上的特定应用程序时可以同时维护的连接数。据统计，西安有人口1300万。按照最多10%的公民同时扫描二维码（这已经很大了），意味着它必须支持百万并发。

(4)吞吐量

通过明确定义系统的吞吐量，可以避免许多性能问题。

据一些研发分析，认为一码访问的问题在于系统所有的js/css/img静态资源都是从一个出口提供，没有接入CDN。

粗略估计一下，总共js/css/img数据大约是。根据某组得到的数据（暂时认为准确），健康码请求峰值达到了3.3w qps，也就是说吞吐量为x 500 x 8 bps ≈ 这个导出水平单次很难承载电脑房。 ，然后系统挂起。

该指标与系统实施方案密切相关，需要有经验的研发人员进行分析和明确。

5、可维护性要求

可维护性需求可分为可保障性需求和可移植性需求。这些要求涵盖的内容比较广泛，与One Code Pass高度相关的要求如下：

(一)保障性要求

它定义了开发者是否可以轻松升级系统，用户是否可以轻松升级。

据每日经济新闻报道，一码通行证升级需要手动删除小程序和清除数据。这意味着保障性要求没有得到很好的满足。

(2) 便携性要求

包括用户的增长和数据量的增长。用户数量的增长意味着当用户数量增加时，系统应该能够轻松扩展。数据量的增长意味着当存储量增加时，系统也能很好地支持。半个月后One Code Pass再次出现故障，可见其便携性要求并不好。

六、总结

以上是 One Code Pass 需要定义的主要非功能性需求，这些需求广泛且重要。除了这些指标外，还有一些次要要求。本文将不再赘述。您可以参考“产品图解”继续改进。

事实上，这套系统的实施并不困难，而且实施方案也相当成熟。即使是优秀的应届毕业生也能应付自如，应该不会有什么问题。

有人会问，我在工作中并没有定义这些内容，研发工作也是如此。是的，大部分互联网公司自主研发的产品不需要那么详细，但涉及民生的定制开发一定要明确，避免无法上线。

如果有些实现细节不清楚，需求方也可以列出框架，开发人员填写。

需方还应明确验收标准、违约责任，并根据上述指标进行压力测试，以约束开发商的行为。这样，开发商就不敢派没有经验的研发人员去处理问题，并且可以避免扯皮，明确责任。