360度环评法：评估质量属性时不追求过度预留

针对[[四种常见的方案挑选思路及其共同缺陷]]缺少系统标准的问题，作者给出的答案是”360度环评”：先列出需要关注的质量属性点（常见的有性能、可用性、硬件成本、项目投入、复杂度、安全性、可扩展性等），再逐一从这些维度评估每个方案，最后综合挑选适合当下情况的方案。这个方法真正的关键不在于列了哪些维度，而在于评估每个维度时必须同时遵循合适原则和简单原则，避免贪大求全——某个质量属性只要能满足一段时期内的业务发展就足够了，而不是盲目对标行业最高水准：例如一个购物网站当前TPS是1000，预期一年内翻倍到2000（业务一年翻倍已经算很好的增速），性能评估的及格线就是”超过2000”，而不是照抄淘宝每秒10万的TPS标准。有人会担心万一业务增长远超预期（比如一年涨了10倍而不是2倍），当初按2000设计的方案岂不是要推倒重来——这种情况确实可能发生，但概率很低，如果每次设计都为了防范这种小概率场景而过度设计，代价反而是持续的资源浪费；即便真的发生了，也应该按演化原则接受重新做方案的代价，因为业务能涨这么猛，团队的人力和资金投入自然也会同步跟上，这时候的”重新设计”成本是完全负担得起的（淘宝、微信的发展史上都出现过多次这类大规模重构）。评估与业务发展相关的质量属性（如性能、硬件成本）时，一个简单的经验法则是把当前业务规模乘以2~4倍作为设计目标：基数较低时可以留出更大余量（乘以4），基数较高时留小一点的余量（乘以2）即可。但要注意，即使方案设计得能”平滑扩容”（如从2台机器扩到20台就能跟上10倍的TPS增长），业务规模真正跨越某个阈值时往往还是会触发架构层面的质变，而不只是量的堆叠——例如团队规模从5人涨到20人后，同一套系统上并行开发的效率会显著下降，逼着系统必须拆分为更多子系统；单机房集群到了某个规模也可能必须升级为异地多活架构。这类质变很难提前很长时间准确预判，试图在团队只有5人时就把20人团队才用得上的高性能、异地多活、可扩展架构一次性做完，只会让项目遥遥无期，业务根本等不起。