運營商跺跺腳 信息中心抖三抖
下午四點多的時候，同事很著急的打來電話，說是學校的主網站、系統、以及各種信息化服務都無法從互聯網訪問了。同時，他也接到了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 攻擊防護、短信網關、支付網關，以及企業郵箱、釘釘、企業微信等等。國內的各種各樣的企業和政府機構，早已經開始廣泛使用這些服務，不僅縮短了建設周期、降低了運行成本，也大大提高了服務的穩定度。
因此，可以說目前高校信息化建設中的某些做法，僅僅是由于過去長期工作而形成的一種慣性，在按照傳統的路往前走而已。而那條路，也許未必是對的。
現在，也是時候理清思路、甩下包袱、調整方向、重新出發了，否則我們也許還要在泥潭中苦苦掙扎很久，而那又如何對得起寶貴的青春和只有一次的生命呢？
