[[416383]]

所謂轉型，是指事物的結構形態、運轉模型和人們觀念的根本性轉變過程。

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

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

如果一個領域，它需要大量的布道，需要進行大量的學習，以及架構(技術上、組織上或者是業務上)的變更，以轉變人們的觀念，那么它就可以稱得上是一種轉型。

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

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

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

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

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

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

一、模式工具化：云平臺

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

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

二、遺留基礎設施現代化

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

這一點倒也沒啥說的。

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

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

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

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

故事到這里就結束了?

1. 轉換觀念，引入新文化

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

云原生改變了什么?

再考慮一下這個問題，你們為什么選擇了云原生?從收益上來看，從組織層面來看，它可以是：

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

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

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

開發者即服務

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

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

平臺團隊需要轉變一下解決問題的思路，諸如于采用內部開源、開發者運營等。

規模化的彈性架構設計

在一個組織內，不同團隊的水平參差不齊，既可能受限于能力水平，還可能受限于業務場景的簡易程度。也因此，一旦面臨著這些架構上的調整時，會變得異常混亂。

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

因此，從組織的層面來看，需要尋找方式來支撐規模化的技術能力提升，諸如于人們在敏捷轉型時，采用的敏捷教練，又或者是在 DevOps 轉型時，引入的 DevOps 教練/工程師。

2. 改善組織協作

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

DevOps >> Dev + Ops

DevOps 運動初期的目的就是打破開發與運維之間的壁壘，鼓勵開發與運維之間的協作。而隨著國內各類標準和成熟度的出現，我們對它的定義已經是：BizDevOps，即業務 + 開發 + 運維的協作。

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

也因此云原生的成功，也是要建立在 DevOps 的基礎上。開發 + 運維一起構建了 PaaS 平臺，并用于支持業務 + 開發的活動。

內部開發者體驗：PaaS Dev + Biz Dev

而一旦出現了 PaaS 平臺，那么這個平臺就是平臺開發(PaaS Dev)與業務開發(Biz Dev)的協作。

要改善它們的協作方式，就需要關注于設計開發者體驗，這便是另外一種協作方式的改變。基于開發者體驗度量優化協作，便是要做的另外一項改變。

3. 構建技術能力中心

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

沉淀知識體系

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

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

內部技術社區

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

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

• 社區支撐和運營體系
• KPI 獎勵機制

雖然如此，但是我一直在思考部門墻是否會限制內部技術社區?

技術能力中心

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

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

4. 成熟度指導持續改進

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

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

其它

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

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

參考資料：

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

本文轉載自微信公眾號「phodal」，可以通過以下二維碼關注。轉載本文請聯系phodal公眾號。