「这是我参与2022首次更文挑战的第5天，活动详情查看：2022首次更文挑战」。
这个问题问的非常好，也应该是大多数初级工程师的困惑，正好拿出来做 #今日份十分钟# 分享。
问题里框定了一个前提：“需求差不多”，而实现过程差异较大。我在回答的这个问题的时候不想就事论事，而是我觉得正好是指导他构建自己工程理念的一个机会，所以有了如下回答。分享出来大家一起交流，有问题欢迎指正，帮我进步。
在工程领域，有一个特别重要的理念或者原则：“不要过度设计”，也有其他类似的说法“非必要勿引入”等。就是告诉我们永远不要设计永远用不到的部分。就比如给三口之家设计房子，肯定不能设计10层楼带一堆高层才用的水路电路通风控温系统之类的。
这时候工程师就琢磨了，我们应该如何来判断我们设计的系统足够使用了呢？ 这里提出了几个量化指标，某个QPS阈值下的：可靠性、可用性和稳定性。
QPS这个就比较容易理解了，就是设计的系统容量是多少。一般而言就是我们生产场景下未来一年或几年的一个峰值估计数。需要注意的是工程师必须清清楚楚的知道自己设计的系统的瓶颈在哪里，是否需要设计扩容方案。
可靠性就是服务产出的准确度， 类似 100次计算1+1 ，98次返回2，2次返回3，可靠性就是98%。
可用性就是服务调用100次，失败1次，可用性就是99% ，当然也有按全年服务时间来计算的。
稳定性就是你的服务在满足设计QPS的情况下，生产耗时的波动率，这个我们一般看分位数，也就是我团常说的TP999。
#_#写到这里有点十分钟超时了，抓紧码啊
就是在做方案之前把这几个指标跟需求方沟通确认清楚，然后再设计系统。 比如：
用户的需求是后台服务场景，那就不用“太过度”设计系统的QPS不会太高。
用户需求是数据挖掘，那可靠性就能适当不那么严格，否则数据全链路保障不重不漏这事就够一个团队忙一阵了。
用户需求是订单服务，那QPS可能不高，可靠性、可用性要求极高，而稳定性可能会有适当放开到一两秒，毕竟可能牵扯的服务多带各种事务。
#真超时了。。。
关于每一种指标的一些常见工程做法、原理、优劣势，可以另行google学习，有时间我也可以再展开来细说一下。
