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

內容來源：2017年6月10日，優維科技高級解決方案架構師黃星玲在「DevOps&SRE 超越傳統運維之道」進行《DevOps在傳統企業的落地實踐及案例分享》演講分享。IT 大咖說做爲獨家視頻合做方，經主辦方和講者審閱受權發佈。

摘要
在傳統支撐模式沒法知足業務價值快速交付要求的狀況下，傳統企業應該如何引入DevOps能力進行突破創新，本次分享將從如下幾個方面具體探討DevOps如何與傳統融合進而落地：
1.DevOps的總體框架及落地方法探討；
2.DevOps落地關鍵點之一：IT元數據平臺的重要性及設計標準；
3.DevOps落地關鍵點之二：持續交付在傳統企業的融合方法探討；
4. 電力行業案例分享。DevOps總體體系框架

DevOps是一連串的工程實踐的有機組合，其中包括敏捷管理、持續交付、IT服務管理等等。
DevOps是關注整個業務/應用/服務生命週期的管理，把業務和IT的戰略進行了對齊。
DevOps以精益思想爲基礎，強調自動化、拉動式、「拒絕浪費、創造價值」等。

從軟件研發模式看DevOps
目前的「瀑布流」模式開發中間有不少部門牆，從研發到測試再到運維，它們中間是徹底斷層的。斷層的理念會致使咱們在研發的過程當中測試和運維都無事可作，這就是一種浪費。
如今作的敏捷迭代、測試驅動開發讓咱們組成小team模式。這種模式以業務價值流來進行交付，要可以保證快速交付產品、模塊，而且是能夠獨立運行的。
DevOps讓團隊共享面向客戶的價值、共享集成目標、共享質量責任。
DevOps也讓運維的做用變得更加突顯，此時須要全新的思惟/平臺/方法論來實現Dev的軟件快速交付到Ops階段，而且可以穩定地運營。DevOps的落地經驗談
移動互聯網時代的業務特徵就是快！產品的決策快、推出快、迭代快、變革快，快能抓住機遇、掌握主動。
對IT支撐也帶來了一些挑戰，例如快速交付產品、IT支撐可靈活擴展、更高要求的客戶體驗、項目時間緊、須要快速響應業務/需求變化。
沒法快速響應業務激增的需求：新型互聯網業務對資源需求的波峯波谷現象更突出，服務對外開放使業務量的不可預估。目前臨時業務不管高峯、低峯期均須要大量的人工介入，系統靈活擴展性不足。
系統維護難度高：支撐系統X86分佈式集羣架構改造後，應用主機多，故障定位困難；缺少自動化的系統處理，須要大量的人工介入，處理時間長，對維護人員技術要求很是高。
不能實現敏捷開發：須要開發人員對每臺服務器進行復雜操做才能完成部署，需求測試環節須要根據業務依賴關係逐一測試，開發難度和上線效率不高，很難作到敏捷開發，快速發佈，持續集成。
傳統架構架構簡單，運維快速定位，快速發佈。但支撐內部總體目標架構沒有統一的規劃設計，系統煙囪式建設。
轉變爲雲化架構後，經過核心雲構建，實現資源共享，和設備資源層造成聯動，實現應用的彈性伸縮。可是雲化架構比較複雜，須要運維過程智能化，自動化轉型。
咱們如何提升產品交付給客戶的速度、如何改變產品更快更好知足咱們客戶、如何恢復故障不至於影響咱們的客戶、如何更快經過咱們的努力得到客戶承認？
打通市場需求、開發、測試、發佈、部署上線、運維等各環節，促進需求、開發、測試、運維團隊更緊密地合做，敏捷開發，持續交付、自動運維，提升支持系統的生產、交付效率。

理念與價值先行
經過持續服務交付價值鏈打破孤島，整合開發和運維的能力成爲一個協做的團隊。進行端到端持續服務交付流程的變革。對新的應用和服務，加快且縮短實現價值的時間。不影響安全性、兼容性和性能。頂層設計、全局規劃

這張圖是咱們產品設計的全局規模規劃圖，但在全部公司都適用。之後不管是作運維自動化仍是DevOps總體門戶化，都是有一個統一運維的門戶。從小作起，Start Small
基於某個角色、某個場景從小作起，從本身作起。基於某個系統或者某個功能域來實施導入，切忌貪大求全。構建元數據基礎平臺CMDB

要構建元數據基礎平臺CMDB，應該是自動化的。

CMDB成爲IT運營管理平臺的核心元數據。CMDB數據的「鮮活性」，核心靠場景驅動。

CMDB分核心模型和擴展模型。核心模型是業務、應用、主機和程序包；擴展模型是基於這個實例的關聯對象。創建以應用爲中心的資源管理模型。

工具也一種文化
做業管理，一方面把運維的腳本能力可視化，另外一方面也在提升運維的效率和質量。
調度管理，提供面向復瑣事務的能力封裝。

基於做業和調度能力，面向角色場景化收斂和歸類各種能力。
好的經驗，經過自動化的手段沉澱，工具化，極簡管理過程。工具是真正推進變革的有效手段，自底向上的核心手段。組織二元性

服務主管，對IT服務及時性相應負責，相似Scrum的PO。
DevOps工程師，有義務提升和維護自動化流程，構建完整的自動化過程和工具，提高效率。
把關人，負責監控IT服務的運行狀態和下一步發佈的進展。
可靠性工程師，監控部署過程當中的服務並處理正在服務執行中產生的問題。
流程主管，領導並促進團隊，這個角色相似於在Scrum中的Scrum Master。

運維交付團隊。分資源交付團隊、應用交付團隊、運維研發團隊。運維研發負責運維交付能力自動化。
開發測試團隊。設立測試研發團隊，負責測試能力自動化。
DevOps研發團隊。負責從持續交付的角度端到端的能力集成。
服務主管、流程主管角色不變。
如上圖所示，等待時間和實際所用時間相差很大，這中間的浪費很是大，這就是部門牆致使的。咱們須要保證每個運轉的中心都是一直在工做的。不論是需求、開發、測試仍是運維，都應該是拉動式的，由於只有他本身才知道當下處於運行狀態仍是空閒狀態。自動化別人，先自動化本身

自動化是一個由點到線到面的過程。要先從一個小的點切入，把自動化作完以後才能夠一點一點影響到周圍，進行擴散。
自動化是一個逐步覆蓋更多角色的過程。作完一件事再作第二件事的時候，它們都是互相影響的。
自動化也是一個環境逐步覆蓋的過程，先生產，再測試，再開發。持續交付是最佳的DevOps實踐

從上圖可見，開發、測試、預發佈和生產所作的事有不少都是重複的。若是能把這些自動化、工具化，重複的工做就不存在了。
還要作到標準化。從開發、測試到運維，基礎環境和應用架構都是標準化的。當咱們把全部的事情都作到標準化、無狀態化、微服務化的時候，這些操做將會變得特別簡單。而且要把整個交付的過程可視化，要知道進度到了哪一個階段。構建面向應用的最強驅動力

CMDB系統要實現向資源管理系統的過渡，應用的變動場景最終是對資源的變動，應用的狀態最終是由其資源的狀態來決定的。
今天的分享就到這裏，謝謝你們！

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