OpsDev的時代來了！

最近在舊金山舉辦的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思想的轉變。

作者：肖遠昊譯

來源：51CTO