前言
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工作臺整合了包括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提供的能力在於，它使上述過程不需要在各個平臺間跳轉完成，只需要在統一的操作平臺上一體化的實現。而應用開發完成後，運維/SRE人員僅需通過TDC提供的可視化上架和部署接口，便可以快速進行上架。然後通過資源參數配置，實現應用一鍵部署。
此外，星環自主研發、整合了一系列運維工具，形成一套完整的治理中心來協助應用運維。TDC的運維管理工具能夠對應用的時序指標如CPU、內存等進行收集、監控和告警；而且可以通過分佈式服務的故障追蹤，快速定位微服務故障點以便於及時處理；同時內置日誌管理平臺，以幫助進行日誌分析。
TDC—Aquila平臺運維管理組件作爲星環自主研發的數據平臺，TDC DevOps平臺集合了DevOps和SRE的管理特色，開發整合了一系列自動化組件，爲企業的應用管理實踐帶來了看得見的便利：開發階段中環環相扣的質量管控流程加速了開發；簡易的上架和部署爲運維人員節約了精力；自研的運維管理組件則提高了日常維護的效率。企業通過星環TDC DevOps工作臺可以實現對DevOps和SRE理念的優秀實踐。
軟件開發/運維流程的未來趨勢
在未來，自動化、敏捷和快速反饋依舊會是軟件開發交付的趨勢。隨着跨雲業務的發展，開發運維間的協同也會不斷在雲端進行；伴隨着雲聯邦場景，跨雲測試環境以及代碼跨雲端自動化部署和交付或將變爲廣泛實踐。智能運維或將從實驗走向落地，對雲系統全鏈路進行問題跟蹤監控、歸納和預測，保證各類雲業務在生產中更穩定的迭代及運行。此外，安全問題也會逐漸成爲關注焦點，目前安全團隊和開發團隊開發相對獨立，安全測試引入流水線已是所需。
往期原創文章
TCOS – 業界首個支持生產級大數據業務的容器操作系統
TDC–帶來新一代大數據產品形態
行業觀察: 雲+大數據+AI推動企業數據業務演進TCOS 2.0 發佈 | 面向異構聯邦的容器操作系統Docker與Kubernetes的前世今生（上）Docker和Kubernetes的前世今生（下）
作者介紹：
本文轉載自大數據開放實驗室，已經過對方授權。大數據開放實驗室由星環信息科技（上海）有限公司運營，致力於大數據技術的研究和傳播。