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

[[260606]]

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

1、運(yùn)維專員小張的故事

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

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

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

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

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

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

有重大問題時(shí)，整個(gè)團(tuán)隊(duì)都可以參與運(yùn)維、解決問題。

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

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

2、DBA小崔的故事

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

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

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

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

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

小崔就是一個(gè)被幾個(gè)交付團(tuán)隊(duì)“共享”的DBA，因?yàn)橐Ｓ趹?yīng)付各交付團(tuán)隊(duì)的請求，他已經(jīng)沒有時(shí)間成長。

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

3、DBA大鵬的故事

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

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

半年后，他辭職了，因?yàn)樗杏X再這樣下去，他的DBA武功就要廢了。

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

二、思考DevOps時(shí)代下工作整合問題

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

這些IT基礎(chǔ)設(shè)施不會因?yàn)椴煌捻?xiàng)目和需求有太多的差異，而且專業(yè)性強(qiáng)，不太適合一人分飾多角，這些角色整合在一個(gè)獨(dú)立團(tuán)隊(duì)中，使他們保持專注，也有利于這些專業(yè)領(lǐng)域的技術(shù)交流和知識傳遞。

2、部署

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

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

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

3、DBA、操作系統(tǒng)等專家團(tuán)隊(duì)

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

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

4、標(biāo)準(zhǔn)流程

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

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

四、總結(jié)

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

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

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

作者介紹

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