[[346069]]

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

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

1.1減少批次大小

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

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

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

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

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

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

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

1.2消除約束

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

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

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

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