由 dawei 真相一：高可用不是靠单台服务器堆性能，而是靠“故障可预期、服务不可停”。一台99.9%可用的机器，年宕机仍超8小时；三台独立部署、带自动切换的实例，配合健康检查，才能逼近99.99%。
真相二：数据库永远是瓶颈起点。读写分离只是第一步，真正关键的是连接池配置——过小导致请求排队，过大拖垮数据库。我们坚持用HikariCP并压测调优，而非盲目加大最大连接数。
真相三：缓存不是万能胶。缓存击穿、雪崩、穿透必须前置防御：空值缓存防穿透，逻辑过期替代物理过期防雪崩，布隆过滤器做前置校验。
真相四：接口幂等性不是可选项。支付、下单、发券类操作，必须通过唯一业务ID+状态机+数据库唯一约束三重保障，避免重复执行引发资损。
真相五：依赖外部服务必须设“熔断+降级+超时”。连第三方短信网关都必须定义500ms超时、2次重试上限，失败后切至站内消息通知，不阻塞主链路。
真相六：日志不是越多越好。关键路径打结构化日志（JSON格式），包含traceId、业务ID、耗时、错误码；非核心调试日志全部关闭，否则IO反成瓶颈。
创意图AI设计，仅供参考
真相七：HTTPS不是加个证书就完事。必须启用HSTS强制跳转、OCSP装订减少握手延迟、TLS1.3优先，否则移动端首屏慢500ms以上。
真相八：静态资源走CDN要分离域名，且HTTP/2 + Brotli压缩双启用。实测JS/CSS体积减35%，TTFB下降40%。
真相九：灰度发布必须带流量染色与实时监控。我们只允许按用户ID哈希灰度，同时对比新旧版本错误率、P95延时、DB慢查数，任一指标超标即自动回滚。
真相十：告警不是越多越好。只设四级阈值：正常、预警、严重、灾难，且每条告警必含可执行SOP链接。避免半夜被“CPU 85%”吵醒却不知是否真实异常。
真相十一：自动化运维不是替代人，而是放大人的判断力。我们用GitOps管理所有配置变更，每次上线自动生成变更摘要、影响接口清单、回滚脚本，全程留痕。
真相十二：真正的高可用始于设计，而非补救。每个新模块立项前，团队必须回答：单点在哪？故障如何隔离？数据怎么兜底？答不上来，不排期。