當(dāng)今的汽車(chē)與數(shù)年前的汽車(chē)相比，雖然作為載具的主要目的變化不大，但不論是駕乘體驗(yàn)、智能化水平還是交互方式，都發(fā)生了質(zhì)的飛躍。

為了能支撐新一代汽車(chē)所提供的這種智能化服務(wù)水平，顯而易見(jiàn)：

需要將軟件平臺(tái)與硬件平臺(tái)相互分離和抽象以提升靈活性。

這種被稱(chēng)為軟件定義汽車(chē)（Software Defined Vehicle，下文簡(jiǎn)稱(chēng)為SDV）的設(shè)計(jì)方法基于更加靈活和易于擴(kuò)展的軟件作為汽車(chē)的核心，將傳統(tǒng)的汽車(chē)升級(jí)為擁有諸如智能駕駛、深度娛樂(lè)、個(gè)性化人機(jī)交互能力的 “第三空間”。

SDV 帶來(lái)了一系列汽車(chē)設(shè)計(jì)的革命性跨越，同時(shí)也引入了各種新的困難。諸如性能、可靠性、安全性、易用性等在軟件領(lǐng)域長(zhǎng)期存在的跨領(lǐng)域、跨業(yè)務(wù)型挑戰(zhàn)，隨著 SDV 被一并引入了汽車(chē)領(lǐng)域。

一、為什么車(chē)企不容易做好軟件性能

“車(chē)機(jī)卡頓”故障常年在汽車(chē)投訴榜單上擁有一席之地，性能問(wèn)題除了影響乘駕體驗(yàn)，有些情況下甚至?xí)斐晌ｋU(xiǎn)，如導(dǎo)航系統(tǒng)的卡頓會(huì)嚴(yán)重干擾駕駛員的決策。

既然汽車(chē)行業(yè)和軟件行業(yè)都已發(fā)展多年，那為什么在軟件定義汽車(chē)之后，車(chē)企不容易做好軟件性能呢？

1.無(wú)可避免的本質(zhì)復(fù)雜性

軟件領(lǐng)域沒(méi)有新鮮事，從單體到分布式，從多任務(wù)到多實(shí)例，軟件領(lǐng)域所面臨的挑戰(zhàn)總是伴隨著業(yè)務(wù)形式和組織形式的發(fā)展。

一切問(wèn)題源于復(fù)雜性。就像冤家路窄的擴(kuò)展性和性能，隨著軟件規(guī)模的擴(kuò)大，擴(kuò)展性差會(huì)降低研發(fā)效率，而擴(kuò)展性要求的層層抽象卻會(huì)成為軟件性能設(shè)計(jì)的掣肘。

由于軟件本身的架構(gòu)靈活性，其功能構(gòu)造十分易于修改和擴(kuò)展，這也使得在表面上看，軟件的規(guī)模似乎可以不受限制的擴(kuò)大。但人類(lèi)大腦的認(rèn)知邊界限制導(dǎo)致了軟件規(guī)模的擴(kuò)大同樣也意味著協(xié)作規(guī)模的擴(kuò)大，這種大規(guī)模的軟件協(xié)作體系，讓軟件的復(fù)雜度成倍提升。

任何軟件在規(guī)模擴(kuò)張的過(guò)程中都容易陷入兩類(lèi)本質(zhì)復(fù)雜性的泥潭：

晦澀性：軟件研發(fā)的過(guò)程可以看做是知識(shí)傳遞和轉(zhuǎn)換的過(guò)程，大規(guī)模軟件的領(lǐng)域知識(shí)不掌握在任何單一個(gè)體的腦中，更復(fù)雜的分工也造成了知識(shí)傳遞過(guò)程中的失真。若不加以治理，這種晦澀性最終會(huì)導(dǎo)致整個(gè)軟件系統(tǒng)無(wú)法被理解。

依賴(lài)性：大規(guī)模軟件通常都包含了十分復(fù)雜的層次結(jié)構(gòu)，其模塊和組件之間通過(guò)各種形式的接口耦合相互依賴(lài)從而形成整體。但這種依賴(lài)性絕大多數(shù)時(shí)候是級(jí)聯(lián)的，一旦處理不好，某個(gè)邊緣組件的修改可能突然導(dǎo)致其他看似毫不相關(guān)的組件發(fā)生故障。

不出意外，為了實(shí)現(xiàn)各種高階智能化特性，SDV 驅(qū)動(dòng)的汽車(chē)軟件系統(tǒng)滿(mǎn)足了復(fù)雜軟件系統(tǒng)的一切特征。

圖源：智能網(wǎng)聯(lián)汽車(chē)電子電氣架構(gòu)產(chǎn)業(yè)技術(shù)路線圖

以上圖所示的汽車(chē)軟件功能架構(gòu)為例，汽車(chē)軟件的架構(gòu)具有業(yè)務(wù)繁雜、技術(shù)棧深、安全性要求高的特點(diǎn)。與其他行業(yè)如手機(jī)制造、互聯(lián)網(wǎng)平臺(tái)等的軟硬件架構(gòu)相比，汽車(chē)軟件在各架構(gòu)層級(jí)中的標(biāo)準(zhǔn)化程度更低，研發(fā)定制化的場(chǎng)景也更多，而整個(gè)汽車(chē)產(chǎn)業(yè)鏈中的各類(lèi)供應(yīng)商更是層出不窮。

以上現(xiàn)狀決定了汽車(chē)軟件研發(fā)過(guò)程中，業(yè)務(wù)交互復(fù)雜、架構(gòu)設(shè)計(jì)復(fù)雜、團(tuán)隊(duì)協(xié)作復(fù)雜。

2.性能是一種橫跨軟件全業(yè)務(wù)、全生命周期的架構(gòu)特性

架構(gòu)特性（Architecture Characteristics）是架構(gòu)師在設(shè)計(jì)軟件時(shí)需要考慮的與領(lǐng)域或業(yè)務(wù)需求無(wú)關(guān)的軟件特性，如可審計(jì)性、性能、安全性、可伸縮性、可靠性等等。在很多時(shí)候我們也會(huì)稱(chēng)之為非功能性需求（Nonfunctional Requirements）或質(zhì)量屬性（Quality Attributes）。

在 ISO/IEC 25010:2011 中，性能效率是軟件質(zhì)量模型中的一項(xiàng)關(guān)鍵架構(gòu)特性，模型中將性能效率更具體的描述為軟件的“時(shí)間特性”、“資源利用率”和“容量”等。

顯然，軟件性能作為一種橫跨業(yè)務(wù)和軟件生命周期的通用架構(gòu)特性，性能的優(yōu)劣在許多關(guān)鍵業(yè)務(wù)場(chǎng)景下都決定著客戶(hù)的使用意愿，而為了構(gòu)建高性能的軟件系統(tǒng)，從軟件的設(shè)計(jì)之初就需要開(kāi)始考慮性能。

當(dāng)性能特性需要橫跨復(fù)雜的汽車(chē)軟件系統(tǒng)時(shí)，就會(huì)面臨跨技術(shù)領(lǐng)域、跨業(yè)務(wù)領(lǐng)域和跨團(tuán)隊(duì)領(lǐng)域的三類(lèi)挑戰(zhàn)。

以導(dǎo)航功能為例：導(dǎo)航作為車(chē)上非常關(guān)鍵的應(yīng)用，如果出現(xiàn)遲滯、卡頓、退出等問(wèn)題，會(huì)嚴(yán)重影響用戶(hù)的駕車(chē)體驗(yàn)。因此為了確保導(dǎo)航使用的流暢性，在運(yùn)行時(shí)需要有更多的系統(tǒng)資源，以及更穩(wěn)定的運(yùn)行環(huán)境。

操作響應(yīng)快要求導(dǎo)航進(jìn)程的調(diào)度優(yōu)先級(jí)更高，連續(xù)讀圖要求 IO 排隊(duì)時(shí)間短，畫(huà)面渲染涉及如 Unity3D 等的第三方庫(kù)以及 GPU 資源，另外導(dǎo)航中的一些輔助功能如AI語(yǔ)音，畫(huà)面共享等則需要調(diào)用其他組件的能力。

因此對(duì)于導(dǎo)航這項(xiàng)關(guān)鍵功能，如果發(fā)現(xiàn)性能故障，其定位和優(yōu)化的過(guò)程可能牽涉多個(gè)業(yè)務(wù)領(lǐng)域，以及包括應(yīng)用層、中間件層和系統(tǒng)層等多個(gè)技術(shù)層，此外還可能會(huì)牽扯信息安全、體驗(yàn)一致性以及系統(tǒng)可靠性等諸多問(wèn)題。

二、性能持續(xù)提升的工程化方法

性能作為一種在復(fù)雜軟件環(huán)境下的跨領(lǐng)域架構(gòu)特性，性能優(yōu)化工作很容易陷入“性能不佳 -> 問(wèn)題拖延 -> 間歇性?xún)?yōu)化 -> 再次劣化”的循環(huán)。

我們期望通過(guò)一種工程化的方法，來(lái)管理和運(yùn)營(yíng)軟件性能，從而實(shí)現(xiàn)持續(xù)的性能守護(hù)和提升。

工程化方法一般指通過(guò)科學(xué)的方法和標(biāo)準(zhǔn)化的流程，來(lái)提升項(xiàng)目的效率和質(zhì)量。因此對(duì)于 “性能優(yōu)化” 這樣的課題，可以通過(guò)如下五個(gè)方面的實(shí)踐來(lái)實(shí)現(xiàn)工程化，即性能工程。

系統(tǒng)方法論：性能優(yōu)化的體系化方法，可參照如《性能之巔》等的性能分析和優(yōu)化方法論。

標(biāo)準(zhǔn)化流程和規(guī)范：定義如性能建模以及自動(dòng)化方法（如適應(yīng)度函數(shù)）等的標(biāo)準(zhǔn)化流程，提升效率。

成熟的技術(shù)支持：需要的知識(shí)、技術(shù)能力和人才，其中領(lǐng)域?qū)＜?、性能?zhuān)家和工程專(zhuān)家這三類(lèi)角色非常關(guān)鍵。

全生命周期管理：類(lèi)似 DevOps 的方式，對(duì)軟件全生命周期的性能優(yōu)化活動(dòng)進(jìn)行定義。

持續(xù)改進(jìn)：通過(guò)持續(xù)觀測(cè)、持續(xù)看護(hù)等手段將性能優(yōu)化的實(shí)踐持續(xù)運(yùn)行。

有關(guān)性能工程更多的細(xì)節(jié)，請(qǐng)見(jiàn)《什么是性能工程》。

下文將從性能觀測(cè)、性能調(diào)優(yōu)、性能團(tuán)隊(duì)三個(gè)角度，介紹上述工程化方法的五個(gè)方面在 SDV 研發(fā)中的落地實(shí)踐。

1.持續(xù)性能觀測(cè)

性能優(yōu)化的前提是能夠?qū)π阅苓M(jìn)行客觀的評(píng)估，通過(guò)構(gòu)建對(duì)系統(tǒng)的觀測(cè)能力，我們能盡可能多的了解系統(tǒng)現(xiàn)狀，從而為之后的性能看護(hù)和優(yōu)化提供評(píng)估依據(jù)。

(1) 建立評(píng)估模型

性能評(píng)估模型作為性能建?；顒?dòng)的產(chǎn)出物之一，在系統(tǒng)建設(shè)之初就可以著手開(kāi)展，同時(shí)，評(píng)估模型也需要隨著產(chǎn)品的不斷迭代，融入更多業(yè)務(wù)和技術(shù)指標(biāo)，以準(zhǔn)確的描述系統(tǒng)性能要求。

指標(biāo)模型一般可分為業(yè)務(wù)指標(biāo)，系統(tǒng)指標(biāo)和資源指標(biāo)。

業(yè)務(wù)指標(biāo)更偏向于黑盒指標(biāo)，以最貼近用戶(hù)使用的角度描述產(chǎn)品性能特性。

系統(tǒng)指標(biāo)則更多地貼近白盒指標(biāo)，描述系統(tǒng)運(yùn)行過(guò)程中的內(nèi)部狀態(tài)，它們會(huì)間接影響到業(yè)務(wù)指標(biāo)。

而資源指標(biāo)是作為前兩種指標(biāo)的補(bǔ)充，獨(dú)立評(píng)估資源指標(biāo)沒(méi)有意義，但與其他指標(biāo)相結(jié)合后能夠更準(zhǔn)確的描述系統(tǒng)狀況。

嘗試落地持續(xù)性能優(yōu)化的過(guò)程中，最困難的部分就是建立評(píng)估模型，因?yàn)樵u(píng)估模型代表性能目標(biāo)。（關(guān)于評(píng)估模型的建立，請(qǐng)參考《智能座艙軟件性能與可靠性的評(píng)估和改進(jìn)》）

如果評(píng)估模型設(shè)計(jì)的有偏差，很容易導(dǎo)致花了不少時(shí)間建立的模型，關(guān)鍵的性能點(diǎn)沒(méi)有納入其中。基于這種模型進(jìn)行優(yōu)化迭代，會(huì)讓團(tuán)隊(duì)產(chǎn)生一種錯(cuò)覺(jué)：花了大力氣建設(shè)的觀測(cè)系統(tǒng)，派不上用場(chǎng)，因?yàn)榧词故怯^測(cè)到指標(biāo)在改善，系統(tǒng)的性能看上去似乎仍舊不佳。

這也反過(guò)來(lái)會(huì)讓團(tuán)隊(duì)產(chǎn)生懷疑：性能觀測(cè)和性能優(yōu)化到底有關(guān)系嗎？在這種自我懷疑中，性能團(tuán)隊(duì)的工作就很容易陷入《性能之巔》中提到的一些反模式，如街燈訛方法或隨機(jī)變動(dòng)訛方法。

(2) 定制可擴(kuò)展的觀測(cè)工具

為了有效地評(píng)估系統(tǒng)，觀測(cè)工具是必不可少的。對(duì)于評(píng)估模型中的各類(lèi)指標(biāo)，大多數(shù)都可以通過(guò)既有的工具進(jìn)行收集。而為了更好的發(fā)現(xiàn)問(wèn)題，業(yè)內(nèi)也存在眾多可對(duì)系統(tǒng)進(jìn)行剖析的追蹤工具。

因此建立觀測(cè)系統(tǒng)的主要目標(biāo)是整合各類(lèi)零散的觀測(cè)工具，形成完整且易用的系統(tǒng)性能觀測(cè)能力。除了傳統(tǒng)的工具整合，觀測(cè)系統(tǒng)的可定制化以及開(kāi)銷(xiāo)也值得關(guān)注。

最簡(jiǎn)單的觀測(cè)系統(tǒng)可分為設(shè)備上的探針前端以及上位機(jī)或服務(wù)器上的分析后端。由于直接運(yùn)行在設(shè)備上，探針自身的開(kāi)銷(xiāo)不容忽視，因此通常性能探針都包含細(xì)粒度的配置能力，在研發(fā)或測(cè)試階段，打開(kāi)全部或大部分開(kāi)關(guān)，而在生產(chǎn)運(yùn)行階段只打開(kāi)部分開(kāi)銷(xiāo)低的信息收集功能。

為了擴(kuò)展探針的系統(tǒng)級(jí)觀測(cè)能力，通過(guò) eBPF 對(duì)內(nèi)核行為進(jìn)行觀測(cè)是一種安全且高效的方式，基于 eBPF，可以方便的對(duì)調(diào)度、內(nèi)存、IO和網(wǎng)絡(luò)進(jìn)行定制化觀測(cè)。

除了開(kāi)銷(xiāo)，在生產(chǎn)運(yùn)行階段，還需要考慮數(shù)據(jù)的隱私合規(guī)以及網(wǎng)絡(luò)流量等方面的限制。因此數(shù)據(jù)脫敏、加密和壓縮也應(yīng)作為重要的設(shè)計(jì)考量。

(3) 性能看護(hù)

擁有了評(píng)估模型后，通過(guò)模型建立系統(tǒng)的性能基線，就能夠在系統(tǒng)迭代過(guò)程中不斷地評(píng)估系統(tǒng)的性能是優(yōu)化還是劣化。

從前文可知，評(píng)估模型包含了一組用于描述不同系統(tǒng)特征的指標(biāo)，因此實(shí)際建立的性能基線就是一組指標(biāo)向量。顯然，性能指標(biāo)基線的建立，需要反復(fù)地、大量的對(duì)系統(tǒng)進(jìn)行性能測(cè)試，之后取統(tǒng)計(jì)值作為基線，才具有評(píng)估價(jià)值。

不論是建立性能基線，還是基于兩組不同的指標(biāo)向量進(jìn)行性能看護(hù)，都應(yīng)采用一些基礎(chǔ)的統(tǒng)計(jì)學(xué)方法來(lái)使評(píng)估和看護(hù)更客觀。

首先，需要對(duì)采集到的指標(biāo)樣本進(jìn)行正態(tài)性檢驗(yàn)。如果指標(biāo)樣本不符合正態(tài)分布，則需要對(duì)樣本進(jìn)行數(shù)據(jù)矯正，或是調(diào)研采樣過(guò)程是否存在偏斜。符合正態(tài)分布的樣本是進(jìn)一步統(tǒng)計(jì)學(xué)對(duì)比的前提。

其次，由于指標(biāo)眾多，加之優(yōu)化或劣化可能僅體現(xiàn)在某些指標(biāo)上。因此在性能測(cè)試樣本與性能基線的對(duì)比過(guò)程中，可通過(guò)諸如 t 檢驗(yàn)的一類(lèi)方法，計(jì)算每個(gè)指標(biāo)變化的顯著性水平，來(lái)客觀的評(píng)價(jià)指標(biāo)值是否發(fā)生了顯著的變化。

最后，考慮到優(yōu)化成本和實(shí)際的收效，系統(tǒng)略微的劣化，可能不值得進(jìn)行大刀闊斧的優(yōu)化活動(dòng)。因此除了顯著性水平的判斷，還可通過(guò)計(jì)算效應(yīng)量來(lái)判斷實(shí)際發(fā)生的劣化/優(yōu)化是否明顯對(duì)系統(tǒng)產(chǎn)生了影響，進(jìn)而幫助工程師進(jìn)行決策。

2.持續(xù)性能改進(jìn)

在發(fā)現(xiàn)性能問(wèn)題后，如何改進(jìn)且持續(xù)的改進(jìn)性能就變成了第一要?jiǎng)?wù)。

(1) TopDown 分析與問(wèn)題建模

一般情況下，性能問(wèn)題都是由業(yè)務(wù)現(xiàn)象或是黑盒指標(biāo)異常所產(chǎn)生的，這類(lèi)問(wèn)題的特點(diǎn)就在于表象之下深層次的原因往往被各種紛繁復(fù)雜的噪聲所掩蓋。而遇到這類(lèi)問(wèn)題最先冒出來(lái)的想法都是隨機(jī)試錯(cuò)，這時(shí)我們會(huì)極度相信大腦所冒出的第一個(gè)可能原因，并有強(qiáng)烈的試一試看看的沖動(dòng)。

然而隨機(jī)試錯(cuò)法不僅是片面的，也是低效的。更科學(xué)的分析方法是對(duì)問(wèn)題建模，從負(fù)載和資源的角度更準(zhǔn)確的定義問(wèn)題，之后基于被測(cè)系統(tǒng)的架構(gòu)進(jìn)行自頂向下的分析，作出假設(shè)后采用客觀的測(cè)試方法進(jìn)行驗(yàn)證。

這里舉一個(gè)問(wèn)題建模的簡(jiǎn)單例子。系統(tǒng)被測(cè)試用戶(hù)認(rèn)為使用流暢度不佳。在分析該問(wèn)題之前，首先需要定義清楚問(wèn)題：系統(tǒng)發(fā)生不流暢時(shí)，負(fù)載是怎樣的？幀率是一種能夠描述系統(tǒng)渲染負(fù)載的黑盒指標(biāo)，如果低于正常值表明渲染過(guò)程存在高負(fù)載，否則就需要進(jìn)一步調(diào)查各業(yè)務(wù)階段的完成時(shí)間。此外，系統(tǒng)發(fā)生不流暢時(shí)，資源是怎樣的？對(duì)硬件資源（CPU、內(nèi)存、磁盤(pán)）以及軟件資源（鎖、線程、連接）的爭(zhēng)用情況進(jìn)行分析，能夠?qū)ο到y(tǒng)所處狀態(tài)做出進(jìn)一步描述。

(2) 構(gòu)建微基準(zhǔn)測(cè)試

對(duì)性能問(wèn)題進(jìn)行建模之后，可能的優(yōu)化路徑也許已經(jīng)逐漸清晰，但在著手嘗試實(shí)施優(yōu)化之前，設(shè)計(jì)相關(guān)的微基準(zhǔn)測(cè)試也是十分必要的。相比于浮現(xiàn)出性能問(wèn)題的業(yè)務(wù)現(xiàn)象或黑盒指標(biāo)，微基準(zhǔn)測(cè)試能從更細(xì)粒度的方向?qū)ο到y(tǒng)進(jìn)行測(cè)試，它排除了不相干的噪聲干擾，可以專(zhuān)注于對(duì)性能優(yōu)化點(diǎn)所影響的指標(biāo)進(jìn)行測(cè)試。

例如在對(duì)前臺(tái)應(yīng)用卡頓問(wèn)題進(jìn)行優(yōu)化的時(shí)候，經(jīng)過(guò)建模和分析，我們假設(shè)卡頓的原因可能是由于在系統(tǒng)負(fù)載較高時(shí)，渲染線程難以及時(shí)被調(diào)度到 CPU 上，導(dǎo)致渲染不及時(shí)。那么對(duì)于這種假設(shè)，我們就需要構(gòu)建一組基準(zhǔn)測(cè)試，包括一個(gè)負(fù)載生成器，能夠?yàn)橄到y(tǒng)施加一定程度的負(fù)載，使之達(dá)到測(cè)試條件。也包含一個(gè)能夠探測(cè)并記錄應(yīng)用調(diào)度延遲的工具。之后通過(guò)一個(gè)測(cè)試腳本，一邊生成負(fù)載，一邊運(yùn)行被測(cè)應(yīng)用，測(cè)試完成后能夠打印過(guò)程中的調(diào)度延遲變化?；谶@樣一組微基準(zhǔn)測(cè)試，就能夠相對(duì)獨(dú)立的測(cè)試對(duì)前臺(tái)應(yīng)用調(diào)度延遲的優(yōu)化程度。

(3) 優(yōu)化驅(qū)動(dòng)模型迭代

在性能優(yōu)化工作中，必須認(rèn)識(shí)到軟件的迭代性，隨著軟件的不斷迭代更新，原本可用的優(yōu)化手段其效果可能會(huì)慢慢變差甚至失效。因此對(duì)優(yōu)化本身的看護(hù)也很關(guān)鍵。

舉例說(shuō)明，IO 預(yù)讀是一種縮短系統(tǒng)啟動(dòng)時(shí)間的方法，通過(guò)將啟動(dòng)過(guò)程中少量多次的 IO 操作進(jìn)行合并以減少總體開(kāi)銷(xiāo)，從而達(dá)到縮短時(shí)間的目的。但預(yù)讀優(yōu)化要求能提前獲悉啟動(dòng)過(guò)程中所有代碼實(shí)際讀寫(xiě)的文件，這種信息勢(shì)必會(huì)跟隨軟件迭代而變化，那么預(yù)讀的內(nèi)容也需要一起更新才能確保有效。

為了能及時(shí)發(fā)現(xiàn)優(yōu)化效果減弱的情況，基于優(yōu)化本身可以提取出與之相關(guān)的檢測(cè)項(xiàng)，可作為白盒指標(biāo)納入評(píng)估模型，最好能通過(guò)相應(yīng)的適應(yīng)度函數(shù)來(lái)自動(dòng)化評(píng)估。仍舊回到預(yù)讀的例子，為了能讓預(yù)讀的內(nèi)容跟得上軟件本身的變化，可以構(gòu)建一個(gè)自動(dòng)化的適應(yīng)度函數(shù)：

在每個(gè)新版本發(fā)布后，自動(dòng)執(zhí)行一次，獲取啟動(dòng)過(guò)程的讀寫(xiě)文件列表，與實(shí)施優(yōu)化的文件列表（這就是基線）進(jìn)行對(duì)比，當(dāng)發(fā)現(xiàn)差異度大于 30% 時(shí)報(bào)警。

通過(guò)這樣的方式，就能持續(xù)確保優(yōu)化的有效性，且一旦建立后就不再需要人工干預(yù)。

3.性能工程團(tuán)隊(duì)

對(duì)于前文提到的性能工程方法，如果沒(méi)有一個(gè)專(zhuān)業(yè)化團(tuán)隊(duì)來(lái)負(fù)責(zé)推進(jìn)，是難以最終在組織中落地生根的。就像在工程化五大實(shí)踐中提到的，成熟的技術(shù)支持必不可少。

對(duì)于構(gòu)建性能工程，需要組建一個(gè)分別包含了領(lǐng)域?qū)＜?、性能?zhuān)家和工程專(zhuān)家的專(zhuān)業(yè)化團(tuán)隊(duì)。

在 Matthew Skelton 和 Manuel Pais 的《團(tuán)隊(duì)拓?fù)洹分?，描述了四種基本的團(tuán)隊(duì)類(lèi)型：

圖片來(lái)自：Organizing Agile Teams and ARTs: Team Topologies at Scale

業(yè)務(wù)流團(tuán)隊(duì)：匹配業(yè)務(wù)領(lǐng)域和組織能力的端到端交付團(tuán)隊(duì)。

賦能團(tuán)隊(duì)：特定技術(shù)領(lǐng)域或產(chǎn)品領(lǐng)域的專(zhuān)家，為業(yè)務(wù)流團(tuán)隊(duì)賦能。

復(fù)雜子系統(tǒng)團(tuán)隊(duì)：構(gòu)建和維護(hù)系統(tǒng)中嚴(yán)重依賴(lài)專(zhuān)業(yè)領(lǐng)域知識(shí)的子系統(tǒng)。

平臺(tái)團(tuán)隊(duì)：為產(chǎn)品導(dǎo)向團(tuán)隊(duì)構(gòu)建能提供自服務(wù)的各項(xiàng)基礎(chǔ)能力。

有趣的是，我們?cè)谛阅芄こ痰膶?shí)踐過(guò)程中，發(fā)現(xiàn)性能工程團(tuán)隊(duì)是一個(gè)融合了包括 “賦能”、“復(fù)雜子系統(tǒng)”和“平臺(tái)”三種類(lèi)型的團(tuán)隊(duì)：

當(dāng)負(fù)責(zé)協(xié)助業(yè)務(wù)流團(tuán)隊(duì)對(duì)具體的產(chǎn)品或組件進(jìn)行性能診斷和優(yōu)化時(shí)，性能工程團(tuán)隊(duì)是賦能團(tuán)隊(duì)；

當(dāng)對(duì)系統(tǒng)層面實(shí)施性能優(yōu)化時(shí)，性能工程團(tuán)隊(duì)變?yōu)閺?fù)雜子系統(tǒng)團(tuán)隊(duì)；

而當(dāng)構(gòu)建性能建模、性能觀測(cè)等平臺(tái)化能力時(shí)，性能工程團(tuán)隊(duì)又成為了平臺(tái)團(tuán)隊(duì)。

能有效承擔(dān)上述工作職責(zé)，與團(tuán)隊(duì)本身的成員構(gòu)成密不可分。

在 SDV 的語(yǔ)境下，領(lǐng)域?qū)＜倚枰煜ぼ?chē)載系統(tǒng)在不同場(chǎng)景下的業(yè)務(wù)構(gòu)成及其性能要求，性能評(píng)估模型中的業(yè)務(wù)指標(biāo)，也大都是由領(lǐng)域?qū)＜一跇I(yè)務(wù)經(jīng)驗(yàn)給出的。領(lǐng)域?qū)＜也灰欢ㄩL(zhǎng)期在性能工程團(tuán)隊(duì)工作，TA 可能是技術(shù)架構(gòu)師，業(yè)務(wù)分析師或產(chǎn)品經(jīng)理，但結(jié)合業(yè)務(wù)和性能的跨領(lǐng)域能力十分關(guān)鍵。

性能專(zhuān)家深諳性能觀測(cè)和性能優(yōu)化的各種原理，方法和實(shí)踐，同時(shí)也需要熟悉整個(gè)系統(tǒng)架構(gòu)。在整車(chē)軟件架構(gòu)中，因不同功能域?qū)?shí)時(shí)性要求的不同，通常會(huì)采用虛擬化技術(shù)在同一硬件平臺(tái)上運(yùn)行多套系統(tǒng)。虛擬化產(chǎn)生的資源抽象和隔離會(huì)對(duì)性能優(yōu)化產(chǎn)生很大的影響。例如，若性能專(zhuān)家不了解虛擬化層對(duì)計(jì)算資源的抽象，在 Guest 系統(tǒng)中盲目進(jìn)行大小核、調(diào)頻等優(yōu)化，不僅不一定有效，還可能導(dǎo)致出現(xiàn)未知的行為。

工程專(zhuān)家則主要參與優(yōu)化的落地，平臺(tái)的搭建以及對(duì)業(yè)務(wù)團(tuán)隊(duì)賦能等任務(wù)。工程專(zhuān)家是經(jīng)驗(yàn)豐富的工程師，排查業(yè)務(wù)團(tuán)隊(duì)的性能故障要求 TA 熟悉 Android、Linux 或 AUTOSAR 的開(kāi)發(fā)；搭建觀測(cè)系統(tǒng)以及平臺(tái)能力要求 TA 熟悉數(shù)據(jù)工程、網(wǎng)絡(luò)通信、云原生服務(wù)等；而包括編譯工具鏈、DevOps、測(cè)試工具開(kāi)發(fā)等研發(fā)相關(guān)的能力也不可或缺。

當(dāng)然一步到位的組建出這樣的“六邊形”團(tuán)隊(duì)不是件容易的事，但組織只要嘗試開(kāi)始構(gòu)建性能工程，相信最初不勝任的團(tuán)隊(duì)，其能力也會(huì)隨著性能工程成熟度的不斷提升，而最終成為勝任的團(tuán)隊(duì)。

總結(jié)

最后總結(jié)一下，由于智能網(wǎng)聯(lián)汽車(chē)與傳統(tǒng)汽車(chē)在功能上的巨大差異，為了靈活性和迭代速度，軟件定義汽車(chē)的理念勢(shì)在必行。然而軟件的兩種本質(zhì)復(fù)雜性，晦澀性和依賴(lài)性，疊加性能本身的跨領(lǐng)域特性，導(dǎo)致車(chē)企不容易做好軟件性能。

我們嘗試通過(guò)工程化的手段持續(xù)提升汽車(chē)軟件的性能，其中包含了一些實(shí)踐：

構(gòu)建系統(tǒng)觀測(cè)能力，了解系統(tǒng)現(xiàn)狀，為性能看護(hù)和優(yōu)化提供評(píng)估依據(jù)。

通過(guò)分析建模、測(cè)試驗(yàn)證、迭代優(yōu)化的方式持續(xù)地優(yōu)化軟件系統(tǒng)的性能。

組建性能工程團(tuán)隊(duì)，專(zhuān)業(yè)化解決性能問(wèn)題、賦能業(yè)務(wù)團(tuán)隊(duì)并搭建平臺(tái)。

對(duì)軟件性能工程這件事，我們?nèi)栽诔掷m(xù)不斷地探索和實(shí)踐，希望本文能對(duì)您產(chǎn)生幫助。