把運維和開發放一起就是DevOps？還差得遠！
劉華（Kenneth）， 就職於世界500強銀行。負責基金外包業務軟體開發與交付。敏捷、精益、DevOps領域專家。著有《獵豹行動——硝煙中的敏捷轉型之旅》一書。
DevOps倡導“誰開發，誰運維”和開發運維一體化，那麼是不是簡單地把開發和運維人員放在一起就完事了呢？
一、DevOps轉型中的“插隊”故事
1、運維專員小明的故事
小明入職時是運維專員，原來隸屬於運維部門，負責某業務線系統的應用維護工作。
一旦系統的生產環境出現任何故障，或者業務人員在生產環境上有任何請求，都是由小明所在的運維部門先處理，處理不了的，再聯絡該系統的開發團隊一起處理。
由於生產環境關乎業務部門的業績，每天收到的請求量也非常多，小明的壓力很大，而且並不是每個故障或請求他都有能力或來得及處理；找開發團隊，又會被開發團隊說他只是把事情“左手交右手”，沒有提供價值，小明很委屈也很為難。
他並沒有參與系統的開發，而系統上線後的問題卻需要他來應對，幹著最苦最累的“背鍋俠”的活，卻沒有什麼掌聲和成就感。
兩年前，公司開始進行DevOps轉型，把運維部門撤銷了，小明“插隊”到了業務線系統的原開發團隊中。
公司希望藉此讓業務線的交付團隊負責從開發到運維的整個鏈條，也讓像小明這樣的運維人員有機會參與到專案工作中，提升他們的技能和工作滿意度。 原來的開發人員也要參與運維，在開發中更多地考慮到生產環境執行的問題。
有重大問題時，整個團隊都可以參與運維、解決問題。
但幾個月後，小明發現他的具體工作並沒有什麼變化，生產環境的一切事務依然還是先派給他，由於這項工作已經佔據了他所有的工作時間，他沒有機會參與專案交付。
他感覺自己和團隊裡的開發人員是“同床異夢”，也沒有機會拓展自己的能力。
2、DBA小崔的故事
小崔是持證DBA。原來隸屬於獨立的IT運維部門，該部門掌管著一切IT基礎設施，如伺服器、作業系統、資料庫、中介軟體、網路以及相應的專家團隊。
由於重要的許可權都掌握在這些專家團隊手上，業務線交付團隊如果無法獲得IT運維部門的支援，專案就進展不下去。 當各業務線的專案需求越來越多時，IT運維部門就成了整個公司的瓶頸。
為了解決這個問題，公司開始將IT運維部門去中心化，部分領域專家“插隊”到各業務線交付團隊中，從而減少交付團隊的對外依賴，實現“自給自足”。
小崔就是這波浪潮中的其中一員。被收編到交付部門後，他比過去更忙了。
由於DBA是比較專業的技能，多大的團隊需要一個全職DBA成了一個問題。團隊太小，擁有一個DBA響應力絕對沒有問題，但是無法充分利用其時間；如果幾個團隊共享一個DBA，又會出現新的瓶頸問題。
小崔就是一個被幾個交付團隊“共享”的DBA，因為要疲於應付各交付團隊的請求，他已經沒有時間成長。
過去，由於DBA都集中在一起，他們之間可以頻繁交流，相互學習，共同成長。而小崔現在收穫到的只有孤獨和壓力。
3、DBA大鵬的故事
同樣以DBA身份入職的大鵬則面對另一個情景。
由於他是新招的，直接進入了交付團隊，但該團隊的DBA工作不飽和，他被安排做了很多與DBA不相關的專案工作。
半年後，他辭職了，因為他感覺再這樣下去，他的DBA武功就要廢了。
如果你的公司也在做DevOps轉型，以上故事是否也在你身邊發生呢？雖然說分分合合是組織轉型的常態，但是處理不好，代價是相當沉重的。
二、思考DevOps時代下工作整合問題
什麼樣的工作需要整合，什麼樣的工作不應該整合？
既然我們已經通過多年的經驗證明了在軟體交付領域，分角色的精細分工是不利於整體交付效率的，那為什麼在DevOps倡導下的全棧工程師、開發運維一體化又會產生新的問題呢？如何解決這些新問題呢？
也許，我們需要認真思考， 在整個軟體交付過程中，什麼樣的工作需要整合，什麼樣的工作不應該整合。
在前DevOps時代，分角色分工的思路其實是來源於工業時代的。做過手工的都知道，如果要手工做100只燈籠，一開始會做得很慢，做了幾隻後，會越做越快，所謂熟能生巧。
再進一步，把做燈籠的過程拆解一下，比如拆解成搭骨架、糊紙、上色等工序，然後多找幾個人來，每人負責其中一道工序，經過幾番磨合，由於每個人要做的事情比較單一，很容易上手和熟練，效率將會大大提升。 燈籠的成品和質量也會越來穩定。
把這個過程放大，就是一個工廠的模式。
所有工廠都是通過拆解和精細分工獲得極高的效率的，而且，分工越精細，效率越高。而 生產最大的特點是在不斷地做重複的事情 ， 產出是同樣的產品，而且產品間的差異越小越好，最好趨近於零。 對於重複的事情，就應該通過拆解、精細分工、標準化和自動化來提升效率。
但是軟體交付過程則完全不一樣， 和生產最大的區別就是“不重樣”。
每一個軟體需求都是不一樣的，使用者想要的結果也是不一樣的，這導致需求分析、開發、測試面對每個需求，或者運維面對每個故障的具體工作是不一樣的。
而且軟體交付是一個知識工作，是資訊流動和轉換的過程，而 交接會帶來資訊的衰減和變異， 因此在軟體交付過程中，按角色分工非但不會帶來像生產那樣的效率提升，反而會因為 資訊在不同角色間的交接和傳遞而產生不必要的摩擦和誤解，甚至交付出錯誤的軟體產品。
因此，我們更希望 軟體交付團隊成員可以具備從需求到運維的端到端的交付能力，每個團隊針對一個特定的業務領域能夠獨立完成交付，減少交接，減少對外依賴。
而且這個團隊應該足夠小（最好不多於7人），以確保團隊內目標一致、高效溝通和高度靈活。
然而，對於業務或使用者來說，IT系統和服務是一個整體，除了軟體，還有硬體。 而每個人的頻寬和能力都是有限的，術業有專攻，不可能每個人都是全能的，特別是有些細分領域專業度非常高。
如果把所有的職責都歸到業務線交付團隊，那麼交付團隊必然需要擁有具備各類所需技能的專家，從而形成新的龐大實體，除了造成不必要的資源浪費外，組織一旦變大，勢必又會變得官僚和低效，原本想避免的問題又會重新出現。
三、解決工作整合問題的關鍵
要找出哪些工作是重複的，哪些是非重複的。
那麼問題的癥結在哪裡呢？通過前面的分析，我們知道，重複的工作，可以通過拆分、精細分工、標準化和自動化來提升效率，非重複的工作，可以通過減少交接和依賴來提升效率。
要解決如何分、如何合的問題，最關鍵的就是找出哪些工作是重複的，哪些是非重複的。重複的，解決方案是整合資源、角色分工和自動化；非重複的，解決方案是一體化。
那麼在軟體交付過程中，哪些工作是重複性的呢？我想到的有以下這些：
1、網路、硬體等基礎設施
這些IT基礎設施不會因為不同的專案和需求有太多的差異，而且專業性強，不太適合一人分飾多角，這些角色整合在一個獨立團隊中，使他們保持專注，也有利於這些專業領域的技術交流和知識傳遞。
2、部署
應該儘量自動化，最低要求也應該標準化，有標準的具體作業流程，誰都可以遵照流程做好。
我們可以安排前文中的小明把應用部署過程整理成含具體操作步驟的標準化手冊，這樣這項工作團隊內誰都能做，把他從部署這項具體工作釋放出來，在此基礎上，讓他把這個過程自動化，從而讓他學習流水線和自動化部署的技術，接觸技術性工作。
他也可以把故障處理流程整理成操作手冊，賦能其他團隊成員在合規的環境下承擔運維工作，把他自己釋放出來；
3、 DBA、作業系統等專家團隊
應該通過指令碼、自助服務等形式賦能交付團隊在受控的環境下滿足交付需要，減少對他們的依賴。
我們可以讓前文中的小崔和大鵬收集各交付團隊對於DBA的具體需求，把具有共性的需求提煉出來，做成可以通過DBA許可權執行的指令碼，既滿足交付的需求，又確保了DBA許可權不會被濫用；
4、標準流程
所有專案都必須要走的標準流程，如採購等，由專業的團隊提供服務的形式來執行，大大降低各專案團隊由於需要熟悉繁瑣流程的過程所導致的不必要浪費；
需求分析、開發、測試、業務支援等非重複性工作則應該保持在一個自滿足小團隊中，為特定的業務領域提供軟體交付和維護服務。
四、總結
分分合合是組織轉型的常態。
DevOps的目標是 實現持續交付，提升整體的交付效率。 要實現這個目標，簡單地把開發、應用維護，甚至IT運維整合在一起，有點過於粗暴。
我們還是 應該認真分析哪些具體工作是重複的、可標準化的和哪些是非重複的、不能標準化的來分開處置。重複的，解決方案是整合資源、角色分工、標準化和自動化；非重複的，解決方案是一體化。