云計(jì)算產(chǎn)品大多都會(huì)與云原生發(fā)生關(guān)聯(lián)，云原生正在重塑整個(gè)軟件的生命周期。但到底什么是云原生？云原生帶來(lái)的最大技術(shù)創(chuàng)新和未來(lái)機(jī)會(huì)是什么？圍繞云原生，是否可以構(gòu)建出一套云上的開(kāi)發(fā)&運(yùn)維體系，打造新一代研發(fā)平臺(tái)，實(shí)現(xiàn)研發(fā)效率的最大化？

我們邀請(qǐng)了阿里云云效研發(fā)平臺(tái)負(fù)責(zé)人神秀，分享團(tuán)隊(duì)關(guān)于高效研發(fā)運(yùn)維體系構(gòu)建的流程和方法論。文章包括三個(gè)部分：首先從問(wèn)題出發(fā)，分析在團(tuán)隊(duì)業(yè)務(wù)逐步壯大的過(guò)程中可能會(huì)遇到的問(wèn)題，以及這些問(wèn)題對(duì)團(tuán)隊(duì)效能的影響。然后結(jié)合問(wèn)題看下什么樣的效能體系能夠滿足團(tuán)隊(duì)效能提升的訴求。最后介紹阿里云云效團(tuán)隊(duì)對(duì)效能提升方法的一些總結(jié)。

一 團(tuán)隊(duì)效能的影響因素

1 團(tuán)隊(duì)效能的影響因素

首先探討下企業(yè)人員規(guī)模增長(zhǎng)對(duì)效能的影響。剛開(kāi)始公司初創(chuàng)期，十幾二十人組成全功能團(tuán)隊(duì)，此時(shí)團(tuán)隊(duì)分工邊界并不明確，大家在一個(gè)非常敏捷的狀態(tài)下工作，互相會(huì)進(jìn)行一些補(bǔ)位，比如技術(shù)去做一些產(chǎn)品的事情，開(kāi)發(fā)去做測(cè)試和運(yùn)維。這種情況下團(tuán)隊(duì)協(xié)作起來(lái)基本上沒(méi)有太多溝通損耗。往往瓶頸在個(gè)人能力上。此時(shí)初創(chuàng)團(tuán)隊(duì)為了更快的完成業(yè)務(wù)需求，在效能工具選擇上更關(guān)注單點(diǎn)效率，比如好用的流水線工具、測(cè)試工具等等，上手門檻是第一考慮的因素。

當(dāng)團(tuán)隊(duì)逐步擴(kuò)張，人員分工開(kāi)始專業(yè)化，多職能協(xié)同的問(wèn)題開(kāi)始凸顯出來(lái)。如何合作，權(quán)責(zé)如何分配，大家之間的協(xié)作流程是怎樣的，是團(tuán)隊(duì)非常關(guān)心的問(wèn)題。此時(shí)團(tuán)隊(duì)并不太會(huì)因?yàn)閭€(gè)人能力而決定產(chǎn)品的成敗，如何提升中位能力是關(guān)鍵問(wèn)題。此時(shí)在效能工具的選擇上會(huì)更偏向于有一定解決方案的產(chǎn)品，比如分支管理模式，測(cè)試環(huán)境管理模式，DevOps如何落地等等。這些工具的使用可以很大程度去提升團(tuán)隊(duì)之間透明度，提升溝通效率。比如分支管理模式的選擇，解決開(kāi)發(fā)與測(cè)試團(tuán)隊(duì)溝通的問(wèn)題，DevOps模式更是將絕大部分運(yùn)維工作交給開(kāi)發(fā)獨(dú)立完成，從而通過(guò)減少溝通來(lái)提升效率。

隨著團(tuán)隊(duì)業(yè)務(wù)進(jìn)一步擴(kuò)大，開(kāi)始出現(xiàn)有明顯業(yè)務(wù)邊界的產(chǎn)品，此時(shí)在溝通協(xié)作成本會(huì)被進(jìn)一步放大，大家更加重視目標(biāo)、共識(shí)和結(jié)果。當(dāng)然可以以戰(zhàn)役模式去承載目標(biāo)、共識(shí)和結(jié)果，是非常好的一種匯聚人力資源，topdown的提升執(zhí)行效率的手段。從另一面也要意識(shí)到，戰(zhàn)役并不能解決所有邊邊角角的跨產(chǎn)品、跨團(tuán)隊(duì)協(xié)同問(wèn)題，如何在日常狀態(tài)下去解決這種兵力分配、業(yè)務(wù)技術(shù)拉通的問(wèn)題才是關(guān)鍵。

2 軟件服務(wù)架構(gòu)對(duì)研發(fā)效能的影響

接下來(lái)看另一個(gè)問(wèn)題，就是服務(wù)架構(gòu)對(duì)研發(fā)效能的影響。服務(wù)架構(gòu)其實(shí)和組織架構(gòu)有很強(qiáng)的關(guān)聯(lián)關(guān)系，比如在扁平化架構(gòu)下，團(tuán)隊(duì)各自獨(dú)立互相關(guān)聯(lián)性不強(qiáng)，有很高的自給率，這里的自給率是指獨(dú)立完成某個(gè)需求的能力。

在網(wǎng)狀架構(gòu)下組織形式往往是一體式的，由同一個(gè)部門老大帶領(lǐng)，團(tuán)隊(duì)之間緊密配合，我中有你，你中有我。在這個(gè)階段架構(gòu)復(fù)雜度高，缺乏抽象。但是因?yàn)闃I(yè)務(wù)流程相對(duì)簡(jiǎn)單，做起需求來(lái)各團(tuán)隊(duì)點(diǎn)對(duì)點(diǎn)溝通也不是太大問(wèn)題，決策鏈路短，共識(shí)快。從另一方面看，技術(shù)債務(wù)也在累積，當(dāng)業(yè)務(wù)之間耦合到一定程度的時(shí)候就會(huì)出現(xiàn)維護(hù)債務(wù)的人力投入開(kāi)始大過(guò)新需求人力投入。中臺(tái)架構(gòu)是解決此問(wèn)題的一個(gè)路徑。

到中臺(tái)模式下，各種業(yè)務(wù)模塊開(kāi)始被抽象出來(lái)，隨之技術(shù)側(cè)也需要組建技術(shù)中臺(tái)，將原來(lái)各自團(tuán)隊(duì)持有的工具開(kāi)始收斂，流程開(kāi)始統(tǒng)一。不過(guò)隨著前臺(tái)和中臺(tái)出現(xiàn)分工后，各自發(fā)展路線獨(dú)立設(shè)計(jì)，此時(shí)就會(huì)出現(xiàn)部門墻、前臺(tái)業(yè)務(wù)自給率低、達(dá)成優(yōu)先級(jí)、交付時(shí)間等共識(shí)很困難的問(wèn)題。

經(jīng)過(guò)這三種產(chǎn)品架構(gòu)、技術(shù)架構(gòu)、組織架構(gòu)的分析，相信大家可以理解團(tuán)隊(duì)不斷演進(jìn)過(guò)程中面臨的效能困局。

3 技術(shù)演化帶來(lái)的效能變化

說(shuō)完了協(xié)作問(wèn)題，再來(lái)看技術(shù)的演化是如何影響研發(fā)效能的。先粗略的看看過(guò)去幾年的幾個(gè)技術(shù)變化。在2008年開(kāi)始業(yè)界提出了微服務(wù)、持續(xù)交付、DevOps等等一系列的概念，延續(xù)至今。與此同時(shí)阿里巴巴也對(duì)電商核心系統(tǒng)進(jìn)行了服務(wù)化改造，后來(lái)又發(fā)現(xiàn)服務(wù)多了，管理出現(xiàn)了難題，只有DevOps可以消除瓶頸，釋放生產(chǎn)力。這幾件事其實(shí)內(nèi)部是有一定邏輯的，也就是業(yè)務(wù)驅(qū)動(dòng)技術(shù)變革，技術(shù)促進(jìn)架構(gòu)變革，架構(gòu)又推動(dòng)研發(fā)模式變革。

再看最近幾年日益興盛的k8s生態(tài)，大致相同，新技術(shù)的應(yīng)用，造就了很多新的架構(gòu)模式比如serverless，小程序等，這些新的架構(gòu)給原有的研發(fā)模式也帶來(lái)了巨大挑戰(zhàn)，比如在Function as Services模式下如何管理代碼分支和環(huán)境，測(cè)試工具和方法會(huì)不會(huì)發(fā)生變化，測(cè)試團(tuán)隊(duì)的職責(zé)會(huì)不會(huì)發(fā)生變化等等。當(dāng)然，大家可以再設(shè)想下，當(dāng)未來(lái)服務(wù)數(shù)量進(jìn)一步爆炸，架構(gòu)復(fù)雜度進(jìn)一步提升，這種復(fù)雜度超過(guò)人的掌控時(shí)，會(huì)出現(xiàn)什么樣的變化，我們需要使用怎樣的工具去解決那個(gè)時(shí)候的效能問(wèn)題。

4 企業(yè)研發(fā)效能的制約因素

結(jié)合上面從人員、架構(gòu)、技術(shù)三方面的分析，在進(jìn)一步提取中間的關(guān)鍵因素，會(huì)形成這樣的一個(gè)環(huán)。這三個(gè)關(guān)鍵因素就是成本、人、和人與人之間的協(xié)同損耗。成本是不可能無(wú)限放大的，所以是這個(gè)環(huán)里面的最關(guān)鍵約束。另外因?yàn)槿说哪芰⒉畈积R，那么就無(wú)法創(chuàng)造出完美的架構(gòu)和完美的組織設(shè)置，這里面就會(huì)出現(xiàn)大量的協(xié)同消耗。剛才也提到了，技術(shù)債務(wù)是會(huì)累積的，協(xié)同消耗往往會(huì)隨著時(shí)間不斷放大，消耗更多的人力，在固定的成本約束下會(huì)導(dǎo)致更少的業(yè)務(wù)人力投入。這個(gè)環(huán)就會(huì)出現(xiàn)負(fù)反饋，也就是越來(lái)越差。所以才有了探討研發(fā)效能這個(gè)問(wèn)題的必要性。

通常會(huì)采用技術(shù)去武裝人，提升個(gè)人能力上限，這是筆者認(rèn)為的重要破局點(diǎn)。接下來(lái)需要適應(yīng)當(dāng)前團(tuán)隊(duì)組織和架構(gòu)現(xiàn)狀的協(xié)同流程，去降低損耗。需要注意的是這往往只能帶來(lái)改進(jìn)，在固有架構(gòu)和組織模式不變的情況下很難根本上改變局面。最后可以使用一些工具去讓我們的工作更有效率，以前手工做的現(xiàn)在自動(dòng)化去做，可以騰出更多時(shí)間去聚焦業(yè)務(wù)價(jià)值輸出。

三管齊下后就可以有效驅(qū)動(dòng)這個(gè)環(huán)進(jìn)入正反饋，團(tuán)隊(duì)效率更高，技能提升更快，協(xié)同更加順暢，業(yè)務(wù)發(fā)展好了又可以投入更多的人力成本。

在阿里自身的實(shí)踐中發(fā)現(xiàn)，就是在在不斷地改變這些要素，遇到瓶頸投入改進(jìn)，走出負(fù)反饋，進(jìn)入高速發(fā)展，然后又遇到瓶頸。

那么這些問(wèn)題如何系統(tǒng)化的被提升或者解決，就需要一套適合的效能工具體系。

二 效能工具體系的建設(shè)思路

1 三種典型的研發(fā)團(tuán)隊(duì)

在我們的實(shí)踐中會(huì)可以歸納出以下三種典型的研發(fā)團(tuán)隊(duì)。

• 第一種是前后臺(tái)的應(yīng)用開(kāi)發(fā)，電商、SaaS等都是典型的形態(tài)。這種業(yè)務(wù)形態(tài)在工程側(cè)比較容易標(biāo)準(zhǔn)化，工具比較完善，尤其是云原生技術(shù)的發(fā)展，讓業(yè)務(wù)的關(guān)注點(diǎn)更加向上轉(zhuǎn)移，底層技術(shù)越來(lái)越云化，越來(lái)越黑盒。
• 第二種是底層基礎(chǔ)軟件研發(fā)，業(yè)務(wù)特點(diǎn)是用戶交互簡(jiǎn)單，但技術(shù)深度和復(fù)雜性較大。這種軟件往往是有狀態(tài)服務(wù)，并且對(duì)硬件基礎(chǔ)設(shè)施有強(qiáng)依賴，以至于在運(yùn)維側(cè)就較難標(biāo)準(zhǔn)化。另外在開(kāi)發(fā)側(cè)也存在技術(shù)棧復(fù)雜，多人在一個(gè)模塊集中研發(fā)的情況，較難像前后臺(tái)應(yīng)用那樣通過(guò)服務(wù)拆分進(jìn)行解耦加快迭代，同時(shí)也衍生出比如分支管理、二進(jìn)制版本管理等新問(wèn)題。這種開(kāi)發(fā)態(tài)和運(yùn)維態(tài)的差異性導(dǎo)致了工具體系的差異。
• 第三種是線下交付型的大型軟件研發(fā)，以混合云、行業(yè)軟件為代表的。因?yàn)橄到y(tǒng)耦合復(fù)雜，疊加客戶專有環(huán)境因素，對(duì)多團(tuán)隊(duì)協(xié)同能力和交付運(yùn)維系統(tǒng)能力要求很高。相對(duì)于第一種前后臺(tái)應(yīng)用開(kāi)發(fā)，對(duì)版本管理、集成升級(jí)、遠(yuǎn)程運(yùn)維能力特別關(guān)注。

2 分層建設(shè)效能體系匹配復(fù)雜協(xié)同場(chǎng)景

因此，面對(duì)不同的研發(fā)場(chǎng)景，不同的側(cè)重點(diǎn)，需要對(duì)效能體系進(jìn)行分層和抽象。在這里可以把整個(gè)體系分為4個(gè)層次，從下到上是基礎(chǔ)底座、工具層、協(xié)同層、場(chǎng)景化。

在基礎(chǔ)底座中應(yīng)該關(guān)注產(chǎn)研核心資產(chǎn)的數(shù)據(jù)沉淀，確保整個(gè)體系的數(shù)據(jù)一致性，通常會(huì)提取研發(fā)體系中核心對(duì)象進(jìn)行下沉，比如團(tuán)隊(duì)、項(xiàng)目、應(yīng)用、代碼、制品等。

之上是最關(guān)鍵的工具層，工具定義為解決單點(diǎn)問(wèn)題的自動(dòng)化手段。其中開(kāi)放性和被集成性應(yīng)該是工具最重要的能力。比如常說(shuō)的api first就是這個(gè)道理。

再往上是協(xié)同層，這一層產(chǎn)品聚焦于解決人和人之間的信息傳遞問(wèn)題，以及將這種協(xié)同流程進(jìn)行線上化、標(biāo)準(zhǔn)化。通過(guò)對(duì)不同領(lǐng)域協(xié)同關(guān)系的抽象，并且串聯(lián)單點(diǎn)工具，最終讓使用者們可以在線完成一個(gè)完整的工作。

通用性、可配置性和體驗(yàn)有時(shí)候是矛盾的，因此還需要場(chǎng)景化層的產(chǎn)品去解決各自領(lǐng)域的精細(xì)化用戶體驗(yàn)問(wèn)題?？梢钥吹阶罱鼛啄陿I(yè)界的趨勢(shì)就是如此，通用的研發(fā)平臺(tái)在不斷成熟和做深，而場(chǎng)景化研發(fā)平臺(tái)不斷產(chǎn)生，通過(guò)集成下層工具能力，快速覆蓋細(xì)分研發(fā)場(chǎng)景。

目前云效正是按照這個(gè)分層思路在建設(shè)研發(fā)工具體系，希望可以將更多開(kāi)發(fā)者納入到這個(gè)體系中來(lái)，一同構(gòu)建這個(gè)復(fù)雜的生態(tài)系統(tǒng)。

3 每個(gè)團(tuán)隊(duì)定制自己的效能方案

公司除了提供標(biāo)準(zhǔn)化的研發(fā)流程體系以外，每個(gè)團(tuán)隊(duì)都應(yīng)該有自己的效能方案來(lái)滿足自己團(tuán)隊(duì)的文化和習(xí)慣。在這里可以有這兩三個(gè)層面可以去提供定制。

一個(gè)是團(tuán)隊(duì)工作臺(tái)，這是團(tuán)隊(duì)的知識(shí)沉淀場(chǎng)所和協(xié)同空間。里面提供多種視圖來(lái)瀏覽工作狀態(tài)以及待辦事項(xiàng)、進(jìn)度等。還會(huì)為leader提供一些列管理工具。

另外兩個(gè)是團(tuán)隊(duì)協(xié)同流程和工具，推薦大家深入學(xué)習(xí)效能提升方法、團(tuán)隊(duì)管理方法，并且結(jié)合團(tuán)隊(duì)現(xiàn)狀，個(gè)性化到系統(tǒng)中，甚至創(chuàng)新出更適合業(yè)務(wù)特點(diǎn)的工具，逐步釋放團(tuán)隊(duì)生產(chǎn)力潛能。

通過(guò)統(tǒng)一平臺(tái)可以守住團(tuán)隊(duì)效能的下限，但是效能上限需要團(tuán)隊(duì)自身的努力來(lái)突破。

4 進(jìn)一步的效能提升建議

基于以上分析，筆者提出以下三個(gè)建議：

• 第一個(gè)是團(tuán)隊(duì)需要著眼于從目標(biāo)、業(yè)務(wù)、產(chǎn)品、研發(fā)全流程進(jìn)行效能提升。舉個(gè)例子，一個(gè)問(wèn)題：測(cè)試團(tuán)隊(duì)如果成為交付瓶頸，是不是完全是測(cè)試團(tuán)隊(duì)的責(zé)任？很顯然，這里面可能是需求側(cè)用戶鏈路分析不全面，或者開(kāi)發(fā)團(tuán)隊(duì)交付質(zhì)量差，更或者是架構(gòu)設(shè)計(jì)不合理導(dǎo)致可測(cè)性不強(qiáng)等等，這些都會(huì)加重測(cè)試團(tuán)隊(duì)負(fù)擔(dān)，讓測(cè)試團(tuán)隊(duì)成為瓶頸。因此團(tuán)隊(duì)負(fù)責(zé)人需要端到端的去思考，掌握方法并具備宏觀視野，而不是頭痛醫(yī)頭腳痛醫(yī)腳。
• 第二點(diǎn)是團(tuán)隊(duì)需要為自己的效能負(fù)責(zé)，是第一責(zé)任人。自己最了解自己的團(tuán)隊(duì)，往往采取的措施也是最有效的。
• 第三點(diǎn)是提升團(tuán)隊(duì)產(chǎn)品設(shè)計(jì)能力、技術(shù)能力，減少技術(shù)債務(wù)，構(gòu)建內(nèi)建質(zhì)量對(duì)效能提升非常重要。效能工具體系只能提供最基礎(chǔ)保障，要讓團(tuán)隊(duì)效能更健康，需要從最基礎(chǔ)的軟件工程細(xì)節(jié)入手，逐步改善，在這方面沒(méi)有銀彈。

三 效能方法體系的演進(jìn)

1 從強(qiáng)調(diào)工具流程走向強(qiáng)調(diào)價(jià)值交付

當(dāng)團(tuán)隊(duì)分工開(kāi)始細(xì)化以后，從組織角度更加專業(yè)化，資源效率更高，但是從業(yè)務(wù)價(jià)值交付的角度來(lái)看，周期非常長(zhǎng)，而且中間還伴隨著各種等待。

因此可以得出這樣一個(gè)結(jié)論就是局部效率，并不代表可以高效的交付業(yè)務(wù)需求。局部效率有很多工具和手段去提升，這是一個(gè)相對(duì)收斂的問(wèn)題，甚至可以通過(guò)加班去彌補(bǔ)效率的不足，但是高效的交付用戶能夠感知到的業(yè)務(wù)價(jià)值并不容易做到，上面這張圖就說(shuō)明了這一點(diǎn)。同樣也并不代表可以持續(xù)的高效交付，因?yàn)閺谋驹瓷蠜](méi)有辦法保障永遠(yuǎn)用全局最優(yōu)的組織和架構(gòu)以及流程去對(duì)應(yīng)，甚至沒(méi)有機(jī)制去發(fā)現(xiàn)瓶頸問(wèn)題。當(dāng)然也并沒(méi)有辦法去回答業(yè)務(wù)成功問(wèn)題，因?yàn)闃I(yè)務(wù)團(tuán)隊(duì)與產(chǎn)研團(tuán)隊(duì)距離過(guò)遠(yuǎn)，這種部門墻阻斷了產(chǎn)研去思考和理解業(yè)務(wù)成功與自己產(chǎn)出的關(guān)系。

2 實(shí)現(xiàn)端到端可見(jiàn)的業(yè)務(wù)價(jià)值

所以筆者認(rèn)為效能提升首先要做到的就是端到端可見(jiàn)的業(yè)務(wù)價(jià)值。從業(yè)務(wù)團(tuán)隊(duì)到產(chǎn)研團(tuán)隊(duì)有以下幾個(gè)實(shí)施路徑。首先是建立以業(yè)務(wù)價(jià)值流為視角的協(xié)作鏈路。以往多半是通過(guò)項(xiàng)目管理軟件解決產(chǎn)研團(tuán)隊(duì)的協(xié)作問(wèn)題，以一個(gè)產(chǎn)品或者團(tuán)隊(duì)為單位組織需求、缺陷、任務(wù)等等。在新的體系中需要將業(yè)務(wù)團(tuán)隊(duì)也納入其中，并且拉通業(yè)務(wù)價(jià)值與產(chǎn)品研發(fā)需求、任務(wù)之間的關(guān)系，從而實(shí)現(xiàn)端到端透明可視。

在產(chǎn)研側(cè)采納大量自動(dòng)化工具仍然是基礎(chǔ)工作，除此之外需要將工具產(chǎn)出的數(shù)據(jù)能夠鏈接到價(jià)值流上，并且盡量沉淀到數(shù)據(jù)平臺(tái)。這里可以采用比較簡(jiǎn)單的評(píng)判方法，比如有多少百分比的工作是在線完成的，是否有統(tǒng)一的數(shù)據(jù)模型去積累數(shù)據(jù)。

在前面兩步完成后，仍然要解決對(duì)齊業(yè)務(wù)、產(chǎn)品、技術(shù)團(tuán)隊(duì)目標(biāo)的問(wèn)題，比如業(yè)務(wù)訴求的優(yōu)先級(jí)是什么，時(shí)間點(diǎn)是什么，其中的各環(huán)節(jié)瓶頸是什么，并且在過(guò)程中實(shí)時(shí)追蹤。各環(huán)節(jié)負(fù)責(zé)人可以感知到異常事件和資源瓶頸，第一時(shí)間去著手解決，達(dá)到高效的目的。

第三步要做到持續(xù)高效，一定要基于前面積累的數(shù)據(jù)去量化分析，此時(shí)數(shù)據(jù)的魅力得到展現(xiàn)，越多的工作在線，分析會(huì)越準(zhǔn)確。哪個(gè)團(tuán)隊(duì)在積累債務(wù)，哪個(gè)團(tuán)隊(duì)在積累資產(chǎn)，哪個(gè)團(tuán)隊(duì)是阻塞點(diǎn)，是調(diào)整架構(gòu)還是調(diào)整組織分工，這種決策會(huì)更加有效率。

3 ALPD—新一代的精益產(chǎn)品開(kāi)發(fā)方法

基于以上的分析，再結(jié)合了精益思想、云思想、以及架構(gòu)設(shè)計(jì)思想等多方面，可以構(gòu)建出來(lái)的一套方法體系。

這個(gè)圖藍(lán)色部分是本文關(guān)注的重點(diǎn)。其中分為三個(gè)部分，全鏈路數(shù)字化的精益協(xié)作，解決業(yè)務(wù)和產(chǎn)品技術(shù)協(xié)作問(wèn)題。第二部分是領(lǐng)域驅(qū)動(dòng)為核心的技術(shù)實(shí)踐，解決日益復(fù)雜的架構(gòu)問(wèn)題。第三部分是云原生的工程實(shí)踐，用這套工程實(shí)踐去進(jìn)一步釋放云原生對(duì)每一個(gè)業(yè)務(wù)開(kāi)發(fā)者的紅利。

4 全鏈路的精益協(xié)作

首先全鏈路的精益協(xié)作。之所以稱為全鏈路是在這個(gè)方法中將業(yè)務(wù)、產(chǎn)品、技術(shù)等多種角色全部納入。最關(guān)鍵的是分層理念，分為業(yè)務(wù)、產(chǎn)品和技術(shù)三部分。分別對(duì)應(yīng)業(yè)務(wù)和目標(biāo)管理、需求和產(chǎn)品管理和團(tuán)隊(duì)交付視圖。

在這個(gè)模型下，配合一系列高效率在線化工具，讓盡可能多的工作在線完成，數(shù)據(jù)以價(jià)值流為核心串聯(lián)和透明化，最終達(dá)成精益協(xié)作的目標(biāo)。

5 領(lǐng)域?yàn)楹诵牡募夹g(shù)實(shí)踐

再來(lái)看領(lǐng)域?yàn)楹诵牡募夹g(shù)實(shí)踐。這里分為三個(gè)部分，分析、架構(gòu)以及對(duì)應(yīng)的實(shí)現(xiàn)。分別為業(yè)務(wù)引領(lǐng)的領(lǐng)域建模、領(lǐng)域驅(qū)動(dòng)的微服務(wù)架構(gòu)、以及契約導(dǎo)向的軟件實(shí)現(xiàn)。

領(lǐng)域模型的設(shè)計(jì)是產(chǎn)品以及架構(gòu)設(shè)計(jì)的核心，良好的設(shè)計(jì)可以輕松地解決技術(shù)團(tuán)隊(duì)的變更、測(cè)試、交付耦合問(wèn)題，提升系統(tǒng)可測(cè)性和可運(yùn)維性，并且通過(guò)一些防腐設(shè)計(jì)，降低技術(shù)債務(wù)對(duì)整個(gè)系統(tǒng)的影響。

6 云原生的工程實(shí)踐

最后是云原生工程實(shí)踐。這張圖把工程實(shí)踐分為了三個(gè)部分，最底層是不可變基礎(chǔ)設(shè)施，中間是持續(xù)交付流水線，最上層是質(zhì)量守護(hù)體系。

重點(diǎn)在中間紅色部分，也就是GitOps Engine，用這個(gè)引擎來(lái)全面落地所謂的以應(yīng)用為中心的IaC體系。筆者認(rèn)為IaC的設(shè)計(jì)是開(kāi)發(fā)者對(duì)云的運(yùn)維界面和使用方法的重大重構(gòu)。通過(guò)代碼這種最符合開(kāi)發(fā)者習(xí)慣的形式，疊加開(kāi)放更多自定義能力，可以進(jìn)一步釋放云原生的技術(shù)紅利。

作者 | 神秀

原文鏈接：http://click.aliyun.com/m/1000288975/

本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。