最近在舊金山舉辦的WWDC(蘋果全球開發者大會)大會上，開發者、終端用戶、投資者、分析師以及競爭者全都渴望知道蘋果公司(Apple)是如何保持其在手機市場領導地位以及市場份額。大會并沒有發布什么令人興奮的產品，而實際上蘋果公司的股票價格有所下降。然而在不同的會議上多次提到了一個共同的主題：用戶體驗。

蘋果公司不斷地調整所有的產品和App，從而讓一個擁有多款蘋果產品的用戶從一個產品或App切換到另一個時能夠具有相似的體驗，降低了用戶使用新產品的門檻。蘋果公司注重的是用戶體驗而不是產品的某些功能或者某些說明。蘋果公司善于對用戶體驗進行思考，當他們的競爭者們通過宣傳攝像頭的高像素以及新款智能手機處理器有多強大來吸引顧客時，他們給用戶展示的是通過iPhone拍的漂亮且富有靈感的照片而不是手機的任何技術細節。

我們都知道現在大多數人已經離不開智能手機，很多以前需要花很多時間才能完成的事情現在很快就能夠完成，因為拿出手機點幾下就能夠獲取大量信息。比如說，在擁有智能手機之前，想要在一個陌生的城鎮找到一個吃飯的好地方，過去我會想想身邊有誰來過這個地方，然后看下他有什么推薦。如果誰都沒來過，到酒店的時候我就會問問那里的服務員。這就意味著即使我特別餓了，我必須先到酒店才能吃上飯。我還必須在離開機場之前通過谷歌地圖查好去酒店的路線，然后才能坐上飛機到酒店。但是今天，我只要拿出我的iPhone打開Yelp，我就能找到我想去的餐館。然后我可以通過Waze找到去餐館的路線，更方便的是Waze還會推薦繞道路線，因為通常最近的路線最擁堵。然后我可以用OpenTable在去餐館的路上預訂一個座位。

如今，蘋果公司考慮的是如何讓我們的生活過的更加效率。通過上面的描述可以得知，為了在陌生的城鎮找到一個吃飯的好地方，我需要打開很多不同的App來完成一系列的事情，蘋果公司設想有一天我只要通過他們提供的服務就能夠完成相同的事情，而不需要打開那么多App。這種憧憬需要一個新的產品或者服務設計模型，任何一家想要加入蘋果服務以提供個性化用戶體驗的公司必須考慮OpsDev而不是DevOps。接下來我會解釋為什么。

進入OpsDev時代

設想我們在為一個機械公司設計一款智能冰箱，用戶體驗大致是這樣：

當你打開車門坐上車時，智能冰箱通過你的手機通知你去超市買些東西回來。它會給你三個選擇，***個超市離你最近，但是沒有你最喜歡的冰欺凌;第二個超市需要多開10分鐘的車程，但你能夠買到你購物清單上的所有東西，并且都是你最喜歡的牌子;***一個超市需要多開15分鐘，除了有你想要的所有東西之外，還會送你一些優惠卷，這樣能夠讓你省下12美元。一旦你選擇了想去的超市，你車上的多媒體系統會給你提示***路線。

企業想要提供上述完整的用戶個性化體驗，就需要將要用的數據和服務整合在一起，包括智能冰箱提供的食品清單、連鎖超市的庫存數據、食品公司和連鎖超市的優惠卷信息、交通和地理位置信息。這些數據存放在不同的數據中心，由不同的提供者提供。為了獲取這些數據，你需要使用不同的證書、不同的處理流程以及不同的API。這種個性化服務的設計者們必須了解不同數據來源和服務的SLA(service level agreement，服務等級協議)，因為如果綜合服務不能及時獲取到正確的信息就會影響用戶體驗。作為零售商，你肯定不希望終端用戶多開了15分鐘車程卻發現他們想要的商品已經賣完了，而且因為優惠卷不能用或者需要買些替代品，比預期多花了20美元。

正如你所看到的，想要交付這種個性化軟件服務就必須轉變傳統的設計模型。DevOps趨向于從開發者主導的挑戰開始(例如：代碼評審、代碼標準、構建管理和持續集成)，***當應用程序上線于生產環境時運維人員才會參與進來。OpsDev正好相反，只有當我們理解了不同數據來源的相互依賴性和可用性時，我們才能設計組件并將各組件連接在一起。此外，智能冰箱軟件會不斷更新，使用新的傳感器提供不同種類的數據。個性化服務軟件必須持續獲取新型數據來提供不同的個性化服務，軟件的更新頻率取決于所依賴的其他服務。因此，設計者必須開發一套自動化系統，用于獲取依賴服務更新提示并立即分析這些更新會影響服務的哪些組件，以及決定何時更新個性化服務來同步依賴服務。

OpsDev是什么?

OpsDev指的是在應用程序正式開發之前，必須首先理解和模型化不同組件的依賴。此外，還必須事先重點考慮基礎服務穩定性、環境建模、安全性和審計/合規措施。應用程序組件是存根的，他們不必處于最終形式。其次，對生產中部署組件的環境必須進行建模。再者，不同組件部署到目標環境的流程必須盡可能自動化。通過上述方式，設計和開發團隊可以在開發和測試階段以一致的方式復制應用程序和環境模型以及自動化部署過程。在開發和測試階段，通過簡單地復制生產環境及部署過程，設計、開發和測試團隊可以盡早知道生產環境的限制和參數，這樣他們在開發應用程序時可以充分考慮這些約束和參數。而使用傳統的模型，大量的時間將浪費在排除由質量保證部門在模擬環境(譯者注：Staging，在正式進入生產環境前模擬生產環境的階段)或生產環境找到的問題。很多時候部署會被取消，因為環境因素略有不同，驗證通過的應用程序將無法部署到生產環境中。

此外，借助OpsDev可以使用版本發行管道工具在開發、測試、模擬和生產環境編排應用程序的部署，這樣不僅能夠通過自動化和并行化加快不同環境的整體部署流程，還能夠減少易出錯的手動任務從而提高整體質量。版本發行管道工具由多種提交管道(commit pipeline)組成，一個提交管道是一個獨立的應用程序管道，用于編排持續集成和持續測試。一個發行版可能包括多個由不同工程團隊開發的應用程序，每一個工程團隊可以擁有他們自己的提交管道。將不同團隊的不同應用程序提交管道集成在一起就構成了一個版本發行管道工具。版本發行管道工具知道應用程序的相互依賴性并且能夠將應用程序整理到模擬和生產環境中。版本發行管道工具使用手動和自動兩種批準方式確保發行版已被批準以及確保部署流程的正確性。

使用OpsDev，版本發布管道工具能夠集成ITSM(Information Technology Service Management，IT服務管理)和APM(application performance monitoring，應用性能監控)解決方案。版本發布管道工具通過往ITSM服務臺發送一份即將部署應用程序的電子清單來尋求批準，并且開啟一個變更請求。IT服務主管在ITSM服務頁面上就會看到即將部署應用程序的通知，然后進行評審以及相應的批準流程。當IT服務主管審核通過后，ITSM就會發送信號給版本發行管道工具讓其進行部署。部署成功后，版本發布管道工具會通過更新變更請求狀態告知ITSM應用程序已經成功部署。

版本發布管道工具也可以集成APM解決方案，版本發布管道工具將應用程序部署在模擬環境中，然后通知APM監控性能和負載測試。APM會報告應用程序是否到達SLA，如果是，應用程序可以繼續部署到生產環境。否則，版本發布管道工具就會終止部署，并且報警說應用程序未到達目標SLA。在生產環境中，APM能夠監控事物、性能和負載。當到達一定的閥值時，APM就會通知版本發布管道工具在數據中心部署更多的應用程序來增加服務能力。當收到APM的請求時，版本發布管道工具會往ITSM上創建一個變更請求，當ITSM批準后，它就會部署更多的應用程序來提供更多的服務能力。當服務能力過盛時，APM就會通知版本發布管道工具關閉一些服務，將資源留給其他服務使用。

正如大家所了解，IoT以及基于手機應用用戶體驗的不斷擴張，企業不能再使用傳統的開發模式開發產品，因為SaaS服務和應用程序組件(設備軟件、數據中心軟件、手機應用和Web應用)相互依賴性的增強組成了單一且密切相關的用戶體驗。蘋果公司，通過鼓勵開發者首先考慮用戶體驗以及提供完整的蘋果個性化服務這種變革使我們的生活變得更加效率，這也將加快DevOps到OpsDev思想的轉變。