DevOps在傳統企業的落地實踐及案例分享

摘要

在傳統支撐模式無法滿足業務價值快速交付要求的情況下，傳統企業應該如何引入DevOps能力進行突破創新，本次分享將從以下幾個方面具體探討DevOps如何與傳統融合進而落地：

1.DevOps的整體框架及落地方法探討；

2.DevOps落地關鍵點之一：IT後設資料平臺的重要性及設計標準；

3.DevOps落地關鍵點之二：持續交付在傳統企業的融合方法探討；

4. 電力行業案例分享。

DevOps整體體系框架

目前的“瀑布流”模式開發中間有很多部門牆，從研發到測試再到運維，它們中間是完全斷層的。斷層的理念會導致我們在研發的過程中測試和運維都無事可做，這就是一種浪費。

現在做的敏捷迭代、測試驅動開發讓我們組成小team模式。這種模式以業務價值流來進行交付，要能夠保證快速交付產品、模組，並且是可以獨立執行的。

DevOps讓團隊共享面向客戶的價值、共享整合目標、共享質量責任。

DevOps也讓運維的作用變得更加突顯，此時需要全新的思維/平臺/方法論來實現Dev的軟體快速交付到Ops階段，並且能夠穩定地運營。

移動網際網路時代的業務特徵就是快！產品的決策快、推出快、迭代快、變革快，快能抓住機遇、掌握主動。

對IT支撐也帶來了一些挑戰，例如快速交付產品、IT支撐可靈活擴充套件、更高要求的客戶體驗、專案時間緊、需要快速響應業務/需求變化。

無法快速響應業務激增的需求：新型網際網路業務對資源需求的波峰波谷現象更突出，服務對外開放使業務量的不可預估。目前臨時業務無論高峰、低峰期均需要大量的人工介入，系統靈活擴充套件性不足。

系統維護難度高：支撐系統X86分散式叢集架構改造後，應用主機多，故障定位困難；缺乏自動化的系統處理，需要大量的人工介入，處理時間長，對維護人員技術要求非常高。

不能實現敏捷開發：需要開發人員對每臺伺服器進行復雜操作才能完成部署，需求測試環節需要根據業務依賴關係逐一測試，開發難度和上線效率不高，很難做到敏捷開發，快速釋出，持續整合。

傳統架構架構簡單，運維快速定位，快速釋出。但支撐內部整體目標架構沒有統一的規劃設計，系統煙囪式建設。

轉變為雲化架構後，通過核心雲構建，實現資源共享，和裝置資源層形成聯動，實現應用的彈性伸縮。但是雲化架構比較複雜，需要運維過程智慧化，自動化轉型。

我們如何提高產品交付給客戶的速度、如何改變產品更快更好滿足我們客戶、如何恢復故障不至於影響我們的客戶、如何更快通過我們的努力獲得客戶認可？

打通市場需求、開發、測試、釋出、部署上線、運維等各環節，促進需求、開發、測試、運維團隊更緊密地合作，敏捷開發，持續交付、自動運維，提高支援系統的生產、交付效率。

通過持續服務交付價值鏈打破孤島，整合開發和運維的能力成為一個協作的團隊。進行端到端持續服務交付流程的變革。對新的應用和服務，加快且縮短實現價值的時間。不影響安全性、相容性和效能。

這張圖是我們產品設計的全域性規模規劃圖，但在所有公司都適用。以後無論是做運維自動化還是DevOps整體門戶化，都是有一個統一運維的門戶。

基於某個角色、某個場景從小做起，從自己做起。基於某個系統或者某個功能域來實施匯入，切忌貪大求全。

要構建後設資料基礎平臺CMDB，應該是自動化的。

CMDB成為IT運營管理平臺的核心後設資料。CMDB資料的“鮮活性”，核心靠場景驅動。

CMDB分核心模型和擴充套件模型。核心模型是業務、應用、主機和程式包；擴充套件模型是基於這個例項的關聯物件。建立以應用為中心的資源管理模型。

作業管理，一方面把運維的指令碼能力視覺化，另一方面也在提高運維的效率和質量。

排程管理，提供面向複雜事務的能力封裝。

基於作業和排程能力，面向角色場景化收斂和歸類各類能力。

好的經驗，通過自動化的手段沉澱，工具化，極簡管理過程。工具是真正推動變革的有效手段，自底向上的核心手段。

服務主管，對IT服務及時性相應負責，類似Scrum的PO。

DevOps工程師，有義務提高和維護自動化流程，構建完整的自動化過程和工具，提升效率。

把關人，負責監控IT服務的執行狀態和下一步釋出的進展。

可靠性工程師，監控部署過程中的服務並處理正在服務執行中產生的問題。

流程主管，領導並促進團隊，這個角色類似於在Scrum中的Scrum Master。

運維交付團隊。分資源交付團隊、應用交付團隊、運維研發團隊。運維研發負責運維交付能力自動化。

開發測試團隊。設立測試研發團隊，負責測試能力自動化。

DevOps研發團隊。負責從持續交付的角度端到端的能力整合。

服務主管、流程主管角色不變。

如上圖所示，等待時間和實際所用時間相差很大，這中間的浪費非常大，這就是部門牆導致的。我們需要保證每一個運轉的中心都是一直在工作的。不管是需求、開發、測試還是運維，都應該是拉動式的，因為只有他自己才知道當下處於執行狀態還是空閒狀態。

自動化是一個由點到線到面的過程。要先從一個小的點切入，把自動化做完之後才可以一點一點影響到周圍，進行擴散。

自動化是一個逐步覆蓋更多角色的過程。做完一件事再做第二件事的時候，它們都是互相影響的。

自動化也是一個環境逐步覆蓋的過程，先生產，再測試，再開發。

從上圖可見，開發、測試、預釋出和生產所做的事有很多都是重複的。如果能把這些自動化、工具化，重複的工作就不存在了。

還要做到標準化。從開發、測試到運維，基礎環境和應用架構都是標準化的。當我們把所有的事情都做到標準化、無狀態化、微服務化的時候，這些操作將會變得特別簡單。並且要把整個交付的過程視覺化，要知道進度到了哪個階段。

CMDB系統要實現向資源管理系統的過渡，應用的變更場景最終是對資源的變更，應用的狀態最終是由其資源的狀態來決定的。