說到自己擅長的網(wǎng)絡技術領域,徐亮神采飛揚
在和他的談話中,我聽到了不少UCloud有趣的研發(fā)故事,讓我對UCloud技術團隊的動手能力有了更深的認識。尤其是, 當UCloud 所倡行的“客戶為先”、“客戶的需求就是我們的下一個產(chǎn)品”等理念從一個專注于前沿技術的技術領軍人物的談吐中汩汩冒出時,印象更深刻了。
轉化:實驗室技術能力——生產(chǎn)能力
我為什么認為UCloud的技術團隊是一支動手能力極強,這得從他們的25G智能網(wǎng)卡項目說起。
眾所周知,如何將實驗室形成的技術能力轉化成生產(chǎn)能力,需要很好的工程能力,25G智能網(wǎng)卡從實驗室到生產(chǎn)環(huán)境恰恰體現(xiàn)了這樣的工程能力。
“去年我們將25G智能網(wǎng)卡產(chǎn)品投入到生產(chǎn)環(huán)境,實際上,UCloud 從2016年就開始跟蹤這項技術。這期間我們測試了很多廠商的智能網(wǎng)卡,有的智能網(wǎng)卡的性能相當不錯。但是阻礙我們將其投入生產(chǎn)環(huán)境的一個重要原因是,它和公有云所要求的熱遷移的能力不兼容。所以,雖然這些智能網(wǎng)卡的性能很好,但是沒有辦法應用到公有云環(huán)境。”徐亮介紹道。
其實,業(yè)界一些公有云廠商很早就在借助這些智能網(wǎng)卡做加速,但是在處理熱遷移的時候做不到用戶的無感遷移,必須要用戶手動修改虛機里面網(wǎng)絡的配置。這雖然能夠達到目的,但是對用戶并不友好。對此,UCloud 秉持一向的態(tài)度:“我們一定要做到用戶沒有額外的負擔,這樣對用戶來說才是最佳的方案,才是成熟的、用戶友好的方案?!?/strong>
據(jù)徐亮回憶,情況在2017年底出現(xiàn)了一個轉機。彼時,Linux內(nèi)核社區(qū)開始討論智能網(wǎng)卡如何能夠無感的支持熱遷移,UCloud技術團隊第一時間進行了深入的技術追蹤和研究。從社區(qū)開始討論和開發(fā),最后到2018年5月份時該功能趨于穩(wěn)定,才被接受到 Linux 的內(nèi)核主線里。
“在發(fā)現(xiàn)該功能已經(jīng)基本成熟后,我們馬上就把這個補丁應用回UCloud的定制內(nèi)核當中,跟智能網(wǎng)卡廠商一起研究,很快就在實驗室完成了該產(chǎn)品。”徐亮接著談到,“然后我們就開始在線上做公測。這個時候就非常體現(xiàn)我們的工程能力。”
在徐亮的團隊將智能網(wǎng)卡投入生產(chǎn)環(huán)境時,雖然也發(fā)生了一些問題,但是就算在連固件都升級過兩次的情況下、對用戶的業(yè)務并沒有產(chǎn)生太大的影響,我想這就是 UCloud技術團隊的工程能力一個重要體現(xiàn)——“我的固件都升級了,而用戶業(yè)務不受影響?!?/strong>
驅動:客戶為先——工程能力
在我采訪的UCloud技術人員中,徐亮并不是第一個提到“客戶為先”、“客戶的需求就是我們下一個產(chǎn)品”等理念的,在與 UCloud技術副總裁楊鐳、私有云和容器產(chǎn)品線負責人葉理燈等人的采訪溝通中他們都曾提及這一貫徹于UCloud所有技術、產(chǎn)品研發(fā)中的理念。他們對于“客戶為先”以及在產(chǎn)品的研發(fā)、技術專研中的踐行,讓我深信他們從骨子里認可這樣一個價值觀??梢哉f,“用戶為先”的理念驅動著其工程能力的形成。
談到他們的經(jīng)典網(wǎng)絡升級至VPC2.0項目,也許你會理解我說的。
以“客戶為先”為出發(fā)點
據(jù)我了解,UCloud應該是全球唯一一家把經(jīng)典網(wǎng)絡升級到VPC 2.0網(wǎng)絡的公有云廠商。在我和多位UCloud 技術人員的接觸中,這個項目被多次提及,它的實施可謂是歷經(jīng)周折,遇到的困難很多。
“我們的出發(fā)點是‘客戶是不是有這個訴求?這件事情對客戶來說是不是有好處?’如果是的話,那我們?yōu)槭裁床蛔瞿兀?/strong>“。當問及項目出發(fā)點時,徐亮談到。顯然,如果能夠透明的將經(jīng)典網(wǎng)絡升級至VPC網(wǎng)絡,對于用戶來說無疑是有訴求和好處,不需要自行遷移或是同時維護兩個架構。但,UCloud一開始低估了這個項目的難度。
徐亮說,“為什么這么難?因為一個默認的前提條件出現(xiàn)了變化——我們以前假設用戶的IP是唯一的,這不光體現(xiàn)在網(wǎng)絡產(chǎn)品上,還包括數(shù)據(jù)庫產(chǎn)品、存儲產(chǎn)品等,都會假設用戶的IP是唯一的——在之前的經(jīng)典網(wǎng)絡時,該前提條件似乎是顯而易見的。但在我們要升級到VPC 2.0時,我們突然發(fā)現(xiàn)這個IP變得不再唯一,由于不同的租戶網(wǎng)絡是完全隔離的,IP完全是可以重復的?!?/p>
因此,這個項目不再是一個純粹的網(wǎng)絡項目,意味著UCloud平臺上的所有產(chǎn)品都需要升級,都要支持這個重要變化,所以在工程上存在非常多的協(xié)調工作。這是一件非常、非常難的事,是一個涉及到全公司協(xié)調的能力。
“客戶為先”驅動產(chǎn)品創(chuàng)新
VPC2.0項目過程中,徐亮團隊還推出了許多創(chuàng)新產(chǎn)品,如IPV6地址轉換。
公有云里面會有一些公共服務,比如說,像鏡像服務、DNS服務等,所有的客戶都可能會訪問這些公共服務,而有些客戶的 IP 是彼此重疊的,只是 VPC 不同而已。傳統(tǒng)上都是采用NAT的方式去做的,因為地址是相同的,肯定需要通過NAT翻譯成不同的地址,然后再去訪問公共服務。
但是,NAT方式有兩個問題,一個是公共服務在獲取原地址時變得很復雜,它要用TOA 或其它手段才能夠提取出原地址。另外是這是一個有狀態(tài)的網(wǎng)關,可擴展性會存在一定的問題,有狀態(tài)的部分容易成為瓶頸,維護狀態(tài)代價很大。
UCloud在這方面做了一個創(chuàng)新——徐亮的團隊把用戶的地址和用戶的VPC 這兩個部分信息組合起來,形成一個 128 位的 IPv6 地址,把用戶的IPv4的請求無狀態(tài)地轉換成了IPv6請求,然后發(fā)送給這些公共服務。徐亮說,“我們這個無狀態(tài)轉換的思路,是非常創(chuàng)新的。對用戶來說,得到的性能很好,同時不需要為此額外增加成本。”
就這樣在“用戶為先”的驅動下,UCloud技術團隊一點一點的完成了經(jīng)典網(wǎng)絡到VPC網(wǎng)絡的升級,歷時三年。
“我們的初衷就是從客戶為先的角度出發(fā),用我們的技術給客戶帶去價值,在這個基礎上我們就認為這件事情值得就去做?!?/strong>
自省:關于工程能力的三句話
關于對工程能力的理解,徐亮談到了幾句話: “先于客戶發(fā)現(xiàn)問題”、 “先扛住再優(yōu)化”、“這件事情能不能做到24小時止血”、“一周之內(nèi)能不能拿出一個中期解決方案?”… 讓我印象深刻,這也是UCloud技術團隊的實踐路線。
“先于客戶發(fā)現(xiàn)問題”
據(jù)徐亮介紹,其團隊做可編程交換機的過程中遇到一個非常隱晦的交換機芯片編譯器的BUG,它會發(fā)生哈希沖突,從而導致行為不可預期,但是這個問題在實驗室是沒辦法復現(xiàn)出來。歷時一個月時間,UCloud通過在工程上引入全量測試的環(huán)節(jié),提前發(fā)現(xiàn)了問題。
這件事情之后,徐亮的團隊開發(fā)了一個新系統(tǒng),對所有用戶虛機點對點通信的信息進行統(tǒng)計,在做變更時就會針對通信過的場景做全量驗證。通過這種方式來發(fā)現(xiàn)一些因為軟件架構變化導致的問題,能夠先于客戶發(fā)現(xiàn)問題,在對客戶業(yè)務沒有產(chǎn)生影響的情況下去解決它。
“先扛住再優(yōu)化”
發(fā)現(xiàn)問題第一時間不是去分析根本原因是什么,而要考慮怎樣降低對客戶的影響,這就是UCloud團隊常說的先扛住再優(yōu)化。比如說,智能網(wǎng)卡出現(xiàn)故障了,不會先修復智能網(wǎng)卡,肯定是先把用戶的業(yè)務切走,讓用戶的業(yè)務正常,然后再想辦法解決智能網(wǎng)卡的問題。
“這件事情能不能做24小時止血“
一旦發(fā)生故障就會做復盤,這時候UCloud技術團隊最常說的一句話就是‘這件事情能不能做24小時止血’。故障對客戶是有影響的,我們要在24小時之內(nèi)先推出一個方案,這個的方案能夠讓客戶降低損失。不光是出現(xiàn)問題的客戶,甚至是其他沒有出現(xiàn)問題的客戶,我們也要在24小時之內(nèi)拿出一個方案,讓這些問題不會影響到客戶。
然后,再問‘一周之內(nèi)能不能拿出一個中期解決方案?’,最后再考慮長期解決方案,長期方案有的時候就真的很長,比如說體系架構設計的不合理、需要進行重構。
結語
在和包括徐亮在內(nèi)的多位UCloud技術領頭人在深入溝通后,深切感受到這是一支極為自信、工程能力極強的技術團隊,他們敢于嘗試新技術,同時其工程能力能在給用戶提高價值的同時,保證不出現(xiàn)問題,我相信這是UCloud技術團隊自信的底氣。(作者:老王 來源:Linux中國)