12月2日消息，今日火山引擎云產品發布會上，字節跳動副總裁、火山引擎業務負責人楊震原發表演講，總結了其對于字節跳動建設IT基礎的思考和洞察。
他談到，過去9年，字節跳動持續建設IT基礎能力。如今，已經實現每天新增1500個AB實驗和2萬次線上變更，3周完成設計和上線新App，曾在27天內備戰完成春晚紅包項目。
今天火山引擎云產品發布會的主題是“新云，共未來”，不管是新朋友還是老朋友，大家都知道我們要發布云產品。火山引擎是字節跳動技術能力的輸出?；鹕揭娴脑飘a品，也是基于字節跳動的理念和實踐來建設的。今天我要跟大家分享的，就是字節跳動在發展的歷程中是怎么建設云的。
IT基礎建設的目標：敏捷
要講這個話題就要回到很多年前。當時我們公司還很小，主要有一個核心產品今日頭條。
按照公司一直以來的做事風格，我們在討論IT基礎建設時，首先就在討論，我們的目標是什么。直到現在我還記得很清楚，我們定下來的核心目標就是敏捷，就是要快。
當時，今日頭條是一個全新的移動互聯網產品，我們有著去建設全球最大內容分發平臺的愿景。我們每天都會有很多想法、很多討論，包括內容體裁、創作工具、產品交互、推薦算法等等，每天都在變。如果這些想法能更快實驗、更快發布，就會給公司帶來很強的競爭力。如果有想法但不能快速上線，就會給公司發展造成很大的風險。
我們實現了敏捷的目標，產品增長很快，大家覺得建設敏捷的IT基礎效果很好。這個理念一直延續到現在。
但是，只關注敏捷是不行的，因為還有很多問題。我們需要考慮到穩定性、綜合成本，不能說做得非?？欤杀竞芨?；
還要考慮到運維的復雜度等等。實現敏捷目標的同時，不能讓穩定性等問題成為短板。
在介紹我們怎么做云之前，首先分享一些案例。
外界有些人說字節跳動好像是一家App工廠，雖然并不準確，但我們做產品確實是非?？斓?。有些新的產品從開始有想法，我們決定要做，只用三周時間就能發布上線，這個基礎就是圍繞著敏捷目標建設的云。
再分享一個案例。去年距離除夕只有27天的時候，我們的產品技術團隊收到了參加央視春晚紅包互動的通知。這個活動很復雜，有很多環節。
大家也知道，春晚是一個突發用戶量非常大的事情，只有27天的時間，要做方案的設計、資源的準備、產品開發上線，最后我們順利完成了這個工作。而在以前，這類活動一般都會有3個月的準備時間，而且都是互聯網大廠在有很多資源準備的情況下完成的。
再列一些數據。第一個是數據中心的天級部署。這是什么概念？當我們交付了一個新的數據中心，我們的物理服務器上架聯網之后，部署業務以及切流，只要一兩天就可以完成。這也是因為我們自建數據中心，以及在全球范圍內用了很多云的供應商，不斷遷移，鍛煉出了這一套能力。
第二個數據，我們每天線上變更是兩萬次。云的能力，讓業務有非常靈活調整的空間。
第三個數據是我們每天新增大約1500個A/B測試，說明我們有很多想法的時候可以快速驗證，就會產生進化。我再舉個例子，假設有兩家公司，他們的方向一致，戰略水平也差不多，如果一家公司每個星期能做10個A/B測試，驗證10個想法，另一家公司每個星期只驗證1個想法，可以想象經過半年之后，兩家公司會拉開多大的差距。
所以說當方向、戰略差不多的情況下，敏捷就是決定競爭力的關鍵因素。
如何做到敏捷開發？
首先是對業務有宏觀設計，對整體架構做合理分層。因為不可能所有地方都敏捷，一些更偏應用、更頻繁改動的部分需要敏捷，一些基礎的模塊需要更穩定、更高性能。
我們要對業務有宏觀的設計，這樣可以把不同子系統放到對應的位置上去。如果胡子眉毛一把抓，什么地方都想快，這是錯誤的，而且也是很難實現的。
有了宏觀的設計，接下來說具體的實現方法：第一是微服務化，拆更小的服務單元，從開發上就可以有利于快速地變更，這些服務單元能夠在很多業務系統中靈活組合，以及多人并行開發。
微服務是提高開發效率非常重要的一點。
第二個是容器化，這個概念我相信在座各位都比較了解。容器對于運維體系來講有點像集裝箱對于貨運，可以解決環境部署的問題、隔離的問題、資源分配的問題。容器本身的開銷可控，未來還有進一步提高靈活性的空間，以及重組的空間。
是不是有這些技術之后就很美好了？我想說的是，從實踐來看，問題才剛剛開始。
比如說運維、質量和發布體系的問題。有了大量的微服務，一旦有一個服務出問題，會導致故障的影響面不可控，排查很麻煩。做過運維的同學會了解，有可能會產生服務雪崩。
另外，當我們想擴容的時候，怎么樣在一條服務鏈路的依賴體系下比較自動地擴容，還有灰度發布問題，還有很多其他的問題。如果這些問題處理不好，你會發現你的發布是變快了，但維護代價也在成倍增加，漸漸的就敏捷不起來了。
所以我們做了大量投入，建設完善的DevOps體系，包括持續集成的流程、平臺、線下測試環境、灰度發布、全面的監控系統、容災系統、故障半徑分析與治理、自動縮擴容等。
直到今天我們還一直在做，就是讓開發人員更關注業務本身，其他麻煩事兒讓平臺解決。
第二個是存儲的易用性問題。微服務化之后，存儲成為限制敏捷開發的一個關鍵因素。
存儲是一個技術很復雜的領域，專業性很強，目前還沒有一種可以應用于各個領域的存儲技術，我們需要建立一套產品矩陣來滿足需求。
通過存儲計算分離、架構改進、容器化部署、自動運維工具等等，來達成更優的存儲方案。
第三是性能優化。前面做了這么多敏捷、自動幫助開發者降低成本的事情，都是有代價的，性能損失就是其中之一。如果不去改進，從系統延遲和綜合成本兩方面，都會遇到挑戰。
我們做了大量的性能優化工作。
經過多年的技術實踐，我們的在線微服務數量超過10萬，這是指微服務的類型，確實是很大的一個數字，我自己都覺得可能有點太大了；
我們容器實例部署的規模大概是1000萬的量級，應該是國內容器規模最大的企業之一，目前我還沒聽到過其他企業公布過更大的數字。我們在微服務和容器的使用上是非常極致的。
云原生理念的實踐
我剛才講的字節跳動建設云的實踐，和云原生概念是非常契合的。
云原生這個概念，也火了很多年了。它的本質是什么？我自己感覺，云原生就是軟件研發體系向前發展的一個過程。
大家想下，計算機剛剛被發明的時候，人們寫機器代碼太麻煩了，程序員都怕麻煩，于是有了高級編程語言，編譯器；
人們自己定義各種數據存儲格式，讀寫存儲非常麻煩，還容易出錯，于是有了數據庫；人們已經寫了軟件，想用的時候，還得買機器，租機房，部署網絡，太麻煩了，于是有了云計算。
那么，現在還有哪些事情太麻煩？還有很多，我上面提到了一些問題，其實現在也還有很大的進步空間。
所以，我覺得云原生，就是考慮云上的軟件開發、維護全流程，去改進各個子系統，目標就是讓開發人員更聚焦在業務本身，讓云平臺去解決其他的“麻煩事兒”。
基于敏捷開發的理念，字節跳動不斷改進系統，就是希望讓開發人員更聚焦在業務。這讓我更加相信云原生這個理念，因為這個理念是有實踐基礎的。
高密度計算、數倉與底層硬件探索
接下來再分享下我們在云實踐過程中的三點經驗。
第一點是高密度計算。業務系統有很多類型，有些系統用非常敏捷的方式是好的。另外有些系統比如推薦、搜索、廣告、視頻理解，這些系統的計算密度很高，服務粒度要稍微大一點。
當我們在這些系統上做敏捷的時候，可能要選擇用插件化的方式去加速它的開發和迭代，這是一類高密度計算的問題。
第二點，數倉的問題。字節跳動的核心技術理念是數據驅動和敏捷開發，我們需要全面的數據平臺。我在2014年初剛入職的時候，發現公司已經有一個小時級可以看到結果的A/B測試平臺，之后我們也一直都在踐行數據驅動理念，讓新的產品發布、新的功能可以很方便地做A/B測試。所以我們在敏捷開發的同時，需要保證數據平臺有很高的數據準確性、一致性、穩定性。
這里列一些規模和效率的數據。現在我們數據倉庫本身，不算視頻和機器學習的數據，總量已經到了9500PB的規模，每天新增40PB左右，指標數超過27000個。
在這樣的一個體量之下，我們依然能夠很快地去做新產品的數據支持。
一個全新的產品線，大概需要兩周時間就可以完成所有核心數據的分析，包括數據報表建設等工作。
第三點，底層硬件的技術探索，這肯定是基礎的事情，我們也有很多的投入，比如自研服務器、DPU、AI芯片、數據中心技術等等。這里不展開介紹，未來可以和大家做更多展示。
以上就是我對字節跳動建設IT基礎的一些思考。這些技術、這些實踐全部都會在火山引擎云產品中開放給我們的客戶，希望能夠幫助更多的企業，這樣也會產生更大的社會價值和商業價值。
