DevOps倡導“誰開發，誰運維”和開發運維一體化，那么是不是簡單地把開發和運維人員放在一起就完事了呢?

[[260606]]

一、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運維整合在一起，有點過于粗暴。

我們還是應該認真分析哪些具體工作是重復的、可標準化的和哪些是非重復的、不能標準化的來分開處置。重復的，解決方案是整合資源、角色分工、標準化和自動化;非重復的，解決方案是一體化。

作者介紹

劉華(Kenneth)，就職于世界500強銀行。負責基金外包業務軟件開發與交付。敏捷、精益、DevOps領域專家。著有《獵豹行動——硝煙中的敏捷轉型之旅》一書。