[[416383]]

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

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

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

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

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

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

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

0. 平臺作為起點，逐步遷移上云

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

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

一、模式工具化：云平臺

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

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

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

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

這一點倒也沒啥說的。

下一步，就是重新設計應用的架構(gòu)。

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

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

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

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

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

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

云原生改變了什么?

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

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

而細到團隊來看，它可以分為兩部分：

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

開發(fā)者即服務

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

團隊所面臨的問題與開源項目的困境是極為類似的，諸如于要提供更好的服務、更舒適的體驗，還想避免疲于支援各種團隊。

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

規(guī)?；膹椥约軜?gòu)設計

在一個組織內(nèi)，不同團隊的水平參差不齊，既可能受限于能力水平，還可能受限于業(yè)務場景的簡易程度。也因此，一旦面臨著這些架構(gòu)上的調(diào)整時，會變得異?；靵y。

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

因此，從組織的層面來看，需要尋找方式來支撐規(guī)?；募夹g(shù)能力提升，諸如于人們在敏捷轉(zhuǎn)型時，采用的敏捷教練，又或者是在 DevOps 轉(zhuǎn)型時，引入的 DevOps 教練/工程師。

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

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

DevOps >> Dev + Ops

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

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

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

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

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

要改善它們的協(xié)作方式，就需要關(guān)注于設計開發(fā)者體驗，這便是另外一種協(xié)作方式的改變?；陂_發(fā)者體驗度量優(yōu)化協(xié)作，便是要做的另外一項改變。

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

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

沉淀知識體系

Wiki 是開發(fā)團隊用來沉淀知識的方式。對于一個組織來說，相同的知識可能分散于不同的團隊。

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

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

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

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

• 社區(qū)支撐和運營體系
• KPI 獎勵機制

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

技術(shù)能力中心

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

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

4. 成熟度指導持續(xù)改進

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

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

其它

由于篇幅很限，文中的很多內(nèi)容就不展開討論了~。

PS：貌似一不小心寫崩了，不過大意就看標題~。

參考資料：

• 《CNCF Cloud Native Definition v1.0》
• 《DevOps 文化：如何進行轉(zhuǎn)型》
• 《如何解決人智商不夠?》
• 《數(shù)字技術(shù)戰(zhàn)略：開發(fā)者體驗 —— 內(nèi)部工具的“最后一公里”》

本文轉(zhuǎn)載自微信公眾號「phodal」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系phodal公眾號。