背锅|西安一码通连续崩溃，产品经理如何写文档才能不背锅？( 二 ) 58同城|百度|美团|小红书|互联

（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 这个出口量级很难用单机房承载，由此系统挂掉。
【背锅|西安一码通连续崩溃，产品经理如何写文档才能不背锅？】该指标和系统实现方案有密切关系，需要由经验丰富的研发来分析、明确。
五、可维护性需求可维护性需求可分为可支持性需求和可移植性需求。这些需求涵盖的内容较多，与一码通相关度高的需求如下：