|上篇：技术架构的设计方法( 二 )

如何应对这类问题我总结为一下几个技巧：
因果判断法很多时候我们都在谈，要抓住事情的本质，要具备化繁为简的能力，其实就是在谈通过表面的结果去探究真实的原因。所以在看哪些是决定性因素时，大家不妨用因果法去检验：这个因素到底是深层次原因还是诱导的结果。
树干树枝法有时候各个因素之前并不是单纯的因果关系，而是依附关系，就像是树枝依附在树干上一样。而我们要找到决定性因素，可以尝试这个方法去检验：如果把这个因素去掉会不会影响全局，是不是导致结论不成立。通过这样多轮的分析，是可以绘制出来树干的与树枝的关系，这个树干就是要找的决定性因素。
支点撬动法有时候各个因素之间可能没有直接或者间接关系，或者这个关联关系太弱很难通过以上两个手段去确定关键点。可以尝试支点撬动的办法，即寻找可以激发这一堆要素的关键要素。我之前给团队举一个例子，国家抓经济肯定不可能是米面粮油各种琐碎地抓，肯定是找到几个关键点起到支点撬动的作用，如房地产行业。抓住这个就能够带动上下游产业，进而激发各行各业。
以上是目前实践下来的抓取关键点的一些方法。但这里一定也要注意一个粒度问题，千万不要走极端。比如一提关键点，就去思考本质，一提到本质就去找根因，一找根因就挖到人性，然后得出来就是人性的原罪问题。这种都是没有任何营养的做法，也不利于事情的推动解决。
1---2
这个思考方法的含义是：
当我们思考一些抽象问题/方案时候，需要对问题进行拆分（一分为二），通过分而治之的方法来确定每个小问题的边界，通过对小问题的解决来降低全局的思考难度，以尽快形成解决方案。
这个应该不需要举例子了，大家日常都应该有所接触，这里只是列举几个比较典型的技术架构动作：
纵深拆解拆解是非常好的一个将问题分而治之的办法，但要注意的是要做有机的拆解而不是物理的分解。比较典型的案例就是关于故障指标这个课题的处理，我是见过有团队层层分解，把故障指标分解到每个同学身上，这是极其错误的做法，也不可能得到想要的结果。我们应该是要做拆解，就是把要守住故障指标这个结果拆解成哪几类关键动作，进而要求团队关键动作做到位，而不是强行分解指标。
横向解剖 【|上篇：技术架构的设计方法】做过实际研发的同学一定遇到一些业务需求的讨论，很多时候来来回回扯不清楚，而且经常会出现产品说这是技术架构问题，技术架构说这是业务需求问题，业务方说这是产品设计问题的现象。要破解这个僵局就需要把这个问题进行解剖，一层一层解剖清楚，把业务需求问题描述清楚，把产品设计搞清楚，把技术方案搞清楚。每一层都面向上游屏蔽下游的细节，才有可能把问题定义得清楚。一般来说，将这件事参与的角色进行解剖会更容易看得全面，更透彻。
以上是我实践对问题拆分的一些方法技巧，凡事多看几层终归是能够更加有结构性地认知事情本事，也越有利于问题的解决。
1---N
这个思考方法的含义是：
当我们思考一些技术方案时候，不要仅局限在当时当刻的条件约束，要适当考虑系统的承载从 1 变到 N 的过程中的对系统架构带来的挑战。
做技术架构师的都知道做架构要求有前瞻性，不能被业务拖着走。但很多时候我们其实没有仔细思考如何才能够做到前瞻性，我总结为最关键的考虑的因素就是时间，把时间拉长来考虑关键生产资料可能发生什么变化，通过去架构这种变化所得出来的方案就具备了前瞻性。一般意义上来说，我们平台演进的生产资料抽象地归纳为三类：