似乎每一家網際網路公司都有一種屬於自己的氣質，我接觸過很多知名網際網路公司的技術專家，其中有一家公司技術專家給了非常深的印象，那就是 UCloud。在和 UCloud 技術專家的溝通中，我深深感受到這是一支極為自信、動手能力很強的技術團隊。
近期，我在UCloud上海辦公室採訪了 UCloud 虛擬網路負責人徐亮，就如同我採訪過的很多一線技術領軍人物一樣，徐亮給我帶來的直接印象就是執著、樸實和認真。
說到自己擅長的網路技術領域，徐亮神采飛揚
在和他的談話中，我聽到了不少 UCloud 有趣的研發故事，讓我對 UCloud 技術團隊的動手能力有了更深的認識。尤其是， 當UCloud 所倡行的“客戶為先”、“客戶的需求就是我們的下一個產品”等理念從一個專注於前沿技術的技術領軍人物的談吐中汩汩冒出時，印象更深刻了。
轉化：實驗室技術能力 ➡️➡️➡️ 生產能力
我為什麼認為 UCloud 的技術團隊是一支動手能力極強，這得從他們的 25G 智慧網路卡專案說起。
眾所周知，如何將實驗室形成的技術能力轉化成生產能力，需要很好的工程能力，25G 智慧網路卡從實驗室到生產環境恰恰體現了這樣的工程能力。
“去年我們將 25G 智慧網路卡產品投入到生產環境，實際上，UCloud 從 2016 年就開始跟蹤這項技術。這期間我們測試了很多廠商的智慧網路卡，有的智慧網路卡的效能相當不錯。但是阻礙我們將其投入生產環境的一個重要原因是，它和公有云所要求的熱遷移的能力不相容。所以，雖然這些智慧網路卡的效能很好，但是沒有辦法應用到公有云環境。”徐亮介紹道。
其實，業界一些公有云廠商很早就在藉助這些智慧網路卡做加速，但是在處理熱遷移的時候做不到使用者的無感遷移，必須要使用者手動修改虛機裡面網路的配置。這雖然能夠達到目的，但是對使用者並不友好。對此，UCloud 秉持一向的態度：“我們一定要做到使用者沒有額外的負擔，這樣對使用者來說才是最佳的方案，才是成熟的、使用者友好的方案。”
據徐亮回憶，情況在 2017 年底出現了一個轉機。彼時，Linux 核心社群開始討論智慧網路卡如何能夠無感的支援熱遷移，UCloud 技術團隊第一時間進行了深入的技術追蹤和研究。從社群開始討論和開發，最後到 2018 年 5 月份時該功能趨於穩定，才被接受到 Linux 的核心主線裡。
“在發現該功能已經基本成熟後，我們馬上就把這個補丁應用回 UCloud 的定製核心當中，跟智慧網路卡廠商一起研究，很快就在實驗室完成了該產品。”徐亮接著談到，“然後我們就開始線上上做公測。這個時候就非常體現我們的工程能力。”
在徐亮的團隊將智慧網路卡投入生產環境時，雖然也發生了一些問題，但是就算在連韌體都升級過兩次的情況下、對使用者的業務並沒有產生太大的影響，我想這就是 UCloud 技術團隊的工程能力一個重要體現——“我的韌體都升級了，而使用者業務不受影響。”
驅動：客戶為先 ➡️➡️➡️ 工程能力
在我採訪的 UCloud 技術人員中，徐亮並不是第一個提到“客戶為先”、“客戶的需求就是我們下一個產品”等理念的，在與 UCloud 技術副總裁楊鐳、私有云和容器產品線負責人葉理燈等人的採訪溝通中他們都曾提及這一貫徹於 UCloud 所有技術、產品研發中的理念。他們對於“客戶為先”以及在產品的研發、技術專研中的踐行，讓我深信他們從骨子裡認可這樣一個價值觀。可以說，“使用者為先”的理念驅動著其工程能力的形成。
談到他們的經典網路升級至 VPC 2.0 專案，也許你會理解我說的。
以“客戶為先”為出發點
據我瞭解，UCloud 應該是全球唯一一家把經典網路升級到 VPC 2.0 網路的公有云廠商。在我和多位 UCloud 技術人員的接觸中，這個專案被多次提及，它的實施可謂是歷經周折，遇到的困難很多。
“我們的出發點是‘客戶是不是有這個訴求？這件事情對客戶來說是不是有好處？’如果是的話，那我們為什麼不做呢？“。當問及專案出發點時，徐亮談到。顯然，如果能夠透明的將經典網路升級至 VPC 網路，對於使用者來說無疑是有訴求和好處，不需要自行遷移或是同時維護兩個架構。但，UCloud 一開始低估了這個專案的難度。
徐亮說，“為什麼這麼難？因為一個預設的前提條件出現了變化——我們以前假設使用者的 IP 是唯一的，這不光體現在網路產品上，還包括資料庫產品、儲存產品等，都會假設使用者的 IP 是唯一的——在之前的經典網路時，該前提條件似乎是顯而易見的。但在我們要升級到 VPC 2.0 時，我們突然發現這個 IP 變得不再唯一，由於不同的租戶網路是完全隔離的，IP 完全是可以重複的。”
因此，這個專案不再是一個純粹的網路專案，意味著 UCloud 平臺上的所有產品都需要升級，都要支援這個重要變化，所以在工程上存在非常多的協調工作。這是一件非常、非常難的事，是一個涉及到全公司協調的能力。
“客戶為先”驅動產品創新
VPC 2.0 專案過程中，徐亮團隊還推出了許多創新產品，如 IPv6 地址轉換。
公有云裡面會有一些公共服務，比如說，像映象服務、DNS 服務等，所有的客戶都可能會訪問這些公共服務，而有些客戶的 IP 是彼此重疊的，只是 VPC 不同而已。傳統上都是採用 NAT 的方式去做的，因為地址是相同的，肯定需要透過 NAT 翻譯成不同的地址，然後再去訪問公共服務。
但是，NAT 方式有兩個問題，一個是公共服務在獲取原地址時變得很複雜，它要用 TOA 或其它手段才能夠提取出原地址。另外是這是一個有狀態的閘道器，可擴充套件性會存在一定的問題，有狀態的部分容易成為瓶頸，維護狀態代價很大。
UCloud 在這方面做了一個創新——徐亮的團隊把使用者的地址和使用者的 VPC 這兩個部分資訊組合起來，形成一個 128 位的 IPv6 地址，把使用者的 IPv4 的請求無狀態地轉換成了 IPv6 請求，然後傳送給這些公共服務。徐亮說，“我們這個無狀態轉換的思路，是非常創新的。對使用者來說，得到的效能很好，同時不需要為此額外增加成本。”
就這樣在“使用者為先”的驅動下，UCloud 技術團隊一點一點的完成了經典網路到 VPC 網路的升級，歷時三年。
“我們的初衷就是從客戶為先的角度出發，用我們的技術給客戶帶去價值，在這個基礎上我們就認為這件事情值得就去做。”
自省：關於工程能力的三句話
關於對工程能力的理解，徐亮談到了幾句話： “先於客戶發現問題”、 “先扛住再最佳化”、“這件事情能不能做到24小時止血”、“一週之內能不能拿出一箇中期解決方案？”… 讓我印象深刻，這也是 UCloud 技術團隊的實踐路線。
“先於客戶發現問題”
據徐亮介紹，其團隊做可程式設計交換機的過程中遇到一個非常隱晦的交換機晶片編譯器的 BUG，它會發生雜湊衝突，從而導致行為不可預期，但是這個問題在實驗室是沒辦法復現出來。歷時一個月時間，UCloud 透過在工程上引入全量測試的環節，提前發現了問題。
這件事情之後，徐亮的團隊開發了一個新系統，對所有使用者虛機點對點通訊的資訊進行統計，在做變更時就會針對通訊過的場景做全量驗證。透過這種方式來發現一些因為軟體架構變化導致的問題，能夠“先於客戶發現問題”，在對客戶業務沒有產生影響的情況下去解決它。
“先扛住再最佳化”
發現問題第一時間不是去分析根本原因是什麼，而要考慮怎樣降低對客戶的影響，這就是 UCloud 團隊常說的“先扛住再最佳化”。比如說，智慧網路卡出現故障了，不會先修復智慧網路卡，肯定是先把使用者的業務切走，讓使用者的業務正常，然後再想辦法解決智慧網路卡的問題。
“這件事情能不能做 24 小時止血”
一旦發生故障就會做覆盤，這時候UCloud技術團隊最常說的一句話就是“這件事情能不能做24小時止血”。故障對客戶是有影響的，我們要在24小時之內先推出一個方案，這個的方案能夠讓客戶降低損失。不光是出現問題的客戶，甚至是其他沒有出現問題的客戶，我們也要在24小時之內拿出一個方案，讓這些問題不會影響到客戶。
然後，再問‘一週之內能不能拿出一箇中期解決方案？’，最後再考慮長期解決方案，長期方案有的時候就真的很長，比如說體系架構設計的不合理、需要進行重構。
結語
在和包括徐亮在內的多位 UCloud 技術領頭人在深入溝通後，深切感受到這是一支極為自信、工程能力極強的技術團隊，他們敢於嘗試新技術，同時其工程能力能在給使用者提高價值的同時，保證不出現問題，我相信這是 UCloud 技術團隊自信的底氣。
“穿山甲專訪”欄目是 Linux 中國社群推出的面向開源界、網際網路技術圈的重要領軍人物的系列採訪，將為大家介紹中國開源領域中一些積極推動開源，諳熟開源思想的技術人，並辨析其思考、挖掘其動因，揭示其背後所發生的事情，為關注開源、有志於開源的企業和技術人標出一條路徑。
取名為“穿山甲”寓意有二：取穿山甲挖掘、深入之意來象徵技術進步和表徵技術領袖的作用；穿山甲是珍稀保護動物，宣傳公益。
