關於作者：
肯尼思他在一家財富 500 強銀行工作。 負責外包業務的軟體開發和交付。 敏捷、精益、DevOps領域的專家。 他是《獵豹行動：火藥煙霧中的敏捷轉型之旅》一書的作者。
DevOps提倡“誰開發、誰運營”和DevOps的融合，那麼是不是簡單地把開發和運維人員放在一起呢？
1. DevOps轉型中“插隊”的故事
1.運維專家小明的故事。
小明加入公司時，是一名運維專員，原本隸屬於運維部門，負責某業務線系統的應用維護。
一旦系統生產環境出現故障，或者業務人員在生產環境中有任何要求，小明所在地的運維部門會先處理，再聯絡系統的開發團隊進行處理。
由於生產環境關係到業務部門的績效，每天收到的請求數量非常多，小明承受著很大的壓力，並不是每乙個故障或請求他都有能力或時間去處理;找開發團隊，開發團隊會說他只是“把東西交給右手”，沒有提供價值，小明很委屈，很尷尬。
他沒有參與系統的開發，但系統推出後的問題需要他來處理，做著“鍋後人”最辛苦最累的工作，卻沒有掌聲和成就感。
兩年前，公司開始進行DevOps轉型，並取消了運維部門，小明“插線”進入了原有的業務線系統開發團隊。
公司希望讓業務線交付團隊負責從開發到運營的全鏈條，也讓像小明這樣的運營人員有機會參與專案工作，提高技能和工作滿意度。 原有的開發者也參與到運維中，在開發中更多地考慮了生產環境的執行。
當出現重大問題時，可以全隊參與運維，解決問題。
但幾個月後，小明發現自己的具體工作並沒有改變，生產環境中的一切還是先分配給他，而且由於這項工作占用了他所有的工作時間，他沒有機會參與專案交付。
他覺得自己和團隊中的開發人員在同一張床上，他沒有機會擴充套件自己的能力。
2.DBA小崔的故事。
Xiao Cui 是一名持牌 DBA。 它最初是乙個獨立的 IT 運營部門的一部分，該部門負責所有 IT 基礎設施，例如伺服器、作業系統、資料庫、中介軟體、網路和相應的專家團隊。
由於這些專家團隊掌握著重要的許可權，如果沒有 IT 運營的支援，業務線交付團隊就無法向前發展。 當各業務線的專案需求不斷增加時，IT運維部門就成了整個公司的瓶頸。
為了解決這個問題，公司開始將IT運維部門下放，一些領域專家“插隊”到各業務線的交付團隊中，從而減少交付團隊的外部依賴，實現“自給自足”。
小崔就是這股浪潮中的一員。在被納入交付部門後，他比以往任何時候都更忙。
由於 DBA 是一項更專業的技能，因此團隊需要多大的全職 DBA 就成了乙個問題。 團隊太小，無法擁有絕對沒問題的 DBA 響應能力，但無法充分利用其時間;如果多個團隊共享乙個 DBA，則會出現新的瓶頸。
崔是乙個被幾個交付團隊“共享”的DBA，他沒有時間成長，因為他要處理各個交付團隊的要求。
過去，因為DBA們都在一起，所以可以經常交流，互相學習習，共同成長。 而蕭翠現在得到的，只有孤獨和壓力。
3. DBA大鵬的故事。
同樣以DBA身份加入公司的大鵬面臨著不同的情況。
由於他是團隊的新人，他直接進入了交付團隊，但團隊中 DBA 工作並不飽和，他被指派做了很多與 DBA 無關的專案工作。
半年後，他辭職了，因為他覺得如果再這樣下去，他的DBA武功就會被廢掉。
如果您的公司也在進行 DevOps 轉型，那麼上述故事是否發生在您周圍？雖然說分離和整合是組織轉型的常態，但處理不好的代價是相當沉重的。
2. 思考DevOps時代的工作整合
什麼樣的工作需要整合，什麼樣的工作不應該整合？
既然我們通過多年的經驗證明，在軟體交付領域，角色的精細分工不利於整體交付效率，那麼為什麼在DevOps的倡導下，全棧工程師和DevOps的融合會產生新的問題呢？如何解決這些新問題？
也許，我們需要認真思考在整個軟體交付過程中，什麼樣的工作需要整合，什麼樣的工作不應該整合。
在前DevOps時代，基於角色的分工思想其實是工業時代最好的。 做過手工的人都知道，要想手工製作100盞燈籠，一開始會做得很慢，做幾盞之後，就會做得越來越快，所謂熟能生巧。
再進一步，拆解製作燈籠的過程，比如拆解成搭建骨架、貼紙、上色等過程，然後再找幾個人，每個人負責其中一道工序，經過幾次磨合，因為大家都要做一些比較單一的事情，容易上手和熟練，效率也會大大提高。 燈籠的成品和質量也會越來越穩定。
放大這個過程是工廠的模型。
所有的工廠都是通過拆解和精細分工而實現極高效率的，分工越精細，效率越高。 而生產的最大特點是不斷地做重複的事情輸出是相同的產品，產品之間的差異越小越好，最好接近於零。 對於重複性的事情，要通過拆解、精細分工、標準化、自動化來提高效率。
但軟體交付過程是另一回事與生產最大的區別在於“不一樣”。
每個軟體需求都不同，使用者想要的結果也不同，這就導致了對需求分析、開發測試、或者每次故障運維的要求都不同。
軟體交付是一項知識工作，是資訊流動和轉換的過程，而交接會帶來資訊的衰減和變化因此，在軟體交付過程中，按角色分工不會像生產那樣帶來效率的提公升，而是因為：不同角色之間的資訊交接和傳遞會導致不必要的摩擦和誤解，甚至交付錯誤的軟體產品。
因此，我們更願意軟體交付團隊成員可以具備從需求到運維的端到端交付能力，每個團隊可以針對特定業務領域獨立完成交付，減少交接和外部依賴。
團隊應該足夠小（最好不超過 7 人），以確保團隊保持一致、有效溝通和高度靈活。
但是，對於企業或使用者來說，IT系統和服務是乙個整體，除了軟體，還有硬體。 但是，每個人的頻寬和能力都是有限的，不可能每個人都是全能的，尤其是在一些細分領域。
如果把所有的責任都分配給業務線交付團隊，交付團隊將不可避免地需要具備所有必要技能的專家，從而產生乙個新的、龐大的實體，這不僅會造成不必要的資源浪費，而且一旦組織規模變大，也會變得官僚主義和效率低下，本應避免的問題會再次出現。
三、解決工作整合問題的關鍵
找出哪些工作是重複的，哪些是非重複的。
那麼問題的癥結是什麼呢？通過前面的分析，我們知道重複性工作可以通過拆分、精細分工、標準化和自動化來改善，非重複性工作可以通過減少交接和依賴來改善。
要解決如何劃分和如何組合的問題，最重要的是找出哪些工作是重複的，哪些是非重複的。 反覆地，解決方案是整合資源、角色分離和自動化;非重複性，解決方案是多合一的。
那麼，在軟體交付過程中，什麼樣的工作是重複的呢？我想到的是：
1. 網路、硬體和其他基礎設施
這些IT基礎設施不會因為不同的專案和需求而有太多的差異，而且專業化程度很高，不適合乙個人扮演多個角色，這些角色整合在乙個獨立的團隊中，這樣他們就可以保持專注，也有利於這些專業領域的技術交流和知識轉移。
2. 部署
它應該盡可能地自動化，最低要求也應該標準化，並且有標準的具體操作程式，任何人都可以遵循。
我們可以安排小明把應用部署流程整理成一本標準化的手冊，有具體的操作步驟，讓團隊中的任何人都可以做這項工作，把他從部署的具體工作中解放出來，並在此基礎上，讓他自動化這個過程，讓他學習習流水線和自動化部署技術， 並與技術工作取得聯絡。
他還可以將故障排除過程組織成操作手冊，使其他團隊成員能夠在合規的環境中承擔操作和維護工作，從而解放自己
3、DBA、作業系統等專家團隊
應使用指令碼、自助服務和其他形式來使交付團隊能夠在受控環境中滿足其需求，並減少對它們的依賴。
我們可以在上面的文章中請崔和大鵬收集每個交付團隊對DBA的具體要求，提煉出共性需求，製作出可以用DBA許可權執行的指令碼，既滿足了首付的要求，又保證了DBA許可權不會被濫用
4.標準流程
所有專案都必須經過標準化流程，如採購等，由專業團隊提供服務來執行，大大減少了因需要每個專案團隊熟悉繁瑣流程而造成的不必要浪費;
需求分析、開發、測試和業務支援等非重複性任務應保留在乙個小型的、自我滿足的團隊中，該團隊為特定業務領域提供軟體交付和維護服務。
四、總結
分離和合併是組織轉型的常態。
DevOps的目標是：實現持續交付，提高整體交付效率。 為了實現這一目標，簡單地整合開發、應用程式維護甚至 IT 運營有點過於粗糙。
我們仍然是要仔細分析哪些具體任務是重複性的，可以標準化，哪些是非重複性的，不能標準化。 反覆的解決方案是整合資源、分工、標準化、自動化;非重複性，解決方案是多合一的。