22日发生的cdn故障，对我们的业务产生严重影响(akamai应该为此赔偿客户损失)。由于故障发生在深夜，所以当时没有及时知晓故障，直到早上6点多才发现群里有处理故障信息，仔细阅读相关信息，发现已经是一个P-1故障。
起来后，赶紧开电脑，查看公司的主站和部分监控后，紧跟着到akamai到官网上查看相关故障说明，故障由于一次线上变更触发dns系统的 bug，最后导致大故障。
从他们的描述来看，事故起因源于一个变更。作为同行业从业者，对此类故障深有感触。笔者职业生涯虽然不算非常长，但经过大小故障/问题数百起，仅DNS引起的故障7,8起。每起故障的原因都不相同。有修改bind源代码测试上线后在半夜coredump崩溃引起的大故障的, 有不符合政策被封禁而浑然不觉造成大面积无法访问的，有变更配置错误 人为导致次生故障进而导致更大的故障的，有容量达到第三方限流阈值 加上应用程序粗暴重试引起DNS不可用的，有第三方厂商软件更新引起的bind不兼容造成性能问题的，有第三方使用IPv6解析姿势不对导致解析慢引起性能故障的，有第三方厂商网络NAT变更引起解析异常的， 等等， 原因各种各样，但是结局一样，业务受到很大影响或者部分影响。这些案例/事件强烈地冲击者我们这些从业者，让我们对DNS的领域认识深刻，同时对高可用的体会更深刻。
线上变更可能会产生故障，但即使不做任何线上变更，老化/年久失修也会产生故障，从事物发展规律来看，没有外力干预的情况下，故障产生是一个必然事件。那是不是只能坐以待毙呢？那也不是，我们就是那个外力，会做各种干预。这种干预带来的效果是：避免故障的产生，或者让大故障变成小故障。
回到故障本身，该故障属于akamai edge dns(权威dns产品)范围，由于全球各地运营商的DNS递归获取权威解析的时都会请求edge dns, edge dns 不可用的时候，递归dns将以servfail返回给cache dns或者dns client(SERVFAIL状态不可缓存)，因此akamai dns故障恢复后国外运营商dns也迅速恢复。
我们业务使用到了akamai cdn的服务，由于akamai edge dns是cdn的基础服务(cdn的调度域名，以及关联的权威解析)，因此akamai edge dns故障期间，cdn也不可用。
对于该类的问题(CDN单厂商故障)，行业解决方案一般是采用融合cdn, 有技术实力可自建融合cdn(适配组件，监控组件，调度组件)，没有技术资源的情况下，可以先做成多CDN厂商半自动调度的。
cdn单厂商故障只是一个例子，将来可能会出现单邮件厂商故障，单短信厂商故障，单云存储故障，单云厂商故障。当然这里不是说，这些厂商不行，这些组件和云自己全部再造一遍，毕竟术业有专攻，具体的基础组件仍然由专业厂商来干，但是融合调度多个厂商的事情，我们是可以做的。考虑到基础组件层多厂商调度相对于公有云多厂商调度容易得多，因为不会涉及到DB，NOSQL等。因此第一期是可以将组件层做出多厂商调度。第二期再集中精力来解决多云厂商调度问题，毕竟这个工作量庞大，涉及到业务架构，应用架构，基础架构，还有很棘手的分布式/分布式事务问题，这里就不展开了。
接下来一段不短的时间内，需要补齐这些基建能力，满足业务的高可用需求。
