一種硬件DevOps數字化研發方略

文/童向杰 謝鳳玲 王克鳳 董麗花 周天才

1 引言

企業數字化轉型是指企業利用數字化技術和能力來驅動企業內外業務創新和商業生態系統重構的一種途徑與方法，其目的是實現企業業務的轉型、創新、增長。它可以在以下三個方面進行智能化賦能：

（1）通過打造出輕量化或者服務化的PaaS、企業應用系統容器化、一站式敏捷IT開發與運維、自動編排和IT 資源最大化利用給企業IT 賦能；

（2）通過智能數據歸一、數據統一治理與服務、數據實體化融合和數據資產化實現數據賦能；

（3）通過賦予企業（AI）智能，改變線性的人為經驗決策，向基于大數據與算法模型的機器智能輔助決策，包括感知智能和認知智能。從而實現業務轉型、創新以及收入增長。

而研發是企業經營的重要一環，因此數字化研發是在企業數字化轉型中必須解決好的關鍵環節之一。對于軟件企業，企業數字化研發通常采用軟件DevOps 思想和方法，DevOps（Development 和Operation 的組合詞）是一組過程、方法和系統的統稱，用于促進開發（應用程序/軟件工程）、技術運維和質量保障（QA 部門）之間的溝通、協調與整合。軟件DevOps 融合了敏捷管理、持續交付、IT 服務管理和精益管理等四大部分內容，形成了完整的框架體系。與之對應，在工程實踐上，通過流水線技術，體現價值流動思維，通過將過程任務代碼化，實現過程自動化，也因此使得DevOps 在數字化軟件研發中大放異彩，也是眾多軟件企業擁抱軟件DevOps 的關鍵所在。

由于企業數字化轉型本質上是要解決“IT”驅動“人”的問題，鑒于軟件DevOps 的成功實踐，所以DevOps 思想完全可以推廣到硬件產品研發領域，雖然相對軟件產品研發，硬件產品研發牽涉到學科、工具、供應鏈和管理等領域更廣，但是本質上一樣的，即硬件DevOps 就是利用數字化技術，消除數據孤島，促進硬件產品研發各專業內部以及專業之間協作的一體化，達到消除業務痛點、提升效率的目的。但是，也正因為牽涉領域廣，還有與企業現行IT 系統兼容問題，存在如投資大、建設周期長、短期支撐業績提升度量等問題，硬件DevOps 進展比較緩慢，仍然以如高效產品研發（HPPD）和集成產品研發（IPD）為主，但是它們的現狀依然是“人”驅動“IT”，相應地，研發數據是沒有結構化的，如果智能化（AI）時代的到來，顯然企業很難完成AI 轉型的。正是綜合考慮發展趨勢，硬件產品數字化研發（硬件DevOps）是勢在必行的。但是考慮到硬件DevOps 實施的挑戰性，在硬件DevOps方案設計和實施策略就顯得尤為重要。從另外一個角度來看，無論是提供硬件產品企業還是軟件產品企業，都是通過“DevOps”實現數字化研發轉型的。

2 軟件DevOps和硬件DevOps業務模型

得益于三大主要數字化技術：流水線技術、微服務和容器技術，軟件DevOps 思想付諸實踐。圖1是軟件DevOps 業務模型和工具鏈示意圖，可以看到軟件DevOps 業務過程的經典啞鈴模型，由計劃、需求、開發、編譯、測試、發布、部署、運維和監控組成。借助流水線技術和研發工具的結合，形成工具鏈，從而將過程任務代碼化，實現過程自動化和閉環，進而形成持續迭代和持續交付能力。圖1a 借助了敏捷思想，實現開發快速響應需求及其變更；圖1b 是DevOps 的初衷，實現高質量的持續部署、運維。

為了便于比較，硬件DevOps 業務過程也按照啞鈴模型設計，如圖2可見，硬件研發過程由需求、開發、檢查、仿真、試制、調試、測試、中試、量產、部署、運維、售后服務和監控組成。與軟件業務過程主要不同有：

圖1：軟件DevOps 業務模型和工具鏈圖

圖2：硬件DevOps 業務模型

圖3：硬件業務“公轉”模型圖

圖4：硬件設計“自轉”模型

（1）業務價值流更長，甚至需要第三方合作方參與協同，才可以完成既定研發目標；

（2）兩個啞鈴閉環模型中，硬件開發中的Dev 與軟件開發中的Dev 是不同的，由于硬件開發是多學科開發，一個學科設計調整都可能影響到另外一個學科的設計，因此在硬件設計環節存在“自轉”循環，如圖2中a 所示，這一過程是完善與優化設計；

（3）圖2中的三個箭頭，右邊兩個箭頭是不動的，需求和開發之間存在互動，比如說，設計因為技術瓶頸達不到預期，就可能需要調整產品需求；設計完成到檢查環節的箭頭也是不動的。而最左邊箭頭是可以動的，一旦移動到某個環節，發現需要修改設計，那么根據修改范圍，可能需要從設計→檢查→......重新開始業務循環，如圖2中b 所示，即硬件業務過程存在圍繞設計的“公轉”循環；

（4）硬件業務開發過程存在虛擬迭代和實物迭代過程，所謂虛擬迭代是指產品設計通過仿真技術來評估產品的預期性能，一旦仿真結果達不到預期，需要優化設計；所謂實物迭代是指在試制、調試、測試等環節發現設計偏差后，需要重新優化設計，以滿足預期的功能及性能指標要求。所以，硬件業務過程比軟件業務過程復雜得多，在某種程度上，可以把軟件業務過程看成硬件業務過程的簡化版，即如長方體與正方體的關系。

為了更好理解硬件設計過程“公轉”循環，設計了硬件業務過程的“公轉”模型或者叫“雪人模型”，如圖3。從檢查、仿真之后的各個環節都可能重新觸發新的迭代，越往后的業務過程因異常導致的設計迭代所付出的代價就越大，由此可見，硬件DevOps 需要重點實現：短迭代路徑，如虛擬迭代（最左邊兩個循環就是虛擬迭代），甚至不迭代（通過提高一版投板成功率），來降低研發費用和縮短研發周期。

類似的，硬件設計“自轉”循環模型如圖4所示。由于硬件產品設計通常包括結構設計、工藝設計、硬件電氣設計、部件設計、邏輯設計和底軟設計等多學科的聯合設計過程，而硬件電氣設計還包括基帶設計、射頻設計、EDA設計和天線設計等。因此，除了需要硬件電氣設計多學科協同循環設計外，還存在跨學科領域的協同開發。

由此可見，從業務模型的角度，可以看到硬件業務流和軟件業務流是存在巨大的差異，也因此決定了硬件DevOps 的復雜性和建設成本與周期。

3 硬件DevOps架構設計

由于阿里云的“厚平臺，輕應用”的技術架構能夠為前臺的一線業務提供更敏捷、更靈活的服務以適應瞬息萬變的市場需求，而中臺整合的運營數據能力、產品技術能力，對各前臺業務形成強有力支撐，因此該技術架構更具創新性和靈活性，也同樣適用于硬件DevOps的架構設計。

圖5是硬件DevOps 中臺分層架構模型，總體上采用了分層和分域相結合的策略。從分層的角度上來看，研發中臺（硬件DevOps）服務對象包括硬件開發人員、客戶（主要指內部業務流下游數字化制造等客戶）、供應商、合作伙伴和子公司；前臺由應用場景/活動、角色編排、接入層、角色化場景編排和業務應用層組成；中臺則由角色化服務編排、擴展服務層、基礎服務層、組件層和數據層組成，其中數據包括結構化的設計數據和管理數據；后臺有PaaS 和IaaS 平臺組成。而從系統服務對象，可以將整個架構分層硬件管理域（服務項目管理和產品經營等需要）、硬件工程域（直接服務工程設計與開發一線）和IaaS 平臺三大部分。

硬件DevOps 分層模型中提到了幾種編排，它們之間的關系如圖6。通過幾種編排器的組合應用，結合權限控制，生成與用戶角色一致的業務流水線和工具流水線，給硬件產品開發與管理工作提供流程和工具支撐，也由此產生“IT”驅動“人”的核心作用。

結合硬件DevOps 業務模型、中臺架構和分域策略，硬件DevOps 中臺“域”模型如圖7。用戶通過硬件DevOps 門戶接入硬件管理域，項目與交付管理是通過編排或者智能編排產生的角色化設計與管理應用界面，以滿足項目管理和開發的需要，同時通過分布式服務或者應用來支撐角色化編排以及權限管理的。而硬件工程域是通過PaaS 平臺、結構化數據管理和硬件平臺、架構管理來支撐設計協同、仿真協同、工藝協同、測試協同和試制與發布協同的，通常硬件工程域更多的是提供開發工具自動化無縫鏈接來形成硬件產品開發中各學科的協同，因此，硬件工程域也叫做硬件工具鏈。

僅從硬件工具鏈中數字化設計來看，就牽涉到眾多工具云化、設計一體化和工程數據結構化等大量工作，也牽涉到與之相匹配的基礎設施的投資與建設，所以硬件DevOps 是一個極其復雜的系統工程，需要長期的投入，因此其本身建設也是DevOps 實踐，是一個持續集成、持續迭代、持續發布與運維的過程。

4 硬件DevOps推進策略與原則

由于軟件DevOps 已經有許多的成功實踐，因此一些成功經驗可以在硬件DevOps實施過程得到借鑒的，圖8就是博時基金在2018年在China DevOps Day 展示其實踐軟件DevOps 的實施策略，其核心策略是：以提高工程工具效率為突破點采用自下而上搭建軟件DevOps 體系與以管理、組織和考評為關鍵點自上而下為軟件DevOps 提供管理資源支撐相結合，使得軟件DevOps 實踐取得了非常好的效果。

圖5：硬件DevOps 中臺分層模型圖

圖6：硬件DevOps 中臺分層模型中的編排器

該策略在硬件DevOps 體系建設上同樣適用的，從圖5和圖6硬件DevOps 架構模型可以看出，在中臺架構的基礎上進行了分域：管理域和工程域，也是為了將工程域作為硬件DevOps 建設突破點，確定了其優先級，比如說工程域中的仿真云、設計云等其核心作用就是為了提升工程工具效率的。另外，將硬件DevOps 拆成管理域和工程域也是組建硬件DevOps 研發團隊的需要。考慮到整個體系的復雜性，建設之初需確定好階段性研發重點和研發資源投放，是硬件DevOps 體系建設成功的基礎。

其次，如前所述，硬件DevOps 體系建設本身是一次大規模的DevOps 實踐，與軟件DevOps 一樣，也會用到工具云化、流水線編排器等等技術，但是由于硬件DevOps 更為復雜，在實施過程中需要對工程域或者管理域需要進一步進行拆分，以確定建設步驟，圖9是硬件工程域建設步驟策略，只有這樣，才能提高持續集成、持續發布和持續部署的效能，即讓硬件DevOps 體系建設本身成為一次偉大的DevOps 實踐，也是對軟件DevOps 成效的一次檢驗！

再者，硬件DevOps 體系建設需要考慮快速變現，這也是為什么硬件DevOps 體系建設和軟件DevOps 一樣，選擇提高工具效率為抓手。當然，硬件工具鏈牽涉學科眾多，企業需要根據自身現狀，選擇影響當前研發業務最痛點作為突破點來啟動硬件工具鏈建設。一旦相關領域取得突破，這將使得DevOps 文化從IT層面向工程一線推廣，逐步深入人心。比如可以以仿真云作為試點，仿真云一旦建成，一方面解決了工作站或者單機版仿真作業慢的問題，仿真效率可以提升成倍提升；另外相應地提高了軟硬件資產的使用效率，降低企業運營費用。如果能夠將仿真前后處理與仿真計算結合，形成一體化仿真作業，使得仿真協同起來，形成合力，效能將進一步提升。

圖7：硬件DevOps 中臺域模型

另外，硬件DevOps 相對于傳統研發模式來看，是一場革命，因此，需要贏得企業管理層自上而下的支持，特別是企業運營管理團隊一把手的支持，包括資源支持和文化支持。與之配套的推進手段如指標、考核和激勵等也是必不可少的。

硬件DevOps 體系（或者叫研發中臺）建設要想取得好的效果，需要采用以上四個策略（（1）選取合適的突破點；（2）能夠快速變現；（3）采用軟件DevOps 開發、部署方法；（4）企業管理層支持）外，還需要遵循以下七個原則：

（1）復用原則：嚴禁各中心之間各種形式的重復開發，遵守One UI、One Logic、One Data 原則，這里的“中心”指的是如設計中心、仿真中心等；

（2）業務解耦原則：基礎服務能力不能同層調用；

（3）數據解耦原則：每個中心獨立數據庫；

（4）高可用原則：每個中心實現高可用設計；

（5）標準化原則：每個中心符合分層模型定義、統一框架、規范、組件；

（6）自動化原則：每個中心UT 覆蓋率＞60%，FT 覆蓋率＞80%，ST 最小集覆蓋率＞90%，該原則關注主要針對軟件測試，確保業務上線質量；

（7）開放原則：中心服務默認在公司范圍內開放。

5 結束語

對于完成數字化轉型的企業，可以通過產品鏈路實現端到端數字化交付，如圖10。從數字化研發角度，對于基于模型設計（MBD）的企業，通過它連接數字化營銷，通過樣機BOM 或者制造BOM 連接數字化制造，從而現成主業務流的協同與一體化，最后通過基于模型的結構化數據來與產品實物一一對應的。

另外，人工智能（AI）將離我們越來越近，它最終會融入到企業運營的方方面面，而影響AI 與企業運營結合的關鍵點就在于結構化數據。李開復在《AI·未來》一書中指出：正因為有了結構化數據，才可以很容易地將人工智能商用，幫助傳統企業優化現有數據庫，更好地識別欺詐、更明智地進行交易、發現供應鏈上缺乏效率的環節，使得企業進一步節約成本，利潤最大化。由此可見，建設硬件DevOps 不僅僅是傳統企業數字化轉型的需要，更是為了迎接人工智能的到來所做的鋪墊與準備，因此對于提供硬件產品的企業，沒有數字化研發就會落后，甚至是沒有未來的。

圖8：博時基金軟件DevOps 實施策略圖

圖9：硬件工程域實施策略

圖10：數字化企業產品鏈路全景圖