今天不談DevOps的開(kāi)源技術(shù)工具鏈，而是從敏捷開(kāi)發(fā)和研發(fā)過(guò)程效能改進(jìn)的角度再來(lái)回顧下DevOps研發(fā)運(yùn)維一體化和研發(fā)效能改進(jìn)。

在前面我專(zhuān)門(mén)寫(xiě)過(guò)一篇文章，里面有個(gè)核心觀點(diǎn)，即：

不要期望通過(guò)DevOps各種工具鏈技術(shù)來(lái)解決研發(fā)效能和過(guò)程管理中存在的問(wèn)題，研發(fā)效能提升有一個(gè)核心還是軟件工程域和過(guò)程管理最佳實(shí)踐。

敏捷和精益各在強(qiáng)調(diào)什么？

大家對(duì)敏捷方法論都比較熟悉，特別是當(dāng)前主流的Scrum敏捷研發(fā)方法論。而敏捷方法論的核心如果用一個(gè)詞就是短周期迭代。

為了短周期迭代，你必須將大塊的用戶需求輸入進(jìn)行拆解為條目化的UserStory，為了確保迭代版本可交付，你需要持續(xù)集成，可視化進(jìn)度看板等。通過(guò)短周期迭代，你具備了一個(gè)關(guān)鍵的敏捷能力，即快速地適應(yīng)變化和自我調(diào)整能力。

敏捷得快，一個(gè)是響應(yīng)變化快，一個(gè)是自身的生產(chǎn)加工過(guò)程也快，效率高。所以你看到在軟件研發(fā)過(guò)程中各種自動(dòng)化工具的引入，自動(dòng)化的流水線，持續(xù)集成等實(shí)際都是提升這個(gè)效率服務(wù)。

再回來(lái)看精益，精益的一個(gè)核心是減少浪費(fèi)。

而軟件開(kāi)發(fā)過(guò)程中的浪費(fèi)實(shí)際體現(xiàn)在幾個(gè)方面。

其一是減少任何不必要的輸出工件，所有的工件輸出本身都要有價(jià)值，不要為了輸入而輸出，為了文檔而文檔。要提倡源代碼就是文檔。

其二是減少返工，所有的返工，不論是需求變更引起的，還是Bug修改等，都是COPQ壞質(zhì)量成本，都是對(duì)資源的極大浪費(fèi)，同時(shí)又拉長(zhǎng)了交付周期。

其三是減少人員等待，任何一個(gè)研發(fā)項(xiàng)目和研發(fā)過(guò)程，如果你在整體計(jì)劃和任務(wù)分解中，導(dǎo)致出現(xiàn)了大量的人員閑置和等待，那么本身就是一種巨大的浪費(fèi)。

對(duì)于第三點(diǎn)減少人員等待或閑置本身是一個(gè)技術(shù)活，考驗(yàn)的是項(xiàng)目經(jīng)理或架構(gòu)師的任務(wù)分解能力，如何通過(guò)恰當(dāng)?shù)慕巧止ず腿蝿?wù)分解，能夠讓所有的人員并行工作，并減少相互之間的依賴(lài)。

推式生產(chǎn)和拉式生產(chǎn)，流水線和看板

在談敏捷和精益生產(chǎn)的時(shí)候，經(jīng)常會(huì)談到看板文化，基于用戶和市場(chǎng)需求的拉式生產(chǎn)模式。看板解決了一個(gè)關(guān)鍵的可視化和進(jìn)度跟蹤問(wèn)題。而拉式生產(chǎn)模式解決了零庫(kù)存和減少浪費(fèi)的問(wèn)題。

回到敏捷研發(fā)和看板，也是同樣的道理。

敏捷團(tuán)隊(duì)中的每一個(gè)人實(shí)際都應(yīng)該時(shí)刻知道我有哪些todo list，我需要做的就是將我待辦的任務(wù)按規(guī)范和質(zhì)量要求盡快做完，并快速地朝下游傳遞。比如一個(gè)開(kāi)發(fā)人員應(yīng)該隨時(shí)能夠看到自己的待辦清單。有哪些功能點(diǎn)要開(kāi)發(fā)，有哪些Bug要修改等。

對(duì)每個(gè)角色都是，我只需要關(guān)注我的todo，并盡快完成。

任何一個(gè)任務(wù)在上游角色完成相關(guān)工作后，通過(guò)流水線都能夠做到自動(dòng)化地推送到下游活動(dòng)節(jié)點(diǎn)。這個(gè)節(jié)點(diǎn)可以是自動(dòng)化機(jī)器節(jié)點(diǎn)，也可以是需要人工進(jìn)入處理的工作節(jié)點(diǎn)。

流水線起到的關(guān)鍵作用就是基于上下游的任務(wù)活動(dòng)協(xié)同關(guān)鍵，將多個(gè)任務(wù)編排為一個(gè)完整的整體，并做到自動(dòng)化或半自動(dòng)化執(zhí)行，同時(shí)隨時(shí)可以監(jiān)控其進(jìn)度和狀態(tài)。

那么流水線的效率體現(xiàn)在哪里？

流水線的效率不僅僅體現(xiàn)在自動(dòng)化的程度，而是體現(xiàn)在流水線運(yùn)行過(guò)程中各種閑置或等待時(shí)間的多少。比如一個(gè)開(kāi)發(fā)過(guò)程流水線，到了開(kāi)發(fā)階段后開(kāi)發(fā)人員始終都無(wú)事可做而處于等待狀態(tài)，那么流水線效率就不可能高效。

所以再回顧下DevOps流水線。

代碼Checkin-》編譯-》構(gòu)建-》打包部署-》環(huán)境遷移

這個(gè)并不是一個(gè)完整的開(kāi)發(fā)過(guò)程流水線，因?yàn)檫@個(gè)流水線并沒(méi)有體現(xiàn)需求人員，開(kāi)發(fā)人員，測(cè)試人員的任務(wù)和活動(dòng)。

完整的研發(fā)流水線一定是自動(dòng)化+人工參與結(jié)合的一個(gè)大流水線。實(shí)現(xiàn)從用戶需求進(jìn)來(lái)，到最終完成IT應(yīng)用的功能交付的完整過(guò)程。

這里面不是簡(jiǎn)單地持續(xù)集成，重點(diǎn)是架構(gòu)，開(kāi)發(fā)，測(cè)試，工程運(yùn)維人員之間的高效協(xié)同，同時(shí)在協(xié)同過(guò)程中如何建設(shè)依賴(lài)。

從條目化需求到文檔結(jié)構(gòu)化

在Scrum敏捷方法論里面，條目化始終是一個(gè)重點(diǎn)強(qiáng)調(diào)的內(nèi)容。

條目化本身就意味著更好的結(jié)構(gòu)化。

敏捷方法論過(guò)程改進(jìn)，最好的思路就是所有文檔都要結(jié)構(gòu)化和條目化掉，而不是再去輸出冗長(zhǎng)非結(jié)構(gòu)化的word文檔。

我們都知道在軟件開(kāi)發(fā)中的需求文檔往往是Word形式的非結(jié)構(gòu)化內(nèi)容，一個(gè)需求文檔往往會(huì)實(shí)現(xiàn)多個(gè)用戶需求并分解為多個(gè)用例，由于沒(méi)有結(jié)構(gòu)化我們管理和變更的單元都將是以一份文檔為準(zhǔn)。而現(xiàn)在結(jié)構(gòu)化的文檔開(kāi)發(fā)工具可以使文檔開(kāi)發(fā)工作結(jié)構(gòu)化，通過(guò)結(jié)構(gòu)化后可以對(duì)文檔的管理顆粒度粒度從一個(gè)Word文件喜歡到一個(gè)具體的用例或用戶故事，而這不僅僅是帶來(lái)了版本控制和多人文檔協(xié)作的方便，更重要的是文檔開(kāi)發(fā)過(guò)程的一個(gè)重要變更。

在軟件開(kāi)發(fā)中需求的端到端管理中，我們對(duì)用戶需求，產(chǎn)品需求，軟件需求都可以拆分為條目化管理，并且實(shí)現(xiàn)條目化需求的狀態(tài)跟蹤和需求追蹤。通過(guò)需求追蹤保證需求實(shí)現(xiàn)的完整性，方便跟蹤需求實(shí)現(xiàn)狀態(tài)，同時(shí)為后續(xù)的需求變更分析提供有利的影響范圍識(shí)別。

需求可以條目化，測(cè)試用例也可以條目化，比較困難的就是設(shè)計(jì)內(nèi)容如何進(jìn)行條目化管理。架構(gòu)設(shè)計(jì)的內(nèi)容放到哪個(gè)層次和級(jí)別。在微軟的SCRUM實(shí)踐里面我們也看到了通過(guò)UserStory驅(qū)動(dòng)的需求跟蹤和管理。為了方便條目化我們又可以解決FDD里面的最佳實(shí)踐通過(guò)領(lǐng)域模型分析找出具體的特征點(diǎn)，而特征點(diǎn)就是一個(gè)細(xì)粒度的可以從需求一直管理到測(cè)試的最小單位。我們的實(shí)現(xiàn)過(guò)程追蹤，狀態(tài)跟蹤，版本管理和控制都可以以這個(gè)為單位進(jìn)行管理。這樣在我們實(shí)現(xiàn)的過(guò)程中，在關(guān)心某一個(gè)具體的功能點(diǎn)的時(shí)候很容易的就能夠獲取到有關(guān)該功能點(diǎn)從頭到尾的全部信息，包括每次變更的相關(guān)信息也可以很容易獲取到。

當(dāng)我們向客戶按階段交付文檔的時(shí)候如何處理呢？這個(gè)其實(shí)在結(jié)構(gòu)化文檔開(kāi)發(fā)工具里面已經(jīng)有了，即可以根據(jù)我們的不同配置規(guī)則，根據(jù)預(yù)定的文檔生成格式，自動(dòng)的抽取相應(yīng)的內(nèi)容來(lái)生成出我們需要的文檔。可以看到在整個(gè)過(guò)程中我們不會(huì)再去專(zhuān)門(mén)強(qiáng)調(diào)文檔這個(gè)概念，而是更加強(qiáng)調(diào)業(yè)務(wù)功能和用例，特征值和需求管理和跟蹤的概念，文檔僅僅是我們?cè)诟鱾€(gè)階段思考過(guò)程的一種記錄后的整合，我們隨時(shí)的思考和實(shí)現(xiàn)思路都應(yīng)該隨時(shí)的記錄，而不是到后面再來(lái)補(bǔ)文檔。

我們可以看到，現(xiàn)在一些SCRUM的敏捷項(xiàng)目管理工具已經(jīng)具備了結(jié)構(gòu)化的UserStory管理和跟蹤的能力，而這正是結(jié)構(gòu)化文檔開(kāi)發(fā)的一個(gè)雛形。

即不再依賴(lài)word去輸出需求文檔，而是應(yīng)該直接在敏捷研發(fā)和過(guò)程管理工具中編寫(xiě)每一個(gè)userStory，對(duì)其業(yè)務(wù)場(chǎng)景，流程，規(guī)則，界面UI等進(jìn)行詳細(xì)說(shuō)明。當(dāng)然從一個(gè)大IT系統(tǒng)構(gòu)建的整體性層面，我們?nèi)匀粫?huì)保留少量的整體業(yè)務(wù)流程，整體架構(gòu)方面的介紹。

那么如果最終需要向客戶交付完整的需求文檔如何辦？

簡(jiǎn)單來(lái)說(shuō)應(yīng)該是我們選擇需要交付的模塊和功能點(diǎn)，然后通過(guò)勾選的內(nèi)容自動(dòng)化的生成最終的word文檔。也就是最終交付的文檔應(yīng)該是通過(guò)配置的方式動(dòng)態(tài)生成的。

從產(chǎn)品結(jié)構(gòu)，WBS分解到任務(wù)活動(dòng)

我們可以回顧下一個(gè)微服務(wù)架構(gòu)下前后端分離開(kāi)發(fā)模式，任何一個(gè)需求點(diǎn)過(guò)了，實(shí)際都可以分解為如下幾個(gè)任務(wù)。

• 需求和原型開(kāi)發(fā)
• 前端開(kāi)發(fā)
• 后端開(kāi)發(fā)和數(shù)據(jù)庫(kù)設(shè)計(jì)
• 測(cè)試設(shè)計(jì)
• 測(cè)試執(zhí)行

如果你是用的傳統(tǒng)開(kāi)發(fā)模式，那么可能分解為如下幾個(gè)任務(wù)：

• 需求開(kāi)發(fā)和文檔編寫(xiě)
• 功能設(shè)計(jì)和數(shù)據(jù)庫(kù)設(shè)計(jì)
• 編碼和自測(cè)
• 測(cè)試設(shè)計(jì)
• 測(cè)試執(zhí)行

什么意思呢？

對(duì)于一個(gè)條目化的需求自然會(huì)對(duì)應(yīng)到相應(yīng)的需求開(kāi)發(fā)，設(shè)計(jì)，編碼和測(cè)試等任務(wù)。對(duì)于PBS產(chǎn)品結(jié)構(gòu)分解處理的最底層的模塊或單元結(jié)合WBS模板都會(huì)產(chǎn)生這些WBS條目。

這就是一個(gè)簡(jiǎn)單的交叉相乘的過(guò)程。

1. 對(duì)于總體設(shè)計(jì)任務(wù)不需要根據(jù)具體的模塊和單元進(jìn)行分解。
2. 對(duì)于集成測(cè)試任務(wù)如何來(lái)產(chǎn)生的問(wèn)題

解決了以上兩個(gè)問(wèn)題，基本上就可以自動(dòng)生成相應(yīng)的WBS。而且我們還可以根據(jù)過(guò)程定義和裁剪來(lái)選擇哪些條目應(yīng)該生成，哪些不應(yīng)該生成。比如可以裁剪掉單元測(cè)試，則就不自動(dòng)生成相應(yīng)的單元測(cè)試任務(wù)?；谝陨峡紤]可以參考下圖的例子，左邊為WBS模板，右邊為一個(gè)簡(jiǎn)單的PBS分解。

其中PBS中黃色的為最底層的模塊或單元，都需要和左邊的WBS模板相乘得到相應(yīng)的WBS條目。對(duì)于集成測(cè)試任務(wù)的生成，可以看到滿足存在葉子節(jié)點(diǎn)，且葉子節(jié)點(diǎn)大于1個(gè)的都需要生成集成測(cè)試任務(wù)。因此根據(jù)該方式可以生成如下實(shí)際的WBS分解

同時(shí)在生成的過(guò)程中我們還可以建立根據(jù)生命周期模型建立WBS條目任務(wù)之間的關(guān)聯(lián)和依賴(lài)關(guān)系，設(shè)置每各WBS條目的類(lèi)型。模板化每個(gè)條目和任務(wù)的輸出格式，責(zé)任人等內(nèi)容。

在實(shí)現(xiàn)了這一個(gè)步驟后，我們接著可以考慮的問(wèn)題就是受崗位角色分工和資源約束限制條件下的自動(dòng)排程。在供應(yīng)鏈管理中我們可以通過(guò)建立模型和目標(biāo)約束來(lái)實(shí)現(xiàn)最優(yōu)的排程，在軟件項(xiàng)目進(jìn)度計(jì)劃的編制中應(yīng)該同樣是可以的，這種方式將通過(guò)約束理論，目標(biāo)規(guī)劃和計(jì)算機(jī)模型來(lái)選擇可行的進(jìn)度方案。而不是根據(jù)簡(jiǎn)單的根據(jù)關(guān)鍵路徑和資源平衡來(lái)制定進(jìn)度。

以上自動(dòng)生成規(guī)則并不復(fù)雜，但是當(dāng)前的各類(lèi)Scrum敏捷項(xiàng)目管理工具往往并不支持這種自動(dòng)化生成規(guī)則。

編輯導(dǎo)語(yǔ)：結(jié)合敏捷項(xiàng)目管理，產(chǎn)品經(jīng)理或業(yè)務(wù)人員可以一定程度上推動(dòng)項(xiàng)目的快速運(yùn)行，實(shí)現(xiàn)降本增效，并推動(dòng)后續(xù)項(xiàng)目的優(yōu)化迭代。那么，若想實(shí)現(xiàn)敏捷項(xiàng)目管理，你應(yīng)當(dāng)具備哪些思維方式、或者拿出什么舉措？本文作者做了相應(yīng)解讀，一起來(lái)看。

一、什么是敏捷項(xiàng)目管理

敏捷管理如果用一句話高度概括就是：面對(duì)高度不確定的事件，思維、行動(dòng)，快速反應(yīng)、快速應(yīng)對(duì)，并作出正確選擇的行為，稱(chēng)之為敏捷。

如果再精煉的概括一下，那就是“對(duì)、好、快”。PO確保做對(duì)的事，SM負(fù)責(zé)快速推進(jìn)，DT保證正確地做事。

二、敏捷管理都有哪些具體措施

1. 思維方式的徹底轉(zhuǎn)變

實(shí)施敏捷管理前，最重要的一步就是給大家“洗腦”，讓大家從傳統(tǒng)的開(kāi)發(fā)模式上徹底轉(zhuǎn)變到敏捷思維的開(kāi)發(fā)模式中，只要先從思想上進(jìn)行徹底改變，才能在日后的身體力行中去積極實(shí)踐。

而轉(zhuǎn)換思維，就先要讓大家深刻理解敏捷的價(jià)值觀，而敏捷價(jià)值觀就是：

大家可能覺(jué)得這個(gè)敏捷價(jià)值觀有點(diǎn)“混沌”，我給大家翻譯一下，大家就一目了然了。

第一條，敏捷管理注重以人為本，因?yàn)槿瞬攀钦麄€(gè)項(xiàng)目的核心“資產(chǎn)”。二戰(zhàn)時(shí)，為什么美國(guó)從歐洲瘋狂搶人才？蘇聯(lián)解體時(shí)，為什么中國(guó)從烏克蘭瘋狂搶各類(lèi)技術(shù)人才？都是這個(gè)道理，因?yàn)橛辛巳瞬?，才有辦好事的“源動(dòng)力”。

第二條，可用的軟件是指交付物，意思是說(shuō)我們最終交付給客戶的東西必須是高價(jià)值，有用的。如果竟是“反人類(lèi)”的操作，文檔寫(xiě)的再好又有什么軟用？

第三條以客戶為中心，這句話就很講究了，為什么不是以用戶為中心？因?yàn)槊艚莨芾硭枷氲耐瞥?，是建立在B端的甲乙雙方這個(gè)邏輯框架下的（當(dāng)然有些內(nèi)容也適合C端）。

在B端市場(chǎng)中，很多能拍板買(mǎi)你軟件的和最終使用你產(chǎn)品的是兩波不同的人。我們軟件開(kāi)發(fā)要優(yōu)先滿足“客戶”，再去滿足“用戶”。如果你設(shè)計(jì)了一個(gè)讓用戶很爽的功能，到時(shí)候客戶不滿意，那恐怕到時(shí)候回款的時(shí)候就懸了。

舉個(gè)最簡(jiǎn)單的例子，你給甲方爸爸開(kāi)發(fā)了一個(gè)企業(yè)內(nèi)部的IM，老板要求顯示員工已閱信息，但是你為了尊重用戶個(gè)人隱私生活空間，就沒(méi)有這個(gè)功能，那老板心里肯定不舒服，以后合同還怎么續(xù)簽。

第四條，擁抱變化我就不細(xì)講了，這個(gè)世界唯一不變的就是“變化”。

除此之外，我們?cè)诮窈蟮男惺逻^(guò)程還要遵循敏捷的12條原則，具體見(jiàn)下圖：

你可能看后，第一感覺(jué)就是：WTF，東一榔頭，西一棒槌的，說(shuō)的什么玩意，雖然列了1234，但還是感覺(jué)沒(méi)有邏輯感。

沒(méi)錯(cuò)，當(dāng)時(shí)我就是這個(gè)感覺(jué)。為了能夠讓大家能夠把他嚼碎了往肚里咽，我給大家做了一下抽象概括和歸納總結(jié)。其實(shí)12條原則這么多話，概括起來(lái)就是一句話（我最煩那種簡(jiǎn)單問(wèn)題復(fù)雜化的人）：

以人為本，高效溝通，以目標(biāo)為導(dǎo)向，不斷自我進(jìn)化，通過(guò)快速迭代的形式為客戶交付高價(jià)值的軟件。

具體我是怎么抽象概括起來(lái)的，還要?dú)w結(jié)于歸納法，看似他把事情說(shuō)了那么多多，但是好多東西都是同一個(gè)主題，具體如下：

歸納完我們發(fā)現(xiàn)，說(shuō)了一大通，原來(lái)就是在敏捷價(jià)值觀中加了“高效溝通、自我進(jìn)化、快速迭代”。這樣一梳理就簡(jiǎn)單明了多了（感覺(jué)哥這總結(jié)能力，可以裸考ACP了-捂臉）。

2. 構(gòu)建敏捷管理團(tuán)隊(duì)

敏捷管理團(tuán)隊(duì)的構(gòu)建有點(diǎn)像管理學(xué)中，變“直線式管理” 為 “矩陣式管理”的意思。

之所以要構(gòu)建敏捷的管理團(tuán)隊(duì)，就是要幫助團(tuán)隊(duì)去除“政治化、部門(mén)墻”等障礙，從而實(shí)現(xiàn)扁平管理，高效溝通的目標(biāo)。其中最好的形式就是構(gòu)建一個(gè)10人內(nèi)的小組，把大家的座位集合到一起，方便日常面對(duì)面的溝通與協(xié)調(diào)，從而免去過(guò)往冗長(zhǎng)的各種流程。

3. 實(shí)施增量式迭代開(kāi)發(fā)

我們拿造汽車(chē)舉例說(shuō)明一下增量式思維和增量迭代式思維的區(qū)別。傳統(tǒng)的開(kāi)發(fā)模式都是增量式思維，這次交付一個(gè)輪子，下次交付一個(gè)車(chē)身等等，每一次交付的東西都不能直接滿足用戶的交通行程需求。

而增量式迭代思維，是這次交付一個(gè)滑板，下次交付一個(gè)自行車(chē)，再交付你一個(gè)小汽車(chē)，每次給你的交付物用戶都可以正常使用，這便是Minimum viable prodouct（最小可行產(chǎn)品）思維。

反觀微信的成長(zhǎng)史，他的快速成長(zhǎng)史便是用了這種思維。首次上線的微信，只有一個(gè)聊天的功能，而且頁(yè)面粗糙，但是隨著快速迭代以及張小龍對(duì)人性和商業(yè)的深刻洞察，微信逐漸從通訊工具到信息平臺(tái)再到生活入口，一步步壯大起來(lái)。

微信歷次大版本迭代內(nèi)容：

1. 微信的1.0版本，就是一個(gè)在熟人之間可以免費(fèi)發(fā)文本信息和圖片的工具。
2. 微信的2.0版本，增加了微信的語(yǔ)音功能和“查找附近陌生人”的功能，到這里，微信成為了陌生人語(yǔ)音社交的工具，但還是個(gè)工具，卻實(shí)現(xiàn)了用戶的爆發(fā)式增長(zhǎng)。
3. 微信3.0版本的時(shí)候推出了“掃一掃”、“服務(wù)號(hào)”，從這個(gè)點(diǎn)開(kāi)始，微信開(kāi)始連接世界。
4. 在4.0版本的時(shí)候，微信推出了“朋友圈”，微信從通訊工具開(kāi)始進(jìn)化，變成了社交平臺(tái)。
5. 微信的5.0版本，加上了“綁定銀行卡”，對(duì)微信來(lái)說(shuō)有一個(gè)巨大躍升，成為了今天的移動(dòng)生活場(chǎng)景，甚至是移動(dòng)商業(yè)帝國(guó)。
6. 在6.0中推出了群紅包和小視頻。
7. 在7.0版本主要是增加了即刻視頻和做一些小優(yōu)化。
8. 微信的8.0版本迭代登頂了熱搜，增加了“視頻號(hào)”和“直播”，但在外界看來(lái)，這是對(duì)快斗圍追阻截的絕地反擊。

4. 借力敏捷管理工具

有句老話說(shuō)得好，叫做“君子性非異也，善假于物也”。能夠巧妙地借助外力，是大多數(shù)成功人士取得輝煌成就的重要因素之一。在敏捷項(xiàng)目管理中更是如此。能夠助力敏捷管理的軟件有PingCode、Jira等，這里我詳細(xì)介紹一下PingCode。

作為國(guó)內(nèi)最標(biāo)準(zhǔn)的Scrum 產(chǎn)品，PingCode不僅支持Scrum框架所必需的基本元素，而且?guī)缀跄軌蚪鉀Q所有敏捷項(xiàng)目管理相關(guān)的問(wèn)題，并且還支持通過(guò)插件來(lái)補(bǔ)充實(shí)現(xiàn)與其他主流開(kāi)發(fā)工具的打通，以實(shí)現(xiàn)敏捷開(kāi)發(fā)過(guò)程中的需求管理、測(cè)試管理、缺陷管理、項(xiàng)目集管理、目標(biāo)管理、知識(shí)庫(kù)管理、自動(dòng)化管理等全過(guò)程管理。

5. 積極擁抱變化

敏捷之所以產(chǎn)生，很大程度上就是來(lái)源于對(duì)管理變化的探索?，F(xiàn)實(shí)中很多變化來(lái)源于不確定性，而不確定性總是和風(fēng)險(xiǎn)相關(guān)的，所以敏捷項(xiàng)目擁抱變化也就意味著與風(fēng)險(xiǎn)共處，擁有了管理變化的能力，也就擁有了管理風(fēng)險(xiǎn)的能力。而擁抱變化主要有如下三種措施：

1）識(shí)別什么樣的變化能帶來(lái)真正的風(fēng)險(xiǎn)

在項(xiàng)目管理中，通常會(huì)遇到兩種變化。第一種是預(yù)期內(nèi)的變化，這種相對(duì)來(lái)說(shuō)好處理或者說(shuō)風(fēng)險(xiǎn)并不是很大，我們一定要提前做好應(yīng)對(duì)方案。

第二種是預(yù)料之外的變化，他無(wú)法預(yù)測(cè)和判斷，不確定性很高，也很難從過(guò)往經(jīng)驗(yàn)里找到最佳解決方案。這種變化是項(xiàng)目管理的關(guān)鍵，因?yàn)樗鼛?lái)的是真正的風(fēng)險(xiǎn)。而這種變化一旦發(fā)生，不僅可能推翻我們?cè)械挠?jì)劃，使我們努力的成果和正在努力的事情從頭來(lái)過(guò)，甚至連最初制定的方向和目標(biāo)都要發(fā)生變化。

遇到這種情況，管理者最應(yīng)該做的事情就是：快速行動(dòng)，識(shí)別原因，驗(yàn)證假設(shè)，評(píng)估風(fēng)險(xiǎn)，尋找辦法，甚至需要設(shè)計(jì)出一個(gè)新的方案。

2）如何管理不確定性帶來(lái)的變化

在我看來(lái)主要有以下三點(diǎn)：

1. 事前時(shí)刻準(zhǔn)備，不間斷地去診斷和評(píng)估現(xiàn)狀。
2. 事中及時(shí)響應(yīng)，快速找到新的平衡，設(shè)計(jì)出針對(duì)性的解決方案。
3. 事后回顧、反思、復(fù)盤(pán)、總結(jié)，讓發(fā)生的事情成為經(jīng)驗(yàn)的一部分。

3）在變化面前，應(yīng)該擁有怎樣的心態(tài)

① 要有開(kāi)放的心態(tài)，充分認(rèn)識(shí)到變化的必然性。

② 敢于擔(dān)當(dāng)，有的時(shí)候你會(huì)發(fā)現(xiàn)客戶也陷在不確定性里，不知道如何應(yīng)對(duì)變化或者并不清晰自己想要什么，很多時(shí)候團(tuán)隊(duì)會(huì)選擇等待，目睹客戶在猶豫中錯(cuò)失良機(jī)或構(gòu)成發(fā)布質(zhì)量的隱患，這個(gè)時(shí)候需要我們主動(dòng)擔(dān)當(dāng)起來(lái)，做好向上管理，幫助客戶一起并肩前行。

③ 不斷成長(zhǎng)，事情是不斷變化的，事情的發(fā)展更多取決于人的選擇方向和努力程度，積極的心態(tài)和精益求精的追求能在很大程度上改變事情發(fā)展的方向和結(jié)果。

三、寫(xiě)在最后

雖然敏捷管理是未來(lái)大勢(shì)所趨，并且有著諸多好處，但是，我們切忌大搞“大躍進(jìn)”式的揠苗助長(zhǎng)，否則未因敏捷而生，卻先因敏捷而死。敏捷管理的實(shí)施是漸進(jìn)式的，初期我們可以先以混合開(kāi)發(fā)為主，慢慢地切入到敏捷管理的主軌道上，讓其穩(wěn)步著陸，如此才能讓敏捷管理成為公司業(yè)務(wù)增長(zhǎng)的增強(qiáng)發(fā)動(dòng)機(jī)。

本文由 @B端實(shí)戰(zhàn)訓(xùn)練營(yíng) 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來(lái)自Unsplash，基于CC0協(xié)議

敏捷開(kāi)發(fā)

敏捷是一種方法，一種組織軟件開(kāi)發(fā)動(dòng)態(tài)以獲得最有效結(jié)果的方法。它強(qiáng)調(diào)最簡(jiǎn)化可實(shí)行產(chǎn)品(MVP)的增量交付，以及一個(gè)頻繁的反饋循環(huán)，為團(tuán)隊(duì)提供有關(guān)改進(jìn)內(nèi)容的數(shù)據(jù)。實(shí)施更改后，將重復(fù)該過(guò)程，直到品質(zhì)保證(QA)批準(zhǔn)該軟件以部署到生產(chǎn)中。

敏捷開(kāi)發(fā)是通過(guò)在通常持續(xù) 1-2周的Sprint周期中迭代開(kāi)發(fā)特定功能來(lái)執(zhí)行?；鶞?zhǔn)系統(tǒng)產(chǎn)品被推送到QA測(cè)試，然后發(fā)送回團(tuán)隊(duì)進(jìn)行調(diào)試與修正。通過(guò)團(tuán)隊(duì)內(nèi)部和團(tuán)隊(duì)之間的頻繁、透明與無(wú)縫的協(xié)作和溝通才能實(shí)現(xiàn)。參與項(xiàng)目的所有團(tuán)隊(duì)成員都必須在時(shí)間表、業(yè)務(wù)需求和技術(shù)優(yōu)先級(jí)方面達(dá)成一致，敏捷開(kāi)發(fā)才能成功。

敏捷是一種哲學(xué)理論，必須通過(guò)某些框架轉(zhuǎn)化為現(xiàn)實(shí)的實(shí)踐。這些框架，例如Scrum與精益是操作藍(lán)圖，為如何開(kāi)展開(kāi)發(fā)事項(xiàng)動(dòng)制定了逐步的可行計(jì)劃。

敏捷開(kāi)發(fā)有四個(gè)基本原則：

• 通過(guò)方法和工具實(shí)現(xiàn)一致、有凝聚力的互動(dòng)與協(xié)作
• 根據(jù)綜合需求文檔對(duì)軟件進(jìn)行編碼
• 多輪消費(fèi)者反饋與隨之而來(lái)的適應(yīng)取用
• 快速適應(yīng)需求變化的靈活性

DevOps(開(kāi)發(fā)運(yùn)維一體化)

在非DevOps開(kāi)發(fā)運(yùn)維中，開(kāi)發(fā)員創(chuàng)建代碼，在他們自己的系統(tǒng)上對(duì)其進(jìn)行測(cè)試，通過(guò)QA運(yùn)行并將其推送到運(yùn)行維護(hù)操作中。由于運(yùn)維(Ops)團(tuán)隊(duì)無(wú)法承受對(duì)其系統(tǒng)進(jìn)行頻繁更改，因此新代碼通常并不兼容。因此運(yùn)維將代碼發(fā)回給開(kāi)發(fā)員而他們又必須又得從頭開(kāi)發(fā)，然后循環(huán)往復(fù)給兩個(gè)團(tuán)隊(duì)帶來(lái)了相互隔離的現(xiàn)象，為此，沒(méi)有太多關(guān)于是什么原因?qū)е麓a不兼容的交流而帶來(lái)各司其職不負(fù)責(zé)任的結(jié)果。

DevOps專(zhuān)注于消除開(kāi)發(fā)與運(yùn)維團(tuán)隊(duì)之間的這種隔閡，從而在不影響質(zhì)量的情況下促進(jìn)更快的交付。 DevOps消除了將開(kāi)發(fā)和運(yùn)維團(tuán)隊(duì)限制在孤島中的情況。就像敏捷開(kāi)發(fā)一樣，DevOps也是一種開(kāi)發(fā)哲學(xué)理論，它使整個(gè)團(tuán)隊(duì)和組織的工作變得更輕松。DevOps還需要協(xié)作才能成功而不僅是開(kāi)發(fā)和運(yùn)維，QA和安全團(tuán)隊(duì)通常也需要將自己集成到管道中，以實(shí)現(xiàn)快速交付完美的軟件產(chǎn)品。

DevOps能否成功取決于將自動(dòng)化大量整合到開(kāi)發(fā)過(guò)程中。自動(dòng)化工具有助于完成單個(gè)任務(wù)（由多個(gè)工程師區(qū)分代碼，通過(guò)預(yù)定的測(cè)試場(chǎng)景推送代碼等）。這就需要一個(gè)技術(shù)堆棧，將后續(xù)步驟歸結(jié)為一門(mén)科學(xué)，并將代碼從一個(gè)階段推送到另一個(gè)階段，直到準(zhǔn)備好發(fā)布作為一個(gè)功能齊全的優(yōu)化應(yīng)用程序。毋庸置疑，對(duì)于各方加快進(jìn)度大有幫助。因此CI/CD在此間就有了用武之地，也可以說(shuō)CI/CD就是DevOps的核心。

CI/CD(持續(xù)集成、持續(xù)交付和持續(xù)部署)

CI/CD是DevOps把理論變?yōu)楝F(xiàn)實(shí)的核心有效方法與方案。為滿足現(xiàn)今數(shù)字市場(chǎng)的需求，企業(yè)公司必須在不錯(cuò)過(guò)質(zhì)量和功能以極快的速度發(fā)布軟件于市場(chǎng)中。

為了實(shí)現(xiàn)這一點(diǎn)，開(kāi)發(fā)人員和測(cè)試人員必須使用CI/CD流水線確保以快速、安全和可靠的方式創(chuàng)建和發(fā)布軟件。

CI(持續(xù)集成)是一種實(shí)踐，開(kāi)發(fā)員定期將代碼推送到共享存儲(chǔ)庫(kù)，通常一天幾次。每次“推送”都會(huì)自動(dòng)驗(yàn)證，并在沒(méi)有任何錯(cuò)誤的情況下與主分支集成。定期集成允許在早期測(cè)試和調(diào)試小批量代碼，這樣就不會(huì)在開(kāi)發(fā)生命周期的后期階段出現(xiàn)重大問(wèn)題。

CD(持續(xù)交付、持續(xù)部署)可確保代碼始終準(zhǔn)備好交付或部署，其中包括所有更改——新功能、錯(cuò)誤修復(fù)、配置更改等。通過(guò)CI實(shí)現(xiàn)推送代碼、測(cè)試代碼并將其自動(dòng)合并到主分支。無(wú)論一天內(nèi)集成多少次代碼，即使數(shù)量是數(shù)千也可輕松實(shí)現(xiàn)。此處的目的是始終擁有已通過(guò)必要測(cè)試的可部署、無(wú)錯(cuò)誤的產(chǎn)品。

CD有時(shí)也指持續(xù)部署。在實(shí)踐中，一旦所有更改經(jīng)過(guò)測(cè)試并與主代碼庫(kù)集成，軟件就會(huì)自動(dòng)部署到生產(chǎn)環(huán)境中。在持續(xù)交付中，部署需要一名或多名人員(QA、業(yè)務(wù)或技術(shù)經(jīng)理)的監(jiān)督和批準(zhǔn)。持續(xù)部署是消除人工干預(yù)的最后一步。

與敏捷開(kāi)發(fā)和DevOps一樣，CI/CD需要正確的工具、框架和熟練的人員才能成功并提供所需的技術(shù)與商業(yè)成果。

敏捷開(kāi)發(fā)、DevOps與CI/CD的主要區(qū)別

敏捷開(kāi)發(fā)

• 軟件開(kāi)發(fā)的總體理念
• 包含許多旨在加速開(kāi)發(fā)的方法、流程和工具
• 專(zhuān)注于增量交付、持續(xù)反饋和協(xié)作
• 通過(guò) Scrum、看板、Scaled Agile Framework(SAFe)等框架實(shí)現(xiàn)

DevOps

• 使用敏捷原則(協(xié)作、溝通、自動(dòng)化)實(shí)踐與工作理論
• 尋求確定和消除開(kāi)發(fā)和運(yùn)維團(tuán)隊(duì)之間的障礙與沖突
• 專(zhuān)注于協(xié)作和使用正確的自動(dòng)化工具
• 可以作為其他敏捷框架和方法的一部分來(lái)實(shí)現(xiàn)

CI/CD

• 基于DevOps的實(shí)踐
• 通過(guò)自動(dòng)化和增量編碼和測(cè)試實(shí)施敏捷開(kāi)發(fā)
• 專(zhuān)注于自動(dòng)化整個(gè)流水線，從代碼開(kāi)發(fā)、構(gòu)建/編譯、集成、測(cè)試整個(gè)代碼庫(kù)并保持部署準(zhǔn)備就緒。
• 使用特定工具或CI/CD服務(wù)實(shí)現(xiàn)，例如: Jenkins、Buddy、GitLab CI/CD、GitHub Actions、CircleCI或Azure DevOps服務(wù)等。

通過(guò)這篇文章，希望您對(duì)這方面的知識(shí)有進(jìn)一步的加深！我們將會(huì)持續(xù)發(fā)表相關(guān)敏捷開(kāi)發(fā)、DevOps與CI/CD更多詳細(xì)的實(shí)踐與操作的文章以便您能將其使用到工作中去。

敏捷開(kāi)發(fā)是一種以人為核心、迭代、循序漸進(jìn)的開(kāi)發(fā)方法。

在敏捷開(kāi)發(fā)中，軟件項(xiàng)目的構(gòu)建被切分成多個(gè)子項(xiàng)目，各個(gè)子項(xiàng)目的成果都經(jīng)過(guò)測(cè)試，具備集成和可運(yùn)行的特征。

換言之，就是把一個(gè)大項(xiàng)目分為多個(gè)相互聯(lián)系，但也可獨(dú)立運(yùn)行的小項(xiàng)目分別完成，且在此過(guò)程中軟件一直處于可使用狀態(tài)。

4大價(jià)值觀

1）個(gè)體和互動(dòng) 高于 流程和工具

項(xiàng)目是人來(lái)執(zhí)行的，困難是人來(lái)解決的，成功也是人來(lái)定義的。流程和工具是項(xiàng)目中必不可少的，但聚焦于個(gè)體參與和互動(dòng)。

2）工作的軟件 高于 詳盡的文檔

軟件項(xiàng)目以創(chuàng)造有價(jià)值、高質(zhì)量的軟件為首要目標(biāo)。文檔是需要的，但要把握其中的度。

3）客戶合作 高于 合同談判

強(qiáng)調(diào)靈活與包容，當(dāng)客戶改變想法或優(yōu)先級(jí)時(shí)，通過(guò)靈活的方法完成新目標(biāo)，而非用最初的規(guī)定來(lái)對(duì)抗。

4）響應(yīng)變化 高于 遵循計(jì)劃

響應(yīng)變化是適應(yīng)的過(guò)程，計(jì)劃是基準(zhǔn)，響應(yīng)變化目的是使項(xiàng)目預(yù)期與未來(lái)計(jì)劃一致。

12條原則

1）我們最重要的目標(biāo)，是通過(guò)持續(xù)不斷地及早交付有價(jià)值的軟件使客戶滿意。

2）欣然面對(duì)需求變化，即使在開(kāi)發(fā)后期也一樣。善于掌控變化，幫助客戶獲得競(jìng)爭(zhēng)優(yōu)勢(shì)。

3）經(jīng)常地交付可工作的軟件，相隔幾星期或一兩個(gè)月，傾向于采取較短的周期。

4）業(yè)務(wù)人員和開(kāi)發(fā)人員必須相互合作，項(xiàng)目中的每一天都不例外。

5）激發(fā)個(gè)體的斗志，以他們?yōu)楹诵拇罱?xiàng)目。提供他們所需的環(huán)境和支持，相信他們能夠達(dá)成目標(biāo)。

6）不論團(tuán)隊(duì)內(nèi)外，傳遞信息效果最好效率也最高的方式是面對(duì)面的交談。

7）可工作的軟件是進(jìn)度的首要度量標(biāo)準(zhǔn)。

8）敏捷過(guò)程倡導(dǎo)可持續(xù)開(kāi)發(fā)。責(zé)任人、開(kāi)發(fā)人員和用戶要能夠共同維持其步調(diào)穩(wěn)定延續(xù)。

9）對(duì)技術(shù)精益求精，對(duì)設(shè)計(jì)不斷完善，將提高敏捷能力。

10）以簡(jiǎn)潔為本，極力減少不必要工作量。

11）最好的架構(gòu)、需求和設(shè)計(jì)出自于自組織的團(tuán)隊(duì)。

12）團(tuán)隊(duì)定期地反思如何能提高成效，并依此調(diào)整團(tuán)隊(duì)的行為。

任何一種方法都有其適用范圍，重要的是根據(jù)實(shí)際情況選擇合適的方法。

10月27，在「稀土開(kāi)發(fā)者大會(huì)」上，火山引擎總經(jīng)理譚待以《數(shù)據(jù)驅(qū)動(dòng)x敏捷開(kāi)發(fā)，業(yè)務(wù)高速增長(zhǎng)的雙引擎》為主題，深度解密了字節(jié)跳動(dòng)業(yè)務(wù)快速發(fā)展的兩大技術(shù)理念——數(shù)據(jù)驅(qū)動(dòng)、敏捷開(kāi)發(fā)，分享如何構(gòu)建數(shù)據(jù)驅(qū)動(dòng)的飛輪，以及如何通過(guò)全棧云原生架構(gòu)，支撐大規(guī)模應(yīng)用實(shí)現(xiàn)敏捷開(kāi)發(fā)。

以下為譚待的演講實(shí)錄：

大家好，我是譚待，是字節(jié)跳動(dòng)火山引擎業(yè)務(wù)的負(fù)責(zé)人。很高興收到稀土開(kāi)發(fā)者大會(huì)的邀請(qǐng)，今天能夠和大家分享、探討字節(jié)跳動(dòng)的技術(shù)理念和實(shí)踐。

火山引擎是企業(yè)的數(shù)字化增長(zhǎng)引擎

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

火山引擎是字節(jié)跳動(dòng)旗下的企業(yè)級(jí)技術(shù)服務(wù)平臺(tái)，是字節(jié)跳動(dòng)技術(shù)團(tuán)隊(duì)對(duì)外提供技術(shù)服務(wù)的統(tǒng)一窗口，我們希望通過(guò)火山引擎，把字節(jié)跳動(dòng)的技術(shù)、產(chǎn)品和服務(wù)對(duì)外開(kāi)放，包括云、AI、大數(shù)據(jù)、推薦等等，來(lái)幫助不同行業(yè)中的企業(yè)實(shí)現(xiàn)自身增長(zhǎng)和數(shù)字化轉(zhuǎn)型。

大家知道，字節(jié)跳動(dòng)內(nèi)部一直在踐行技術(shù)中臺(tái)的技術(shù)文化。所以我們?cè)谧黾夹g(shù)ToB過(guò)程中，也采取了這種機(jī)制，讓技術(shù)中臺(tái)直接實(shí)現(xiàn)自身產(chǎn)品的商業(yè)化。因此，火山引擎對(duì)外開(kāi)放的技術(shù)和工具，與字節(jié)跳動(dòng)技術(shù)中臺(tái)完全同源。比如說(shuō)推薦，用的就是今日頭條、抖音的同款推薦平臺(tái)、工具和方法論。通過(guò)這種方式，我們可以把內(nèi)部最好的能力對(duì)外進(jìn)行服務(wù)。

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

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

數(shù)據(jù)驅(qū)動(dòng)：構(gòu)建數(shù)據(jù)驅(qū)動(dòng)的飛輪

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

構(gòu)建數(shù)據(jù)驅(qū)動(dòng)的飛輪

回到數(shù)據(jù)驅(qū)動(dòng)這個(gè)話題，我們認(rèn)為同樣如此。數(shù)據(jù)驅(qū)動(dòng)不是一蹴而就的，不是用了一個(gè)工具，或者說(shuō)建了幾張報(bào)表就做起來(lái)了，而是在整個(gè)過(guò)程中，不停地去解決一個(gè)個(gè)問(wèn)題，最終形成多個(gè)體系，讓他自動(dòng)轉(zhuǎn)起來(lái)，形成數(shù)據(jù)的飛輪效應(yīng)。一旦飛輪效應(yīng)形成，越到后面轉(zhuǎn)得越快。數(shù)據(jù)驅(qū)動(dòng)就會(huì)成為日常內(nèi)部協(xié)同的習(xí)慣，最終成為業(yè)務(wù)增長(zhǎng)的源動(dòng)力。

圍繞這一目標(biāo)，我們可以把建設(shè)飛輪分為四個(gè)關(guān)鍵步驟，業(yè)務(wù)過(guò)程數(shù)字化、數(shù)字化協(xié)同、數(shù)據(jù)驅(qū)動(dòng)業(yè)務(wù)優(yōu)化、客觀的分析評(píng)估。

這幾個(gè)步驟之間是一個(gè)有機(jī)推動(dòng)的過(guò)程：

業(yè)務(wù)過(guò)程的數(shù)字化是第一步，也是非常關(guān)鍵的一步。業(yè)務(wù)過(guò)程的數(shù)字化越充分，對(duì)業(yè)務(wù)的描述就越精準(zhǔn)，才能有利于后面步驟的展開(kāi)。所以，我們需要不斷地將離線活動(dòng)在線化，在線活動(dòng)精細(xì)化，全部通過(guò)數(shù)字化的方式進(jìn)行表達(dá)。

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

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

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

最后，走完這四步后，在業(yè)務(wù)優(yōu)化和評(píng)估過(guò)程中，我們又能沉淀更多的數(shù)據(jù)，這就形成了閉環(huán)，實(shí)現(xiàn)了飛輪的轉(zhuǎn)動(dòng)。

字節(jié)的數(shù)據(jù)驅(qū)動(dòng)飛輪

剛剛是一個(gè)偏抽象的描述，下面我們?cè)俳Y(jié)合字節(jié)跳動(dòng)的具體情況來(lái)看：

• 業(yè)務(wù)過(guò)程數(shù)字化，主要是對(duì)于不同觸點(diǎn)的數(shù)據(jù)埋點(diǎn)，比如APP、小程序、運(yùn)營(yíng)頁(yè)等等；

• 數(shù)字化協(xié)同，是多角色對(duì)數(shù)據(jù)應(yīng)用的協(xié)同加工。比如研發(fā)如何做好數(shù)據(jù)開(kāi)發(fā)、數(shù)據(jù)治理，運(yùn)營(yíng)更好更快的用好數(shù)據(jù)等；

• 數(shù)字驅(qū)動(dòng)業(yè)務(wù)優(yōu)化，主要是根據(jù)數(shù)據(jù)，根據(jù)數(shù)據(jù)產(chǎn)生的insights，對(duì)產(chǎn)品、算法進(jìn)行優(yōu)化，比如對(duì)推薦系統(tǒng)策略的優(yōu)化，面向不同用戶群體運(yùn)營(yíng)的優(yōu)化等；

• 客觀的分析評(píng)估，一方面通過(guò)A/B測(cè)試，對(duì)不同的、新的迭代進(jìn)行客觀評(píng)估，另一方面則是通過(guò)ABI進(jìn)一步地進(jìn)行數(shù)據(jù)洞察，能夠積累對(duì)于的insights，從而促進(jìn)整個(gè)流程的轉(zhuǎn)動(dòng)。

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

下面我們就數(shù)據(jù)中臺(tái)和應(yīng)用優(yōu)化，進(jìn)行展開(kāi)。

面向應(yīng)用的數(shù)據(jù)中臺(tái)

剛才其實(shí)也提到了數(shù)據(jù)中臺(tái)，它最大的一個(gè)作用是幫助各個(gè)應(yīng)用、業(yè)務(wù)基于數(shù)據(jù)驅(qū)動(dòng)進(jìn)行優(yōu)化。所以做數(shù)據(jù)中臺(tái)有一個(gè)很重要的理念，那就是一定要面向應(yīng)用來(lái)構(gòu)建。從數(shù)據(jù)開(kāi)始，用數(shù)據(jù)來(lái)做驗(yàn)證。那么談到數(shù)據(jù)的驗(yàn)證，那最重要的其實(shí)就是A/B測(cè)試。之前我們也在不同場(chǎng)合強(qiáng)調(diào)過(guò)字節(jié)對(duì)于A/B測(cè)試的重視，包括抖音、頭條的起名也是通過(guò)A/B測(cè)試得來(lái)的。

對(duì)于評(píng)估而言，測(cè)試只是第一步，我們還需要進(jìn)一步對(duì)結(jié)果進(jìn)行分析，因此構(gòu)建了相應(yīng)的數(shù)據(jù)運(yùn)營(yíng)平臺(tái)、智能數(shù)據(jù)洞察和客戶數(shù)據(jù)平臺(tái)等工具，幫助產(chǎn)品和運(yùn)營(yíng)可以深入分析數(shù)據(jù)。

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

所以可以說(shuō)在底層，我們更關(guān)注數(shù)據(jù)開(kāi)發(fā)的效率和規(guī)模，而在上層，我們關(guān)注的是整個(gè)產(chǎn)品和運(yùn)營(yíng)在做數(shù)據(jù)分析過(guò)程中的易用性、可交互性。要實(shí)現(xiàn)易用性、可交互性和底層規(guī)模和效率的一個(gè)連接，我們需要一個(gè)非常強(qiáng)大的數(shù)據(jù)分析引擎，那就是我們的ByteHouse。

ByteHouse起源于開(kāi)源的clickhouse項(xiàng)目，所以有了House的后綴。但它其實(shí)是根據(jù)字節(jié)跳動(dòng)大規(guī)模數(shù)據(jù)場(chǎng)景，進(jìn)行了非常多的需求改造，最終形成的一個(gè)云原生的大規(guī)模數(shù)據(jù)分析平臺(tái)。

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

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

面對(duì)剛才說(shuō)的大規(guī)模挑戰(zhàn)，我們?cè)贐yteHouse上主要做了五個(gè)層次的深度改造：

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

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

在計(jì)算和存儲(chǔ)的分離之外，我們?cè)谶\(yùn)維、安全方面做了很多工作，以進(jìn)一步去彌補(bǔ)社區(qū)版本功能的缺失。

最后一個(gè)很重要的是我們做了多級(jí)的資源隔離。因?yàn)槊刻煊胁煌牟块T(mén)、角色在做各種各樣的分析，那么權(quán)限、時(shí)效性的要求都不一樣。那么通過(guò)租戶的隔離、讀寫(xiě)的分離以及異構(gòu)的計(jì)算資源，就能很好地滿足不同部門(mén)、不同角色在大規(guī)模集中式地使用資源分配的問(wèn)題。

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

應(yīng)用優(yōu)化

剛才講了數(shù)據(jù)中臺(tái)的一些實(shí)踐，接下來(lái)再講講怎么去通過(guò)數(shù)據(jù)驅(qū)動(dòng)來(lái)做應(yīng)用和業(yè)務(wù)的優(yōu)化。這里以增長(zhǎng)獲客來(lái)舉例。

當(dāng)然不管是增長(zhǎng)場(chǎng)景還是其他場(chǎng)景，如果要做好數(shù)據(jù)驅(qū)動(dòng)優(yōu)化，首先最關(guān)鍵的就是設(shè)計(jì)好指標(biāo)體系。因?yàn)橹笜?biāo)不對(duì)，做的再多都是錯(cuò)的。

那么對(duì)于增長(zhǎng)而言，我們認(rèn)為最重要的有兩個(gè)指標(biāo)——「正向的投入產(chǎn)出」和「健康的用戶規(guī)?！?。

正向的投入產(chǎn)出，簡(jiǎn)單來(lái)說(shuō)就是ROI>1。看起來(lái)非常簡(jiǎn)單，但怎么把ROI算對(duì)、算準(zhǔn)以及精細(xì)到每個(gè)用戶粒度跟進(jìn)長(zhǎng)期的 ROI，其實(shí)是難點(diǎn)和關(guān)鍵。

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

設(shè)定了這些關(guān)鍵指標(biāo)之后，其實(shí)就可以通過(guò)指標(biāo)去找到對(duì)應(yīng)的優(yōu)化增長(zhǎng)策略。這個(gè)增長(zhǎng)策略不僅要滿足指標(biāo)的正向，同時(shí)也要具備可持續(xù)、可規(guī)?；⒖蓮?fù)制的模式。這樣就把業(yè)務(wù)的增長(zhǎng)模式轉(zhuǎn)化成了可衡量、可跟蹤的數(shù)據(jù)驅(qū)動(dòng)模式。

最后用一張圖去完整地闡述數(shù)據(jù)驅(qū)動(dòng)、基于中臺(tái)和應(yīng)用優(yōu)化，來(lái)構(gòu)建整體飛輪的案例。

• 首先基于數(shù)據(jù)做用戶定向，定義好目標(biāo)，找到對(duì)產(chǎn)品最關(guān)鍵的人群；

• 找到之后，去做對(duì)應(yīng)的創(chuàng)意、內(nèi)容，然后讓這些最優(yōu)質(zhì)最吸引的內(nèi)容在不同渠道觸達(dá)到客戶，形成轉(zhuǎn)換并產(chǎn)生新的數(shù)據(jù)。而且我們有數(shù)字化記錄的過(guò)程，能夠準(zhǔn)確地歸因，精細(xì)化地追蹤效果；

• 在優(yōu)化過(guò)程中，會(huì)有很多創(chuàng)意。我們通過(guò)A/B測(cè)試高速迭代，看看哪個(gè)創(chuàng)意更合適。而在評(píng)估的過(guò)程中，也會(huì)出現(xiàn)更多的數(shù)據(jù)，從而又補(bǔ)充了整個(gè)策略方案，最終就形成一個(gè)數(shù)據(jù)驅(qū)動(dòng)的增長(zhǎng)飛輪。

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

敏捷開(kāi)發(fā)：全棧云原生架構(gòu)支撐大規(guī)模應(yīng)用

說(shuō)到敏捷開(kāi)發(fā)，我們可以看到市面各種各樣不同層次的解決方案，比如說(shuō)低代碼，aPaaS等等。不過(guò)今天主要想和大家聊的還是云原生這塊，因?yàn)闊o(wú)論是SaaS層還是PaaS層的方案，在底層都離不開(kāi)一整套云原生架構(gòu)的支持。

字節(jié)跳動(dòng)全棧云原生化架構(gòu)

這里也簡(jiǎn)單回顧下云基礎(chǔ)技術(shù)的發(fā)展歷史，相信很多人也比較熟悉這段軌跡了?？梢钥吹剑?3年是一個(gè)重要的拐點(diǎn)。13年之后，隨著Docker、K8s等技術(shù)的興起和普及，云從以基礎(chǔ)設(shè)施為中心，走向以應(yīng)用為中心；從資源服務(wù)化走向平臺(tái)服務(wù)化，而字節(jié)跳動(dòng)剛好誕生在2012年，因此非常幸運(yùn)沒(méi)有什么歷史包袱，直接擁抱了最新的云原生技術(shù)。

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

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

第一是如何支撐海量服務(wù)。隨著應(yīng)用微服務(wù)化，治理對(duì)象由單體應(yīng)用轉(zhuǎn)變?yōu)閿?shù)量更龐大的微服務(wù)，這導(dǎo)致全局治理難度更加大，包括構(gòu)建全局的配置中心以及更靈活的全局網(wǎng)絡(luò)、運(yùn)行時(shí)的選擇、配備完善的安全機(jī)制，以及如何端到端的和整個(gè)DevOps流程進(jìn)行打通。

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

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

同時(shí)，在底層，我們還構(gòu)建了一個(gè)容器+多云的整體解決方案。

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

這張圖從架構(gòu)體系角度，進(jìn)一步來(lái)闡釋全棧云原生的體系結(jié)構(gòu)。

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

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

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

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

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

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

因?yàn)闀r(shí)間有限，我挑了兩個(gè)比較有意思的話題來(lái)進(jìn)一步的分享。一個(gè)是微服務(wù)，一個(gè)是移動(dòng)開(kāi)發(fā)。一方面比較有代表性，另一方面這兩者覆蓋了大部分業(yè)務(wù)研發(fā)的場(chǎng)景。

服務(wù)器端——微服務(wù)、服務(wù)治理與DevOps

首先來(lái)看微服務(wù)。我們可以用四個(gè)點(diǎn)來(lái)形容字節(jié)跳動(dòng)微服務(wù)的現(xiàn)狀：

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

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

技術(shù)體系以Golang語(yǔ)言為主。根據(jù)最新的調(diào)查統(tǒng)計(jì)，字節(jié)跳動(dòng)內(nèi)部Golang是主要語(yǔ)言，超過(guò)55％的服務(wù)都采用了Golang，排名第二的語(yǔ)言是NodeJS，然后是其他的語(yǔ)言。

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

大家可以發(fā)現(xiàn)整個(gè)字節(jié)跳動(dòng)在微服務(wù)的使用上是非?？斓模踔量梢哉f(shuō)是比較激進(jìn)的。這背后，是因?yàn)樵谧止?jié)跳動(dòng)，速度和效率是我們研發(fā)要解決的Top1問(wèn)題。每天新應(yīng)用和新用戶增長(zhǎng)都非?？?，研發(fā)必須要解決好產(chǎn)能問(wèn)題。這也是我們激進(jìn)地采取微服務(wù)架構(gòu)的原因。但這么大的規(guī)模下，做這么快的迭代，自然會(huì)對(duì)穩(wěn)定性、信任帶來(lái)非常大的沖擊。

為了應(yīng)對(duì)這些困難和矛盾，我們?cè)诙说蕉寺涞匚⒎?wù)架構(gòu)時(shí)，針對(duì)性地做了各項(xiàng)優(yōu)化：

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

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

最后是通過(guò)落地和實(shí)踐DevOps工具和方法來(lái)提升研發(fā)的效率，進(jìn)一步提升運(yùn)維的可觀測(cè)性。

下面我們就一個(gè)個(gè)展開(kāi)。

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

這是Kitex和gRPC性能的對(duì)比，我們選了兩組，分別是基于Thrift和Protobuf協(xié)議的對(duì)比?？梢钥吹皆趦煞N方式下，Kitex都有比較好的性能表現(xiàn)。特別是在在TP99延遲上，隨著并發(fā)連接數(shù)的增大，Kitex表現(xiàn)出的優(yōu)勢(shì)是越來(lái)越大。

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

接下來(lái)我們看服務(wù)網(wǎng)格的治理。剛才談到過(guò)因?yàn)楸旧淼臉I(yè)務(wù)類(lèi)型、業(yè)務(wù)體量，所以我們?cè)趯?shí)踐微服務(wù)的架構(gòu)中，面臨著非常多挑戰(zhàn)，比如語(yǔ)言碎片化、服務(wù)異構(gòu)、協(xié)議異構(gòu)，還有安全、可觀測(cè)性、問(wèn)題追查調(diào)用等等。所以我們采取了基于服務(wù)網(wǎng)格模式，來(lái)進(jìn)行整體的微服務(wù)治理。

上圖綠色方框是控制面，虛框是數(shù)據(jù)面。我們通過(guò)服務(wù)網(wǎng)格將控制平面和數(shù)據(jù)平面進(jìn)行了分離，消除了單點(diǎn)故障的可能。比如當(dāng)數(shù)據(jù)平面流量過(guò)大出現(xiàn)性能問(wèn)題時(shí)，就不會(huì)影響到控制平面的路由策略；反過(guò)來(lái)也是，當(dāng)控制平面策略負(fù)載過(guò)重時(shí)也不會(huì)影響數(shù)據(jù)平面的轉(zhuǎn)發(fā)。

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

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

在網(wǎng)絡(luò)和內(nèi)核層面，我們用共享內(nèi)存或者系統(tǒng)調(diào)用的方式來(lái)實(shí)現(xiàn)真正的zero copy。

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

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

移動(dòng)端——極致體驗(yàn)的移動(dòng)APP研發(fā)

剛才講的是微服務(wù)框架和服務(wù)治理的內(nèi)容，接下來(lái)我們?cè)賮?lái)說(shuō)一說(shuō)移動(dòng)開(kāi)發(fā)。

對(duì)于字節(jié)來(lái)說(shuō)，可以算是一個(gè)移動(dòng)原生的企業(yè)，我們絕大部分的業(yè)務(wù)也都是通過(guò)APP在承載的。截止目前，我們已經(jīng)運(yùn)營(yíng)超過(guò)100款A(yù)PP，公司內(nèi)部也有數(shù)千人的移動(dòng)應(yīng)用研發(fā)團(tuán)隊(duì)。

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

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

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

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

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

4. 另外在質(zhì)量管控，我們也提供了一站式全鏈路測(cè)試平臺(tái)，基于海量真機(jī)真實(shí)模擬線上實(shí)際場(chǎng)景，最大限度檢測(cè)潛在異常。

5. 最后是全鏈路監(jiān)控平臺(tái)，能夠覆蓋“終端-網(wǎng)絡(luò)-后臺(tái)應(yīng)用-基礎(chǔ)環(huán)境”的完整應(yīng)用鏈路監(jiān)控，幫助研發(fā)人員精準(zhǔn)定位問(wèn)題，解決問(wèn)題。

通過(guò)以上對(duì)微服務(wù)、移動(dòng)開(kāi)發(fā)平臺(tái)Mars的介紹，我想大家對(duì)字節(jié)跳動(dòng)敏捷開(kāi)發(fā)應(yīng)該有了一個(gè)更生動(dòng)的認(rèn)識(shí)。

回到今天分享的主題，在整個(gè)字節(jié)技術(shù)發(fā)展的背后，數(shù)據(jù)驅(qū)動(dòng)和敏捷開(kāi)發(fā)是兩個(gè)重要的理念，但這兩個(gè)理念并不是割裂的，二者是一體的。因?yàn)閷?duì)于數(shù)據(jù)驅(qū)動(dòng)而言，我們需要有更多的實(shí)驗(yàn)，來(lái)找到好的方案進(jìn)行推廣，找到不好的點(diǎn)進(jìn)行改進(jìn)。而敏捷開(kāi)發(fā)就能保證每天都有大量的實(shí)驗(yàn)?zāi)軌蜻M(jìn)行。反過(guò)來(lái)通過(guò)數(shù)據(jù)驅(qū)動(dòng)，我們又能夠去找到里面有價(jià)值的東西，同時(shí)也能沉淀更多的數(shù)據(jù)，這樣就構(gòu)建了整個(gè)業(yè)務(wù)高速發(fā)展的閉環(huán)。

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

而我們底層的技術(shù)、平臺(tái)的技術(shù)，還有業(yè)務(wù)層的技術(shù)，也正是因?yàn)檫@兩個(gè)理念在不斷的積累和迭代，最終去推動(dòng)業(yè)務(wù)的高速發(fā)展。

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

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

謝謝大家！