前 言
90年代末期和21世紀早期，市場主要以傳統C/S架構為主，而且流行胖客戶端，對於伺服器端的壓力較小，運維對於企業的價值並不是很高，也往往被視為成本部門。當時軟體本身開發、測試的時間成本較高且企業多採用瀑布式的開發模型，客戶端軟體發布往往是一個重量級操作，經常以年為周期發布新版本。運維人員不用和開發人員直接高頻接觸，甚至針對一些純離線業務，並不設有運維人員崗位。
隨著網際網路的發展，由傳統客戶端軟體逐步演變為面向PC和手機終端的業務。這時候軟體架構逐漸往B/S架構發展，大量業務開始依賴伺服器端的計算，多頻次版本迭代取代了年度級別的產品發布，確保穩定持續的提供可用服務變得愈發重要。
長期以來，開發者和運維人員的協作方式是分裂的：開發者做的事情是將程序打包，交給運維部門進行部署上線；而運維部門負責將程序安裝與部署到生產環境。運維人員不關心代碼是如何運作的，開發人員不知道代碼如何運行在伺服器上，導致了生產效率低、故障排除速度慢的問題。隨著開發和運維協作問題對於發布速度的影響不斷加深，軟體行業的工程師借鑑製造業中例如「精益製造」的先進理念，通過研究新的管理方法，引入自動化集成，使軟體開發周期中的研發、測試、部署團隊能夠更緊密的結合，以提升生產力。其中，DevOps和SRE是其中較為流行的兩個開發理念。
— DevOps：開發運維強力催化劑—
DevOps旨在關注全流程效率提升，制定一系列指導原則以改進開發和IT運維的交互關係，縮小開發和運維團隊之間的工作差異，讓有效的交付生產系統更加穩定和可維護。
在DevOps文化中，企業需要關注開發交付流程的優化，監控反饋機制的完善和應急處置能力的積累。DevOps主張三種原則：流動原則、反饋原則、持續學習原則。流動原則主張使工作能快速穩定的從開發端流動到運維端，實踐包含流水線構建、自動化測試、可持續集成構建等，通過降低每次交付規模來增強工作內容的可視化。反饋原則體現在開發過程中構建反饋迴路，引入同行部門評審，將質量控制和決策的權力滲透在各個團隊，並通過監控機制及時遏制問題，幫助企業持續積累經驗防止類似問題復發。持續學習通過建立持續學習和改進的制度文化提升團隊能力，包含學習復盤、流水線保護運作等實作，幫助團隊快速地適應變化的市場環境，提高企業競爭力。
總體來看，DevOps更像是一個抽象類別的指導方針，並不告訴怎麼做才會成功，而是制訂一些基本原則幫助企業根據實際情況制定符合本企業特點的開發和管理方式，只要符合理念，就可以說是DevOps文化的實踐。不同規模、不同種類業務和不同研發及生產環境的公司其實際執行DevOps理念的方式均不盡相同。
— SRE：Google開發運維理念實作 —
除了DevOps，我們往往還會聽到一個與開發運維協作效率相關的名詞——SRE（Site Reliability Engineering）。SRE一詞的出現實際上早於DevOps，與DevOps不同，SRE是Google在2003年定義的一個崗位，發展到後面才逐步演變為一種工程思維。那麼Google為什麼會提出SRE呢？作為大型的網站公司，Google為全球十幾億用戶提供服務，即使是短暫的服務不可用，也會帶來大量的損失。因此，服務可用性對Google至關重要，使得Google的運維人員需要對開發有深入了解才能更好的完成工作，在出現應急故障時進行及時排除並解決。
SRE的工作職責可以總結為緊急事件處理、日常運維和工具與業務開發三個方面。可以看出，SRE與普通運維不同，不僅包含了運維職責，還要兼顧開發。這樣的要求使得SRE深入產品研發和架構中，能夠了理解產品的開發流程和設計理念，便於更好的在應急事件發生後及時定位和解決問題。
緊急事件處理SRE團隊主張系統能及時監控到應急事件的產生，並發到相應的負責人。應急事件出現後，團隊每個人都明確責任分工，如果發生跨部門之間協作的問題，也會持續不停的跟蹤處理，保證問題以最快的速度解決。
日常運維SRE的日常運維工作需要保證系統能夠進行正常更新、快速迭代，並進行容量管理。同時，SRE也要對業務有深入了解，能夠向公司提出資源分配和規劃方案，並確保這些方案的提出有數據支撐，能夠解決問題。
工具與業務開發SRE在研發方面一方面參與了公司自動化管理工具開發、產品架構設計等工作；另一方面與業務部門之間進行配合併給予反饋，幫助產品部門確定數據指標，給予需求和成本方面的決策幫助。
足夠的開發能力使得SRE能夠深入研發過程，在應急處置和日常運維時可以避免舊時因運維人員技術棧廣度不夠且對產品研發過程理解不足造成的部署效率問題。
— SRE實作與DevOps理念的區別 —
SRE崗位專注於開發和運維工作內容本身，更依靠人的能力去兼顧開發與運維。而DevOps並不是一套具體的實作細則，其理念貫穿了開發、測試、運維，專注於利用自動化工具和流程管理方法以縮短新功能的交付時間，加速技術價值流。較於DevOps，SRE作為一個具體崗位更偏向於包含更多的實現細節，強調「人」的作用；而DevOps文化更突出反饋、工具貫穿開發生命周期的作用，更強調「規則」的控制力。
— DevOps和SRE在容器時代的演變 —
容器技術的發展使得DevOps廣泛落地
虛擬化技術的出現對於DevOps的落地起到關鍵作用。Devops實現的技術關鍵在於自動化部署、標準化交付、應用隔離和配置管理等，而虛擬化技術的出現則提供了技術保障。在初期，DevOps的流水線構建主要依靠Vagrant提供虛擬化技術實現應用隔離和部署，利用Puppet、Chef進行配置管理。但基於虛擬機的隔離和編排依舊繁瑣而笨重，導致啟動速度慢、傳遞交付笨重。
隨著容器技術的出現，輕量級隔離和資源管理優勢令網際網路企業開始重視。Docker帶來了更輕量的運行、更快速的啟動和更便捷的分發模式，由此開啟了DevOps的容器實現時代。Docker為DevOps的實施提供了更多在開發部署和編排的操作延展性，流水線的所有環節都是流暢的，易配置的。開發者在代碼提交後生成應用鏡像，並在自動化測試通過後服務以鏡像的形式產出並上傳到鏡像倉庫中，便於後續測試、部署上線。環境配置文件和應用一次性打包確保了環境的一致性，使得定位復現問題更方便。鏡像的可復用性和更新的疊加性也使得應用的回滾、升級都變得容易。
此外，伴隨著容器技術的成熟，應用微服務化也日益流行。微服務化和DevOps的發展是互相成就的：微服務的出現是為了實現開發的快速、敏捷、反饋，這本身就與DevOps的理念相合；而穩定、自動化的流水線又是應用微服務化得以實現的基礎設施。另外，微服務化解耦了服務，使應用的運行更穩定，僅在對應功能的下的容器裡進行操作即可實現功能變更，提升自動化框架成功率。可以說，微服務不光是一種應用架構，更是包含了敏捷開發、DevOps容器等技術的綜合實踐。
SRE面向雲的變化
隨著大數據和雲計算時代的到來，依靠分布式伺服器所構建起來的「雲」集群帶來了強大的計算能力；資源的動態伸縮、高擴展性也使得集群的架構變得更加複雜多元，極大增加了運維難度。因此，如何保證複雜雲業務環境高可用，同時維持高頻度的迭代更新為SRE帶來了新的挑戰。
對於SRE來說，如果和以往一樣依然通過人力運維大規模複雜集群必定是不可取的，依靠自動化工具進行管理則省時省力。以Google為例，首先它開發了集群編排工具Borg（Kubernetes是它的開源實現），使雲系統的軟體業務運行不受硬體故障的影響，實現整個容器集群的自治；Bigtable、Spanner等工具則帶來了集群級別的可持久化的存儲系統，以保證數據多副本和一致。此外，大規模應用監控必不可缺，需要針對容器集群進行自動監管，Google通過監控工具Borgmon（啟發了Prometheus的實現）對容器雲集群無間斷監控以及基於時間序列的告警。這些工具使SRE不再需要直接做一線的運維操作，但對這些系統框架的掌握成為了架構「雲」化時代下對SRE從業者的基本要求。
可以說SRE一方面在適應雲環境對工作內容帶來的變化，另一方面推動了容器集群管理和微服務架構的發展，進一步提高了服務雲端化後的可靠性。集群監控跟蹤能力的提升也使SRE可以對服務運行中的各環節進行自動化的數據收集和追蹤，高價值的數據資產為SRE團隊深入了解應用上線後的性能問題和用戶行為帶來便利，從而形成正向的反饋迴環。
—星環科技TDC：DevOps理念實踐 —
現代的開發模式不僅要有理論上的支撐，基礎的工具也是流程運作必不可少的要素。一些公司開始為企業構建平臺級的應用管理系統，星環科技大數據云平臺TDC便是其中之一。TDC一直致力於為企業提供全面的數位化建設支持，除了應用部署能力，還提供支持服務線上應用開發的DevOps工作檯，為企業的開發、上架、部署、運維提供一站式解決方案。
TDC-DevOps工作檯工作流程
TDC—DevOps工作檯整合了包括GitLab代碼管理、鏡像構建、鏡像管理、部署等一系列開發管理工具，貫穿應用開發、構建、測試全過程。下面以星環科技內部採用的開發過程為例，介紹應用是如何從代碼開發到部署上TDC的。
首先，代碼通過開發平臺集成的GitLab進行管理，代碼提交後，分別經過以下四個階段，產生不同成熟度的鏡像。
Precommit：開發人員本地代碼commit到Gitlab倉庫後，在合併到主幹分支之前，由GitLab pipeline自動化觸發單元測試和靜態代碼檢查，此階段稱為precommit，測試通過後則可被合併從而進入postcommit階段。Postcommit：postcommit階段會對合併後的代碼進行構建，產生的Java代碼包被推送到軟體包管理庫，而容器鏡像和charts被推送到鏡像管理庫。隨後TDC的包管理工具WALM將容器應用部署到開發測試環境中，並在Jenkins上覆蓋基礎測試。這個階段的測試通過後，應用鏡像將會被打上postcommit標籤。Gold：通過postcommit的鏡像將在Jenkins上繼續進行更全面的集成測試，這個階段完成後，鏡像將會被打上gold標籤。Release：版本發布前，測試人員從gold鏡像中挑選出滿足當前發布一個版本，進行發布驗證，如果可以滿足生產環境的需求，則被release版本推送到生產環境倉庫中，由運維/SRE人員進行生產環境的部署、升級等操作。
TDC開發質量管控流程圖
TDC提供的能力在於，它使上述過程不需要在各個平臺間跳轉完成，只需要在統一的操作平臺上一體化的實現。而應用開發完成後，運維/SRE人員僅需通過TDC提供的可視化上架和部署接口，便可以快速進行上架。然後通過資源參數配置，實現應用一鍵部署。
TDC應用上架圖
此外，星環科技自主研發、整合了一系列運維工具，形成一套完整的治理中心來協助應用運維。TDC的運維管理工具能夠對應用的時序指標如CPU、內存等進行收集、監控和告警；而且可以通過分布式服務的故障追蹤，快速定位微服務故障點以便於及時處理；同時內置日誌管理平臺，以幫助進行日誌分析。
TDC—Aquila平臺運維管理組件
作為星環科技自主研發的數據平臺，TDC DevOps平臺集合了DevOps和SRE的管理特色，開發整合了一系列自動化組件，為企業的應用管理實踐帶來了看得見的便利：開發階段中環環相扣的質量管控流程加速了開發；簡易的上架和部署為運維人員節約了精力；自研的運維管理組件則提高了日常維護的效率。企業通過星環科技TDC DevOps工作檯可以實現對DevOps和SRE理念的優秀實踐。
— 軟體開發/運維流程的未來趨勢 —
在未來，自動化、敏捷和快速反饋依舊會是軟體開發交付的趨勢。隨著跨雲業務的發展，開發運維間的協同也會不斷在雲端進行；伴隨著雲聯邦場景，跨雲測試環境以及代碼跨雲端自動化部署和交付或將變為廣泛實踐。智能運維或將從實驗走向落地，對雲系統全鏈路進行問題跟蹤監控、歸納和預測，保證各類雲業務在生產中更穩定的迭代及運行。此外，安全問題也會逐漸成為關注焦點，目前安全團隊和開發團隊開發相對獨立，安全測試引入流水線已是所需。
【微信搜索關注關注「星環科技」公眾號>>>更多內容資訊等你來看>>>還有不定時福利放送哦！】
>>>