运营商跺跺脚 信息中心抖三抖
下午四点多的时候，同事很着急的打来电话，说是学校的主网站、系统、以及各种信息化服务都无法从互联网访问了。同时，他也接到了DNSPod的邮件提醒：
根据这条提醒，我感觉教育网链路出现问题导致学校根域无法解析的可能性非常大，然后通过 dig 命令验证了一下，的确学校的 DNS 服务器无法访问了。这时基本可以确认是机房的教育网链路出现了问题，但究竟是我们自己的防火墙、交换机出现了问题，还是学校到北大的线路出现了故障，或者是更上层结点出现了故障，就需要进一步排查。但可以肯定的是，我们自己最近没有做任何配置上或链路上的调整，所以外部出现问题的可能性是更大的。
于是同事从一台位于美国机房的虚拟机进行了 trace，得到结果是在 101.4.117.97 这个地址后发生了故障，根据 ip.cn 的数据库，101.4.117.97 这个地址属于赛尔网络。到这时，问题基本搞清楚了，同事又打电话给赛尔网络进行了确认。到了晚上教育网的问题基本解决了，同时我们也收到了链路正常的通知：
至此，故障基本恢复，是否由于故障导致了更多的问题（譬如第三方支付回调失败导致的掉单），仍需进一步确认。（当然根据程序的设计逻辑和以往的经验，微信支付在回调失败后会进行重试，而我们的支付对接网关也会主动抓取未超时的订单状态，以往类似情况并未出现过掉单问题。）
在学校信息中心工作的过程中，类似的问题出现过很多次，光纤被破坏、网络上级结点调整、运营商合同到期的链路切换。作为末端结点，每一次故障都会让我们扔下既定的工作瞎忙活好一阵子，当然“网络又断了”这种锅，即便问题不在我们，也总是要信息中心自己背的。
为了解决这类问题，我们在几年前开始尝试公有云上的 DNS 服务，实际上的效果还是不错的，但为什么这一次又中招了呢，还要慢慢说来。
网络结构和 DNS 解析的调整
高校最早介入的都是教育科研网，那时大家只有一个网络出口。但由于历史上很长时间通过教育网访问国际互联网的价格特别昂贵，各学校开始和各大运营商接洽并开通了更多的网络出口。譬如我所在的学校，就在最近几年陆续接入了中国电信、中国联通和中国移动的出口。当然，接入这些出口链路是要解决师生上网速度的问题，并不是要解决学校自身提供的网络服务的问题，因为学校提供的网络服务，其主要用户还是来源于校园网内部。
但由于相当长一段时间教育网从国内运营商网络和国际互联网访问的速度特别慢，经常被出差在外的教师和干部们吐槽，于是就开始尝试利用这些新的出口链路来向互联网提供信息服务的访问。方法就是根据访问者所使用的网络环境，为其提供一个对于该网络更快的访问地址。于是我们的很多服务就有了好几个 IP 地址，分别对应于不同的网络出口。譬如 www.bit.edu.cn 对应的教育网地址为 202.204.80.112，而且对应的中国联通网络地址为 114.247.56.112。
这种方式，虽然能够从一定程度上解决访问速度的问题，但无形之中引入了两个问题：一是我们必须自己维护区域列表，根据互联网相关组织发布的信息不断进行更新；二就是任何一条链路出现故障的时候，导致该地址所对应的区域无法访问学校的服务。那时我们只能对重点的服务进行切换，但由于 DNS 的缓存时效性，即便是手工切换完成了，也不能保证用户马上能够使用。如果想实现自动切换，就必须解决两个问题，其一是从互联网进行故障检测，其二是要降低 DNS 的缓存时间，也就是要有性能更好的 DNS 服务来应对不断产生的 DNS 查询请求。
经过调研，我们发现国内已经有一些专业的公有云 SaaS 化 DNS 服务商，譬如 DNSPod。他们在基础的 DNS 解析功能上，提供了以下功能：
- 分区域 DNS 解析（我们再也不用自己更新区域IP列表了）
- 通过遍布全国的服务器进行各区域 IP 的可用性监测
- 根据可用性检测结果自动进行切换，切换时效为 10 秒
虽然这一服务是为了互联网上的 CDN 提供的，但它也恰恰可以解决我们遇到的问题。但要使用这一服务，就必须将学校的根域所对应的 DNS 调整为 DNSPod 提供的服务器的地址，而这一操作需要经过精心的准备，因此我们采用了一种折衷的方法：重新申请一个域名 bithosts.net，将其配置到 DNSPod 上，然后将学校的 bit.edu.cn 的域名 CNAME 到 bithosts.net 的对应域名上。这样可以在影响最小的情况下实现链路故障时域名解析结果的自动切换。
在使用这一方式后，学校整体信息化服务的稳定程度提高了很多，绝大多数原因造成的单条网络故障，都不会造成信息服务无法访问。但有一种情况，是无法解决的，就是教育网链路损坏。
原因也很简单：虽然我们实现了 bithosts.net 这一域名的动态解析，但用户首先访问的是 bit.edu.cn，而 bit.edu.cn 只能通过教育网链路访问。如果 bit.edu.cn 自身无法解析，无论后续的优化有多少，都无济于事。
跳出故障频发的泥潭
要解决我们目前遇到的问题，有不同的方案，但最直接了当而又一劳永逸的：就是直接将 bit.edu.cn 的域名解析彻底搬迁到 DNSPod 这类公有云上的 SaaS 服务中。实际上我们今年也已经对此进行了简单的讨论并确定了这一基本方向，只是由于其它工作的牵绊，尚未开始正式的实施。而我们之所以要这么做，就是我们相信公有云上的优秀 SaaS 服务提供商，他们一定可以做的比我们自己更好。而事实上，我们所采用的公有云服务，只要按时付费，几乎都没有出现过问题。
高校开始建设校园网络时，国内的互联网还是一片蛮夷，同时由于高校在信息化建设上的投入相对于中小企业而言大得多，所以很多情况下都是通过自建机房、采购设备、自己运维的方式来提供服务的。因此仅以对公网的 DNS 解析服务而言，国内大多数高校也都是通过自己的服务完成的。随着设备和系统的不断增加也引入了更多的故障点和安全风险点，因此而造成的故障频发已经成为运维人员的噩梦，给他们带来了极大的压力。
二十年来，随着国内商业互联网的发展和互联网公司在技术上的不断精进，很多过去需要通过购买安装专用设备和系统来解决的问题，都已经可以通过公有云上的 SaaS 化服务来解决了。除了 DNS 解析服务，常见的还有云 WAF 和 DDoS 攻击防护、短信网关、支付网关，以及企业邮箱、钉钉、企业微信等等。国内的各种各样的企业和政府机构，早已经开始广泛使用这些服务，不仅缩短了建设周期、降低了运行成本，也大大提高了服务的稳定度。
因此，可以说目前高校信息化建设中的某些做法，仅仅是由于过去长期工作而形成的一种惯性，在按照传统的路往前走而已。而那条路，也许未必是对的。
现在，也是时候理清思路、甩下包袱、调整方向、重新出发了，否则我们也许还要在泥潭中苦苦挣扎很久，而那又如何对得起宝贵的青春和只有一次的生命呢？
