看著一個個“慶祝3000萬”的運營推廣活動，心裡卻沒有一丁點兒的興奮，反而成為了失落感的起始點。

一個“3000萬”的背後隱藏著一大堆冰冷的數字：100+臺（平均84GB記憶體+16C）伺服器（物理機+虛擬機器）、50+個應用服務、300+個Redis例項、500+個應用程序、10W+高峰併發、8億+日API訪問量、每天1TB+系統日誌......，看起來我是在裝逼的節奏。

看得見的是數字，看不見的是真相

如果系統是一個偏查詢類的應用，我想幾個號稱10W併發的Redis例項足以支撐千萬級使用者+10W併發規模的系統，你還會覺得NB嗎？如果1TB的系統日誌有50%是非主動業務觸發，並且可能只有0.1%的日誌才具有分析價值的系統，你還會覺得NB嗎？如果3000萬用戶裡面有99.99%的使用者是“被迫”使用的，你還會覺得NB嗎......

縱觀數年，最興奮的莫過於當年幾個同事守在伺服器前7*7*24小時不間斷地尋找問題和重啟服務伺服器，往往最花費時間的事情就是大海撈針，而這一根“針”也往往就是一行程式碼或一個配置的事情，也是對這跟“針”的發現讓我的程式設計師生涯興奮指數登上了高峰。這種程式設計師的“單純”，我想只有程式設計師才能懂。作為程式設計師，“高效能、高可用、高靈活”是我的目標，作為管理者，“政治性、社會性、經濟性”是我考慮的重中之重（考慮因素權重排名分先後順序）。我喜歡並擅長把一件複雜的事情簡單化，但有時候不得不面對必須把一件簡單的事情複雜化的現實存在。程式設計師時期面向的都是正向挑戰，而當下面對的更多是一堆不情願的負向情緒。

今天的數字，其實只是延期了四年的結果

 按目前的資源規模，別說3000W，再多的使用者量都能支撐，這份自信心源於4年前對架構整改方案的決策。不知當年哪來的勇氣，拍著自己腦袋喊著“自主研發”。可能是那一週連續的故障排查把腦袋短路的原因，埋下了“控制”的慾望。近千行核心程式碼的自主框架實現了高約束和規範的IOC和AOP，拋棄對各種外部中介軟體的高度依賴（如會話管理、資料分散式方案等），讓系統建設的主動性和可控性完全掌握在自己手裡。無論從8臺伺服器擴充套件到目前的100臺伺服器，還是從5個服務擴充套件至50個服務，亦或從單一區域網到混合私有云的遷移，這一切的順利歸功於當年對系統可控性改造和持續性建設的執著，回想起這些“前瞻性”的決定，確實有時會感到那丁點兒的自豪。

我不能保證99.99%的穩定性，但......

 系統有Bug很正常，運維操作失誤也是常有的事，系統上線出錯回滾更不在話下，所以我不敢保證系統100%的正常運轉。通過對故障的“大資料”分析，我們系統的故障率（所有大小故障）大概30%，也就是三天一“日經”，所以我無法保證4個9的穩定性。但通過資料顯示，故障的99.99%都不是我們系統的內部故障，而是對接外部系統的故障。無論我們系統容災能力多麼強大，“系統繁忙，請稍後再試”成了我們唯一最有價值的降級方案。有些許朋友經常向我反饋，為什麼你們應用經常“系統繁忙”，我會很自豪地跟他們說：“幸好是我們做的，換作別人，給你個白屏，連‘系統繁忙’都不跟你說一聲”。

有時候一個“滿意”的回饋比這些數字暖和得多

 目前同時掌管著大數十號人以及多個專案，無論如何，整個組織的順利運轉還是歸功於以上多年方法的思考以及工具的積累，但最讓我舒心的不是以上系統使用者量的突破，而是其它小規模“自主應用”給使用者體驗所帶來滿意的回饋。一串串大資料的背後可能是一個個冰冷的KPI指標，但一個個使用者的認可卻是真金白銀的服務回饋。或許，以上的這些感想只是因為人生階段的不同對滿足的追求有了不一樣的想法而已。