云原生轉(zhuǎn)型：規(guī)模化演進(jìn)與文化思考

作者： Phodal 2021-08-09 21:02:02

如果一個(gè)領(lǐng)域，它需要大量的布道，需要進(jìn)行大量的學(xué)習(xí)，以及架構(gòu)(技術(shù)上、組織上或者是業(yè)務(wù)上)的變更，以轉(zhuǎn)變?nèi)藗兊挠^念，那么它就可以稱得上是一種轉(zhuǎn)型。

[[416383]]

所謂轉(zhuǎn)型，是指事物的結(jié)構(gòu)形態(tài)、運(yùn)轉(zhuǎn)模型和人們觀念的根本性轉(zhuǎn)變過程。

PS：源于所見所聞所習(xí)所思總結(jié)而成，所代表的場(chǎng)景比較有限，可能不會(huì)適用于多數(shù)場(chǎng)景。

上周末，我在思考『大型組織如何進(jìn)行 DevOps 的成熟度模型設(shè)計(jì)』時(shí)，便開始在思索，為什么 DevOps 是一種轉(zhuǎn)型?敏捷也可以是一種轉(zhuǎn)型?它們有著足夠大的復(fù)雜度，需要改變一系列的組織文化，還有技術(shù)實(shí)踐上的改變。所以，我嘗試著繼續(xù)去探索轉(zhuǎn)型的領(lǐng)域。

所以，我重新思考了一下敏捷轉(zhuǎn)型、DevOps 轉(zhuǎn)型中的一些核心變革因素，諸如于：

觀念的轉(zhuǎn)換，引入新文化。
調(diào)整架構(gòu)，改善協(xié)作。這里的架構(gòu)包含了技術(shù)、組織、業(yè)務(wù)、團(tuán)隊(duì)。
構(gòu)建能力中心。
成熟度指導(dǎo)持續(xù)提升。

于是乎，我嘗試性地將它融入到云原生轉(zhuǎn)型的過程中。說是嘗試性，其實(shí)呢，我是結(jié)合了一些公司的訴求和上云過程提煉而成。諸如于中大型組織在內(nèi)部推廣自己的微服務(wù)框架，培養(yǎng)自己的內(nèi)部技術(shù)教練等，提煉而成的技術(shù)能力中心。

0. 平臺(tái)作為起點(diǎn)，逐步遷移上云

云原生源自于 CloudNative，它和微服務(wù)類似，微服務(wù)代表的是一種架構(gòu)風(fēng)格，云原生則是相比更為抽象的一種模式，即理念。因此，基于云原生理論的應(yīng)用，它在設(shè)計(jì)架構(gòu)時(shí)就是為云而設(shè)計(jì)的。

在今天，走向云原生的第一步，采用或者構(gòu)建云原生平臺(tái)。

一、模式工具化：云平臺(tái)

過去的幾年里，走上云原生的主流模式就是：構(gòu)建容器化平臺(tái)，諸如于采用 Kubernetes 作為平臺(tái)的基石，搭建企業(yè)內(nèi)部的 PaaS 平臺(tái)。所以，這點(diǎn)陳芝麻爛谷子的過程，也就無關(guān)緊要了。

提及這個(gè)的原因是，有一些組織的云平臺(tái)( PaaS )走歪了。在 Kubernetes 火爆之前，市面上已經(jīng)有一系列的 DevOps 工具，做了類似的事情：基礎(chǔ)設(shè)施即代碼。圍繞著『基礎(chǔ)設(shè)施即代碼』這一模式，才是構(gòu)建云平臺(tái)的核心。人們從實(shí)踐中提取模式，模式中提煉了工具，工具集中打造了平臺(tái)。但是，用了平臺(tái)的人總會(huì)忘了原來的模式。這就也是為什么有些云平臺(tái)( PaaS )需要大量的手工配置。

二、遺留基礎(chǔ)設(shè)施現(xiàn)代化

圍繞著云平臺(tái)，就需要把傳統(tǒng)的遺留基礎(chǔ)設(shè)施去掉，遷移到云平臺(tái)( PaaS )上。

這一點(diǎn)倒也沒啥說的。

下一步，就是重新設(shè)計(jì)應(yīng)用的架構(gòu)。

三、設(shè)計(jì)彈性架構(gòu) —— 你并一定不需要微服務(wù)

微服務(wù)架構(gòu)是云原生下的一種非常好的架構(gòu)模式，但是這并意味著微服務(wù)是唯一的答案。過多錯(cuò)誤的微服務(wù)劃分方式，導(dǎo)致了大量的系統(tǒng)失去了應(yīng)具有的彈性架構(gòu)。所以，不要以微服務(wù)作為你遷移路徑的目標(biāo)。我們要設(shè)計(jì)的方向，應(yīng)該是彈性架構(gòu)。

圍繞如何實(shí)現(xiàn)彈性架構(gòu)而設(shè)計(jì)，隨后相關(guān)技術(shù)，如采用容器、服務(wù)網(wǎng)格、微服務(wù)、不可變基礎(chǔ)設(shè)施和聲明式 API，才才是解決問題的正解之路。

故事到這里就結(jié)束了?

1. 轉(zhuǎn)換觀念，引入新文化

單純的遷移到云平臺(tái)，應(yīng)用進(jìn)行微服務(wù)改造。對(duì)于多數(shù)的團(tuán)隊(duì)來說，它沒有帶來太大的改變，團(tuán)隊(duì)依舊繼續(xù)原先的思路設(shè)計(jì)和構(gòu)建系統(tǒng)。如果只是單純的上云，團(tuán)隊(duì)可能也沒有意識(shí)去構(gòu)建所需要的核心能力。

云原生改變了什么?

再考慮一下這個(gè)問題，你們?yōu)槭裁催x擇了云原生?從收益上來看，從組織層面來看，它可以是：

更好的客戶體驗(yàn)
提高了收益并降低運(yùn)維成本
新產(chǎn)品和服務(wù)的推行等待時(shí)間顯著降低

而細(xì)到團(tuán)隊(duì)來看，它可以分為兩部分：

從平臺(tái)側(cè)，即從基礎(chǔ)設(shè)施的層面來看，它是關(guān)于基礎(chǔ)設(shè)施的抽象。它還關(guān)乎于基礎(chǔ)設(shè)施的不可變性及可拋棄性。
從開發(fā)側(cè)，即從使用平臺(tái)的層面來看，它是關(guān)于應(yīng)用如何彈性。

開發(fā)者即服務(wù)

而故事并沒有那么簡(jiǎn)單，平臺(tái)團(tuán)隊(duì)如果只是定位于開發(fā)平臺(tái)，那么他們會(huì)遇到一系列的現(xiàn)實(shí)沖擊，諸如于我在《開發(fā)者即服務(wù)：開發(fā)者的被按需即用》所提及的。

團(tuán)隊(duì)所面臨的問題與開源項(xiàng)目的困境是極為類似的，諸如于要提供更好的服務(wù)、更舒適的體驗(yàn)，還想避免疲于支援各種團(tuán)隊(duì)。

平臺(tái)團(tuán)隊(duì)需要轉(zhuǎn)變一下解決問題的思路，諸如于采用內(nèi)部開源、開發(fā)者運(yùn)營(yíng)等。

規(guī)模化的彈性架構(gòu)設(shè)計(jì)

在一個(gè)組織內(nèi)，不同團(tuán)隊(duì)的水平參差不齊，既可能受限于能力水平，還可能受限于業(yè)務(wù)場(chǎng)景的簡(jiǎn)易程度。也因此，一旦面臨著這些架構(gòu)上的調(diào)整時(shí)，會(huì)變得異常混亂。

在云原生的場(chǎng)景下，它相當(dāng)于立了一個(gè)技術(shù)基線，所有的團(tuán)隊(duì)都應(yīng)該到達(dá)這條基線。而從現(xiàn)實(shí)情況來看，多數(shù)的業(yè)務(wù)團(tuán)隊(duì)并不具備這樣的能力和精力。與能力相比，精力和時(shí)間是一個(gè)主要問題。

因此，從組織的層面來看，需要尋找方式來支撐規(guī)模化的技術(shù)能力提升，諸如于人們?cè)诿艚蒉D(zhuǎn)型時(shí)，采用的敏捷教練，又或者是在 DevOps 轉(zhuǎn)型時(shí)，引入的 DevOps 教練/工程師。

2. 改善組織協(xié)作

從模型上來看，云原生的轉(zhuǎn)型，也意味著在改變組織的協(xié)作方式。從維度上來說，它更多的是一種開發(fā)對(duì)開發(fā)的協(xié)作方式。而不會(huì)像 DevOps 轉(zhuǎn)型一樣，有著更廣泛的組織內(nèi)影響。

DevOps >> Dev + Ops

DevOps 運(yùn)動(dòng)初期的目的就是打破開發(fā)與運(yùn)維之間的壁壘，鼓勵(lì)開發(fā)與運(yùn)維之間的協(xié)作。而隨著國(guó)內(nèi)各類標(biāo)準(zhǔn)和成熟度的出現(xiàn)，我們對(duì)它的定義已經(jīng)是：BizDevOps，即業(yè)務(wù) + 開發(fā) + 運(yùn)維的協(xié)作。

成為的 DevOps 運(yùn)動(dòng)，可以讓組織變得更加流暢 —— 至少在協(xié)作上已經(jīng)是規(guī)范化、工具化的。

也因此云原生的成功，也是要建立在 DevOps 的基礎(chǔ)上。開發(fā) + 運(yùn)維一起構(gòu)建了 PaaS 平臺(tái)，并用于支持業(yè)務(wù) + 開發(fā)的活動(dòng)。

內(nèi)部開發(fā)者體驗(yàn)：PaaS Dev + Biz Dev

而一旦出現(xiàn)了 PaaS 平臺(tái)，那么這個(gè)平臺(tái)就是平臺(tái)開發(fā)(PaaS Dev)與業(yè)務(wù)開發(fā)(Biz Dev)的協(xié)作。

要改善它們的協(xié)作方式，就需要關(guān)注于設(shè)計(jì)開發(fā)者體驗(yàn)，這便是另外一種協(xié)作方式的改變。基于開發(fā)者體驗(yàn)度量?jī)?yōu)化協(xié)作，便是要做的另外一項(xiàng)改變。

3. 構(gòu)建技術(shù)能力中心

對(duì)于多數(shù)組織來說，我覺得它們犯了一個(gè)錯(cuò)誤就是：沒有建立內(nèi)部的技術(shù)社區(qū)。以通過構(gòu)建技術(shù)社區(qū)，可以沉淀組織的技術(shù)資產(chǎn)。其中一個(gè)原因或許是：部門之間的競(jìng)爭(zhēng)。而在云原生時(shí)代，這個(gè)問題就變得非常緊迫，如何去共享云原生相關(guān)的知識(shí)?

沉淀知識(shí)體系

Wiki 是開發(fā)團(tuán)隊(duì)用來沉淀知識(shí)的方式。對(duì)于一個(gè)組織來說，相同的知識(shí)可能分散于不同的團(tuán)隊(duì)。

傳統(tǒng)模式下，這并不是問題。而在云原生時(shí)代，這個(gè)問題更為突出。所以，對(duì)于 PaaS 平臺(tái)團(tuán)隊(duì)來說，它們應(yīng)該主動(dòng)發(fā)起對(duì)于知識(shí)庫(kù)的建立。除了，幫助其它人解決問題，還可以減少自己的響應(yīng)時(shí)間。

內(nèi)部技術(shù)社區(qū)

內(nèi)部技術(shù)社區(qū)是 Tw 用來構(gòu)建技術(shù)能力的方式之一。在特定領(lǐng)域的商機(jī)來臨時(shí)，它可能有足夠的能力來支撐。對(duì)于多數(shù)的組織來說，這也是一種頗為有效的方式。

在這之上，對(duì)于組織來說，它們還要考慮的因素是：

社區(qū)支撐和運(yùn)營(yíng)體系
KPI 獎(jiǎng)勵(lì)機(jī)制

雖然如此，但是我一直在思考部門墻是否會(huì)限制內(nèi)部技術(shù)社區(qū)?

技術(shù)能力中心

在云原生的背景下，便是讓相關(guān)的 PaaS 平臺(tái)和開發(fā)人員可以就模式、藍(lán)圖、技術(shù)和代碼示例開展協(xié)作。與上述的兩個(gè)方式相對(duì)，成為一個(gè)圍繞提升技術(shù)能力的團(tuán)隊(duì)，是一個(gè)更有挑戰(zhàn)的事情。

有意思的是，這種模式已經(jīng)在大量技術(shù)型氛圍的公司采用了，它們招募了一系列的內(nèi)部技術(shù)教練，用于幫助各個(gè)團(tuán)隊(duì)進(jìn)行技能能力提升。

4. 成熟度指導(dǎo)持續(xù)改進(jìn)

成熟度模型，又是一個(gè)更有意思的標(biāo)準(zhǔn)化模式。它用于指揮一個(gè)組織如何高效地工作，換句話來說，就是一個(gè)組織如何成為社會(huì)這個(gè)巨大車輪中的一部分。

成熟度依舊是我們用于指導(dǎo)進(jìn)行規(guī)模化方式的。就這一點(diǎn)而言，我們已經(jīng)在上一篇文章《中大型組織 DevOps 成熟度模型》中，做了一系列的設(shè)計(jì)介紹。對(duì)于大型組織來說，依舊是根據(jù)業(yè)內(nèi)的通用模型，進(jìn)一步完善自己的模式。