做一个不崩溃的核酸系统有多难？比如每天2000万的检测量，要做到软件系统不崩溃究竟需要多牛的技术，多少的硬件投入，多少的研发投入？
做一个项目主要有几个方面的困难，至少包括1）技术层面的困难，2）生产关系层面的困难，3）信任困难 和 4）合规困难。

一般人来看，做一个项目主要考虑的是1）技术层面的困难。具体在核酸系统中，它主要包括一些基本的 热备份/容灾、负载均衡、弹性计算、高并发等问题.国内由于人口基数大，用户多，这些技术和实践都不是瓶颈。根据公开资料,支付宝就能支持每秒几十万次级别的交易，这比核酸系统所需要的流量和稳定性要高很多。实际上，目前国内成熟的云服务上甚至都提供了支持这些功能的打包的全套解决方案，作为技术人员只需要关注数据接口和程序逻辑实现就行了。

但在实际项目中，常常是其他方面的困难耗费项目参与者更多的时间和精力：

1)生产关系困难：一个项目需求有很多人可以做，但是有些人在对应的部门，有利益关系问题，具有优先支持权。也就是说，即使他们不接这个需求，他们也有否决其他人做这件事的权利；即使他们能力不足以支持这个需求，他们也有优先落地这个项目的权利。

2）信任困难：Web项目涉及到很多数据接口，调试和运行中有很多数据传输，项目委托方通常会担心这些数据和接口的安全问题，特别是，数据涉及用户隐私的情况下，如果项目方所用的技术方案不是经过验证的可信平台的，信任困难问题就会发生。项目执行者可以列举出很多证据证明数据安全，但是从逻辑上，一个人无法证明他没有做某件事，信任问题因此无法避免。

3）合规困难：合规不仅是合法性这类最基础的问题，更重要的是，一旦出现问题，如何排查问题，如何分配责任。作为项目的甲方，天然排斥系统运行过程中出现问题需要自己担责的情况，特别是可能的法律法规责任。所以项目执行方需要考虑甲方这方面的需求，甚至，即使项目做不成或者性能差，也要优先满足这个需求，对于大型项目来说这一点尤其重要。

在现实世界中，能用技术方式解决的问题实际上都是小问题、简单问题。而那些更大的更重要的问题，常常被忽略。这类问题被称为“制度成本”或“信任成本”。