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

[[260606]]

一、DevOps轉(zhuǎn)型中的“插隊”故事

1、運維專員小張的故事

小張入職時是運維專員，原來隸屬于運維部門，負責(zé)某業(yè)務(wù)線系統(tǒng)的應(yīng)用維護工作。

一旦系統(tǒng)的生產(chǎn)環(huán)境出現(xiàn)任何故障，或者業(yè)務(wù)人員在生產(chǎn)環(huán)境上有任何請求，都是由小張所在的運維部門先處理，處理不了的，再聯(lián)系該系統(tǒng)的開發(fā)團隊一起處理。

由于生產(chǎn)環(huán)境關(guān)乎業(yè)務(wù)部門的業(yè)績，每天收到的請求量也非常多，小張的壓力很大，而且并不是每個故障或請求他都有能力或來得及處理;找開發(fā)團隊，又會被開發(fā)團隊說他只是把事情“左手交右手”，沒有提供價值，小張很委屈也很為難。

他并沒有參與系統(tǒng)的開發(fā)，而系統(tǒng)上線后的問題卻需要他來應(yīng)對，干著最苦最累的“背鍋俠”的活，卻沒有什么掌聲和成就感。

兩年前，公司開始進行DevOps轉(zhuǎn)型，把運維部門撤銷了，小張“插隊”到了業(yè)務(wù)線系統(tǒng)的原開發(fā)團隊中。

公司希望借此讓業(yè)務(wù)線的交付團隊負責(zé)從開發(fā)到運維的整個鏈條，也讓像小張這樣的運維人員有機會參與到項目工作中，提升他們的技能和工作滿意度。原來的開發(fā)人員也要參與運維，在開發(fā)中更多地考慮到生產(chǎn)環(huán)境運行的問題。

有重大問題時，整個團隊都可以參與運維、解決問題。

但幾個月后，小張發(fā)現(xiàn)他的具體工作并沒有什么變化，生產(chǎn)環(huán)境的一切事務(wù)依然還是先派給他，由于這項工作已經(jīng)占據(jù)了他所有的工作時間，他沒有機會參與項目交付。

他感覺自己和團隊里的開發(fā)人員是“同床異夢”，也沒有機會拓展自己的能力。

2、DBA小崔的故事

小崔是持證DBA。原來隸屬于獨立的IT運維部門，該部門掌管著一切IT基礎(chǔ)設(shè)施，如服務(wù)器、操作系統(tǒng)、數(shù)據(jù)庫、中間件、網(wǎng)絡(luò)以及相應(yīng)的專家團隊。

由于重要的權(quán)限都掌握在這些專家團隊手上，業(yè)務(wù)線交付團隊如果無法獲得IT運維部門的支持，項目就進展不下去。當(dāng)各業(yè)務(wù)線的項目需求越來越多時，IT運維部門就成了整個公司的瓶頸。

為了解決這個問題，公司開始將IT運維部門去中心化，部分領(lǐng)域?qū)＜?ldquo;插隊”到各業(yè)務(wù)線交付團隊中，從而減少交付團隊的對外依賴，實現(xiàn)“自給自足”。

小崔就是這波浪潮中的其中一員。被收編到交付部門后，他比過去更忙了。

由于DBA是比較專業(yè)的技能，多大的團隊需要一個全職DBA成了一個問題。團隊太小，擁有一個DBA響應(yīng)力絕對沒有問題，但是無法充分利用其時間;如果幾個團隊共享一個DBA，又會出現(xiàn)新的瓶頸問題。

小崔就是一個被幾個交付團隊“共享”的DBA，因為要疲于應(yīng)付各交付團隊的請求，他已經(jīng)沒有時間成長。

過去，由于DBA都集中在一起，他們之間可以頻繁交流，相互學(xué)習(xí)，共同成長。而小崔現(xiàn)在收獲到的只有孤獨和壓力。

3、DBA大鵬的故事

同樣以DBA身份入職的大鵬則面對另一個情景。

由于他是新招的，直接進入了交付團隊，但該團隊的DBA工作不飽和，他被安排做了很多與DBA不相關(guān)的項目工作。

半年后，他辭職了，因為他感覺再這樣下去，他的DBA武功就要廢了。

如果你的公司也在做DevOps轉(zhuǎn)型，以上故事是否也在你身邊發(fā)生呢?雖然說分分合合是組織轉(zhuǎn)型的常態(tài)，但是處理不好，代價是相當(dāng)沉重的。

二、思考DevOps時代下工作整合問題

什么樣的工作需要整合，什么樣的工作不應(yīng)該整合?

既然我們已經(jīng)通過多年的經(jīng)驗證明了在軟件交付領(lǐng)域，分角色的精細分工是不利于整體交付效率的，那為什么在DevOps倡導(dǎo)下的全棧工程師、開發(fā)運維一體化又會產(chǎn)生新的問題呢?如何解決這些新問題呢?

也許，我們需要認真思考，在整個軟件交付過程中，什么樣的工作需要整合，什么樣的工作不應(yīng)該整合。

在前DevOps時代，分角色分工的思路其實是來源于工業(yè)時代的。做過手工的都知道，如果要手工做100只燈籠，一開始會做得很慢，做了幾只后，會越做越快，所謂熟能生巧。

再進一步，把做燈籠的過程拆解一下，比如拆解成搭骨架、糊紙、上色等工序，然后多找?guī)讉€人來，每人負責(zé)其中一道工序，經(jīng)過幾番磨合，由于每個人要做的事情比較單一，很容易上手和熟練，效率將會大大提升。燈籠的成品和質(zhì)量也會越來穩(wěn)定。

把這個過程放大，就是一個工廠的模式。

所有工廠都是通過拆解和精細分工獲得極高的效率的，而且，分工越精細，效率越高。而生產(chǎn)的特點是在不斷地做重復(fù)的事情，產(chǎn)出是同樣的產(chǎn)品，而且產(chǎn)品間的差異越小越好。對于重復(fù)的事情，就應(yīng)該通過拆解、精細分工、標準化和自動化來提升效率。

但是軟件交付過程則完全不一樣，和生產(chǎn)的區(qū)別就是“不重樣”。

每一個軟件需求都是不一樣的，用戶想要的結(jié)果也是不一樣的，這導(dǎo)致需求分析、開發(fā)、測試面對每個需求，或者運維面對每個故障的具體工作是不一樣的。

而且軟件交付是一個知識工作，是信息流動和轉(zhuǎn)換的過程，而交接會帶來信息的衰減和變異，因此在軟件交付過程中，按角色分工非但不會帶來像生產(chǎn)那樣的效率提升，反而會因為信息在不同角色間的交接和傳遞而產(chǎn)生不必要的摩擦和誤解，甚至交付出錯誤的軟件產(chǎn)品。

因此，我們更希望軟件交付團隊成員可以具備從需求到運維的端到端的交付能力，每個團隊針對一個特定的業(yè)務(wù)領(lǐng)域能夠獨立完成交付，減少交接，減少對外依賴。

而且這個團隊應(yīng)該足夠小(建議不多于7人)，以確保團隊內(nèi)目標一致、高效溝通和高度靈活。

然而，對于業(yè)務(wù)或用戶來說，IT系統(tǒng)和服務(wù)是一個整體，除了軟件，還有硬件。而每個人的帶寬和能力都是有限的，術(shù)業(yè)有專攻，不可能每個人都是全能的，特別是有些細分領(lǐng)域?qū)I(yè)度非常高。

如果把所有的職責(zé)都歸到業(yè)務(wù)線交付團隊，那么交付團隊必然需要擁有具備各類所需技能的專家，從而形成新的龐大實體，除了造成不必要的資源浪費外，組織一旦變大，勢必又會變得官僚和低效，原本想避免的問題又會重新出現(xiàn)。

三、解決工作整合問題的關(guān)鍵

要找出哪些工作是重復(fù)的，哪些是非重復(fù)的。

那么問題的癥結(jié)在哪里呢?通過前面的分析，我們知道，重復(fù)的工作，可以通過拆分、精細分工、標準化和自動化來提升效率，非重復(fù)的工作，可以通過減少交接和依賴來提升效率。

要解決如何分、如何合的問題，最關(guān)鍵的就是找出哪些工作是重復(fù)的，哪些是非重復(fù)的。重復(fù)的，解決方案是整合資源、角色分工和自動化;非重復(fù)的，解決方案是一體化。

那么在軟件交付過程中，哪些工作是重復(fù)性的呢?我想到的有以下這些：

1、網(wǎng)絡(luò)、硬件等基礎(chǔ)設(shè)施

這些IT基礎(chǔ)設(shè)施不會因為不同的項目和需求有太多的差異，而且專業(yè)性強，不太適合一人分飾多角，這些角色整合在一個獨立團隊中，使他們保持專注，也有利于這些專業(yè)領(lǐng)域的技術(shù)交流和知識傳遞。

2、部署

應(yīng)該盡量自動化，至少要求也應(yīng)該標準化，有標準的具體作業(yè)流程，誰都可以遵照流程做好。

我們可以安排前文中的小張把應(yīng)用部署過程整理成含具體操作步驟的標準化手冊，這樣這項工作團隊內(nèi)誰都能做，把他從部署這項具體工作釋放出來，在此基礎(chǔ)上，讓他把這個過程自動化，從而讓他學(xué)習(xí)流水線和自動化部署的技術(shù)，接觸技術(shù)性工作。

他也可以把故障處理流程整理成操作手冊，賦能其他團隊成員在合規(guī)的環(huán)境下承擔(dān)運維工作，把他自己釋放出來;

3、DBA、操作系統(tǒng)等專家團隊

應(yīng)該通過腳本、自助服務(wù)等形式賦能交付團隊在受控的環(huán)境下滿足交付需要，減少對他們的依賴。

我們可以讓前文中的小崔和大鵬收集各交付團隊對于DBA的具體需求，把具有共性的需求提煉出來，做成可以通過DBA權(quán)限執(zhí)行的腳本，既滿足交付的需求，又確保了DBA權(quán)限不會被濫用;

4、標準流程

所有項目都必須要走的標準流程，如采購等，由專業(yè)的團隊提供服務(wù)的形式來執(zhí)行，大大降低各項目團隊由于需要熟悉繁瑣流程的過程所導(dǎo)致的不必要浪費;

需求分析、開發(fā)、測試、業(yè)務(wù)支援等非重復(fù)性工作則應(yīng)該保持在一個自滿足小團隊中，為特定的業(yè)務(wù)領(lǐng)域提供軟件交付和維護服務(wù)。

四、總結(jié)

分分合合是組織轉(zhuǎn)型的常態(tài)。

DevOps的目標是實現(xiàn)持續(xù)交付，提升整體的交付效率。要實現(xiàn)這個目標，簡單地把開發(fā)、應(yīng)用維護，甚至IT運維整合在一起，有點過于粗暴。

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

作者介紹

劉華(Kenneth)，就職于世界500強銀行。負責(zé)基金外包業(yè)務(wù)軟件開發(fā)與交付。敏捷、精益、DevOps領(lǐng)域?qū)＜摇Ｖ小东C豹行動——硝煙中的敏捷轉(zhuǎn)型之旅》一書。