超级访谈：对话毕玄_06_架构架构师只是个角色不是个岗位
你好，我是叶间。
今天我们对谈的主题是架构师知道你是抱着收获一二三四条方法论的想法来的。
没错，今天一定会有，而且呢会非常具体，甚至会具体到你在系统设计文档里的设计思想。
这一小章节应该写什么，是不是非常期待呢？不过在讲具体的方法论之前啊，有几个至关重要的概念呢，我们先要理解清楚，不然很多人连架构师具体是干嘛的，能做到什么，不能做到什么都不清楚，就冲着这个概念去高喊，我要当架构师，岂不是事倍功半，甚至还有可能南辕北辙了。
相信我，下面这段概念澄清会对你的职业规划有巨大帮助。
嗯，关于架构师这个主题啊，有一些概念大家会觉得非常基础，但是又好像有点似懂非懂啊。
比如说第一个问题啊，到底什么是架构师，你是怎么觉得的？其实吧架构师就是个title,就很多公司不会明确有架构师的岗位。
就是做这个事情的时候呢，需要一个架构师，或者说是你兼任了，或者是指定了一个人而已。
不会说这个人他就是架构师啊，很少有的公司是这样子的，因为这确实会有点问题。
那架构师部门是什么？嗯，很少有这个公司会有架构师部门啊，嗯但是像饿了么CTO线下名台会有一个虚拟的架构师团队，那那个呢都是很小的，而且虚拟的可以啊。
是是这样啊，多数不是说这个人的角色就是一个架构师。
因为这里面最大的问题就是架构师到底干啥啊，我们一直都认为架构师他不是个岗位，他只是个角色。
那大家的岗位全部都是研发工程师，只是说在这个项目或者说系统里，我需要有一个人去承担架构师的职责啊，承担这个角色来负责这个整个的系统。
啊，那整个系统这个设计是是个什么意思啊？嗯现在前面有了一堆的需求，对吧？不管是来自业务方，还是说技术方本身啊，技术方本身就是做基础技术那群人啊，那需求有了之后，那这个需求要被翻译成一个技术的解决方案。
那这就是架构师要干的那通常呢这个人呀他也会去承担比较核心的代码编写啊，其他人呢会遵照这个设计来完成整体的一个落地啊，就这个活。
但是好像有些架构师他好像就负责写方案，嗯，有些可能是外部来的，有些是做业务架构的。
比如说呃业务方有大需求。
那这个时候有人要提解决的思路，那可能是另外一回事啊，他可能是不负责落地的，翻翻译完就随便做做。
但是这种是很容易虚的，比如说呃你话要这么做啊，但是研发最后具体怎么做，你根本就不知道啊，可能跟你想的千差万别啊，为呢研发他会有自己的想法，这很正常啊，挺乱的啊。
架构师也搞不清楚到底什么是架构师，反正我们是看过很多，最后还是觉得你架构师不太适合实体化。
那就是在阿里啊，架构师会分级别嘛，比如说初级、中级、高级这种。
嗯，这对我们来说是讲这个负责的这个系统的大小啊，但这也很主观可大可小。
那比如说一个小的系统里呢，包括一些模块啊，更大的一点呢可能是涉及两三个系统，嗯，啊，更大的呢涉及上百个，那就需要很多的这个大的架构师啊，那像大的架构师呢会是一个团。
对，因为会跨很多的专业啊，他自己不可能全懂嘛。
所以说他只是去根据整个的全貌去画定一个指导的框思想框架，来去判断出负责每个系统的架构师在设计的时候要解决的好几个问题啊，剩下就是这些事儿了。
那解的思路呢有的时候会给出来，但具体啊你要根据你自己想法去结合做好最后的这个落地的工作。
嗯，因为你刚刚说的这个总架构师感觉有点像导演，就像张艺谋最近导那个冬奥会，嗯，你可以认为他就是个架构师，他讲思路啊，下面人支持啊。
至于怎么去确保下面执行的过程，不要跟他的想法有太大的偏差呢？他不是靠系统去控制的啊，他是靠人在打。
嗯嗯，但技术上的架构师是我必须要设立一些指标，可以确保啊你们上线了我也能看啊，这个是个很好的架构师，因为多数这个架构师啊画完框就不管了，最后都不知道啊，程序员自由发挥成啥样儿。
嗯嗯，那像现在啊其实会有很多呃教架构师的课程，就是教研发怎么成长为架构师这种课你是怎么看的？哦，这种课简直太难讲了，就外面架构师课程讲啥都我都很很好奇。
呃，以前培训人问啊要不要采购，我就我就说你们不要听他们瞎扯，就是这个话题我都想了很久了。
但是就是我们一般会认为觉得嗯架构师是从初期培养的吧。
比如说最先开始去了解架构工具，然后什么这我们从来没有，我们之前都是用PPT给大家讲的。
因为呃架构师我觉得工具一点不重要，架构师最重要的传达清楚，就是你的想法就可以了啊，至于你用什么工具一点都不重要。
嗯嗯，其实不只是工具，比如说还会讲一下架构理论啊这些嗯，等他学完之后会发现一点用没有像设计原则呀、设计模式这些东西也不是完全没用啊，还是有点用，但这就是跟数学公式一样。
就是你知道这些公式就是学了一个天花板，只是那可能只是一个很小的点哈。
嗯那你觉得架构师是可以被培养的吗？我以前觉得很难被培养，因为我觉得方法论这个东西没什么用。
嗯，但后来啊我觉得方法论还是可能有点用的。
所以我在离开阿里之前呢，是特意搞了一个可以培培的的吗？嗯，你们是初级、中级高一都在一起上课嘛，那讲的是啥呢？嗯，级别其实我们不区别啊，班里都是承担过架构师角色，人大小都有啊。
因为负责的系统大小呢是知识面的问题。
但不管你是哪一级啊，负责多大系统啊，我看过我们以前所有的系统设计方法都是一样的。
大的呢就无非更复杂一点，可能分下去有更多人组成。
嗯，所以说呢做架构啊，首先做事情的大概的思路是可以抽象出来的。
比如说呃我的方法第一步是这个啊第二步，第三步是什么？另外更重要的是呢，我可以告诉你，我在每一步犯过的错是什么。
因为呢光讲方法论啊，最大的问题呢，就是讲完之后没有一个人能听懂啊，他也不会落到自己的实践上。
但是如果你给他讲这个血淋林的案例啊，等未来他真正干这个活的时候，他也许是忘记了这些方法论，但他想起的那个教训可能偏差也不大啊，这就是我们觉得架构师能去培养的地方啊。
但是嗯其他的呢我们觉得确实培养不了，只能实战啊。
其实你们这种讲案例倒很像是分享，但不太像是培训。
因为我们觉得想成为一个更大的架构师啊，就是真的不是靠培训啊，是知识面的问题。
嗯，像蚂蚁做的确实好，他们还会去划分几个等级，上面有更大的预架构师。
比如说你这个领域是交易啊，交易里面还有订单优惠等等。
你以前可能只是负责优惠这个小系统啊，只能讲清楚这一块。
那如果你要负责负责，这整个呢必须要清楚全部的问题啊，根根不是培训训活活因因为家公司的业务都不一样，而且你外面培训很难帮他，那只能靠他自己。
嗯，但是你刚刚举的这个例子是业务架构师。
那技术层面的呢对技术架构师其实也一样，都是全貌貌问题题。
那最大的系统呢，架构师啊，就越南有全貌，因为没有一个人的角色呢是我专门来看全貌的啊，只有你干的时候才承受那边认命了。
那们的区别只是业务架构师的需求，是来源于业务啊，技术架构师就更纯粹一点。
那最大的挑战是只是业务构的问题是什么？因为基础技术是需要自己想的，要做什么东西啊，自己去创造一个需求。
那业务说实话不需要你想，那所以事实上做事儿的方法都是同一个。
嗯，所以你们当时抽象出来的那个方法论是什么？是呃你之前在公众号写的那个架构式套路，就是是呃你先是做系统设计的目，然后是目标标后是核心心计啊，然后最后到呃设计原则呀，各个子模块的设计啊这种。
对，是的。
嗯，那我们具体解读一下这个套路你一般是怎么开展的？嗯，首先就是必须有个最大架构师，他是划定框的啊，决定了这一次的协作的关系。
嗯，啊那这个架构师呢最重要的呢是去定义目的啊，所以他架构之前他要去告诉所有的人，这次为什么要做架构级的改造。
因为架构级的改造其实不多，这是超级大的作作。
所以为什么架构师不大需要？因为老做这么大的，肯定肯定是出了挺严重的问题啊。
嗯，要像阿里发生过的大的架构，其实就这四轮啊，哪有那么多架构事情啊啊正常情况下是在我原来的框里去，天天改改就好啊。
行，那我们也举一个具体的案例吧。
啊，比如说你当时做那个集团上云，当时的目的是什么？嗯，第一个目的呢是后来嗯采购的所有的机器啊，百分之百必须是阿里云的，不允许自己去采购了。
所以我们只看预算啊，如果大家都是全部从阿里云走了，就说明成功了。
嗯，啊第二呢，像这个pass这一层呢，我们定义的目标是目的是这个凡是阿里云有了产品，全部不允许自言了，那就要就而且要去用这个标准的云产品。
然后呢下面的架构师啊会来分解。
比如说pass要全部去切换成云资源。
那所有的系统架构师呢要来看他们的系统要搬上去到底会面临一个什么样的问题。
那这些问题提出来呢，会由阿里云负责计算资源的架构师来看，应该怎么去解决。
那这他们应该干的。
所以这个越大的架构师啊，其实就越是个框架，是个方向性的指导。
嗯，下面人都在这个框里。
但因为你定义了一个目的，最后你就可以确保这么多人的协作不会走偏。
啊，所以你当时做统一调度也是类似吧，就是第一步先提一个大的方向，对像统一调度啊，涉及基础设施、网络、大数据、各种各样团队。
啊，那我就必须说清楚啊，我的总体思路是什么啊，然后你这部分最重要的人是做好什么就可以了。
那你们怎么做起来的？跟我没有关系，你也不用告诉我，因为我也不懂那大的架构师就是这样的。
其实我呢是给一帮人提了一堆的问题，然后你们去做掉啊，最难的是提问题，而不是写。
嗯，我有一个比较好奇的点啊，就是为什么你的方法论第一步跟第二步会有目的跟目标的区别。
目的呢是我做这件事情是为了什么啊，但是目标呢是我怎么考核你做到啊，这其实是个指标。
因为通常来讲呢，架构设计最大的问题是你最后目完了发发现跟跟当初设设计是偏偏差的啊，这很正常。
因为程序员呢会自己发挥啊，像画建筑设计图一样，你开始画成这样啊，最后干成什么样，谁都不知道，搞不好啊天差地别。
所以说目的目标啊就指标那是做系统架构师，在前面就要做好的。
啊，所以目标就比如说会给一个数字。
对，那比如说异地多活，那核心的目的啊就是把切流啊封要去封闭在一个单元里。
嗯，那所以我们一定会考核跨单元的交互啊，这是会在系统指标里定义清楚的那以后系统上线了，只用看这个就就能够知道有没有达到我们的设计目标，确保偏差不会太大。
嗯，那会不会有一些东西是不太能够用数据去衡量的呢？那不会肯定可以的，就如果不能衡量，应该是这个架构师没有想的很清楚。
那像我刚刚说的呃目的目标啊，其实是应该写在系统设计文档里面的啊系统设计思想啊这个部分的东西。
以前很多系统设计的文档里都有系统设计的思想啊，这个小章节，但是很多人都瞎写啊。
那你是怎么判断就是他有没有瞎写的那有的人是不管做什么系统设计，那放进去的这个设计思想都一模一样，这就是瞎写啊。
设计思想就是你针对这一次的改造，你觉得所有人需要遵循的最基本的原则是什么？嗯，那就像异地多活啊，那我们给的第一设计思想的指导啊，就是数据错乱保护啊，你要确保你的数据不会出现错乱。
那在下面去的各个系统实现的时候呢，我会告诉你大概的解决思路是什么。
那在你的这个系统里啊，一定要把这些写上，其他都是次要的。
比如说要做分流，那我告诉你分流的思路是什么？那剩下的就是你正常解决问题而已，随便你怎么发挥啊。
那所以你写的其实就是解决问题的一个大思路啊，也不用写太细。
嗯，因为没有多少人呢会真的去那么细的去看那个文档啊，你要看你写这些条，在下面的这个架构师的文档里会不会承接好啊，会的话呢说明这真的是设计思想啊。
那像后面就是具体的架构方案了吗？嗯，这个你们在培训的时候会讨论吗？这个我们没有，我们几乎是不做架构理论啊，最多最多是这个在晋升面试的时候留用。
嗯，不会说嗯找其他人参考一下我的方案，这种吗？不会啊，你想这个架构是干啥的那就是前面有个问题要想一个解决方法而已啊，这是工程多数工程师是非常擅长的，尤其是写代码优秀的工程师，这个能力就跟数学解题一样，只是你解的方法可能有有问题而已。
但是你不会这么认为，嗯，技术的人都是这样，都觉得哎我的方法当然没问题啊。
但但前面大家对于空对空谈有可能最终落地的，真的被你说中了，哪些地方确实有问题。
然后返工啊，这是很正常，因为他只有到那个阶段才能够明白哦，原来我确实是设计的有点问题。
嗯，所以你觉得架构设计哪个环节最难，是前面设写那个设计思想吗？对，因为很多人根本就没有想清楚啊，大家对这个系统架构的认知也是这样啊，前面一页需求啊，后面一页就是个框，觉得架构师这活好像也挺容易干的，不就是画框嘛。
嗯，啊但关键的是你的框，为什么要画成这样啊，这是你的选择。
你的观点说白了就是前面有个问题，你准备怎么解决？你要把这个解决思路告诉所有的人。
但大家都知道啊，解决思路有很多种。
嗯，那你为什么选选择这种啊？你的思路是不是最好的？如果不是最好的，你要知道最好是什么？嗯，很多架构师讲不出这个逻辑的，他为什么要把框画成那样？是因为别人把框画成那样而已，他只是套用了一下而已。
这就不叫做架构设计，这只是复制一下。
所以架构师通常是会讲的人，因为架构师是需要传达的啊，嗯这一步的话感觉是非常不好。
培训的对，我们只能讲案例，因为选择涉及很多方面，那像技术选型啊，需要你见过主跑啊，还有工程落地的问题。
你要想好到底哪几个地方是一定要解决的啊，哪些在当前阶段是不重要的啊，这就是架构构式的取舍。
你不能说我么都要做好，那不可能。
那像我们作为统一调度，也是，然后当时做决定去做两个调度器啊，在线的西格玛离线的伏羲。
嗯，然后中间呢有个所谓的零层来做两层的交互啊，后来应该是一九年合在一起的，就是这个ASI.嗯嗯，最最早我们也有纠结说要不要去做一个呃统一的调度啊，去同时支持在线和离线，嗯，就是一个呃就是一个方案去解决这个问题。
对，很多人从这个技术梦想上讲，应该先统一啊，像我坚决同同意，那就跟团队讲啊，这不光是技术的问题，还有工程问题，如果统一成一套，那光做这套调度器可能就三年了。
那这三年年我们不会看到任何的效果。
但是我要的是三年内看到类似bog的混部，那带来的整体的收益啊，有了收益以后，自然就有机会去实现技术梦想了。
啊，如果没有收益，可能公司隔两年哎，觉得这个项目不值得干啊，直接就不让我们干了，这很正常。
而且关键是这个选择不是我们做到业务效果的障碍啊，不做统一，也能做到这个效果统一啊，纯属只是好看一点而已啊。
技术上我也认我们的方案呢，一看就很丑陋啊，很妥一些。
但是从工程的落地上来看呢，这就是最高效的方案，因为落地才是最重要的。
嗯，像你会觉得落地是最重要的，但是好像很多人可能优先级调整不过来。
为什么很多技术很好的人在一家公司做不成事情呢？啊，最大的问题就是他不能接受妥协，他会觉得哎呀我必须做成这样才可以。
但是很多东西都不是这样的，你慢慢其实可以做到那个样子。
但是你要能接受前面恶心一点的过程，反正也是为了最终能够做到啊，要慢慢来，没有太着急啊。
当时我们做统一调度，被很多人狂喷啊，说你们简直了，他们就觉得哎呦，你们这伙人是不是觉得太难了，想绕路啊啊具被他们鄙视，但是这些我都不在乎，因为我当然也知道啊，有另外一套更好看的，但关键是要判断工程节奏以及判断。
如果用这种丑陋的方案，是不是做不到业务效果啊？如果做不到，那就是当然是另外一个事儿，那关键是他不是阻碍的点，对不对？那干嘛要去挑战难度呢？反正我觉得挺好的，能做成就行了，你管我什么方案呢？嗯，而且这个方案我也逐步变完美的嘛。
嗯，如果让你总结一下啊，你觉得一名优秀的架构师他应该具备哪些核心的能力？那对于架构师来讲哈那第一就是要非常的清楚知道你你做这个事情的意义，那这个还是个核心问题。
嗯，啊那在这个意义上你再去做技术方案啊，思考技术上怎么去解决掉这个问题。
那你肯定会有很多种方案，那这就是权衡要考虑很多的方面了。
像早期的HSF啊t four,那我们技术选型都是出现了很大的问题，那这其实就是架构师最重要责任了。
如果你的解决方法有问题，那后面就彻底完蛋了啊。
如果你做比较顶级的方案，还有之前讲的这个天花板问题。
嗯，另外就是一个你对未来发展趋势的看法。
比如说HSF,我们知道呃，我们认为就是为java场景去设计的。
嗯，但是就是没有想到一家公司一定会发展成多元化啊，一开始我们没留口子，呃，后来根本就没有机会。
那后面来，所以后来就多元元进之之就就知知道怎么搞了，你是个个设计题题啊，有时候呢构构师会面临临团队分的问题题。
比如说你需要的技术啊，有三个团队提供的问题，嗯，啊，这也是架构师要去解决的啊，我们会看平时哪些人做整个系统啊更有想法，而不只是我那个部分的代码怎么写。
那也会从团队的定位和长远发展看，而做这个东西对哪个团队来讲是它的长期主业，但这是非常复杂的话题。
你要有自己的观点，肯定会得罪一些人，这很正常。
嗯，所以架构师是有很大的挑战的，有时候要面临一些呃比较复杂的问题和方案。
嗯，而且你上面说的这几点也都很难去培养，纯培养，我觉得太难了。
只能说尽量告诉他们在做每一步的时候应该考虑好什么。
比如说技术选型，那我们会大概告诉你技术选型的思路是什么，要注意哪些点。
那另外也会重点强调你做一个架构设计啊，千万别去随便写设计思想。
嗯，但是现在有这样一种认知啊，就是大家都觉得好像不想做架构师的程序员，他就不是一个好程序员。
因为看起来就好像是架构师去负责了整个的系统啊，那架构师呃那程序员的最终归宿是架构师，这个说法是真的吗？不会啊，这成长路径有问题，程序员的成长路径的一条就是继续做程序员啊，这还是得一续做下去的啊。
另外确实有些程序员是成长成了架构师，但其实他就是一个兼职研发工程师兼这个架构师的角色。
那如果谁说我就只设计系统啊，这个人很多时候没活干的，因为系统统需需要去老的的那万一你真的是设这个岗位，那完蛋了，因为这个人就会老想回去凭空去创造一些需求啊，这就尴尬了。
因为架构师呢是设计系统结构的人，不是设计细节的人，细节呢才是需要经常变的。
所以之前专职架构师部门啊，最后会变成一个很虚的。
因为你又不实干，你讲了很多，但别人研发呢觉得哎你又不懂，他还是自己干自己那一套，跟你的设计方案一毛钱关系没有。
那架构师的成长来说，架构师一般是怎么选出来的？一般呢就是研发里面面写代码写的比较好的就去做啊一个项目呢。
比如说业务方有需求了，那也就牵头去处理这个需求去做规划。
所以平时呢根本就不存在这个人嗯，就是说哎这个项目出现的时候才会啊突然说任命了谁去负责横向架构啊，那这当然是基于大家日常对他的认可啊，所以大家就正常从程序员，然后慢慢往上走。
对，不会说因为你是架构师啊，就给你定什么级。
当然这个架构师呢肯定会比程序员更有优势。
这个我们也认，因为做过架构师的人呢，说明你可以去承担更大的责任嘛。
啊除非是做专业技术的，像虚拟化内核。
那对业务团队来讲，那为什么那么多做业务研发的程序员想做架构师呢？说白了他只是想复习一个更大的责任而已。
多数的公司的发展路径啊，是有些程序员他能够兼任架构师啊，他可能就变成leader了。
嗯，那可以去负责这个系统了啊，因为架构师其实已经具备了技术层面啊，业务层面的技能了，只是说欠缺的是管理行政什么的啊，他离这个leader只剩一步，所以说架构师确实就是几乎啊是leader的前提。
但是有一些人，他可能只想当架构师，不想当leader呢。
我觉得很多人想成为架构师的目标，就是想做leader,而不是想做架构师。
啊，当然也有人呢就是也喜欢做架构师啊，就是因为我不想去承担管理责任，但是我也想负责整个系统，嗯，啊，这种人也有，这也没错。
但通常来讲，作为一个技术leader,嗯，最重要的肯定是技术能力，对管理能力是可以培养的。
所以我们不会接受说这个团队有一个管理能力很强的人啊，因为他技术能力差一点，所以说要给他配一个架构师啊，这简直是太丢人了。
所以通常呢就是架构师做了leader.好，今天的对谈呢到这里就结束了。
说实话，今天聊完呢，我对架构师有了一个全新的认知。
之前我一直认为架构师是一个岗位，就是说有一个人一路打怪升级上去，最终成为了一名架构师。
但是必选认为呢，架构师就是一个角色，有一堆架构演近的需求来了，需要被翻译成一个技术的解决方案。
然后有一个人出来干这个活，根据系统全貌去划定了一个指导思想的框，然后也承担了比较核心的代码编写，来保障最终的项目效果。
这个人就是一个架构师。
如果你还想成为一名优秀的架构师呢，毕选认为你应该具备几大核心能力。
第一点就是要想清楚，并且讲清楚你做这次架构改造的意义是什么？包括目的和目标。
然后在这个意义之上呢，再去做技术方案的思考和权衡，包括技术选型顶级方案的天花板问题，对未来方向趋势的判断、团队分工问题等等。
那你对架构师的理解是什么呢？在你眼中，架构师的能力模型应该是什么样子的呢？你对这些能力有怎样的排序呢？如果你有自己的架构方法论呢，也欢迎分享到这里呢，我们的五场专题研讨会就结束了。
后面我还会更新一讲番，外来聊一聊必选的大学经历。
如果有兴趣的话呢，欢迎期待。