西安一码通连续崩溃产品经理若何写文档才能不背锅？,韶光慢。

2022年1 月 4 日9 时，西安一码通又崩溃了。
这是半个月内，一码通第二次涌现故障。

一方面，软件开拓方有任务，开拓的系统可用性太差。
而另一方面，软件的需求方也需写清楚哀求，这也每每是产品经理的事情，详细而言便是定义清楚产品需求、验收标准、违约任务。

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

这些事情涉及面很广，本文仅磋商个中的非功能需求的部分，也便是产品经理如何定义清楚一码通的非功能需求。

一码通的功能需求很大略，便是查询自己的核算检测信息，个人康健信息。
难是难在了非功能需求，下面我们就用3000字来逐一解释。

一、需求的全貌

产品经理要明确的需求浩瀚，在我的书《图解产品》中，我将这些需求做了归类，并命名为PURPS+模型，详细便是：

而产品经理需逐一定义这些需求，才能将文档写全面。
下面我们重点说说个中的可用性、可靠性、性能和可支持性需求如何写，这些内容在《图解产品》中有更多解释。

二、可靠性需求

可靠性定义了系统的健壮性，如可靠性高则解释产品的软件、硬件故障少，能正常运行。
而这些故障常常会严重影响用户的利用。

详细到西安一码通则需定义清楚四个指标，分别是：均匀无端障韶光 （MTBF）、可靠性、掩护相应韶光、均匀掩护韶光。

（1）均匀无端障韶光 （MTBF）

该韶光是指产品涌现一次故障的均匀韶光。
如电脑的MTBF 为 15 年， 便是说有的电脑第 1 年出故障，有的电脑第 30 年出故障，均匀算起来第15 年出故障。
一样平常可用履历数据和实验数据，大致预估硬件的MTBF。

而软件的故障多是由于软件BUG，因此很难预估MTBF值，有时会给个承诺值。

（2）可靠性

软件的故障次数越少越好，但如不幸涌现了故障，则希望有故障的韶光尽可能短，这个指标便是可靠性。

如可靠性为99.999%，便是指在1年韶光里，该业务会中断5.26分钟，打算公式为（1-99.999%）× 365 × 24 × 60，个中365 × 24 × 60为整年的分钟数。

同样该值也较难预估，老例是厂商会承诺99.99%或99.999%的可靠性。

（3）掩护相应韶光和均匀掩护韶光

当产品涌现故障后，很多时候要维修，而维修包括掩护相应韶光、均匀掩护韶光。

（4）掩护相应韶光

是指从创造故障到开始维修所须要的韶光。
对付西安一码通业务来说，可哀求开拓方支持7×24小时的随时相应，并哀求10分钟内开始维修。

（5）均匀掩护韶光 （MTTR）

虽然开拓方能够快速相应，但是要修睦还需韶光，由此须要定义均匀掩护韶光，这个韶光包括在途韶光（如须要）和到达现场维修睦的韶光。
该指标也须要根据业务情形定义，如哀求必须1小时内修睦。

以上便是均匀无端障韶光 （MTBF）、可靠性、掩护相应韶光、均匀掩护韶光指标的定义和建议值。
这些值多数无法精准给出，更多地是开拓方对可靠性的一个承诺。

三、可用性需求

可靠性是从系统角度看的，也便是反应了软件有没有问题；而可用性则是从人的角度看的，也便是人以为产品可用不可用。
有时两者是一回事，但有时两者不是一回事。

之前我曾卖力的一款产品，其可靠性很差，硬件和软件总出问题。
但是有些情形下却不太影响用户的利用，由于用户大不了重新拨打一次电话，或重新连一次网络，也能用。

而所采纳的手段是，当疑似有问题后，该系统会自动重启系统或重启某进程。
以是从用户的角度看，其可用性尚可；但从系统角度看，其可靠性很差，系统总是坏掉。

现在的互联网系统也多是分布式支配，从而将单点故障的影响降到最低，提升用户的可用性。

而西安一码通也需定义清楚可用性。
如当软件、硬件涌现故障后，系统应尽可能支持一定的规复手段，同时也要实现分布式支配等。

但从本次一码通的故障看，紧张是性能问题，此时靠重启进程等手段是不能办理问题的，由此须要定义清楚性能需求。

四、性能需求

性能需求要先定义用户访问情形，再定义系统的相应韶光、新建数、并发数、吞吐量。

1. 用户访问情形

用户访问情形需确认峰值访问量、均匀访问量和访问的业务。
对付一码通业务，需依据历史数据做预估。
如预估逐日10点-11点为峰值访问，且同时利用的人数是多少人，并应尽可能精确到每秒的峰值。

2. 相应韶光、新建数、并发数和吞吐量

定义清楚了用户访问情形后，就要再从软件角度定义性能指标，如能定义清楚这些指标，就可避免不得当的软件架构设计，这些指标如下。

（1）相应韶光

指标反响了网站响运用户要求的速率，也便是我们日常所说的网络快慢。
影响相应韶光的成分有系统延迟、网络延迟和用户真个延迟，一样平常可由开拓方给个相应韶光。

（2）新建数

每个用户利用一码通查看信息时，系统都会新建建立一个连接。
该指标与用户访问指标比较类似。
比如登录要新建、查询要新建，这便是两个新建。
有时一次查询须要几个新建，需由研发确认。

（3）并发数

定义了当访问系统的特定运用时，能同时坚持的连接数量。
据统计西安有1300万人口，按照最大10%的市民同时扫码（已经很大了），也便是要支持百万的并发量。

（4）吞吐量

该系统定义清楚吞吐量，很多性能问题就可避免。

按照一些研发的剖析，认为一码通的问题集中在该系统所有的 js/css/img 静态资源全都从一个出口进行供应，没上 CDN。

粗略估算了一下，js/css/img 数据统共约 500kB。
而按照某个群里得到的数据（暂且认为是准的），康健码的要求量峰值达到了 3.3w qps，也便是吞吐量要 33000 x 500 x 8 bps ≈ 125Gbps 这个出口量级很难用单机房承载，由此系统挂掉。

该指标和系统实现方案有密切关系，须要由履历丰富的研发来剖析、明确。

五、可掩护性需求

可掩护性需求可分为可支持性需求和可移植性需求。
这些需求涵盖的内容较多，与一码通干系度高的需求如下：

（1）可支持性需求

定义了开拓职员是否可以方便地升级系统、用户是否可以很方便地升级。

而据逐日经济新闻宣布，一码通的升级须要人工删除小程序，并打消数据。
这便是没有做好可支持性需求。

（2）可移植性需求

括用户的增长和数据量的增长。
用户量的增长是指当用户量增加后，系统应能方便地扩容。
数据量的增长是指当存储的数量增加后，系统也能很好地支持。
而一码通半个月后又出故障，由此可看出其可移植性需求做的并不好。

六、总结

以上便是一码通需定义的紧张非功能需求，而这些需求涵盖面又广又主要。
除了这些指标外，还有一些次要需求，本文就不再赘述，你可参考《图解产品》连续完善。

实在该系统的实现不算难，实现方案也颇为成熟，乃至精良的应届生都能搞定，确实不该出问题。

有人可能会问，事情中我没有定义这些内容，研发一样事情。
是的，对付互联网公司的自研产品多数不需这么详细，但对付这种关系民生的定制开拓则必须明确，从而避免上线失落败。

如一些实现细节不清楚，需求方也可列出框架，由开拓方填写。

而需求方还应基于以上指标，再定义验收标准，违约任务，并进行压力测试，由此来约束开拓方的行为。
这样开拓方就不至于敢派履历不敷的研发来搪塞事，更可避免扯皮，分清任务。

作者：擎苍，《“图解”产品：产品经理业务设计与UML建模》作者、UML建模、数据建模研究者，公众年夜众号：图解产品设计

本文由 @"大众年夜众号：图解产品设计 原创发布于大家都是产品经理。
未经容许，禁止转载。

题图来自Unsplash，基于CC0协议