所謂轉型，是指事物的結構形态、運轉模型和人們觀念的根本性轉變過程。
PS：源于所見所聞所習所思總結而成，所代表的場景比較有限，可能不會适用于多數場景。
上周末，我在思考『大型組織如何進行 DevOps 的成熟度模型設計』時，便開始在思索，為什麼 DevOps 是一種轉型？靈活也可以是一種轉型？它們有着足夠大的複雜度，需要改變一系列的組織文化，還有技術實踐上的改變。是以，我嘗試着繼續去探索轉型的領域。
如果一個領域，它需要大量的布道，需要進行大量的學習，以及架構（技術上、組織上或者是業務上）的變更，以轉變人們的觀念，那麼它就可以稱得上是一種轉型。
是以，我重新思考了一下靈活轉型、DevOps 轉型中的一些核心變革因素，諸如于：
- 觀念的轉換，引入新文化。
- 調整架構，改善協作。這裡的架構包含了技術、組織、業務、團隊。
- 建構能力中心。
- 成熟度指導持續提升。
于是乎，我嘗試性地将它融入到雲原生轉型的過程中。說是嘗試性，其實呢，我是結合了一些公司的訴求和上雲過程提煉而成。諸如于中大型組織在内部推廣自己的微服務架構，培養自己的内部技術教練等，提煉而成的技術能力中心。
0. 平台作為起點，逐漸遷移上雲
雲原生源自于 CloudNative，它和微服務類似，微服務代表的是一種架構風格，雲原生則是相比更為抽象的一種模式，即理念。是以，基于雲原生理論的應用，它在設計架構時就是為雲而設計的。
在今天，走向雲原生的第一步，采用或者建構雲原生平台。
0.1 模式工具化：雲平台
過去的幾年裡，走上雲原生的主流模式就是：建構容器化平台，諸如于采用 Kubernetes 作為平台的基石，搭建企業内部的 PaaS 平台。是以，這點陳芝麻爛谷子的過程，也就無關緊要了。
提及這個的原因是，有一些組織的雲平台（ PaaS ）走歪了。在 Kubernetes 火爆之前，市面上已經有一系列的 DevOps 工具，做了類似的事情：基礎設施即代碼。圍繞着『基礎設施即代碼』這一模式，才是建構雲平台的核心 。人們從實踐中提取模式，模式中提煉了工具，工具集中打造了平台。但是，用了平台的人總會忘了原來的模式。這就也是為什麼有些雲平台（ PaaS ）需要大量的手工配置。
0.2 遺留基礎設施現代化
圍繞着雲平台，就需要把傳統的遺留基礎設施去掉，遷移到雲平台（ PaaS ）上。
這一點倒也沒啥說的。
下一步，就是重新設計應用的架構。
0.3 設計彈性架構 —— 你并一定不需要微服務
微服務架構是雲原生下的一種非常好的架構模式，但是這并意味着微服務是唯一的答案。過多錯誤的微服務劃分方式，導緻了大量的系統失去了應具有的彈性架構。是以，不要以微服務作為你遷移路徑的目标。我們要設計的方向，應該是彈性架構。
圍繞如何實作彈性架構而設計，随後相關技術，如采用容器、服務網格、微服務、不可變基礎設施和聲明式 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：貌似一不小心寫崩了，不過大意就看标題~。
參考資料：
![與專家面對面：Android開發入門問與答[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)