互聯網科技公司的長久穩定發展，離不開堅實的技術支撐。
在全球擁有 15 億月活用戶的字節跳動，背後的技術支撐，離不開牢固的基礎架構和對技術理解深刻的技術人。
目前主管字節跳動基礎架構團隊的是樑宇明，樑宇明 2010 年清華大學畢業後加入 Hulu，曾擔任 Hulu 中國數據與廣告團隊負責人。2018 年，樑宇明離開 Hulu，加入字節跳動，成爲字節跳動基礎架構團隊負責人。
2019 年 12 月 6-7 日的 ArchSummit 全球架構師峯會，擁有豐富的技術架構實踐管理經驗的樑宇明將擔任會議 Co-chair。藉此機會，我們採訪了樑宇明，採訪中，樑宇明分享了他這些年在工作方式、思考能力、技術洞察、技術管理上的經驗，希望對大家有啓發。
InfoQ：您在 Hulu 工作多年，在 Hulu 哪些方面的收穫對於對現在的工作很有幫助？
首先，Hulu 的經歷幫助我可以以動態變化的觀點審視周邊。我是 2007 年在 Hulu 剛剛建立 4 個月的時候加入到 2018 年離開 Hulu，歷經了 Hulu 從初創期到高速成長期歷經波折逐步進入成熟的生命週期，參與了一段相對完整的企業生命週期。在不同的階段，企業所展現出來的業務特徵、人才結構、組織流程、技術體系有非常大的不同。這份經歷讓我學會了以動態變化的觀點來審視周圍，對於企業所處的階段有更好的判斷，進而可以做出更加適應發展階段的技術決策。
其次，因爲在初創期加入 Hulu，涉及到的技術棧相當對來說比較廣泛，從搜索推薦到移動端開發再到大數據體系都有所涉獵，對於不同技術體系、業務體系的認知會使得做基礎架構的時候可以更加理解業務需求，與業務達成更深度的合作共贏。
InfoQ：您認爲 Hulu 和字節跳動兩家公司有哪些異同？
從文化上講，兩者有很多的相同點，也有些不同點。相同之處在於，Hulu 的基本文化特徵是強調 collaboration & consensus 而非 command & control，這一點與字節的始終創業、坦誠清晰、開放謙遜是非常一致的，一鳴提過一個理念，叫“Context，not Control”，兩家公司都有比較強的自下而上推動革新的特徵。不同之處在於字節更加敢爲和突破，更加強調不設邊界，而 Hulu 更加追求穩定，這個業務特徵以及用戶預期是非常相關的。
從組織管理上來講，兩者有非常大的區別。Hulu 更像是經典的樹狀組織結構，一些重要共識需要上升到共同父節點達成共識，而字節更加扁平化，構建的是網狀鏈接，可以無需上升到 leader 層面快速達成多團隊的共識。在 Hulu 要發揮重要作用需要非常熟悉 Hulu 的流程和機制，將自己的想法在一定的流程中尋求共識；而在字節需要建立更加廣泛的連接，通過連接達成共識，前者更加可預期，後者更加高效，適應了各自企業的發展階段。
從發展階段來講，兩者也非常不同，Hulu 相對進入成熟期，業務模型趨於固定，商業模式比較穩定，技術體系相對穩定，組織結構和組織流程也相對完善，更加強調的 integrity；字節仍舊處於高速發展期，業務模型、商業模式還在快速演進的階段，更加強調能能突破敢擔當，強調嘗試多種可能，在組織結構和組織流程上還在持續優化中。
InfoQ：您認爲字節的業務有什麼樣的特性，這些特性對基礎架構產生了怎樣的挑戰？
首先字節的業務模型非常的多元化，不同業務呈現出非常不一樣的特徵。傳統的信息流業務數據以及服務規模極大，對於系統的可擴展性和性能有非常高的要求；新型的飛書、教育等業務的數據模型非常複雜、系統的可用性、數據的一致性要求非常高。這樣截然不同的業務模型，使得基礎架構很難通過較爲精簡的幾套系統做到全面支持，需要更爲複雜的產品矩陣。
其次字節的規模性是非常大的，國內我們有幾十萬臺頂配的物理服務器、數 EB 的存儲的規模、數萬微服務，而且傳統信息流業務模型、中臺化構建，使得字節業務架構體系非常複雜。如何在系統穩定的前提下，提升系統的可觀可控性，同時有降低系統成本是一個很大的挑戰。
最後從發展階段上來講，字節還處於高速發展的階段，在做各種類型的探索，總體上來講，我們期望儘量減少對於業務的約束（雖然有些約束是更合理的），提供更加豐富的功能 / 特性來使得業務更加快速的迭代，而這種輕約束、重 feature 的期待對於基礎架構的挑戰尤爲困難。
InfoQ：應對這些挑戰，字節跳動的基礎架構有何思路？
首先需要明確我們的優化目標：
- 支持業務的快速迭代：針對字節當前業務發展階段，爲了更好地支持業務的快速迭代，需要做好這幾件事：
架構需要提供提供豐富的產品矩陣，提供研發最熟悉的接口，讓業務研發可以最快速的上手，最快速的解決業務問題，而不是提供非常精簡的系統，讓業務方花時間去適配；
在豐富的產品特性下，儘量減少用戶約束，例如我們對於業務使用 Redis 時的數據規模和數據結構不做太多約束，儘量將需要做的優化下沉到基礎架構側，爲了應對 Redis 的數據規模突破了 Redis Cluster 規模極限問題，我們自研了 Redis 集羣化方案；
儘量將一些通用的能力下沉到基礎架構側完成，例如流量調度、單元化構建、系統容災等。
- 體系結構持續升級換代：字節跳動急速發展使得早期的架構必然呈現“糙快猛”的特性，體系結構的升級換代是非常關鍵的，爲了字節更長遠的發展，需要下定決心給高速行駛的飛機換發動機，而非在已有系統上縫縫補補，所以體系結構的升級換代和支持短期業務增長是一樣重要的目標。
其次要對齊我們的技術理念，字節跳動在 2018 年開啓了基礎架構 2.0 的演進，基本特徵就是從「跟隨業務」向「源於業務而高於業務」「源於業務而先於業務」的方向發展。
-
基礎架構必須「源於業務」，完全脫離業務的基礎架構是空中樓閣，容易陷入自嗨。真正的好的架構必須來源於業務實際，這也意味着基礎架構需要和業務建立深入聯繫；
-
「高於業務」是指架構提供的系統基本指標是高於業務需求的，抽象度是高於業務需求的，這一點對於高速發展期間的公司是非常重要的，因爲業務發展變化非常快，如果做到「恰好」滿足業務需求，會很快發現幾個月後，變成「恰好」不滿足用戶需求。從基礎架構側角度講，我們也應當給出最佳實戰的範例，這也意味着基礎架構不僅僅聚焦在 Infrastructure，同時需要提供 Architecture 的支持；
-
「先於業務」是指架構需要對業務發展方向有預判，提前做好準備，因爲基礎架構很多系統的實現時間很長，有一定的提前量對於業務系統會很有幫助，這也意味着基礎架構會做很多面向未來的投資。
InfoQ：在這樣的指導思路下，字節的基礎架構是怎麼做的？
首先從組織結構上，字節將在線的基礎架構與離線的基礎架構融合爲一個團隊。整合後的基礎架構提供了橫跨離線在線的存儲、計算、研發體系這三大基礎設施，成爲支撐今日頭條、抖音、飛書等所有字節產品線的共同底座。組織結構調整和優化目標密不可分，例如字節的在線編排調度團隊（以 Kubernetes 爲基礎）和離線（以 YARN 爲基礎）整合爲一個團隊爲離線在線混合部署的快速推進、和技術體系演化打下了堅實基礎。
其次從技術體系上，字節的架構主要由三部分構成，存儲 + 計算 + 研發體系：
-
在存儲層面（注：這裏的存儲包括 HDFS、對象等經典存儲系統，也包括 NoSQL、NewSQL、圖數據庫等系統），字節的策略是演進到分層存儲的體系結構下，在統一的池化存儲上構建兼容開源系統的存儲產品矩陣來滿足業務需求。基於池化存儲的分層結構幫我們統一底層實現，將分佈式的常見問題以及重要優化實施一次，benefit 所有上層系統，簡化上層系統的開發，避免豐富的存儲產品矩陣所帶來運維複雜性；兼容開源系統的存儲產品矩陣主要用來簡化業務接入，提升開發效率；
-
從計算層面，我們在推進在線計算系統和離線計算的融合，長期來講會將 Kubernetes 和 YARN 底層整合爲一套資源調度系統，將 PaaS、FaaS、批式計算、流式計算在統一編排調度體系運行，持續推進資源利用率的提升。字節內部也在探索虛擬化和容器化的進一步融合；
-
從研發體系側（字節將 RPC 框架、PaaS、智能運維、治理系統、穩定性系統、效能系統統稱研發體系），字節絕大部分的業務是基於 PaaS 構建而非基於 IaaS 構建的，PaaS 化使得業務方關注的是資源而非機器，對於資源流量統一調配、環境治理系統的統一有非常重要的意義。
再次從合作流程上，基礎架構有相對完善的長期規劃、中期目標、短期執行管理機制，同時最大限度的將架構的信息同步給業務方，因爲在一個業務急速變化、團隊規模快速成長的團隊中，增強信息同步、減少信息不對稱對於增強互信、推進合作有着非常重要的意義。
InfoQ：您提到字節基礎架構在需要滿足業務的需求的同時，也需要做體系結構的升級換代，這兩者是有一定矛盾的，您是如何把握這個平衡點的？
管理業務預期是非常關鍵的，有時業務並不是真的此時此刻那麼着急，而是看不到好轉的希望，所以着急。將長短期計劃更好分享給業務，管理好大家的預期，對於營造寬鬆氛圍，梳爭取更多資源意義重大。
需求比想象的要收斂：基礎架構經常收到各種類型的需求，但如果可以抽象到更高的層次，很多需求是可以歸位一類的。這要求基礎架構的同學並不是一味執行，需要更多的思考與昇華，避免沒有想清楚盲目做，留下各種問題，使得迭代速度越來越慢。
優先級是可以談的，大部分業務需求真實緊急度和宣稱的有比較大出入，深入業務，理解真實需求和優先級，有助於抓住主要矛盾，解決核心問題。
作爲基礎架構要做好“融資”。基礎架構經常面臨的問題是，業務覺得架構做的不夠快，自己有很着急，業務自己就開啓了。往往業務側更注重短期實用性，對於所做的基礎設施通用型會有差距。如果以後這些系統交給基礎架構維護，架構往往要花費更大的力氣重構，很多也會成爲歷史債；如果不交給基礎架構維護，那麼公司級的基礎設施會逐步分裂。要解決這個問題，需要基礎架構擅長和業務達成合作關係，“豎起大旗，引導大家跟隨”很重要。要做到在方向和方案層面和業務達成共識，指引關鍵方向，引入更多業務資源共同開發，藉助業務方的力量共同演進。
技術大的迭代往往需要組織結構的支撐，條件允許的情況下，做團隊的拆分，分別 focus 在長短期，會非常有幫助。
InfoQ：在基礎架構演進的過程中，您有碰到什麼棘手技術問題嗎？您是如何解決的？
演進過程中肯定有很多棘手的問題，我在這裏給大家講一個相信每個快速成長的團隊都會遇到，但不是所有團隊都可以快速走出來的問題，那就是運維黑洞。所謂運維黑洞，就是團隊的主體精力都投入在運維中了，系統本身根本沒有空迭代，而業務規模還在持續擴張，運維越來越吃力，最終深陷其中。如何預防運維黑洞，相信大家都有想法，例如要推進運維從人肉化到腳本化、到平臺化、最後到智能化的進化，但是事實上，很多方向還是會陷入運維黑洞中去，這和技術體系、業務發展階段等都有密切的關係。
前幾個月我接手的一個存儲系統，就是因爲早期運維投入不夠，穩定性投入不夠，而業務使用產生了爆發式增長，導致所有的研發幾乎都陷入到運維之中去了。爲了解決這個問題，我們做了幾方面的努力：
-
既然是黑洞，通過自身的力量是非常難逃逸出來的，所以快速人員調配、擴充團隊是非常必須的，這時可以把其他團隊低優先級的事情先停下，快速召集人力，通過擴充人員這個最土的辦法，先把人均運維負載降低下來，這樣纔有時間去做優化；
-
僅僅是調配人還是不夠的，還需要補充不同類型的角色進來，例如陷入運維黑洞這個事實可能反映出來團隊已有人才在構建高可維護性系統上可能的缺失，補充不同的角色，補充具有不同特性人員的進入是非常有必要的；
-
在有人的基礎上，走出運維黑洞最重要的是準確識別核心問題，避免東一榔頭、西一棒槌抓不住重點。明確梳理核心運維痛點，制定專有計劃，抓住要點是關鍵；
-
往往陷入運維黑洞的系統，不僅僅是運維工具本身的缺失，也和系統設計、系統部署等有密切的聯繫，有的時候需要有大的更改纔可以走出來，所謂不破不立。但更改伴隨着風險，作爲 leader 要做好背書，做最全面的準備，做最壞的打算，對走出運維事故過程中的可能產生的事故不能過激反應，不然會嚴重的影響團隊的決策；
-
最後往往在運維黑洞中的團隊，團隊士氣會是一個很大的問題，補充人力、明確計劃，給大家清晰地預期是非常關鍵的，定期的進展同步，對於積極改變的肯定，多會幫助團隊重塑信心。
運維黑洞是大家都想避免的，但陷入其中的不在少數，要走出來需要的不僅僅是重視，而更多的是 leader 的資源傾斜、問題背書、精神支持。
InfoQ：您強調強調基礎架構的發展需要先於業務，您也闡釋過字節有很強的創新文化，在您的團隊中，您是如何鼓勵創新的？
團隊的目標要與公司相一致，字節文化中對創新的重視是各團隊構建良好創新氛圍的基礎。針對到架構團隊，我忍創新是需要制度來保證的，沒有制度保證的創新往往不是 reproducable 的。
-
首先要創新就要求大家不僅僅是關注自己眼前的一點事情，需要獲得整體的視野。字節基礎架構每雙週會做架構內部大範圍信息同步，幫助大家瞭解架構各個方向重要進展，從而獲得全局視野，雙月的總結也會不斷強化這一個過程；
-
其次創新是需要有規劃性的，結合字節項目週期，架構每個雙月會更新一版本的長期規劃，長期規劃是自底向上大家一起探討的，反映了大家共同對於長期的思考，因爲雙月迭代一次，這裏的 overhead 也不會太大。再次創新是需要組織保證的，我們構建了應用創新中心團隊，這個團隊與其他團隊共同推進創新新項目的研發與落地。
-
最後創新是需要激勵機制的，我們在年度績效總結的時候，要求所有的 team member 必須寫一項由自己主動提出而非自頂向下指派項目，也要求所有 leader 寫一項由 team member 提出並在他們的支持下落地的項目。通過這些機制結合在一起推進架構的創新。
InfoQ：作爲基礎架構的負責人，您不僅僅需要關注技術，也需要管理技術團隊，您在團隊管理方向有何經驗，您現在會重點修煉哪些技能？
在我看來，作爲一個技術管理者，至少需要具備三方面的能力：Leadership Skills + Management Skills + Technical Skills
-
Leadership Skills 用來確立團隊方向、凝聚培養團隊、構建組織文化，保證我們有正確的人在朝正確的方向走；
-
Technical Skills 用來完成 Solution Design、Problem Solving、Engineering Excellence，保證我們技術選型能夠支持我們的 vision；
-
Management Skills 用來確立工作模式、構建組織項目流程、推進外部合作共識，保證我們在以合作共贏、風險可控的方式前進。
在不同的公司發展階段，管理者的關注點會有所不同，在不同的管理層級上的關注點也會不同。一般一線 leader 更重 Technical Skills，二線 leader 更加強調 Leadership skills；初創期的 leader 更強調 Technical Skill，快速成長期的 leader 需要更好的 Management Skills。作爲字節這家快速成爲大型公司的基礎架構的負責人，我需要更多的時間確立團隊方向、構建團隊、設置組織項目流程、推進合作，但要引領基礎架構走向下一個階段，技術又是重中之重，所以這些方面我都在持續學習中。
12 月 6-7 日北京 ArchSummit 全球架構師峯會上，策劃了微服務架構，業務架構，實時計算，反應式架構，雲原生等基礎架構方向的專題，邀請了阿里，Google，美團、滴滴等公司技術專家來分享技術實踐。更多內容點擊 官網查看大會日程，購票請聯繫票務經理灰灰 15600537884 （同微信）