本文摘抄自《DevOps的概念與實踐》

1. 什麼是DevOps

通常是指新興的專業化運動，這種運動提倡開發和IT運維之間的高度協同，從而在完成高頻率部署的同時，提高生產環境的可靠性、穩定性、彈性和安全性。

2. DevOps與敏捷有什麼不同

相對於瀑布開發模式，敏捷開發過程的一個基本原則就是以更快的頻率交付最小化可用的軟體。在敏捷的目標裡，最明顯的是在每個Sprint的迭代週期末尾，都具備可以交付的功能。（部署的高頻率經常會導致部署堆積在IT運維的面前）

DevOps和敏捷軟體開發是相輔相成的，因為它拓展和完善了持續整合和釋出流程，因此可以確保程式碼是生產上可用，並且能確實給客戶帶來價值。

DevOps不僅僅建立了一個面向IT運維的工作流，當代碼已經開發完成但卻無法被部署到生產上時，這些部署都會被堆積到IT運維的面前，客戶因此也無法享受到任何價值，而且，部署經常導致IT環境的中斷和服務不可用。

3. DevOps與ITIL及ITSM有什麼不同

ITIL：即IT基礎架構庫(Information Technology Infrastructure Library, ITIL，資訊科技基礎架構庫)由英國政府部門CCTA(Central Computing and Telecommunications Agency)在20世紀80年代末制訂，現由英國商務部OGC(Office of Government Commerce)負責管理，主要適用於IT服務管理（ITSM）。ITIL為企業的IT服務管理實踐提供了一個客觀、嚴謹、可量化的標準和規範。

ITSM：即IT服務管理，是一套幫助企業對IT系統的規劃、研發、實施和運營進行有效管理的方法，是一套方法論。ITSM起源於ITIL（IT Infrastructure Library，IT基礎架構標準庫），ITIL是CCTA（英國國家電腦局）於1980年開發的一套IT服務管理標準庫。它把英國在IT管理方面的方法歸納起來，變成規範，為企業的IT部門提供一套從計劃、研發、實施到運維的標準方法。

在支撐IT運維的業務流程方面，ITIL和ITSM無疑還是最好的，實際上，它們描述了需要被IT運維支援的功能集合，這些功能集合足以支撐DevOps式的工作流。

DevOps的目標不僅僅只是增加變更的頻率，而且也支援在不中斷和破壞當前服務的基礎上確保功能部署成功，同時也可以快速檢測和修復缺陷。

4. DevOps與可視運維

可視運維是一個說明性的指南，該指南使得高效能IT運維能順利實現“從優秀到卓越”的轉換，關鍵點之一是如何控制和減少計劃外的工作。

DevOps不僅聚焦在建立快速和穩定的計劃工作流，而且DevOps也有一個更全面的方法來系統的消除計劃外的工作，定義開發彈性準則，並負責管理和減少技術債務。

5. DevOps的基本原則

DevOps的支撐原則--DevOps的三個基本點

由IT推動的業務價值流，它始於需求定義，進行開發構建，又交給IT運維，最後以一種服務的形式交付給客戶。

絕不傳遞一個已知缺陷至下游 

• 強調整個系統的效能，而非將效能侷限到特定的工作領域裡。
• 關於建立從右至左的反饋迴路，幾乎所有的流程改進計劃的目標都是縮短和放大反饋迴路，以便可以持續進行必要的修正。
• 打造一種文化用來促進兩件事：持續不斷的探索精神，勇擔風險的精神以及從成功和失敗中來學習的能力，同時記得：重複和實踐是融匯貫通的前提。

 探索精神和勇擔風險的精神可以確保我們持續改進，持續學習。

分配時間去改進每天的例行工作，培養一種獎勵冒險精神的風氣，同時主動引入故障到系統中，從而提高彈性。

6. DevOps模式的應用領域

•  將開發延伸至生產中--包括拓展持續整合和釋出功能至生產，整合QA和資訊保安至整個工作流，確保程式碼和環境可在生產中直接部署
• 向開發中加入生產反饋--包括建立開發和IT運營事件的完整時間表用於幫助事件的解決，使得開發融入無指責的生產反思，儘可能使開發可以自助服務，同時建立資訊指示器來表明本地的決策如何影響全域性的目標。
• 開發嵌入到IT運維中--包括開發投入到整個生產問題處理鏈，分配開發資源用於生產問題管理，並協助退回技術債務，並且開發為IT運維提供交叉培訓，增加IT運維處理問題的能力，從而降低升級問題的數量。
• 將IT運維嵌入至開發--包括嵌入和聯絡IT運維資源至開發，幫助開發建立為運維使用的可重用的使用者故事，定義一些可以被所有專案共用的非功能性需求。

7. DevOps的價值

3個業務優勢：

• 產品快速推向市場
• 提高質量
• 提高組織的有效性：比如將時間花在價值增加活動中，減少浪費，同時交付更多的價值至客戶手中。

8. 資訊保安和QA如何融入DevOps的工作流

DevOps的高部署頻率通常會給QA和資訊保安帶來很大的壓力！

相較於標準的功能單元測試，DevOps工作流依賴於檢測和恢復更多一點。當開發以軟體套件的方式交付的時候，部署變更和補丁就比較困難，同時QA也嚴重依賴程式碼檢測來驗證功能的正確性。另一方面，當軟體以服務的形式交付，缺陷就可以被很快修復。而且，QA可以減少測試依賴，取而代之的更多依賴缺陷的生產監控，只要缺陷能被快速的修復。

程式碼故障恢復可藉助於“功能標籤”等手段，通過以配置的形式來啟用或禁用某些程式碼功能，從而達到避免推出一個全功能部署，而只部署通過測試的功能至生產。

當功能不可用或效能下降等情況時，依賴於檢測和恢復進行QA將會一種更好的選擇，但當出現損失保密性或資料和系統不一致性的時候，就需要在部署之前進行充分的測試，而不是檢測和恢復了！