Blog

Blog

PHODAL

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

最近在构筑架构能力体系的时候,刚好看到了 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)、基础设施。

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


或许您还需要下面的文章:

关于我

Github: @phodal     微博:@phodal     知乎:@phodal    

微信公众号(Phodal)

围观我的Github Idea墙, 也许,你会遇到心仪的项目

QQ技术交流群: 321689806
comment

Feeds

RSS / Atom

最近文章

关于作者

Phodal Huang

Developer, Consultant, Writer, Designer

ThoughtWorks 高级咨询师

工程师 / 咨询师 / 作家 / 设计学徒

开源深度爱好者

出版有《前端架构:从入门到微前端》、《自己动手设计物联网》、《全栈应用开发:精益实践》

联系我: h@phodal.com

微信公众号: 与我沟通

标签