DevOps在09年被提出之后，熱度一直不減。最近幾年，隨著容器化、微服務(wù)等概念的興起，DevOps又開始了大規(guī)模實踐。但是，隨著基礎(chǔ)設(shè)施的增加，軟件設(shè)計從Ops角度出發(fā)，可以更好的規(guī)避基礎(chǔ)設(shè)施變更帶來的風(fēng)險。

從蘋果公司開始

開發(fā)者、用戶、投資者、分析師和競爭對手都渴望在WWDC上學(xué)習(xí)到蘋果公司維持其領(lǐng)導(dǎo)地位的方式。雖然沒有令人興奮的新產(chǎn)品發(fā)布，但是貫穿其中很多話題的核心是：用戶體驗。

和其他手機廠商的發(fā)布會不同，蘋果公司專注于客戶的體驗，而不是其產(chǎn)品的功能和特性。當(dāng)競爭者在吹捧他們新品擁有的高像素相機和處理器核心數(shù)量的時候，蘋果公司展示iPhone拍攝的優(yōu)美、富有靈感的照片時，沒有提及設(shè)備的任何技術(shù)細(xì)節(jié)。

現(xiàn)在，手機已經(jīng)改變了我們的生活，日常的衣食住行都可以通過手機app來協(xié)助完成。但是蘋果公司認(rèn)為智能設(shè)備還能使我們的生活更加高效。不同于目前每個app提供獨立的功能，蘋果公司希望能夠?qū)⑦@些服務(wù)整合到一起，對于用戶來說，他們只需要使用蘋果的服務(wù)，而無需打開多個app。要實現(xiàn)這樣的愿景，產(chǎn)品或者服務(wù)都需要有新的設(shè)計范式。任何期望通過接入蘋果服務(wù)以對外提供個性化用戶體驗的公司，都應(yīng)該考慮OpsDev而不是DevOps。

進入OpsDev的世界

我們假設(shè)一家電器公司制造的智能冰箱，為用戶提供以下體驗：

當(dāng)我坐在車?yán)飼r，智能冰箱通過手機發(fā)出提醒：冰箱存貨不足，該去買些食品啦。此時，手機自動生成并推薦了三個采購方案。第一個超市不需要繞路，但是沒有我喜歡吃的冰淇淋；第二個超市比第一個遠(yuǎn)10分鐘，但是有所有我喜歡吃的所有食物；第三個超市更遠(yuǎn)，需要多15分鐘的路程，但是它除了有所有需要采購的東西，還提供額外優(yōu)惠券。我點擊了其中一個方案，車載導(dǎo)航開始自動規(guī)劃行車路線，并顯示在汽車多媒體系統(tǒng)中。

在不久的將來，很多公司會致力于提供集成的個性化用戶體驗，因此不同的數(shù)據(jù)源和服務(wù)必須被整合到一起。智能冰箱通過傳感器判斷冰箱內(nèi)的存貨，超市服務(wù)提供其庫存和優(yōu)惠信息，其他還有交通信息、地理位置信息等等。這些數(shù)據(jù)源由不同的提供商提供，并且保存在不同的數(shù)據(jù)中心。這些數(shù)據(jù)的訪問，需要特定的授權(quán)方式、API和數(shù)據(jù)處理流程。個性化服務(wù)的設(shè)計者，必須明確了解每個服務(wù)的規(guī)約，因為任務(wù)信息不能及時正確的獲取，都會影響到用戶體驗。作為零售商，不會希望用戶多花了15分鐘時間過來，結(jié)果卻因為需要購買的商品缺貨，或者無法使用優(yōu)惠券而造成損失。

由此可見，個性化軟件服務(wù)的交付影響了現(xiàn)有的軟件設(shè)計模式。DevOps克服了傳統(tǒng)瀑布流所不能提供的快速交付能力，通過諸如代碼審查、編碼規(guī)范、持續(xù)集成等方式解決軟件開發(fā)遇到的挑戰(zhàn)，并且讓開發(fā)直接參與到了產(chǎn)品上線流程。而OpsDev考慮的方面卻不同。由于個性化服務(wù)依賴于底層一系列基礎(chǔ)設(shè)施，一旦我們知道了每個獨立的數(shù)據(jù)源的依賴關(guān)系和可用性，首先需要設(shè)計出將各個數(shù)據(jù)源結(jié)合在一起的組件。因此，設(shè)計者必須從運維的角度來考慮，對每個服務(wù)的依賴程度、故障修復(fù)、容錯等；同時，由于每個服務(wù)相對獨立由于每個服務(wù)相互獨立，個性化軟件服務(wù)的升級頻率受其依賴的服務(wù)升級頻率影響，這也需要從運維的角度考慮向下（向上）兼容。

什么是OpsDev？

OpsDev是在開發(fā)行為開始前，就需要了解應(yīng)用程序依賴的所有組件，并進行建模。此外，對基礎(chǔ)設(shè)施穩(wěn)定性的考量、環(huán)境建模、安全審計措施都是第一要務(wù)。其次，應(yīng)用程序組件上線后的部署環(huán)境需要被建模。再次，將組件部署到生產(chǎn)環(huán)境的流程必須盡可能自動化。通過以上步驟，設(shè)計和研發(fā)團隊可以在開發(fā)和測試階段復(fù)制應(yīng)用程序、環(huán)境模型和自動化部署流程。這樣設(shè)計、研發(fā)和測試團隊可以清楚的知道應(yīng)用程序在生產(chǎn)環(huán)境的約束和參數(shù)。在傳統(tǒng)的項目模式下，大量時間浪費在完成驗證的應(yīng)用程序部署到生產(chǎn)環(huán)境之后才發(fā)現(xiàn)的缺陷。

由于部署自動化在設(shè)計之初就被考慮到，應(yīng)用程序可以隨時被部署到開發(fā)、測試和生產(chǎn)環(huán)境。這種方式不僅可以通過自動化流程加快各個環(huán)節(jié)的部署速度，還可以減少因為手工部署導(dǎo)致的質(zhì)量問題。部署程序應(yīng)該可以聚合多個獨立開發(fā)的模塊。每個模塊都可以由獨立的開發(fā)團隊進行開發(fā)，并且定制適合自己的持續(xù)基礎(chǔ)、持續(xù)交付流程。發(fā)布程序需要預(yù)先知道每個模塊之間的依賴關(guān)系，這樣可以快速的聚合每個通過持續(xù)集成、持續(xù)交付的流程的模塊，將它們整合之后部署到集成環(huán)境或者生產(chǎn)環(huán)境。

通過OpsDev方法，發(fā)布方式變得更加靈活。整個部署流程被設(shè)計的可以插入驗證流程。一個典型的持續(xù)交付流程可以是：發(fā)布程序首先將待發(fā)布應(yīng)用程序部署到集成環(huán)境（UAT測試環(huán)境、預(yù)發(fā)布環(huán)境）上，然后觸發(fā)發(fā)布前的自動化、手工驗證、性能基線驗證等一系列驗證措施，整個過程通過之后，部署程序再將應(yīng)用程序發(fā)布到生產(chǎn)環(huán)境，發(fā)布成功之后記錄基線信息和本次變更的狀態(tài)。

總結(jié)

對于物聯(lián)網(wǎng)或者基于用戶體驗的移動app廠商來說，傳統(tǒng)的軟件開發(fā)流程無法適應(yīng)它們的產(chǎn)品，因為它們都會對很多SaaS服務(wù)有依賴，且應(yīng)用程序包含很多組件（物聯(lián)網(wǎng)設(shè)備中的app、移動設(shè)備中的app、數(shù)據(jù)中心的后臺服務(wù)、網(wǎng)頁服務(wù)等）。像蘋果這樣鼓勵開發(fā)者優(yōu)先思考用戶體驗，并提供個性化服務(wù)的公司，可能會加速思考方式從DevOps向OpsDev的轉(zhuǎn)變。