你可能还想看
其他
阿里10年技术人：实战中的架构设计方法
凌云时刻
常用思考方法
技术常用思考方法
技术思考本质还是结构化思考，所以常见的结构化思考方法是比较适用的，大家也会看到很多技术架构师会用一些方法论去分析问题的原因。本文就不再论述这些常见的技巧，而是分享从技术实战中得到的一些思考方法，我将其分为“技术架构设计的方法”和“技术 Leader 的思考方法”两类。
技术架构思考方法
这个思考方法的含义是：当我们在一堆迷茫和混乱中不知道如何下口时，应该先贴近问题本身，还原客观事实，并快速形成 1 个能够拉起认知并快速讨论迭代优化的版本。大家围绕着这样的一个初始版本去叠加和丰富其他维度的内容，直到方案达成共识。
我举一个实际的 CASE，大家在谈某平台能力升级的方案时，会经常喜欢用 PPT 画一些模块图，试图通过一些抽象的词汇来厘清边界和核心概念。大家以为自己是在讲本质讲原则，但实际所有人听了都是云里雾里，不知所云。因为通过概念去推导概念是无法真正回答问题的。
比较好的应对方法我总结为以下三个步骤：
用户视角的客观世界还原
用户故事的串联，基于用户视角，通过交互流程和真实的数据来描绘这件事在客观世界是怎么发生的。这就是我们找准一个大家都能够共识的视角，让所有人快速把客观事实搞清楚画出来这个 1，而这个 1 就是后续讨论的靶子 。这个 1 的表现形式我认为往往都是很简单的，要么是交互时序图，要么是 Excel 表格，而不是复杂的模块概念图。
客观信息的结构化整合与提炼
只是树立起来 1 这个初始版本，还远远不够。因为第一个步骤只是将模糊、混乱的东西通过一种方法信息化地表达出来，还远远达不到使用的程度。所以还需要将上述信息进行结构化的整合与提炼，因为信息只有经过结构化才能够变成有意义的知识，才能够与之前的经验形成互动，也才能够进行初版的设计加工。比如对数据流的处理，就会发现有哪些是可以合并的同类项，有哪些需要平衡校验逻辑等。
加入多元视角的检验与抽象
通过第二步的处理把 1 这个版本变得更加丰满，但是要形成完整的可实施方案还远远不够。我们还需要加入更多维度的校验和抽象，比如进一步抽象以看透其本质，比如加入重要异常、ROI、合理性等扩展性多方视角去做校验。
所以大家以后在遇到很多方案谈不清楚的时候，不要去听别人讲什么原则、概念、价值等虚头巴脑的东西。而是应该把大家拉回来，回到最简单、最朴素的东西来对焦，那就是一张交互序列图或者一张表格。越快速从一堆迷茫中快速提炼出这个 1 ，就越容易快速拿到结果。
这个思考方法的含义是：当我们在做一个方案时面对无数因素无法抓住关键点时，我们应该考虑用删除法（把这个 1 拿掉行不行）寻找决定性因素，以确保我们是真正地抓到了关键点。
我举一个实际的 CASE，每年都会做技术规划，相信这是很多架构师、技术Leader 很痛苦的事。痛苦的根源就是在脑子里面有无数需求，有无数的待优化点，也有无数的想法在萦绕，看到每个点都觉得值得在新一年做攻坚。最终多半形成的就是一个表格，把今年要做的事罗列下，最多还排个优先级，好一点的换个形式变成 Xmind 或者 PPT，再稍微好一点的可能会搭配上业务的目标和策略打法。但透过这些表面现象，其本质就是一个表格，一个没有抓住重点的表格。相信大家应该都看得蛮多了。
如何应对这类问题，我总结为以下几个技巧：
因果判断法
很多时候我们都在谈，要抓住事情的本质，要具备化繁为简的能力，其实就是在谈通过表面的结果去探究真实的原因。所以在看哪些是决定性因素时，大家不妨用因果法去检验：这个因素到底是深层次原因还是诱导的结果。
树干树枝法
有时候各个因素之间并不是单纯的因果关系，而是依附关系，就像是树枝依附在树干上一样。而我们要找到决定性因素，可以尝试用这个方法去检验：如果把这个因素去掉会不会影响全局，是不是导致结论不成立。通过这样多轮的分析，是可以绘制出来树干的与树枝的关系，这个树干就是要找的决定性因素。
支点撬动法
有时候各个因素之间可能没有直接或者间接的关系，或者这个关联关系太弱很难通过以上两个手段去确定关键点。可以尝试支点撬动的办法，即寻找可以激发这一堆要素的关键要素。我之前给团队举了一个例子，国家抓经济肯定不可能是米面粮油各种琐碎地抓，肯定是找到几个关键点起到支点撬动的作用，如房地产行业。抓住这个就能够带动上下游产业，进而激发各行各业。
以上是目前实践下来的抓取关键点的一些方法。但这里一定也要注意一个粒度问题，千万不要走极端。比如一提关键点，就去思考本质，一提到本质就去找根因，一找根因就挖到人性，然后得出来就是人性的原罪问题。这种都是没有任何营养的做法，也不利于事情的推动解决。
这个思考方法的含义是：当我们思考一些抽象问题/方案的时候，需要对问题进行拆分（一分为二），通过分而治之的方法来确定每个小问题的边界，通过对小问题的解决来降低全局的思考难度，以尽快形成解决方案。
这个应该不需要举例子了，大家日常都应该有所接触，这里只是列举几个比较典型的技术架构动作：
纵深拆解
拆解是非常好的一个将问题分而治之的办法，但要注意的是要做有机的拆解而不是物理的分解。比较典型的案例就是关于故障指标这个课题的处理，我见过有团队层层分解，把故障指标分解到每个同学身上。这是极其错误的做法，也不可能得到想要的结果。我们应该是要做拆解，就是把要守住故障指标这个结果拆解成哪几类关键动作，进而要求团队关键动作做到位，而不是强行分解指标。
横向解剖
做过实际研发的同学一定遇到一些业务需求的讨论，很多时候来来回回扯不清楚，而且经常会出现产品说这是技术架构问题，技术架构说这是业务需求问题，业务方说这是产品设计问题的现象。要破解这个僵局就需要把问题进行解剖，一层一层解剖清楚，把业务需求问题描述清楚，把产品设计搞清楚，把技术方案搞清楚。每一层都面向上游屏蔽下游的细节，才有可能把问题定义得清楚。一般来说，将这件事参与的角色进行解剖会更容易看得全面，更透彻。
以上是我实践中对问题拆分的一些方法技巧，凡事多看几层终归是能够更加有结构性地认知事情本事，也越有利于问题的解决。
这个思考方法的含义是：当我们思考一些技术方案的时候，不要仅局限在当时当刻的条件约束，要适当考虑系统的承载从 1 变到 N 的过程中，对系统架构带来的挑战。
做技术架构师的都知道做架构要求有前瞻性，不能被业务拖着走。但很多时候我们其实没有仔细思考如何才能够做到前瞻性，我认为最关键考虑的因素就是时间，把时间拉长来考虑关键生产资料可能发生什么变化，通过去架构这种变化所得出来的方案就具备了前瞻性。
一般意义上来说，我们平台演进的生产资料抽象地归纳为三类：
业务场景：这是最原始的生存资料，更是平台演进的源动力。典型的如市场份额变化，用户体价值的变化，竞对动态等。
团队组织：是人创造了平台，也是主导平台的演进发展，这个生产资料如果不能得到有效利用并充分释放能动性，就会出现平台无法支持业务快速发展的问题，同时人也在平台中内卷。
技术架构：技术架构其实本身也是非常重要的生产资料，这是很多人会忽略的地方。大家想一个最简单的例子，同一个变量分散在多个地方导致语义不清，维护成本巨大就明白了。
针对这几个生产资料，我抽取了几个技巧去思考如何从 1 扩张到 N：
架构考虑所有可能性但做有限明确实施
从业务场景的变化情况来看，的确充满很多不确定性。也遇到过一种典型的业务与架构陷入死循环的情况：前端业务面临太多不确定性需要技术架构给予专业意见和评估，但是技术架构认为业务啥都想不清楚还要我评估这评估那，两边就开始互相死锁。
而比较好的做法就是架构能够基于自己的经验和业务变化的理解，将可能性进行罗列考虑，然后给出基于 XX 业务假设下，系统架构需要 XX 量级的工作量做 XX 样的能力迭代升级，可以做到 XX 的业务效果和价值，但需要进一步 XX 的业务输入。这就是架构考虑所有可能性的含义，是需要给予业务的选择。
但技术架构实施却未必要留有太多的空白，架构要大但是实施要小，对于值得留白的地方做好扩展设计，对于实在看不清楚的地方就要明确拦截（宁愿不做也不错做），将可能性留足但也不瞎埋坑。
没有靠谱的人只有靠谱的机器
我常常去听一些故障复盘会议，在谈以后如何改进的时候很多同学都价值观爆棚，说以后 XX 类变更都加签上我来审核一道，我确认没问题再往后走。虽然这种精神值得鼓励，但是这种做法实在是很不值得推荐，这样沉淀出来的平台其实是非常脆弱的，在做技术方案时一定要思考，能够交给系统的绝对不要用流程，能够做到领域模型校验的千万不要靠旁路系统的侧面印证（如不必要场景下的核对）。
提前思考“幸福”的烦恼
很多技术同学都希望做高并发大流量的系统，但很多时候在写代码的时候身体很诚实，怎么简单怎么来。实际做的时候既不考虑大流量也不考虑高并发，对于资损风险考虑也极其少，而且基本上都很有道理：现在的业务量没到，不需要考虑那么多，这种事发生概率极其小，一期先这样......
要对技术架构做提前思考就必须从每行代码做起，提前考虑高并发大流量和严谨性。通常来说大家其实都比较喜欢从 0 到 1 的过程，按照互联网的迭代式打法，后面的 1 到 N 的过程也会被不断压缩。所以提前在 0 到 1 的过程加入 1 到 N 的架构预判非常重要，因为很多时候结构性的问题在最开始就决定了，而且只有一次机会。
这个思考方法的含义是：当我们思考一些技术方案的时候，不要一条道走到黑，要前后、上下、左右、正反多个方面去思考，让技术方案具备更多维的视角。
我把常用的技巧总结如下：
正反思考法
日常也 review 了很多同学产出的架构方案和系分以及测分，大家对于正常业务需求功能的论述基本上都没啥大问题，按部就班去写就可以。但普遍的问题都是对问题的反面论述不多，如支付正常流程浓墨重彩，退款/拒付等逆向流程就没那么细致，业务功能正常流转论述很饱满但是异常场景就寥寥几笔。事实上，正面与反面结合起来才是完整的一体，而且对反面的思考其实是对正面的有益补充。通常来说，我们在正面出现的概率大于反面，但是反面出现差错的影响及所需要付出的精力却远远大于正面。
极限思考法
在 review 技术架构方案风险相关的内容时，我都会特意问一下，如果出现 XX 问题最坏的业务影响是什么。为什么是问最坏的业务影响，是因为如果谈风险那肯定都是有一点点的，不利于大家去深究最关键的问题。通过极限设问，其实是激发大家去做最坏的打算，有了最终极的兜底手段才能够更乐观地去做技术变更。
对称思考法
在 review 代码或者逻辑结构时，深挖细节和关键点后，我时常会拔出来看看整体的逻辑结构是不是饱满，是不是对称，是不是美。最简单的例子就是写了 if 我一定要有 else，不然没对称结构就让我很不舒服。因为我相信对称的美就是一种生产力，因为美的东西一定是简洁且直达本质的。而我们写程序要的就是逻辑清晰简单直达业务本质，逻辑结构清晰的基本上没大问题，不清晰（如变量瞎命名，方法无语义）的深挖下去多半都能发现大问题。根源就是逻辑清晰代码才清晰，代码不清晰基本上就是逻辑混乱，逻辑混乱就会产生 BUG。
这个思考方法的含义是：当我们思考技术问题时，可以尝试从系统耦合的角度去思考，尝试找一些突破口。
我举一个实际的 CASE，高速公路网的连接不是把所有目的地之间都修一条高速公路，而是会选择修建复用的高速公路主干道 + 分支道路的方式来组织这个网络。一条一条串联的方式就是耦合在一起的，这就是 M * N。通过主干道 + 分支道路的方式就是解耦的，M + N 就能够组建这个高速网络。
在技术架构上如何运用解耦这个技法，我有如下几个提炼：
解耦上下游关联性
在业务和技术架构发展的前期，把很多东西糅杂在一起是最快解决问题的方法。但随着业务和平台架构的进一步演进，势必是要做解耦，目的就是重新去界定各个模块的边界，平衡新的业务发展要求下各方发展快慢的诉求差异，通过解耦互相松绑快速发展。
这种技法在服务化的分布式架构中非常常见，基本上跨域的平台架构升级都有解耦的影子。
解耦各个角色的依赖
解耦上下游关联性其实更多是在技术模型的抽象上，但在落入到技术模型范畴之前，还有就是我们在做更加抽象的解决方案探讨时要注意解耦各个角色之间的依赖。上述【架构考虑所有可能性但做有限明确实施】中提及的就是最好的案例。其实这里的本质表达就是，技术架构的设计应该要与商业选择、产品设计等解耦开来。
通过这一层的解耦，其实多个角色之间能够基于 SLA 去交互，并且能够基于自身的专业思考给予对方更多的选项和可能性。很多时候的前瞻性和竞争力可能就是比别人多一个选择。
解耦思考法其实很有意思，几乎所有的大型平台架构升级都有这个思考法的影子，所以下次没啥思路的时候可以从这个角度做一个审视思考，说不定是有新的收获。
以上是我在做技术架构方案时沉淀总结的一些思考方法，这些思考方法不可能解决遇到的所有实际问题，只能算是一个思考提示，在遇到问题可以尝试从这几个方法去看看是否有灵感。基于方法论但是不局限于方法论，才是方法论最大的意义和价值。接下来一篇文章，我会从技术 Leader 的视角谈谈我在实践中的一些思考。
混合云《Apsara Stack 同行者专刊》
属于混合云的专刊 ——《云栖战略参考》之《阿里云混合云 Apsara Stack 同行者专刊》上线了。
混合云平台大咖倾囊分享，干货满满；索尼、谢宁、墨辩领衔编委会，集中输出行业洞察，分享：混合云的行业发展轨迹、行业现状与挑战、政企云平台的需求特点与对应的云平台能力要求、混合云架构技术洞察、政企云平台建设趋势、 阿里云混合云产品技术策略、Apsara Stack 核心能力......
欢迎点击下方“阅读原文”下载完整内容。
你可能还想看