最近的互联网故障太多了，先有10月23日语雀7小时宕机故障，后有11月27日滴滴十余小时宕机故障，接下来腾讯视频也不甘示弱。互联网产品出现故障屡见不鲜，印象最深刻的是支付宝527事件（2015年5月27日，支付宝宕机），那次之后，每年的5月27日都会搞很多攻防演练检验系统的稳定性。为啥各种演练还是避免不了故障呢？除了流量激增，咱来看互联网宕机常见问题主要有三个：①系统问题，②云产品问题，③网络异常。那这些问题是否能提前预防呢？技术经常提到的「变更三板斧」，针对任何变更，包括系统发布、改配置、修数据等各种形式的变更，都应该遵循这个原则。这三板斧是：可监控、可灰度、可回滚（用于应急）。首先是可监控。有任何变更，相关人员需提前部署好版本的监控和报警策略，目的是及时发现问题，比如应用监控（响应时间、成功率和错误率等）、网络监控（带宽异常、丢包率等）、日志监控（应用日志、系统日志等）、安全监控（扫描漏洞、恶意攻击等）……然后是可灰度。灰度能力是互联网产品必备技能，比如支付宝抖音这种过亿体量的 C 端产品，发布一个新功能后一定是先让员工体验体验，提早发现 Bug。这还不够，正式对外的时候还得按照百分比逐步放量。如果苗头不对，得立即想办法回滚，否则就是史诗级灾难。对于体量小的产品，一般不会这么复杂，甚至对于一些 B 端产品，可能就几个客户，直接就发了，完全没有业务灰度的必要。但是，请注意，即使没有业务灰度的必要，在执行变更的时候，在机器层面，也应当遵循灰度的原则逐步生效，这样可以早点发现变更问题，而不至于让整个机器集群瞬间瘫痪。灰度直至全量放开结束如果未发现问题，不代表一定不会出现问题，可能到达某个临界点因为产品逻辑问题才会触发。这时候应该配合可回滚：这里需要判断，是否比较明确判断和变更相关，若相关，就应该无脑回滚，先止血再说；若不能通过直接回滚修复故障，那就需要备用方案。我了解到语雀利用的是：①先备份差异数据：防止数据丢失或损坏而进行的复制；②后一致性校验：当我们在多副本或分布式系统中存储数据时，为了确保所有副本中的数据都是一致的，需要进行一致性校验。核心是保证数据的完整性和可靠性。在执行上线操作时，团队所有成员都应该慎之又慎，大胆小心……上次听说一互联网公司裁员，首先裁掉了部分运维，愚蠢，真是愚蠢，紧接着好像就出问题了…… 检查作业，《创造：用非传统方式做有价值的事》这本书看了多少了？
