火山引擎是企業(yè)的數字化增長引擎

　　在開始分享之前，我先向大家介紹一下火山引擎。

　　火山引擎是字節(jié)跳動旗下的企業(yè)級技術服務平臺，是字節(jié)跳動技術團隊對外提供技術服務的統(tǒng)一窗口，我們希望通過火山引擎，把字節(jié)跳動的技術、產品和服務對外開放，包括云、AI、大數據、推薦等等，來幫助不同行業(yè)中的企業(yè)實現自身增長和數字化轉型。

　　大家知道，字節(jié)跳動內部一直在踐行技術中臺的技術文化。所以我們在做技術ToB過程中，也采取了這種機制，讓技術中臺直接實現自身產品的商業(yè)化。因此，火山引擎對外開放的技術和工具，與字節(jié)跳動技術中臺完全同源。比如說推薦，用的就是今日頭條、抖音的同款推薦平臺、工具和方法論。通過這種方式，我們可以把內部最好的能力對外進行服務。

　　這是火山引擎整體的產品技術體系，一共分為四層，分別是：統(tǒng)一基礎服務、技術中臺、智能應用和行業(yè)解決方案。這四層從下至上，分別滿足企業(yè)從運維、研發(fā)、產品、運營到營銷，在不同行業(yè)、不同業(yè)務場景下的需求。

　　這是過去一年里，我們不斷把字節(jié)跳動內部技術商業(yè)化后形成的結果，而在這個過程中我們一直在思考，字節(jié)跳動是怎么一步一步發(fā)展至今的，這背后支撐著業(yè)務快速發(fā)展的技術理念是什么？今天我想和大家分享下我的理解，我認為在這個過程中，有兩大理念非常重要，分別是：數據驅動、敏捷開發(fā)。

　　數據驅動：構建數據驅動的飛輪

　　首先和大家聊聊數據驅動。亞馬遜有一個著名的飛輪理論：一個公司各個業(yè)務模塊之間應當有機地組合，相互推動，就像是咬合的齒輪一樣。每一個飛輪從靜止到轉動起來需要花費力氣，但是由于他們組合在一起，所以每一圈的轉動都不會白費。一旦有一個齒輪轉動起來，整個系統(tǒng)都會跟著轉動，越轉越快。

　　構建數據驅動的飛輪

　　回到數據驅動這個話題，我們認為同樣如此。數據驅動不是一蹴而就的，不是用了一個工具，或者說建了幾張報表就做起來了，而是在整個過程中，不停地去解決一個個問題，最終形成多個體系，讓他自動轉起來，形成數據的飛輪效應。一旦飛輪效應形成，越到后面轉得越快。數據驅動就會成為日常內部協(xié)同的習慣，最終成為業(yè)務增長的源動力。

　　圍繞這一目標，我們可以把建設飛輪分為四個關鍵步驟，業(yè)務過程數字化、數字化協(xié)同、數據驅動業(yè)務優(yōu)化、客觀的分析評估。

　　這幾個步驟之間是一個有機推動的過程：

　　業(yè)務過程的數字化是第一步，也是非常關鍵的一步。業(yè)務過程的數字化越充分，對業(yè)務的描述就越精準，才能有利于后面步驟的展開。所以，我們需要不斷地將離線活動在線化，在線活動精細化，全部通過數字化的方式進行表達。

　　實現了業(yè)務過程的數字化之后，第二步就是數字化協(xié)同。第一要通過數據治理等手段讓底層數據得到規(guī)范、統(tǒng)一的表達。第二是要讓更多的人參與進來，所以需要通過數據可視化等工具讓不同的角色（開發(fā)人員、運營人員、使用人員、管理者等等）使用起來，加入數字化協(xié)同的過程。

　　數字化協(xié)同能力，最直接的影響是效率的提升。協(xié)同得越好，就能越及時、全面地獲取業(yè)務的認知，也就能在數據上更客觀地支持上層業(yè)務的優(yōu)化。

　　優(yōu)化的效果一定不是拍腦袋，也不是憑感覺，而是用客觀的分析評估。一方面，可以用A/B測試等方式通過數據來精準評估業(yè)務帶來的實際收益，另一方面，我們也要進一步多維度的關聯(lián)原因。

　　最后，走完這四步后，在業(yè)務優(yōu)化和評估過程中，我們又能沉淀更多的數據，這就形成了閉環(huán)，實現了飛輪的轉動。

　　剛剛是一個偏抽象的描述，下面我們再結合字節(jié)跳動的具體情況來看：

　　業(yè)務過程數字化，主要是對于不同觸點的數據埋點，比如APP、小程序、運營頁等等；

　　數字化協(xié)同，是多角色對數據應用的協(xié)同加工。比如研發(fā)如何做好數據開發(fā)、數據治理，運營更好更快的用好數據等；

　　數字驅動業(yè)務優(yōu)化，主要是根據數據，根據數據產生的insights，對產品、算法進行優(yōu)化，比如對推薦系統(tǒng)策略的優(yōu)化，面向不同用戶群體運營的優(yōu)化等；

　　客觀的分析評估，一方面通過A/B測試，對不同的、新的迭代進行客觀評估，另一方面則是通過ABI進一步地進行數據洞察，能夠積累對于的insights，從而促進整個流程的轉動。

　　這就是字節(jié)跳動構建整個數據驅動飛輪的過程，在這個過程中，我們把“業(yè)務過程數字化”、“數字化協(xié)同”、“客觀的分析評估”這三個沉淀下來，固化成數據中臺統(tǒng)一的能力，去支持不同應用的數據優(yōu)化，同時中臺能力，還能對業(yè)務不同維度，包括增長、體驗、變現等等實現進一步的優(yōu)化。

　　下面我們就數據中臺和應用優(yōu)化，進行展開。

　　面向應用的數據中臺

　　剛才其實也提到了數據中臺，它最大的一個作用是幫助各個應用、業(yè)務基于數據驅動進行優(yōu)化。所以做數據中臺有一個很重要的理念，那就是一定要面向應用來構建。從數據開始，用數據來做驗證。那么談到數據的驗證，那最重要的其實就是A/B測試。之前我們也在不同場合強調過字節(jié)對于A/B測試的重視，包括抖音、頭條的起名也是通過A/B測試得來的。

　　對于評估而言，測試只是第一步，我們還需要進一步對結果進行分析，因此構建了相應的數據運營平臺、智能數據洞察和客戶數據平臺等工具，幫助產品和運營可以深入分析數據。

　　而在底層，面向每天產生的大規(guī)模、批量、實時的數據，我們也建設了一套完整的數據采集、研發(fā)和治理的套件，提升數據開發(fā)的效率。

　　所以可以說在底層，我們更關注數據開發(fā)的效率和規(guī)模，而在上層，我們關注的是整個產品和運營在做數據分析過程中的易用性、可交互性。要實現易用性、可交互性和底層規(guī)模和效率的一個連接，我們需要一個非常強大的數據分析引擎，那就是我們的ByteHouse。

　　ByteHouse起源于開源的clickhouse項目，所以有了House的后綴。但它其實是根據字節(jié)跳動大規(guī)模數據場景，進行了非常多的需求改造，最終形成的一個云原生的大規(guī)模數據分析平臺。

　　剛剛提到，數據驅動是字節(jié)跳動的重要技術理念，每天我們有數十PB的新增數據，有數萬多人要從各種維度各種細節(jié)，對這些數據進行分析。這里面就有很多性能問題、實時問題需要解決，背后就是靠ByteHouse支持的。

　　目前為止，ByteHouse幾乎服務于字節(jié)內所有的業(yè)務線，也是ABI系統(tǒng)、UBA系統(tǒng)、畫像系統(tǒng)、A/B測試等分析系統(tǒng)的核心引擎。整體規(guī)模達到了三萬臺服務器，每天查詢有幾千萬次。

　　面對剛才說的大規(guī)模挑戰(zhàn)，我們在ByteHouse上主要做了五個層次的深度改造：

　　第一是支持流式數據。對分析而言，我們對實時性的要求非常高，所以我們通過Kafka支持了對實時數據的處理。這樣通過ByteHouse可以實現對實時和離線的數據提供統(tǒng)一的分析平臺，支持批流一體。

　　第二是計算和存儲的分離。因為我們的規(guī)模實在太大了，如何在數十PB新增數據基礎上，支持數萬人，高效快速地做千萬次的即時查詢，是一個很大的挑戰(zhàn)。通過計算和存儲的分離，我們能更好地解決性能問題。分離之后，計算層可以單獨地進行彈性的擴縮容。在存儲一塊，可以和分布式存儲系統(tǒng)進行對接，包括HDFS、S3等等。這樣一方面能解決存儲的穩(wěn)定性問題，另一方面也能解決擴容問題。

　　在計算和存儲的分離之外，我們在運維、安全方面做了很多工作，以進一步去彌補社區(qū)版本功能的缺失。

　　最后一個很重要的是我們做了多級的資源隔離。因為每天有不同的部門、角色在做各種各樣的分析，那么權限、時效性的要求都不一樣。那么通過租戶的隔離、讀寫的分離以及異構的計算資源，就能很好地滿足不同部門、不同角色在大規(guī)模集中式地使用資源分配的問題。

　　通過以上這五個大的層次上優(yōu)化，所以我們能夠基于ByteHouse去支撐起整個字節(jié)跳動數據驅動里的核心步驟。

　　剛才講了數據中臺的一些實踐，接下來再講講怎么去通過數據驅動來做應用和業(yè)務的優(yōu)化。這里以增長獲客來舉例。

　　當然不管是增長場景還是其他場景，如果要做好數據驅動優(yōu)化，首先最關鍵的就是設計好指標體系。因為指標不對，做的再多都是錯的。

　　那么對于增長而言，我們認為最重要的有兩個指標——「正向的投入產出」和「健康的用戶規(guī)模」。

　　正向的投入產出，簡單來說就是ROI>1。看起來非常簡單，但怎么把ROI算對、算準以及精細到每個用戶粒度跟進長期的 ROI，其實是難點和關鍵。

　　當然我們也不能只看短期的ROI，還要看長期的用戶的健康度，包括留存，LT等等。

　　設定了這些關鍵指標之后，其實就可以通過指標去找到對應的優(yōu)化增長策略。這個增長策略不僅要滿足指標的正向，同時也要具備可持續(xù)、可規(guī)模化、可復制的模式。這樣就把業(yè)務的增長模式轉化成了可衡量、可跟蹤的數據驅動模式。

　　最后用一張圖去完整地闡述數據驅動、基于中臺和應用優(yōu)化，來構建整體飛輪的案例。

　　首先基于數據做用戶定向，定義好目標，找到對產品最關鍵的人群；

　　找到之后，去做對應的創(chuàng)意、內容，然后讓這些最優(yōu)質最吸引的內容在不同渠道觸達到客戶，形成轉換并產生新的數據。而且我們有數字化記錄的過程，能夠準確地歸因，精細化地追蹤效果；

　　在優(yōu)化過程中，會有很多創(chuàng)意。我們通過A/B測試高速迭代，看看哪個創(chuàng)意更合適。而在評估的過程中，也會出現更多的數據，從而又補充了整個策略方案，最終就形成一個數據驅動的增長飛輪。

　　在這樣的過程里面，實驗的速度是非常關鍵的。如果別人一天只能做10個實驗，你能做100個，那結果不言而喻。小到創(chuàng)意的實驗，大到APP功能的迭代開發(fā)，速度在里面都起到非常大的作用。而這就呼應了我想講的第二個理念，敏捷開發(fā)。

　　敏捷開發(fā)：全棧云原生架構支撐大規(guī)模應用

　　說到敏捷開發(fā)，我們可以看到市面各種各樣不同層次的解決方案，比如說低代碼，aPaaS等等。不過今天主要想和大家聊的還是云原生這塊，因為無論是SaaS層還是PaaS層的方案，在底層都離不開一整套云原生架構的支持。

　　字節(jié)跳動全棧云原生化架構

　　這里也簡單回顧下云基礎技術的發(fā)展歷史，相信很多人也比較熟悉這段軌跡了。可以看到，13年是一個重要的拐點。13年之后，隨著Docker、K8s等技術的興起和普及，云從以基礎設施為中心，走向以應用為中心；從資源服務化走向平臺服務化，而字節(jié)跳動剛好誕生在2012年，因此非常幸運沒有什么歷史包袱，直接擁抱了最新的云原生技術。

　　給大家分享一組數字（2021年2月份統(tǒng)計）：字節(jié)跳動內部業(yè)務中，服務器的節(jié)點數近百萬；同時在線的微服務數有8w+，并且在以每月2000的數量增長；容器數750w+；每日新增量60多PB。

　　從這些數字大家也可以看得出，我們面臨的是一個非常大規(guī)模的，而且還在不斷快速上漲的服務體量的挑戰(zhàn)。所以從基礎架構的視角，我們認為有三個方面的問題需要考慮：

　　第一是如何支撐海量服務。隨著應用微服務化，治理對象由單體應用轉變?yōu)閿盗扛嫶蟮奈⒎眨@導致全局治理難度更加大，包括構建全局的配置中心以及更靈活的全局網絡、運行時的選擇、配備完善的安全機制，以及如何端到端的和整個DevOps流程進行打通。

　　第二是在大規(guī)模調度運維下的挑戰(zhàn)，如何讓基礎設施更加穩(wěn)定。目前內部平均單集群規(guī)模是5000多節(jié)點，大的集群有數萬臺。在這么大體量的情況下，需要考慮各種各樣的問題，比如在大規(guī)模鏡像分發(fā)的場景下，怎么做鏡像預熱、多集群的聯(lián)邦管理的問題；在弱網環(huán)境下，云邊協(xié)同的問題；在異構的環(huán)境下，機器學習的場景里面的GPU調度問題。

　　第三，是在線/離線的混部。因為這么大的規(guī)模，成本自然也很大，所以我們要做好利用率的提升。在線/離線的混部是非常重要的手段。特別是字節(jié)跳動業(yè)務本身，其實波峰和波谷都很明顯。比如抖音高的峰值就在晚上，其他時候的QPS就沒有這么高。所以我們設計了一套在線/離線混部的機制，一方面可以降低成本，一方面能夠更好地應對極端情況下業(yè)務規(guī)模增長的難題。

　　同時，在底層，我們還構建了一個容器+多云的整體解決方案。

　　在多云方面，我們不僅計算能夠做到多云，有狀態(tài)的存儲也能夠做到多云，這樣我們就能夠非常靈活的去應對各種的突發(fā)情況，比如年初的春晚搶紅包，以及818新潮購物節(jié)等等。

　　這張圖從架構體系角度，進一步來闡釋全棧云原生的體系結構。

　　首先在最底層，是一套完整的云原生基礎設施。通過統(tǒng)一的底層去提供新一代的高性能計算存儲和網絡的解決方案，這其實是保證業(yè)務穩(wěn)定和敏捷的基石。

　　在云原生基礎之上是服務平臺層，它要解決的是業(yè)務開發(fā)中的一些通用平臺和服務能力的抽象。這里面包含了高性能的微服務框架、基于服務網格的微服務治理能力，以及Serverless、邊緣計算平臺的能力。服務平臺構建就是為了讓開發(fā)人員更敏捷、專注地開發(fā)業(yè)務邏輯，而能更少地考慮資源、平臺、服務間通信和治理。

　　在平臺層之上是整個研發(fā)體系的構建。這一層我們是希望通過各種各樣的工具、流程機制和組織，能夠去幫字節(jié)跳動靈活地支撐全部業(yè)務線的快速開發(fā)和開發(fā)管理工作。

　　這中間三層設施的兩邊是重要的云原生安全體系和SRE服務支撐體系。

　　第一個是云原生安全的體系。那么相比傳統(tǒng)的安全體系，它要做到不同層次的延伸，一個是左延，不僅關注運行時的安全，我們也需要和DevOps的流程結合在一起，去關注應用整個生命周期的安全。第二個就是下延，不僅只關注到容器的安全，還要關注到主機的安全。

　　第二個就是SRE體系，它來支撐整個業(yè)務高速發(fā)展過程中的穩(wěn)定性。

　　因為時間有限，我挑了兩個比較有意思的話題來進一步的分享。一個是微服務，一個是移動開發(fā)。一方面比較有代表性，另一方面這兩者覆蓋了大部分業(yè)務研發(fā)的場景。

　　服務器端——微服務、服務治理與DevOps

　　首先來看微服務。我們可以用四個點來形容字節(jié)跳動微服務的現狀：

　　規(guī)模龐大且增長迅速。剛才介紹過字節(jié)跳動現在的微服務數是8萬，但在2018年，整個微服務數大概只有7000到8000，所以三年其實翻了近10倍，并且還在不斷的增長。在這個過程中，我們自然遇到了非常多的挑戰(zhàn)。

　　在線微服務超過90％都運行在容器里。對于業(yè)務線，是看不到資源的，看到的只是PaaS、容器。這帶來很多便利性，有利于新技術的核心功能推廣，但同時也有很多挑戰(zhàn)，尤其是調度復雜性這方面。

　　技術體系以Golang語言為主。根據最新的調查統(tǒng)計，字節(jié)跳動內部Golang是主要語言，超過55％的服務都采用了Golang，排名第二的語言是NodeJS，然后是其他的語言。

　　Service Mesh的全面落地和應用。字節(jié)跳動是國內最早在生產環(huán)節(jié)大規(guī)模使用Service Mesh的公司之一。

　　大家可以發(fā)現整個字節(jié)跳動在微服務的使用上是非常快的，甚至可以說是比較激進的。這背后，是因為在字節(jié)跳動，速度和效率是我們研發(fā)要解決的Top1問題。每天新應用和新用戶增長都非常快，研發(fā)必須要解決好產能問題。這也是我們激進地采取微服務架構的原因。但這么大的規(guī)模下，做這么快的迭代，自然會對穩(wěn)定性、信任帶來非常大的沖擊。

　　為了應對這些困難和矛盾，我們在端到端落地微服務架構時，針對性地做了各項優(yōu)化：

　　首先是語言層面，Golang是主力使用的語言，因此在Golang層面做了很多框架層面的優(yōu)化，比如RPC框架、HTTP框架。這些框架我們已經通過開源的方式回饋到社區(qū)——9月初，字節(jié)跳動開源CloudWeGo，幫助更多開發(fā)者搭建云原生微服務架構。

　　第二則是針對海量服務的治理，我們基于ServiceMesh的概念構建了自己的服務網格體系，將服務治理的能力固化到字節(jié)內部平臺上，一方面幫助我們多元多服務的兼容問題，另一方面通過Golang穩(wěn)定的框架和以Mesh治理為基礎的理念，我們實現了全局流量的治理、單元化和體系化的整體建設。

　　最后是通過落地和實踐DevOps工具和方法來提升研發(fā)的效率，進一步提升運維的可觀測性。

　　下面我們就一個個展開。

　　首先是Golang框架這塊，一個是Kitex，這是RPC的框架。另一個是Hertz，是HTTP的框架。這些框架背后集成了我們自研的高性能的網絡庫，去解決網絡上的一些性能、交互上的問題。同時我們支持多消息協(xié)議（Thrift/Protobuf）和多交互方式（Ping-Pong/Oneway/Streaming），能提供更加靈活自主的代碼生成器。

　　這是Kitex和gRPC性能的對比，我們選了兩組，分別是基于Thrift和Protobuf協(xié)議的對比。可以看到在兩種方式下，Kitex都有比較好的性能表現。特別是在在TP99延遲上，隨著并發(fā)連接數的增大，Kitex表現出的優(yōu)勢是越來越大。

　　這是Hertz和業(yè)界一些框架的對比，包括平均時延、QPS，以及在不同Size包的情況下的對比結果。這兩個框架我們現在都通過開源的方式在對外提供，所以歡迎各位開發(fā)者去下載使用，和我們交流，提供意見。

　　接下來我們看服務網格的治理。剛才談到過因為本身的業(yè)務類型、業(yè)務體量，所以我們在實踐微服務的架構中，面臨著非常多挑戰(zhàn)，比如語言碎片化、服務異構、協(xié)議異構，還有安全、可觀測性、問題追查調用等等。所以我們采取了基于服務網格模式，來進行整體的微服務治理。

　　上圖綠色方框是控制面，虛框是數據面。我們通過服務網格將控制平面和數據平面進行了分離，消除了單點故障的可能。比如當數據平面流量過大出現性能問題時，就不會影響到控制平面的路由策略；反過來也是，當控制平面策略負載過重時也不會影響數據平面的轉發(fā)。

　　圖中每個虛框是一個pod，與傳統(tǒng)的服務相比，我們的服務網格是通過sidecar方式進行流量治理，比如熔斷、限流、超時重試、降低等，把這些功能從每個服務中剝離出來形成一個代理，通過這些代理實現服務間的治理。這樣的好處是能夠讓每個服務只關注自己的業(yè)務邏輯，不需要管全局的調度和通訊問題，讓開發(fā)更簡單、高效。

　　當然這種ServiceMesh無侵入性的模式帶來了很多便利，但是實際上也帶來了很多挑戰(zhàn)。最大一個挑戰(zhàn)就是額外的性能開銷，所以我們做了大量的工作去解決服務網格的極致性能優(yōu)化。這樣的一個優(yōu)化是多個層次的：

　　在網絡和內核層面，我們用共享內存或者系統(tǒng)調用的方式來實現真正的zero copy。

　　也會在基礎庫、組件架構層面的優(yōu)化，去除一些不必要的交互。甚至在編譯階段，我們通過更好的全靜態(tài)的編譯，不需要任何代碼的修改，就能夠獲得2%左右的性能提升。

　　最終通過這種整體的、多層次的組合優(yōu)化，我們既享受到了服務網格帶來的便利，也保證了性能。

　　移動端——極致體驗的移動APP研發(fā)

　　剛才講的是微服務框架和服務治理的內容，接下來我們再來說一說移動開發(fā)。

　　對于字節(jié)來說，可以算是一個移動原生的企業(yè)，我們絕大部分的業(yè)務也都是通過APP在承載的。截止目前，我們已經運營超過100款APP，公司內部也有數千人的移動應用研發(fā)團隊。

　　要支撐如此大規(guī)模的研發(fā)團隊和對應業(yè)務的發(fā)展，我們必須建立一套行業(yè)領先的移動應用開發(fā)平臺，并且要通過大量的實踐和各種極端場景的打磨來不斷優(yōu)化。因此我們很早就建立了公司級的移動研發(fā)平臺，代號：MARS，通過它來統(tǒng)一支撐上層各個業(yè)務應用的開發(fā)工作。如今大家在用的抖音、頭條等APP都是基于MARS進行開發(fā)和迭代。

　　從層次角度，MARS整體可以分為5個板塊：

　　首先是項目管理，通過抽象字節(jié)內部的研發(fā)特點，我們建立了統(tǒng)一的項目管理平臺用于支撐日常業(yè)務迭代管理，特別是發(fā)版等特殊流程的優(yōu)化。

　　其次在應用開發(fā)環(huán)節(jié)，這一步效率是很關鍵的，我們針對效率采用低代碼的方式來進行進一步的提升。比如針對設計人員提供了通過設計直接生成代碼的方式。對于運營人員、研發(fā)人員，我們采取了這種可見即可得的方式，通過拖拉拽去幫助業(yè)務人員能更容易更便捷地構建業(yè)務應用。

　　然后面向傳統(tǒng)的編碼和研發(fā)階段，我們面向APP、前端以及小程序等不同的端都輸出了一套完整的端到端的開發(fā)平臺。

　　另外在質量管控，我們也提供了一站式全鏈路測試平臺，基于海量真機真實模擬線上實際場景，最大限度檢測潛在異常。

　　最后是全鏈路監(jiān)控平臺，能夠覆蓋“終端-網絡-后臺應用-基礎環(huán)境”的完整應用鏈路監(jiān)控，幫助研發(fā)人員精準定位問題，解決問題。

　　通過以上對微服務、移動開發(fā)平臺Mars的介紹，我想大家對字節(jié)跳動敏捷開發(fā)應該有了一個更生動的認識。

　　回到今天分享的主題，在整個字節(jié)技術發(fā)展的背后，數據驅動和敏捷開發(fā)是兩個重要的理念，但這兩個理念并不是割裂的，二者是一體的。因為對于數據驅動而言，我們需要有更多的實驗，來找到好的方案進行推廣，找到不好的點進行改進。而敏捷開發(fā)就能保證每天都有大量的實驗能夠進行。反過來通過數據驅動，我們又能夠去找到里面有價值的東西，同時也能沉淀更多的數據，這樣就構建了整個業(yè)務高速發(fā)展的閉環(huán)。

　　這里也分享一些數據，在字節(jié)跳動內部，我們每天新上的實驗有1500個，實驗總量有80多萬個，同時運行的實驗有1萬多個，覆蓋了內部500多個業(yè)務線以及各種各樣的場景。包括個性化的場景、推送的場景、建站的場景、服務端的場景、廣告營銷的場景等等。

　　而我們底層的技術、平臺的技術，還有業(yè)務層的技術，也正是因為這兩個理念在不斷的積累和迭代，最終去推動業(yè)務的高速發(fā)展。

　　其實道理非常簡單，就像大家說天下武功唯快不破一樣，道理都是很簡單的道理，但是要做好這些事情的背后，我們需要工具平臺和方法的不斷積累，以及把這些方法形成日常的習慣，最終形成業(yè)務推動的原動力。

　　以上就是我對字節(jié)跳動在數據驅動、敏捷開發(fā)兩方面技術實踐的概括與分享。希望對大家有所啟發(fā)。里面提到的很多技術，基本都在火山引擎上實現了對外產品化，也非常期待大家能使用這些產品，反饋意見，創(chuàng)造更大價值。

　　謝謝大家！