所谓转型，是指事物的结构形态、运转模型和人们观念的根本性转变过程。
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 成熟度模型》中，做了一系列的设计介绍。对于大型组织来说，依旧是根据业内的通用模型，进一步完善自己的模式。
