推廣項目架構體系不斷完善已經發展到3臺雲服務器和105臺撥號服務器,其中2臺雲服務器和71臺撥號服務器同時支持老版架構項目的運營和新版架構項目的測試。2臺雲服務器是每月底續費,71臺撥號服務器分兩個時間段提早兩天續費,十一假期的提早休息致使了雲服務器的漏續費。服務器
推廣項目整個平臺的開發和維護由兩我的組成,我負責項目的開發和部署,另外一個朋友負責服務器的購買和環境搭建。一時的疏忽在10.1號凌晨00:45暴露出問題,當時我還在作着好夢,忽然接到運營後臺奔潰的電話,此時纔想到服務器沒續費。打了好幾個電話才聯繫到運維,可能他也在呼呼大睡,打電話的同時我也在確認問題,聯繫上後問他是否能夠續費立刻恢復。架構
雲服務器不一樣於撥號服務器,之前撥號服務器忘續費的時候,服務器會被託管到回收站三天,三天時間內即時續費立刻就能夠運營,撥號服務器上沒有核心數據咱們也不會擔憂數據丟失。咱們從未處理過ucloud雲服務器的忘續費問題,當時看到後臺確實也在回收站,咱們的想法就是儘快續費看是否能夠恢復,若是回收站都沒有了,那麼項目的數據將是災難性丟失產生的損失也將委實不小。運維朋友聯繫財務大概花了1個小時的時間續費重啓服務器和初始化數據,所幸數據沒有丟失,可是咱們兩臺雲服務器的IP都變了。由於基於業務場景咱們沒有綁定域名,全部項目都是經過IP接口直接交互數據的,如今所面對的問題就是將全部雲服務器上18個工程和撥號服務器上71個工程所有修改更新IP,同時將數據方對接和結算的工程IP都要變動。爲了保證項目儘快運營,雖然任務比較重,可是好在任務明確,大概到早上6:00左右工程修改測試徹底,吃個早餐能夠安然入睡啦!運維
此次的事件風波都由未續費引發,若是能提早通知續費就不會浪費一夜的美夢!從中看到的不僅是提早續費,項目與項目之間IP作成可配置也能減小大部分的工做量,新版架構也確實將各類配置參數設計成了靈活的數據傳輸,只是爲了節省服務器開支將老版架構和新版架構放到一塊兒碰到了忘續費產生的悲劇,更重要的是這將時刻警醒這我任什麼時候候都要作好數據備份.....測試