發佈怪獸DevOps是怎麼做妖的——淺析DevOps過程

什麼叫DevOps

DevOps（Development和Operations的組合詞）是一組過程、方法與系統的統稱，用於促進開發（應用程序/軟件工程）、技術運營和質量保障（QA）部門之間的溝通、協做與整合。

 

DevOps的引入能對產品交付、測試、功能開發和維護（包括──曾經罕見但現在已家常便飯的──「熱補丁」）起到意義深遠的影響。在缺少DevOps能力的組織中，開發與運營之間存在着信息「鴻溝」──例如運營人員要求更好的可靠性和安全性，開發人員則但願基礎設施響應更快，而業務用戶的需求則是更快地將更多的特性發布給最終用戶使用。這種信息鴻溝就是最常出問題的地方。

 

爲什麼要引入DevOps：

一、使用敏捷或其餘軟件開發過程與方法

二、業務負責人要求加快產品交付的速率

三、虛擬化和雲計算基礎設施（可能來自內部或外部供應商）日益廣泛

四、數據中心自動化技術和配置管理工具的普及

五、有一種觀點認爲，占主導地位的「傳統」美國式管理風格（「斯隆模型 vs 豐田模型」）會致使「煙囪式自動化」，從而形成開發與運營之間的鴻溝，所以須要DevOps能力來克服由此引起的問題。

DevOps對應用程序發佈的影響

在不少企業中，應用程序發佈是一項涉及多個團隊、壓力很大、風險很高的活動。然而在具有DevOps能力的組織中，應用程序發佈的風險很低，緣由以下 ：

（1）減小變動範圍

與傳統的瀑布式開發模型相比，採用敏捷或迭代式開發意味着更頻繁的發佈、每次發佈包含的變化更少。因爲部署常常進行，所以每次部署不會對生產系統形成巨大影響，應用程序會以平滑的速率逐漸生長。

（2）增強發佈協調

靠強有力的發佈協調人來彌合開發與運營之間的技能鴻溝和溝通鴻溝；採用電子數據表、電話會議、即時消息、企業門戶（wiki、sharepoint）等協做工具來確保全部相關人員理解變動的內容並全力合做。

（3）自動化

強大的部署自動化手段確保部署任務的可重複性、減小部署出錯的可能性。

與傳統開發方法那種大規模的、不頻繁的發佈（一般以「季度」或「年」爲單位）相比，敏捷方法大大提高了發佈頻率（一般以「天」或「周」爲單位）

 

DevOps技術的應用和發展

微服務目前仍然是DevOps技術的主要應用領域，微服務將單塊應用系統切割爲多個簡單獨立的應用。從技術上說，這是經過工具把應用程序的內部複雜度轉化爲外部複雜度，須要一系列工具支撐微服務自己以及服務之間的通訊。從組織上說，微服務團隊要知足「快速發佈，獨立部署」的能力，則必須具有DevOps的工做方式。

 

如何拆解微服務一直是微服務技術應用的最大難點之一，領域驅動設計是比較理想的微服務拆解方法論。社會化代碼分析幫助團隊經過更精確的數據找到更加合適的拆分點。CodeScene是一個在線服務，它能幫助識別出熱點和複雜且難以維護的子系統，經過分析分佈式子系統在時間上的耦合發現子系統之間的耦合。此外，它還能幫你認識組織中的康威定律，這會大大下降微服務解耦的難度。

 

此外，微服務系統本質上是一個分佈式系統，分佈式系統之間的通訊一直是很重要的問題。本期介紹的 Kafka Streams 和 OpenTracing 就是這類技術的條目。Kafka做爲一個成熟的分佈式消息系統已經被普遍採用，而Kafka Streams則將最佳實踐以「庫」的方式呈現給開發人員，使得操做Kafka更加天然和簡單。而OpenTracing則彌補了跨越多個微服務之間請求追蹤的空白。

另外一方面，無服務器風格的架構（Serverless architecture）把DevOps技術在微服務領域的應用推向極致。當應用程序執行環境的管理被新的編程模型和平臺取代後，團隊的交付生產率獲得了進一步的提高。一方面它免去了不少環境管理的工做，包括設備、網絡、主機以及對應的軟件和配置工做，使得軟件運行時環境更加穩定。另外一方面，它大大下降了團隊採用DevOps的技術門檻。

 

然而，端到端交付以及微服務中的函數管理問題日漸突出。儘管AWS API gateway和AWS Lambda幾乎成了Serverless架構的代名詞，但這兩者結合的開發者體驗並不佳。因而出現了Serverless framework和CLAUDIA這樣的管理工具。

 

AWS Lambda帶來的優點也深深影響了企業級應用領域，Apache OpenWhisk就是企業級無服務器領域的選擇之一，它使得企業級應用也能夠採用無服務器風格的架構構建應用程序。

在微服務端到端交付流程上，Netflix開源了自家的Spinnaker，Netflix做爲微服務實踐的先鋒，不斷推出新的開源工具來彌補社區中微服務技術和最佳實踐的缺失。而Spring Cloud則爲開發者提供了一系列工具，以便他們在所熟悉的Spring技術棧下使用這些服務協調技術(coordination techniques)，如服務發現、負載均衡、熔斷和健康檢查。

而在微服務的安全上，最多見的需求之一 是經過身份驗證和受權功能來保護服務或API。這部分功能每每是最重要且不斷重複構造的。而Keycloak就是一個開源的身份和訪問管理解決方案，用於確保應用程序或微服務的安全。且幾乎不須要編寫代碼，開箱即用。它支持單點登陸，社交網絡登陸和標準協議登陸(如OpenID Connect，OAuth2和SAML等)。

安全成爲推進DevOps全面發展的重要力量

安全是DevOps永遠繞不開的話題，也每每是新技術在傳統行業（例如金融和電信）應用中的最大阻礙。一方面，組織結構的轉型迫使企業要打破原先的部門牆，這意味着不少原先的控制流程再也不適用。另外一方面，因爲大量的DevOps技術來源於開源社區，缺少強大技術實力的企業在應用相關技術時難免會有所擔心。

 

從代碼中解耦祕密信息的管理則讓咱們避開了一些開發過程當中可能會產生的安全隱患。採用git-crypt這樣的工具能夠幫咱們保證在開發的過程當中源代碼內部的信息安全。而採用HashiCorp Vault則提供了脫離應用程序代碼的祕密信息存儲機制，使得應用在運行過程當中的祕密獲得了有效保護。

Linux Security Module則一直在技術雷達的「採用」區域，經過SELinux和AppArmor這樣的LSM兼容幫助團隊評估誰能夠訪問共享主機上的哪些資源(包括其中 的服務)。這種保守的訪問管理方法將幫助團隊在其SDLC流程中創建更好的安全性。以往這是Ops團隊須要考慮的問題，而對DevOps的團隊來講，這是每個人的事情。

「合規性即代碼」（Compliance as Code）是繼「基礎設施即代碼」，「流水線即代碼」以後的又一種自動化嘗試。InSpec做爲合規性即代碼的提出者和實現者，經過自動化手段確保服務器在部署後的運維生命週期中依然保持安全與合規。它所帶來的意義在於將規範制度代碼化，獲得了肯定性的結果和解釋。

 

在不遠的未來，不難想象人們所面對的法律和法規規定再也不是一堆會致使歧義的語言文字條目，而是一組由自動化測試構成的測試環境。

 

安全性和易用性每每被認爲是魚與熊掌不可兼得的兩個方面。在DevOps以前，團隊吞吐量和系統穩定性指標曾經也面臨這樣的境遇，然而DevOps使得兩者能夠兼得。一樣我也有信心看到在將來DevOps的領域裏，更多易用且安全的工具將會不斷出現。在下降DevOps所帶來的安全風險的同時，也提高團隊開發過程的順暢性和用戶便利性。

 

以上就是柳貓初識DevOps的一些認知和感覺，有失偏頗，還請多多指教。