云原生转型模式：构筑云迁移的加速器

云原生转型模式：构筑云迁移的加速器

Posted by: Phodal Huang Oct. 18, 2021, 9:17 p.m.

最近在构筑架构能力体系的时候，刚好看到了 O'reilly 出版社的《Cloud Native Transformation》（英文影印版） —— 一本关于云原生转型的书，结合了云原生迁移 + 组织文化转型两个维度。书中花了四个章节在介绍云原生转型的相关模式，书中的模式的类型为：策略和降低风险、组织和文化、开发和流程、基础设施和云。而作为半个转型“砖家”，我大抵对其中的一些模式比较熟悉，过去也想着编写相关的模式，只是一直没有时间编写。

如果你对于云原生转型缺乏相关的概念，可以参考我先前写的那篇《云原生转型：规模化演进与文化思考》。在那一篇文章里，介绍了企业的规模化云迁移为什么应该视为转型，以及中如何更好也进行云迁移。

所以，在这一篇文章里，我将结合云原生转型模式与开发者体验设计，重新构筑云原生转型模式体系。所以，我将其重新划为了五个维度，并且 只描述一些重要的模式（相对的）：

1. 重塑团队形态。相关的模式诸如于：核心转型团队、赋能团队、转型办公室、团队拓扑
2. 共享认知社区。相关的模式诸如于：内部开源、特别兴趣小组、技术主题社区
3. 自动化 “开发者即服务”。相关的模式诸如于：自服务、开发者中心
4. 组织协作设计。相关的模式诸如于：团队 API、技术布道师
5. 构建生机型文化。相关的模式诸如于：遗留组织现代化、设计思维、概念证明

PS：这里的模式是经过我重新加工的。对于想深入相关转型的读者来说，由于知识体系的不同，建议应该去阅读一下《Cloud Native Transformation》，以下简称为 CNT。

模式 0：观念转变

有太多关于云原生观念转变相关文章的讨论，我也不想讨论太多，主要就是如下的三点。

遗留文化迁移

对于多数的组织来说，遗留系统并不是开发者的挑战，开发者有大量的 plan b 来改进遗留系统。每个开发者都很聪明，只是受限于组织的文化因素，往往难以自信地做出相关的决定 —— 从承担风险的角度来说。

所以，你可以重新思考一下，技术问题并不是核心问题，遗留的文化问题才是。

开发者优先

其次，在云迁移的过程中，另外一个重要的因素是：开发者体验设计，即从开发者的层面来考虑问题。在这一方面的相关反例就是，某些需求偏向于 KPI 式的驱动方式，自然而然的内部对于平台的反对声明就越来越大。

对于开发者来说，他们需要高效地解决他们的问题。

产品思维：☁ 云平台即产品。

最后，对于构建的云平台来说，经常被错误采用的模式是采用平台思维。在转换为产品思维之后，很多问题就迎刃而解了，诸如于：为什么要做内部技术运营？为什么需要内部技术社区等？如 Thoughtworks 技术雷达中，在 2017 年就推荐了相关的技术实践：“将产品管理思维应用于内部平台”。它意味着与内部消费者（开发团队）建立共情，并在设计上彼此协作。

和其他产品一样，好的产品管理就是为消费者创造喜爱的产品。

模式集：重塑团队形态

对于中大型组织来说，实施云迁移意味着需要有基础设施、云原生平台、云原生框架等多个团队，一起帮助组织内的大大小小各种各样的团队进行迁移。所以，就会出现 《云原生转型》中说的 Core Team、Platform Team、SRE Team 等一系列的团队模式，从模式来看，它们都是《团队拓扑》一书中介绍的平台团队、赋能团队等模式。

因此，我们结合平台/产品思维，重新组织的团队形态，出现诸如于核心转型团队等，又或者是使用团队拓扑理论重新划分组织团队。

核心转型团队

核心转型团队（Core Team）源自于《云原生转型》，其意图是：让工程师和架构师团队致力于发现最佳转型路径，并在此过程中实施。 它可以降低了转型中的风险，同时团队获得了有助于以后加入其余团队的经验。

简单来说，就是参与到团队的云原生迁移任务中，尽可能解决问题，并总结出常见问题。如此一来，便可以快速推广到其它团队。

转型办公室

转型本质上是一种变革，因此需要管理。所以，可以参考敏捷转型中采用的转型办公室的机制，它用于确保转型过程中从管理层到基层团队目标一致、沟通高效、响应快速，从而有效实现组织转型目标。

越来越多的大型 IT 组织，如腾讯的工程效能教练、华为的软件教练等，它们都出现了帮助不同团队提升能力的专业赋能团队。即通过专业化的人才来提升组织的 IT 能力，他们可以更好地核心转型团队进行相关的能力提升

团队拓扑是一种重新划分组织的团队构建的方式。它重构了 IT 组织内的团队元素，将其划分了四种类型的团队：产品导向团队、赋能团队、复杂子系统团队、平台团队，由它们相互交互构成了组织的团队模型，更多的相关内容可以参考先前的：《团队拓扑：在云原生时代，如何定位自身与团队？》。

引入团队拓扑模式，能让我们更快地分析组织所需要的团队形态。

模式集：共享认知的社区

共享认知的社区的意图是：构建内部的云原生社区，分享相关的认知，以大大加速转型的速度。诸如于分享成功的经验，遇到的问题，对相关的内容进行脱敏并记录。

简单来说，就是让团队帮助团队。

内部开源项目

内源即将开源方法（最佳实践、协作方式、架构模式等）融入到组织的软件构建和发布方式之中，以在组织内构建类似开源的文化。对于云原生转型来说，它可以是一个示例的开源应用、开源示例架构、开放型文档项目、模板应用等。一个示例的应用往往比一千个文档来得更有作用。

技术主题社区

通过内外部 IM 围绕于云原生的主题，发动起相关的技术社区，让开发者帮助开发者解决问题。

特别兴趣小组（SIG）

特别兴趣小组（SIG）专注于一些特定议题的小组，目的是要对那些专题增加关注，或者集中开发的焦点。基于这种模式，组织可以围绕于 Web 框架、数据库、容器化、平台等构建一系列的兴趣小组，通过专家（与主题社区的核心区别）来用于解决特定主题的技术问题。

模式集：自动化“开发者即服务”

这部分的模式，主要是从平台的层面来考虑，用于提升云平台的效能，减少平台开发者的碎片化的时间。

自服务是指提供一系列的自动化服务，可以让平台或工具的使用者们，快速地完成相关技术的使用等。过程中，无需平台团队提供直接的支持。

基于这种模式，需要做好一系列关于开发者体验的设计与度量。

开发者门户

懂的都懂。

Bezos API 授权

它由一系列的备忘录组成，诸如于：所有的团队都要以服务接口的方式，提供数据和各种功能。对于平台来说，它对开发者的所有支持都应该可以 API 化，以实现高内聚-低耦合的团队。

模式集：组织协作设计

在这一系列的模式里，强调的是设计好团队与组织的边界，让团队成员能更关注于自己的内部。

内部布道师

这个角色常用于技术产品化的公司，它也适用于中大型组织内部。其职责是向其它团队分享观点，给予反馈，提供帮助，并向平台团队技术提供反馈、建立沟通机制等。可以作为不同团队与平台团队的接口，提升平台团队的效率。

在那一篇《技术产品化运营》中，我们详细定义了布道师（Evangelist）、开发者关系（DevRel）、开发者运营、技术运营等几个角色。

团队 API

团队 API 是在《团队拓扑》中提及的概念，它包含的内容有代码、版本、文档、实践和原则等相关的内容。其中一个目的是让团队基于契约、基于 API 的独立运作模式。它可以切断团队间的代码库依赖 —— 即 B 团队不能直接修改 A 团队的代码，应该以 Pull Request 的方式，或者结对的方式。

模式集：构建生机型文化

未来，我们依旧会遇到更多的相关挑战。

PS：这方面我并不擅长写。

遗留组织现代化

与遗留系统相比，我觉得遗留组织可能是人们会遇到的最大挑战，具体就不用展开了。

设计思维是一种以人为本的解决复杂问题的创新方法，它利用设计者的理解和方法，将技术可行性、商业策略与用户需求相匹配，从而转化为客户价值和市场机会。

我还挺喜欢书中的云原生成熟度模型，只是我忘了出处，我不想去寻找了，大概是这么几个维度：文化、产品/服务设计、团队、流程、架构、运维、交付、供应层（Provisioning）、基础设施。

不过，这个模型是有问题的，在粒度和维度上有过多的偏差。