阿里10年沉淀|那些技术实战中的架构设计方法 https://mp.weixin.qq.com/s/k-PBeN68pNJT9E7R3oTNxQ
阿里10年沉淀|那些技术实战中的架构设计方法
上周我写的一篇文章《关于技术能力的思考和总结》引起了大家的关注,好多读者的评论“以写代想、以想促真、以讲验真”,大家的感受很深刻,基于上次的文章,这篇文章我其实更想跟大家聊聊一些常用的思考方法,思考问题的方式对了,往往可以帮助大家少走弯路。
常用思考方法
技术常用思考方法
技术思考本质还是结构化思考,所以常见的结构化思考方法也是适用的。这也是大家会看到很多技术架构师都会用一些方法论去分析问题的原因。但这里我不是重新去论述这些常见的技巧,而是分享从技术实战中得到的一些思考方法,为此我分为了技术架构设计的方法和技术Leader的思考方法两类。
技术架构思考方法
0--->1
这个思考方法的含义是:
当我们在一堆迷茫和混乱中不知道如何下口时,应该先贴近问题本身,还原客观事实,并快速形成 1 个能够拉起认知并快速讨论迭代优化的版本。大家围绕着这样的一个初始版本去叠加和丰富其他维度的内容,直到方案的共识。 我举一个实际的CASE,大家在谈某平台能力升级的方案时候会经常喜欢用PPT画一些模块图,试图通过一些抽象的词汇来厘定清楚边界,核心概念。大家以为是在讲本质讲原则但实际所有人听了都是云里雾里,不知所云。因为通过概念去推导概念是无法真正回答问题的。 而比较好的应对方法我总结为以下三个步骤:
-
【用户视角的客观世界还原】
用户故事的串联,基于交互流程和真实的数据来描绘这件事在客观世界中用户视角看来是怎么发生的。这就是我们找准一个大家都能够共识的视角,让所有人快速把客观事实搞清楚画出来这个 1,而这个 1 就是后续讨论的靶子 。这个 1 的表现形式我认为往往都是很简单的,要么是交互时序图,要么是Excel表格,而不是复杂的模块概念图。
-
【客观信息的结构化整合与提炼】
只是树立起来 1 这个初始版本,还远远不够。因为第一个步骤只是将模糊、混乱的东西通过一种方法信息化表达出来,这还远远达不到使用的程度。所以还需要将上述信息进行结构化的整合与提炼,因为信息只有经过结构化才能够变成有意义的知识,才能够与之前的经验形成互动,也才能够进行初版的设计加工。比如对数据流的处理,就会发现有哪些是可以合并的同类项,有哪些平衡校验逻辑等。
-
【加入多元视角的检验与抽象】
通过第二步的处理把 1 这个版本变得更加丰满,但是要形成完整的可实施方案还远远不够。我们还需要加入更多维度的校验和抽象,比如进一步抽象以看透其本质,比如加入重要异常,ROI,合理性等扩展性等多方的视角去做校验。 所以大家以后在遇到很多方案谈不清楚的时候,不要去听别人讲什么原则,概念,价值等等虚头巴脑的东西。把大家拉回来,回到最简单的最朴素的东西来对焦,那就是 一张交互序列图 或者 一张表格。越快速从一堆迷茫中快速提炼出这个 1 ,就越容易快速拿到结果。
1--->0
这个思考方法的含义是:
当我们在做一个方案时面对无数因素无法抓住关键点时,我们应该考虑删除法(把这个 1 拿掉不要行不行)去寻找决定性因素,以确保我们是真正的抓到了关键点。 我举一个实际的CASE,每年都会做技术规划,相信这是很多架构师/Leader很痛苦的事。痛苦的根源就是在脑子里面有无数需求,有无数的待优化点,也有无数的想法在萦绕,看到每个点觉得值得在新一年做攻坚。最终多半形成的就是一个表格,把今年要做的事罗列下,最多还排个优先级,好一点的换个形式变成xmind或者PPT,再稍微好一点的可能会搭配上业务的目标和策略打法。但透过这些表面现象,其本质就是一个表格,没有抓住重点的表格。相信大家应该都看得蛮多的了。 如何应对这类问题我总结为以下几个技巧:
-
【因果判断法】
-
【树干树枝法】
-
【支点撬动法】
以上是目前实践下来的抓取关键点的一些方法。但这里一定也要注意一个粒度问题,千万不要走极端。比如一提关键点,就去思考本质,一提到本质就去找根因,一找根因就挖到人性,然后得出来就是人性的原罪问题。这种都是没有任何营养的做法,也不利于事情的推动解决。
1--->2
这个思考方法的含义是: 当我们思考一些抽象问题/方案时候,需要对问题进行拆分(一分为二),通过分而治之的方法来确定每个小问题的边界,通过对小问题的解决来降低全局的思考难度,以尽快形成解决方案。
这个应该不需要举例子了,大家日常都应该有所接触,这里只是列举几个比较典型的技术架构动作:
-
【纵深拆解】
-
【横向解剖】
1--->N
这个思考方法的含义是: 当我们思考一些技术方案时候,不要仅局限在当时当刻的条件约束,要适当考虑系统的承载从1变到N的过程中的对系统架构带来的挑战。 做技术架构师的都知道做架构要求有前瞻性,不能被业务拖着走。但很多时候我们其实没有仔细思考如何才能够做到前瞻性,我总结为最关键的考虑的因素就是时间,把时间拉长来考虑关键生产资料可能发生什么变化,通过去架构这种变化所得出来的方案就具备了前瞻性。一般意义上来说,我们平台演进的生产资料抽象地归纳为三类:
-
业务场景:这是最原始的生存资料,更是平台演进的源动力。典型的如市场份额变化,用户体价值的变化,竞对动态等。
-
团队组织:是人创造了平台,也是主导平台的演进发展,这个生产资料如果不能得到有效利用,充分释放能动性就会出现平台无法支持业务快速发展,同时人也在平台中内卷。
-
技术架构:技术架构其实本身也是非常重要的生产资料,这是很多人会忽略的地方。大家想一个最简单的例子,同一个变量分散在多个地方导致语义不清,维护成本巨大就明白了。
针对这几个生产资料我抽取了几个技巧去思考如何从 1 扩张到 N:
-
【架构考虑所有可能性但做有限明确实施】
-
【没有靠谱的人只有靠谱的机器】
-
【提前思考“幸福”的烦恼】
-1<--->1
这个思考方法的含义是:当我们思考一些技术方案时候,不要一条道走到黑,要前后、上下、左右、正反多个方面去思考,让技术方案具备更多维的视角。
我把常用的技巧总结如下:
-
【正反思考法】
-
【极限思考法】
-
【对称思考法】
M*N--->M+N
这个思考方法的含义是:当我们思考技术问题时,可以尝试从系统耦合的角度去思考,尝试找一些突破口。 我举一个实际的CASE,高速公路网的连接不是把所有目的地之间都修一条高速公路,而是会选择修建复用的高速公路主干道 + 分支道路的方式来组织这个网络。一条一条串联的方式就是耦合在一起的,这就是M * N。通过主干道 + 分支道路的方式 就是解耦的,M + N 就能够组建这个高速网络。 在技术架构上如何运用解耦这个技法,我有如下几个提炼。
-
【解耦上下游关联性】
在业务和技术架构发展的前期,把很多东西糅杂在一起是最快解决问题的方法。但随着业务和平台架构的进一步演进,势必是要做解耦,目的就是重新去界定各个模块的边界,平衡新的业务发展要求下各方发展快慢的诉求差异,通过解耦互相松绑快速发展。 这种技法在服务化的分布式架构中非常常见,基本上跨域的平台架构升级都有解耦的影子。
-
【解耦各个角色的依赖】
总结
以上是我在做技术架构方案时沉淀总结的一些思考方法,这些思考方法不可能解决遇到的所有实际问题,只能算是一个思考提示,在遇到问题可以尝试从这几个方法去看看是否有灵感。基于方法论但是不局限于方法论才是方法论最大的意义和价值。接下来一篇文章,我会从技术Leader的视角谈谈我在实践中的一些思考。作者:知明,蚂蚁金服国际事业群资深技术专家,全球资金平台技术负责人,负责了蚂蚁全球化进程中底层资金清结算、外汇等平台能力的搭建和迭代演进。