三个核心指标与"倍数留白"的评审原则

[[最小改动原则拒绝重写也拒绝裱糊匠]]要求”准确定义问题”，而准确定义问题离不开数据支撑——雪球在所有地方都强推三个数据指标：QPS、p99、error rate。团队认为每个技术人员对自己负责的服务都必须有最基本的数据指标意识，因为数字是发现问题、定位根源、找到本质最重要的依赖条件，没有之一——脱离这三个指标去谈”这个服务是不是有问题”，讨论就只能停留在感觉层面。团队的另一条原则是保持技术栈的一致性和简单性、有节制地尝试新技术，保持所有线上服务依赖的技术处于可控范围内——简单说就是”要能hold住”，这条原则在Q&A环节被反复印证：团队公开表示”不建议用Akka”，理由不是Akka不好，而是”我个人的原则是hold不住的东西就不做推荐，使用太简单太方便，但坑太多，不知道什么时候就踩上了，想用好太难了”；同样因为”是Erlang写的，不会调优、出问题不会排查”而放弃了RabbitMQ、改用Kafka。在代码和方案评审环节，雪球有一条具体的”留白”经验法则：技术方案层面要做”20倍设计、10倍实现、3倍部署”（即设计阶段要考虑到未来20倍量级的场景、实现阶段按10倍量级考虑、部署阶段预留3倍容量），扩展性方面奉行”凡事留一线，以后好相见”；技术实现层面则强调DevOps意识（上线后维护的还是自己，实现时要认真考虑各种出错处理，因为用户投诉时要负责解释的也是自己）、注意边界和异常情况、追求”快速实现”而不是”随便实现”（因为不知道哪个功能会突然”火了”，需要考虑到性能和后续扩容的方便性）。这套”三个指标+能力可控+倍数留白”的组合，构成了雪球架构治理落地到具体评审动作上的可操作标准。