云原生轉型：規?；葸M(jìn)與文化思考

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

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

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

如果一個(gè)領(lǐng)域，它需要大量的布道，需要進(jìn)行大量的學(xué)習，以及架構(技術(shù)上、組織上或者是業(yè)務(wù)上)的變更，以轉變人們的觀(guān)念，那么它就可以稱(chēng)得上是一種轉型。

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

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

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

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

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

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

一、模式工具化：云平臺

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

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

二、遺留基礎設施現代化

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

這一點(diǎn)倒也沒(méi)啥說(shuō)的。

下一步，就是重新設計應用的架構。

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

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

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

故事到這里就結束了?

1. 轉換觀(guān)念，引入新文化

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

云原生改變了什么?

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

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

而細到團隊來(lái)看，它可以分為兩部分：

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

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

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

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

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

規?；膹椥约軜嬙O計

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

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

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

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

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

DevOps >> Dev + Ops

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

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

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

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

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

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

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

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

沉淀知識體系

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

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

內部技術(shù)社區

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

在這之上，對于組織來(lái)說(shuō)，它們還要考慮的因素是：

• 社區支撐和運營(yíng)體系
• KPI 獎勵機制

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

技術(shù)能力中心

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

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

4. 成熟度指導持續改進(jìn)

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

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

其它

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

PS：貌似一不小心寫(xiě)崩了，不過(guò)大意就看標題~。

參考資料：

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

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

【編輯推薦】