如果讓三個人描述DevOps，您將得到四個不同的答案。有時，從事運營工作的開發人員被稱為DevOps。其他人則說這與基礎架構和部署的自動化有關。有時，您可以看到DevOps是sysadmins的現代化標籤。我們可以看到該術語很流行。那到底是什麼呢？什麼是DevOps？

DevOps的第一種方式是通過組織中各個職能領域（從收集需求到生產中的軟體運維）建立平衡穩定的工作流程。重點放在整個系統的全域性目標上，而不是單個部門的區域性目標上。為了使概念更清晰，讓我們看幾個關鍵要點。

1.1減少批次大小

進行中（WIP）是已開始但尚未完成的工作量。大量在製品是多工處理的標誌，並且會阻礙工作流程。為了限制在製品，我們應該減小批量大小。這個想法源於精益製造。大批量生產零件在製造業中很常見。設定新機器並在工作之間切換既昂貴又費時。因此，在設定好機械之後，儘可能多地製造零件被認為是可行的。

例如，一家汽車生產廠將生產大量的車身面板以減少轉換次數。但是，這會產生大量的WIP。工作流程的可變性在整個製造工廠中級聯，從而導致更長的交貨時間。想象一下，如果在組裝汽車時在車身面板上發現缺陷，會發生什麼？最有可能的是，整個批次必須被丟棄和再生產。批量生產會延遲反饋，如果出現錯誤，則必須重做更多工作。

同樣的想法適用於軟體開發。但是，我們正在處理程式碼，而不是機械和車身面板。對版本控制的每次提交都會增加軟體開發價值流中的批處理大小。

一個典型的例子是年度生產部署計劃。如果每年進行一次部署，則批處理量很大。一步就可以部署一年。與汽車廠類似，如果出現任何問題，則必須將整個批次回退。然後必須付出更多的努力來重做被認為已完成的工作。而且要發現並解決導致部署失敗的問題，例如6個月前，就具有挑戰性。

使用壽命較長的特性分支時，可能會遇到類似的問題。分支保持隔離狀態的時間越長，看到的更改越多，批處理大小就越大。隨著時間的流逝，將其整合回主幹變得越來越困難。合併衝突的可能性很高。由於反饋被延遲，因此返工的可能性很高。這些因素破壞了工作流程並增加了部署前置時間。

為了縮短部署的交付時間，我們必須減小批量大小。不建議使用長期存在的功能分支。如果我們儘早整合並且以較小的增量部署軟體，則可以獲得更快的反饋。如果我們繼續減小批處理的大小，我們最終將達到單件流，其中每次提交都會流經整個軟體開發價值流。一旦所有自動檢查都通過，更改將最終投入生產。

能夠實現這一目標的團隊將利用基於主幹的開發，持續整合，持續交付和持續部署等實踐。他們在測試自動化方面進行了投資，併為低風險版本設計了他們的軟體。他們還組織了自己，以使所需的移交次數最小化。交接需要溝通和協調。不幸的是，即使在最好的情況下，一些知識也會丟失。這是一個潛在的錯誤點，錯誤可能蔓延，工作可能堆積起來，從而中斷流程並增加部署提前期。

1.2消除約束

不斷髮現和消除我們工作中的限制是提高產量和減少交貨時間的關鍵。Goldratt博士在《超越目標：約束理論》中指出

在任何價值流中，總是有一種流動的方向，並且總是隻有一個約束。在這種約束下沒有做的任何改進都是一種幻想。

技術價值流的一個例子是環境創造。如果建立測試環境需要花費數小時，那麼在價值流中進行的任何改進工作都是一種幻想。

例如，如果我們將構建時間從10分鐘減少到3分鐘，則構建速度會更快。但是總體上沒有什麼事情做得更快。建立環境仍然是一個障礙。更糟糕的是，WIP增加了。現在，新版本的堆積速度甚至更快，等待部署到測試環境。由於建立環境會阻止新的工作順利進行，因此在我們應該在價值流中找到約束，將其消除，然後找到下一個約束。

關於我們

澤陽，DevOps領域實踐者。專注於企業級DevOps運維開發技術實踐分享，主要以新Linux運維技術、DevOps技術課程為主。豐富的一線實戰經驗，課程追求實用性獲得多數學員認可。課程內容均來源於企業應用，在這裡既學習技術又能獲取熱門技能，歡迎您的到來！（微信ID: devopsvip）

DevOps流水線實踐課程

????戳閱讀原文，進入課堂