郭东白的架构课¶
郭东白 2021-11-29
车好多集团 CTO,前阿里 P10,浙大兼职教授和博导
郭东白,当前担任车好多（即瓜子二手车母公司）集团 CTO, 同时兼任浙江大学计算机学院兼职教授和博导。
东白从布朗大学获得博士学位后,先后在美国甲骨文、微软、亚马逊任职。2014 年回国,在阿里集团先后担任全球速卖通 CTO、Lazada 集团 CTO。2020 年,加入车好多。
东白是云计算和国际化电商平台领域的资深专家,分别为亚马逊、阿里巴巴和 Lazada 搭建每秒上万次成交,年成交额超百亿美金的大型电商平台,覆盖数字、跨境和本地三种电商商业模式,同时支持内容化、社交化、游戏化、私域化等一系列创新技术,为企业带来了巨大的商业成功和生存优势。
东白还是国际标准领域的资深专家,分别为美国甲骨文、微软和亚马逊制定了国际标准战略,并代表公司在多个国际标准组织任职。他还担任过全球最大的医疗图像标准组织 DICOM 的执行委员会成员（全球共 26 名）。
除上述技术能力外,东白也是一个资深的全球化团队管理者,有 15 年管理经验,其中包括 6 年的全职 CTO 经验。在 Lazada,管理六个城市近 700 人的研发团队。在速卖通,从无到有搭建了深圳、西班牙和俄罗斯三个新的研发中心；还为公司引入多名优秀高级管理人才,而且连续 3 年维持了低于 3% 的离职率。
我的收获¶
靠记忆和技能学习,是成不了一个好架构师的。真正的架构师成长,主要靠思考力的提升。
所有的架构规划必须有且只有一个正确的目标,而且它必须与公司的战略意图相匹配,这是你架构设计的起点。否则,系统就会变得复杂和无序,缺少结构性。
决策权决定要什么,取舍权决定保留什么。一个决策者,必须要行使自己的取舍权,在自己的决策领域内做取舍。事实上,取舍权是一个决策者最重要的权限
马斯洛的需求理论的两个重点:优先级、跃迁（马斯洛强调的不是需求有层次,而是动机有优先级。动机是独占的,跃迁后从一个动机独占转为另一个动机独占）
最合理的配置是一名研发维护一个微服务。唯一能够支持多名研发维护同一个服务的理由是服务本身对公司的价值太大。（这样在这个服务上有唯一的责任人,提升主人翁精神；而离职等是小概率事件发生时,再花力气处理）
课程设计¶
1. 模块一: 架构工作中要遵守的原则
2. 模块二: “为复杂场景设计和实施结构化的软件系统”的具体工作方法
3. 模块三: 做好架构工作所必需的能力项
4. 模块四: 这些能力维度背后的本质能力,即思考力。
备注
架构师就是要在多种资源条件的限制下,组织研发人员交付一个结构化的解决方案。
架构师具有单个模块的设计能力、解决横向问题的能力、解决跨领域冲突的能力、全局性技术决策的能力,以及通过技术带来生存优势的能力。
想成为一个架构师,必须有意识地锻炼自己的战略意图和思考力。有了这两方面的锻炼,才能提升你作为一个架构师,在未知环境中判断和取舍的质量,并通过架构设计为你所在的团队或企业带来竞争优势。
模块一:架构师的六大生存法则。
生存法则指的是你作为架构师必须要尊重的一些原则。如果违背,你指导的架构活动可能会面临巨大的失误,而你在团队中的生存也会受到威胁。
所以,老师结合自己多年的架构实战,提炼出了六条生存法则,来帮助你提升架构成功的概率,提高你作为架构师的增量价值。
模块二:架构活动的八大关键节点。
老师把架构活动划分出了八个关键节点,包括环境搭建、目标确认、可行性探索、架构规划、项目启动、阶段交付、全面上线和复盘。
通过这个模块的学习,你可以增强风险识别和应对的能力,学会怎么通过真实的贡献让自己在团队或企业中变得不可或缺。
模块三:架构师成长的五大关键能力。
老师把架构师的成长分解成五种能力,分别是:单个模块的设计能力、解决横向问题的能力、解决跨领域冲突的能力、全局性技术决策的能力,以及通过技术带来生存优势的能力。
通过跨越这些能力障碍,不仅可以帮助你建立全新的能力维度,提高你的核心竞争力。还可以帮助你完成职业上的发展跃迁,从兼职架构师到跨域架构师再到总架构师,甚至到 CTO。
最后一个模块,这是一个接近于手把手传授技能的环节,会着重锻炼你的思考力。
思考力,是一个架构师生存与发展最核心的能力。因此,老师会提供一些他和团队提升思考质量的方法,并通过实际案例来示范他常用的思考路径（比如中台）,带你从宏观视角去审视一个复杂事件,从而提高你的认知,看清问题的本质。
00开篇词|没有战略意图,就成不了一个顶尖的架构师¶
备注
靠记忆和技能学习,是成不了一个好架构师的。真正的架构师成长,主要靠思考力的提升。
01模块一:生存法则 (15 讲)¶
01|模块导学: 是什么在影响架构活动的成败¶
在一个企业内,大多数研发任务的交付都与架构师无关。多数时间,研发团队开发的软件解决方案和软件产品是用来服务用户的,不需要架构师的参与。但当面对跨多个团队,或者是大面积的技术改造时,就需要架构师参与到其中,来完成软件研发任务的交付。
中间白色部分是架构师的决策领域,包括架构方案和架构活动。需要强调的是,架构师对研发活动没有完全的决策权。也就是说,架构师无法决定研发项目的选择、优先级、排期、代码实现方式等等。黄色部分指架构师的输入和输出部分。蓝色部分指架构师的工作环境¶
六个法则:
1. 架构师必须保障整个架构活动有且仅有一个正确的目标
2. 架构活动需要尊重和顺应人性
3. 架构师永远需要在有限资源下最大化商业价值
4. 架构选型必须要考虑到所依赖的商业和技术模块的生命周期
5. 架构师需要在架构活动中不断干预活动的目标和内容,以同时保证整个架构活动可以为企业注入外部适应性
6. 架构师需要在一个相对安全的文化环境中探索未知
备注
架构师的职责不是研发交付,而是跨团队、跨领域的组织技术团队交付。
02|法则一:为什么有些架构活动会没有正确的目标¶
备注
架构师的第一条生存法则:所有的架构规划必须有且只有一个正确的目标,而且它必须与公司的战略意图相匹配,这是你架构设计的起点。否则,系统就会变得复杂和无序,缺少结构性。
从技术维度去思考目标缺失的根因,就在于缺少全局视角,主要有三方面的表现:技术同学对于先进技术的强烈好奇心,开发者的个人利益,以及信息沟通不畅。
比技术原因更常见的是业务原因,主要表现在:目标太多、目标不明确或者是目标摇摆不定。
03|法则一:如何找到唯一且正确的架构目标¶
架构目标的决策,对于一个人或一个团队的影响是巨大的。所以当你有了一个正确的关于架构目标的决策,要知道这只是一个起点。你还要认真思考这个决策的实施路径,让大家团结在正确的架构目标上,而不是你自己一个人举着架构目标,变成孤家寡人。
决策权决定要什么,取舍权决定保留什么。一个决策者,必须要行使自己的取舍权,在自己的决策领域内做取舍。事实上,取舍权是一个决策者最重要的权限
备注
架构生存法则:架构师必须尽量保障整个架构活动有且仅有一个正确的目标,且这个目标必须和公司的战略意图相匹配。这是架构活动的起点,也是甄别架构方案的主要输入,所以架构师有义务影响和干预这个目标,以确保目标本身的正确性。
这个原则让你能够找到现有方案的弱点,看到这个目标和公司大目标不匹配的地方,然后让你有勇气站出来敢讲真话。讲真话的时候,不是你在反对你的上级,而是你在用一个架构原则来判断另外一个人的决策质量。
04|法则二:架构师为什么要学习马斯洛的需求理论¶
马斯洛的需求理论的两个重点:
1. 动机有优先级
2. 动机是跃迁的
1. 动机有优先级¶
不是需求有层次,而是动机有优先级
马斯洛是在研究动机（Motivation）时提出需求层次的。所谓动机,就是人类的行为到底是由什么驱动,其实是对人类行为的当下原动力。
马斯洛认为,人类的动机以抢占顺序依次排列（Being arranged in a hierarchy of prepotency）马斯洛用 “prepotency” 这个词,特指人类的动机是依次独占人类的全部意识的。
只有这个动机背后的需求被满足了,而且是长期被满足了,那么由更高层次需求所诱发的动机才会被解锁。因而当这个新动机开始作用的时候,它又像之前的生理动机一样,抢占你所有的意识和行为,并且压制更高层次的动机,直到它背后的需求得到完全满足。
假设一个人同时存在 5 个需求,需求 1 和需求 2 已经被满足了,那么这两个需求就不会再诱发动机。而需求 3、4 和 5 没有被满足,它们会同时诱发各自的动机。但由于需求 4 和 5 诱发的动机被需求 3 所压制,因而最终是需求 3 诱发的动机,在组织和驱动这个人整体的意识和行为。¶
备注
马斯洛理论的本意是:我们可能同时并行存在着多个需求,这些需求之间并不存在依赖或层次关系。如果这些需求得不到满足,那么它们各自会诱发动机。但动机有优先级,且具备抢占性质。所以任何时候,只有一个动机在主导着整个人的意识和行为。
马斯洛强调的不是需求有层次,而是动机有优先级。从某种程度上来说,诱发这些动机的需求也被传递了同样的优先级。所以把马斯洛理论翻译为需求层次理论,虽然不能说完全错误,但却没有完整传递马斯洛理论的核心观点,甚至是部分曲解了马斯洛的理论。
2. 动机跃迁¶
跃迁是指从一个状态进入到另一个状态的过程。 这两个状态之间不需要相邻。
马斯洛认为,人的行为在单一时刻不是面向多目标做优化,而是面向单一目标做优化。一旦某个动机抢占了人的意识,那么它就抢占了这个人的全部意识,此时整个生命的所有思考、行为等,都在为满足这个动机而工作。那些帮不上忙的器官和能力,就被放置在后台运行了。
备注
人有且只有一个主导动机。这个动机由人的内在需求所驱动,并独占且主导这个人当前的一切意识和行为。直到这个动机背后的需求被完全满足之后,更高层次的动机才可能进入主导位置。
评论¶
企业家们似乎都违反了马斯洛的需求层次模型,比如创业初期可能吃饭都吃不好睡觉都睡不好；没有什么娱乐活动；不被大多数人所理解；见人说人话见鬼说鬼话,似乎也没有什么自尊。但从动机的优先级上来看似乎就可以理解了,会不会是高层次的需求对于他们来说优先级更高,压制了低层次的需求
这个马斯洛的原文里面还真解释了一下。 他认为有牺牲精神和对目标极度追求的人, 往往具备一个特质, 就是他们的童年生活在非常满足的状态,以至于到了成年他们不在认为一些基本的动机, 比如说物质享受、安全感有那么重要。 他们甚至不惜牺牲这些来追逐自我实现。
05|法则二:研发人员的人性需求是如何影响架构活动成败的¶
项目评审:越是大型的架构方案,就越要在早期去讨论它的方案可行性,而且要尽量试图要从批判和否定的眼光去看待它。这种讨论越早越好,涉及的利益方也越少越好,而不是放在详细规划已经完成之后,甚至是项目已经了启动一小半了才做评审。
最合理的配置是让一名研发维护一个微服务。唯一能够支持多名研发维护同一个服务的理由,就是服务本身对公司的价值太大,它上面承载的业务量,对稳定性的要求,对服务连续性的要求,大到可以忽略研发资源的成本的时候；或者是从性能角度来看,服务无法拆分,它得复杂度大到可以支持多个研发维护的时候。
06|法则二:拼多多是如何通过洞察用户人性而脱颖而出的¶
一个架构师要站在用户的角度去思考架构的规划和设计。
有一个关键因素和马斯洛的人性理论有关:拼多多对用户人性的理解,远远超越了其他同时期的电商玩家。拼多多创始人`黄峥在《财经》杂志的采访 <https://www.bilibili.com/video/av244628965/?p=6>`中说了这个洞察:“
我们的核心不是便宜,而是满足用户占便宜的感觉”。可以把占便宜理解为一种欲望,它不完全等同于人性中贪婪的欲望,而是更接近人性中获取不对称生存优势的欲望。这种获取不对称生存优势的欲望,应该是动物的一个根本欲望。因为你需要更有效地获取自己生存所必需的资源,那么这个欲望,就会诱发你的动机,并占据主导地位。从这个视角来看,人性中占便宜的需求,在马斯洛的需求层次中应该更接近生理需求层次。也就是说,一旦这个需求被触发,它将抢占其他一切动机,成为主导。而你的所有意识、行为都是在满足这个主导动机。所以这时候,你已经不是单纯地在购物了,你是在为自己获取不对称的生存优势
“省钱” 和 “占便宜” 是两种截然不同的心智:占便宜的心智就会诱发具备抢占性的主导动机,但省钱是不会的,省钱是个非常理性的心智。
飞轮效应:一个平台的定位,也就是满足用户占便宜的心智,反向选择了用户人群。然后在这些人群的共性需求中建设了自己的供应链,从而形成正反馈闭环。¶
淘宝无所不能的心智带来了大量的猎奇和浏览者,但是平台却是靠天猫的品牌,获取了大量利润、金融收入和资本市场的认可。聚划算和拼多多的心智相同,也自带流量,但是一个以占便宜心智为主导的用户,大多是不愿意花更多的钱在品牌溢价上的。所以,平台到底是要刺激哪一种心智呢？事实上,这几种心智是互不兼容的。聚划算要追逐极致性价比的商户,那么产品的稀缺性就会降低,就不会帮助到淘宝。而且所谓的极致性价比,在某些质量维度上,必须要打折扣,那么你也就不能维持天猫 “品质生活” 的保障了。
一个架构师,如果你能尽早看懂看透你公司的用户心智,那么你就可以在技术上提前布局,从用户思维出发,扩大你的技术搜索空间,最终为公司创造更大的价值。
评论¶
不被认可的架构设计是没用的设计,依靠行政命令强制推行,只能是一地鸡毛。
07|法则三:架构师如何找到自己的商业模式¶
备注
作为一个架构师,必须要在有限的资源下最大化架构活动所带来的商业价值。对于任何一个架构活动而言,架构师的可用资源,包括商业成本、研发成本、时间成本、迁移成本等等,都是非常有限的。但架构活动就是要在这些限制条件之下,将商业价值最大化。
什么是商业模式/什么是商业价值¶
商业模式（Business model) 就是讲一个企业是以什么样的方式赚钱的,比如电商行业,有自营和平台两种不同的商业模式。
商业价值 (Business value) 呢,就是从现金收入的视角看价值创造的过程。你每天忙碌的工作,从企业的收入上来说,可以为公司带来什么样的短期和长期现金和其他收入,那么对这部分收入的量化,就是你创造的商业价值。简单来说,商业价值就是帮助公司获取商业收入。
从创造商业价值视角来看,你的代码和设计有三个作用:
1. 实现一个商业模式；
2. 提升一个商业模式的效率；
3. 加速一个商业模式的收敛速度。
=> 你作为一个程序员,主要通过上面这三个路径为公司赚钱。
1. 你写代码实现一个电商平台的一部分功能,最终电商平台可以获取交易收入。
2. 你实现一个算法,提升了买家转换率,从而提升了电商平台这个商业模式的效率。
3. 你通过 A/B 实验的平台、数据仿真的功能等等,加速一个公司的商业模式收敛速度。
把第三条生存法则分为五个部分来讲:
1. 理解你所在的企业或团队的商业模式
2. 理解你在自己所处环境中创造的商业价值
3. 保障架构活动的长期商业价值
4. 在架构规划中寻找扩大收入的机会
5. 在架构规划中寻找减少成本的机会
1. 理解一个企业或团队的商业模式¶
不知道商业模式,就没法主动创造商业价值,你的日常工作很可能只是不断被动实现需求。这时候,你的成长也会是缓而慢的。
一个商业模式的技术表达公式:就是对所在行业的商业逻辑的数学表达,也就是我们常说的 KPI 的逻辑。
大多数公司往往处在商业模式的探索期,有的团队连自己的 KPI 是什么都不知道。但无论如何,至少要理解你的团队为什么存在,你的工资收入从哪里来。
2. 理解自己所处的工作环境¶
我们研究一家公司的商业模式,就是希望你认真理解自己所处的工作环境。
备注
如果你活在一个靠公司拨款而生存的部门,那么你学习到的能力是有限的,因为你们部门从上到下都不是在求生,也不是为客户创造价值,所以你也学不到真正的生存技能。
重要
对于一个业务部门而言,存在不一定合理,只有提供稳定商业价值的存在才是合理的。
3. 每个人都要有自己的商业模式¶
每个人都要有自己的商业模式。意思是说,你必须在工作环境中找到创造价值的方式,这样才能保障自己一直被需要,也能保障未来的收入。
具体怎么做呢？那就是你要为公司、部门或团队提供可量化的增量价值。
两个关键元素:
第一是增量价值,就是你通过工作所创造的价值,是在社会提供的平均价值之上的。
第二个是可度量性。
例子:2010 年之前,如果你是一个做微服务框架的高手,那你的增量价值就非常大,一个人能顶十个甚至一百个研发。因为那时候开源的微服务框架还不够成熟。但到了今天,如果你还是单兵作战,擅长写微服务框架,那跟开源的 Spring Framework 相比,你提供的增量价值可能就是一个负数了。因为团队剩下的同学还要花时间来学习、使用和维护你写的框架,公司也要为这些同学付出工资成本。虽然你的工作没有变,但社会提供的开源解决方案的价值增加了,那你的增量价值相应地就会减少,甚至不存在。
架构师如何创造自己的增量价值¶
一个架构师想要创造长期的商业价值,就必须同时满足三个条件:
1. 确保最终架构方案的可行性。
2. 确保参与方达成一个合理的实施路径,最终能够完成实施。
3. 确保设计方案可以最大化解决方案的结构性。
备注
事实上,这三个条件很难被同时满足。架构师之所以参与一个方案,往往有这么几个原因:已经有现成的方案,但比较复杂；参与团队众多,但各个团队的优先级不一样；公司压力大,能够投入到现存方案的人力资源有限。这就意味着你作为一个架构师,需要在资源有限的条件下做取舍。事实上,这三个条件很可能是互相冲突的,很难被同时满足。于是,靠对阶段性精确目标的最大化投入去取得成功,就成了实施架构活动的重点。
例子:假设你们已经有一套在一些核心系统上使用的老网关,之后又开发了新系统,却发现老网关落后,于是就把老网关迁移到了 Spring Cloud Gateway 上去。但是最近你们发现,出于公司整体安全的要求,还需要在网关层上开发安全功能。这个时候,你作为一个架构师至少有三种不同的选择路径:一种是在现有的两种网关上各自加安全功能；一种是迁移和整合现有的网关,然后再加安全功能；一种是在这两个网关之外再加一层安全网关,之后再想办法把现有的网关能力都迁移上去。
在不同的交付时间、需求压力、现有系统复杂度和研发人员能力的组合之下, 这三种方案都可能是最好的方案。但作为架构师,就要在兼顾方案可行性和实施路径合理性的同时,寻找一个最合理的结构化方案。所谓最合理的结构,就是从长期看,网关层不是越来越复杂,而是全公司统一、易维护和高可用。
如果相关方都能接受长期规划,那么构建第三个网关,然后逐渐把现有网关的功能都迁移上去,可能就是最结构的方案。反之,如果你的迁移项目烂尾了,那么两个网关变成三个网关,而且在迁移到一半的情况下,安全和网关逻辑散落在各处。那就是一个糟糕透顶的设计。
所以架构师在这个过程中创造的增量价值就在于能够审时度势,在企业内部各种资源限制和现实条件下,找到合理可行,并且能够最大化企业长期价值的架构方案。
08|法则三:架构师如何在一定时间内最大化自己的增量价值¶
4. 如何寻找扩大收入的机会¶
在小数据里看大机会,在大数据里看小机会:
前半句指的是从个性需求中抽象出共性的机会。也就是从解决一个具体问题的过程中得到启发,并从中找到一个可以规模化应用的机会。
后半句指的是靠数据来打磨用户体验。也就是通过数据分析找到机会点,然后通过产品和技术的改进,不断提升转化减少损失。
其中前半句是重点（演绎法）:看到了别人忽略的小痛点,或者在别人不去排查的小异常上执着探索,才最终跨越了现实的障碍。
在别人容易忽视的痛点和异常点上,深度挖掘可能大规模复制的机会,不失为扩大收入的好方法。
5. 如何寻找减少成本的机会¶
时间成本、机会成本,包括技术的迁移成本,都是一样的。你作为一个架构师,要能省则省。
有些人会过分强调极客精神,事事追求完美。我觉得出发点是好的。但在一个企业中,追求完美必须以成本可控为前提。
案例背景与分析¶
我刚去 AliExpress 时,负责公司的全站架构。那时全站的性能非常差,但大家不知道这个差到底意味着什么,也不知道做性能优化到底要付出多大成本,又能带来多大回报。
当时我们已经有了全站的埋点。也就是说,我们有办法获取任意一个页面上跳出率和加载时长的关系,有办法获取任意一个页面上流量分布和加载时长之间的关系。
但问题就在于,如果针对每个页面的优化都要做投入。再加上维持这些优化效果,就要对页面的变更做限制和性能监控,那么付出的成本会非常高昂。要知道,AliExpress 是个跨境电商网站,当时有 14 个站点,每个站点的前端代码都有微小的差异。一到大促,就要根据国家和语言一次性发布数千个页面。如果按部就班一个一个页面去优化,哪怕配十几个全职研发,从头到尾做一年也跟不上发布的速度。
我发明了一个方法,``能够准确度量性能优化后每个页面的预期产出``。而我们要做的,就是按预期产出除以预期投入成本,也就是预期回报的 ROI 来排序,再依次做优化。
本来完全不等价的优化动作,有的在网络层,有的前端,有的在后端。这下子就可以在一个指标上做比较了,因为我们的每一个优化动作最终都能被归因成了订单贡献。
之后我和团队把它做成了一个基于性能损耗的度量系统,共申请了 13 项专利。而这个理念也从最开始的指导架构规划,变成了性能归因、性能监控、转化分析和准实时的转化排查工具,并从 AliExpress 的一个部门逐步推广到阿里巴巴的其他部门。
当发现性能优化的回报不够大了,我们就不再做性能优化了。而是换个赛道去创造价值:做现有网络的性能监控。
如何践行¶
第一,你作为一个架构师,在架构设计中要追求商业价值。我们做性能优化时,不是单纯做性能指标的优化,而是一上来就以提升商业价值为目标。因此我们的优化目标是订单数,而不是一个技术指标。
第二,想要创造商业价值,就必须不断度量你创造的增量价值,这样才能确保自己处在价值创造的前沿。并且能够在一个相对未知的环境下,不断寻找自己的增值空间。
第三,作为一个架构师,要最小化整个架构活动的成本。你要做的是:确保最终方案的可行性；寻找最优的实施路径,确保最终能够完成实施；试图最大化最终解决方案的结构性,以最小成本放大你的产出。
第四,做架构和做业务一样,都不能靠饱和攻击取胜,而要靠对阶段性精确目标的最大化投入来取得进步。
第五,不断寻找通过技术手段扩大收入的机会。
第六,不断寻找通过技术手段缩减成本。
我刚加入 AliExpress 时还没有很强的号召力,能调用的资源也极为有限。但当我发现性能优化是个突破口之后,就立即制定了一个可行的方案,而不是一个宏大的方案。
我当时仅仅把上面这个理念解释给了几个同学,然后我们就靠手算找到了回报率最大的几个页面,并且凭经验找到了投入产出比最大的优化点。这就确保了我们整个项目有非常强的可行性,同时也给了我们信心。
紧接着,我们迅速搭建了刚才提到的性能损耗的度量工具,验证了从工具中发现的优化点到订单回报的全流程。这样一来,不到一个月,整个项目的可行性就得到了验证。
最后,我还做了设计方案的结构性规划:先把相关理论和公式做了完整的推导,确保所有参与到项目的同学,都知道未来这个系统能给部门带来的核心技术价值,以及它对我们业务的支柱性作用。再把这些公式变成性能监控和性能损耗度量的工具。
小结¶
备注
你作为一个架构师,必须要创造足够的商业价值,这样才能保障你在企业长期存在的意义。
09|法则四:为什么要顺应技术的生命周期¶
三个人性上的弱点:
1. 自我麻痹,以繁忙的重复工作来代替深度思考；
2. 畏惧变化,以最小化改变来维持自己的心理安全感；
3. 路径依赖,以过去的成功经历来应对未来案例。
备注
把自己的思考尺度从三五个月扩大到五年或十年,那么这件事情的价值必然会很大。这个放大思考尺度的动作,会让你用不一样的视角来看待技术。
如何克服弱点去把握技术趋势:
1. 跳出自我麻痹状态的办法就是,每年会留出两次深度忏悔的时间
放下当前所有事情,回想过去半年是不是做错了什么,有没有获得什么本质上的能力提升。
半年后,如果发现自己还是同样沮丧,那么我就会琢磨,是不是要逼迫自己找个更有压力、更能成长的事情和环境了。
2. 克服内心的恐惧,迎接变化
用对获取惊喜的期待,来压制内心的恐惧
所有的技术都像人类的生命一样,也有终结的一天。这是个自然规律。一个老去的技术就让他老去,快死的架构不值得投入人力和时间去维护,更不用说去翻修或者是复用了。
10|法则四:架构设计中怎么判断和利用技术趋势¶
技术真正的推动力来自市场,需求规模决定技术走向。
软件行业内的竞争,则是软件架构技术发展的第二个核心推动力。
架构师需要不断监控自身能力的有效性和增量价值,不断提升自身能力的稀缺性和价值创造的空间。
任何一个新技术,你进入的时间就决定了你的未来:萌芽期赌命,增长期圈钱,至捧期交学费,灵感期拿价值,产出期养老,衰老期做死,退出期刨腹。
什么是萌芽期的技术呢？其实最好的源头,就是从顶尖学术会议中,找一下最近三年论文增长最快的领域。
对于个人而言,技术的初期充满风险,但值得进入。在这个赌命的过程中,你不但可以学习设计思路,看到一个技术的成长与发展过程,而你自己也能获得先发优势。如果精力允许,那么多看些萌芽期的技术,对于你的成长而言会非常有价值。
11|法则五:架构师为什么要关注技术体系的外部适应性¶
在架构活动内部,也就是在架构师可控的范围内,应该遵守哪些法则。
作为架构师,能在企业的竞争中做些什么,同时也为自己创造增量价值呢？答案是:通过技术手段为企业注入更多的外部适应性。
架构师要通过优化架构方案、干预架构活动,以保证最终交付的项目不仅能满足既定目标,还能适应不断变化的外部环境。这个过程有一个总的指导原则,那就是为最终产生的架构设计不断注入外部适应性。
外部适应性是指一个企业对外部环境变化的适应能力,以及对新机会的捕捉能力。
架构师是技术职能的一种,所以也是通过打磨技术体系来为企业注入外部适应性的。
架构师这个职能有自己的特殊性。
首先,架构师与研发经理不同。后者具有人员管理的职责,因而可以通过人才招聘、培养和组织架构的调整来创造价值。
然后,架构师也不同于研发人员。研发人员可以通过优化数据模型、算法迭代、代码重构和模块升级来为企业直接注入外部适应性。
架构师仅仅可以通过组织架构活动与优化架构方案设计,来为企业注入外部适应性。
业务、产品和架构师所处的技术视角,分别代表研发活动的三个不同层次。¶
第一个层次,研发活动由业务驱动,直接在业务人员的指挥下响应外部机会。我们把这一组研发人员称为业务线研发。在一些公司里,这些人一般直接向业务部门汇报。比较常见的是增长的产品和技术人员同时汇报给增长业务部门,以迅速响应新的业务机会。
第二个层次,研发活动由产品规划驱动。产品把业务活动抽象为一组产品,沉淀出产品矩阵,并通过产品运营不断打磨用户心智。在这个过程中,相应的技术人员会不断提升自己对产品的理解,并通过技术手段放大产品提供给用户的增值。比较常见的产品有营销产品、供应链产品、物流产品等。除了产品特性本身外,一些纯技术手段,比如营销的资金池优化、反作弊、供应链优化、物流调拨等等,也会为产品带来新的增值手段。
第三个层次,研发活动就是由架构师主导的架构活动。架构师和研发同学对业务、产品做了一系列的抽象,最终形成由技术驱动的技术产品。比如工作流引擎、风控引擎、策略引擎、算法的特性引擎和标签引擎,都属于这一类产品。
很多架构师把帮助他人创造价值与自身创造价值这两件事混为一谈,这样做,你就很难提升自己独立创造价值的能力。
架构师需要在技术层面为整个企业的技术体系注入外部适应性,这才是你独立于其他职能所创造的长期价值,是你有底气的自尊的源泉。
12|法则五:如何提升一个架构设计的外部适应性¶
如何抵抗内部压力而为企业注入外部适应性¶
企业内部压力的挑战:
1. 业务交付时间的压力
2. 技术岗供给压力导致技术人员的稳定性差和设计短视的问题
3. 考核带来的短期效应
交付压力,其实就是在一个高速迭代的业务中维持技术体系的外部适应性。
对于业务尝试,我们需要以最低成本完成这么一个任务:从这个尝试中得出一个正确的结论。
从架构设计的角度来说,我们要把大多数的尝试尽量封装到一个小的领域内。
第一,单一职责,指的是要把每个业务尝试尽量封装到一个单一模块中。好处是一旦尝试失败,就可以迅速把业务逻辑下线,避免影响整体的复杂性。
第二,最小依赖,指的是整体架构设计要保障大多数业务尝试尽量少的依赖。
第三,最小数据共享。一个正在尝试中的业务应该尽量减少与其他业务模块的数据交换,尤其是输出,这样才能最小化它的爆炸半径。
第四,最小暴露,指的是在业务尝试期接口不对部门或企业外部暴露,包括 API、数据共享、事件、消息流等一切对外界造成影响的通信机制。
应对交付压力的挑战¶
第一,提升对封装能力重要性的认知。你要帮每个做技术的同学认识到:我们都要有有效封装业务尝试的能力,这个能力最终会转化为提升技术的外部适应性的能力。
第二,建设复杂度控制机制。设计评审很关键。业务尝试也要有设计评审,而评审的一个固定环节就是逻辑、数据和接口的最小爆炸半径的设计。
第三,推行最小必要架构原则。在公司范围内推行奥卡姆剃刀（Occam’s Razor）原则。任何增加功能、引入复杂性的设计,都要做一个正式的评审,而简化的行为则不需要。
完善技术体系的考核¶
短期效应这种挑战,它的根因在于公司的激励机制不够合理。
这个问题,架构师其实没有真正有效的抓手。这是制度上的问题,要靠改变公司的制度来修复。我见到的比较好的办法是,把绩效考核仅仅与业务结果绑定,而把技术线晋升与长期的技术体系建设绑定。
13|法则六:如何鉴别文化环境是否有利于架构师的生存¶
架构师通常并不管理团队,而是管理架构活动。更准确地说,是定义和引导架构活动。
架构师要在一个相对友善的环境下,才能找到并推进一个正确的架构方案,进行有效的架构探索。
架构师就要通过包容和求真的认知态度,以及有良知有勇气的行为,来影响所有参与架构活动的人。如果企业文化环境无法帮你完成有效的架构探索,那就要选择另一个更友善的环境了。
什么样的文化环境对架构师是友善的¶
架构师的做事方式:你从技术洞察中产生一个商业假设,也就是你期望技术能带来的商业价值,然后再通过架构设计最大化你创造的价值。如果项目上线后成功了,那你预期的商业价值也就实现了。反之,如果你发现问题,那么就需要重新修正你的假设和设计。
这是一个不断假设、求证、再假设的过程。这个过程像科学方法一样,你要主动探索而不是被动执行。
什么样的环境才有利于架构的科学探索呢？我认为企业的文化环境必须要足够包容和求真。这种文化主要是在思想和认知层面,属于知行合一中“知”的部分。
架构师如何在小范围内打造一个友善的文化环境¶
我们经常把架构师称为技术领导者,领导者有一个重要的能力,那就是影响力。不是通过职位,也不是通过权益的分配,而是通过你的行为来影响周围人的行为。
小结¶
企业的文化能够包容不同意见,也鼓励对真理的追求。甚至能够容忍一定程度的试错和探索。那么这就是一个对架构师友善的环境了。在这样的环境里,你自己除了在思想上要保持包容和求真的态度,还要在行为上有良知和有勇气。
14|模块小结:这些生存法则的逻辑是什么¶
过程正义:为什么要定义生存法则¶
架构师要尤其信奉原则（Work by principles）。所谓信奉原则,就是采用相信过程正义的工作方式,用一组原则来指导行为和决策,而不是随心所欲地工作。
过程正义,表示你作出决策的每一步都是公平（Fair）、正义（Justified）和可解释的（Explainable）,而不是靠一两个人的强势来达成的。
架构师这个角色从定义上来说,本身并不具备决策权和取舍权,他仅仅可以靠寻找更优路径和目标来推动架构活动。如果多数参与者都不认同你的 “更优”,那么架构活动成功的概率就会大幅缩小。所以过程正义的价值就在于,架构师可以和架构活动参与者一起找到那个更优的路径。
法则具有对称性。你是法则的发现者和传播者,但同时你也受法则的约束,这是一组行为信条,引导你与周围人共同去做正确的决策。
道可道:生存法则背后的总体价值观¶
“道可道”。意思是架构活动的成功规律都是可以被发现、表达和反复使用的。
企业生存是第一优先级。
非常道:六条生存法则就够了吗¶
从一线研发人员到 CTO,真正要取舍的只有几个最核心、最基础、最具决定性的点。其他的都不重要,甚至你也不应该关心。
对架构师来说,针对每一个问题,你都需要有一个行动点。
第一,审视整个架构活动的方向是否正确。对应的法则是要有一个正确的目标。而你的行动点就是确保目标与公司的战略意图相匹配。
第二,审视参与者动机和用户的需求是否合理。对应的法则是不要搭没有人性的架构。而你的行动点就是在方案设计和架构活动组织中充分考虑研发和用户的人性。
第三,审视你的技术是否能够创造商业价值。对应的法则是要有自己的商业模式。而你的行动点就是在一个有限资源下最大化商业价值。
第四,从技术和商业视角审视架构方案是否合理。对应的法则是注重商业和技术的生命周期。而你的行动点就是选择已经有规模优势或者是即将有规模优势的技术。
第五,在变化的环境中审视你的行动。对应的法则是追求外部适应性。 而你的行动点就是干预架构活动和设计方案来不断地注入外部适应性。
第六,审视你是否拥有安全的架构探索的环境。对应的法则是构建或寻找一个友善的环境。而你的行动点就是在思想上要包容和求真,在行为上要有良知和勇气,最终达到知行合一的形态。
编辑加餐|六张图,带你回顾架构师的六条生存法则¶
法则一¶
法则二¶
法则三¶
法则四¶
法则五¶
法则六¶
02模块二:创造价值 (21讲)¶
上个模块讲的基本法则,相对来说,能适应的时间跨度和技术体系跨度会更长一些。但在这个模块里,这些行动建议有着非常强的时效性,主要针对现在主流的计算方式 —— 以分布式技术为主的互联网研发活动。
15|模块导读:互联网时代架构师都面临哪些新挑战¶
架构师在互联网时代面临的新挑战¶
第一,反射式研发行为。不论是初创公司还是大企业里的初创团队,往往持续面临着巨大的交付压力,导致一种被我称之为 “反射式研发” 的行为:写代码就像膝跳反射一样。研发人员的日常工作都是在接需求、写代码、上线、修故障之间循环,很少有时间去思考和追求长远的设计。这种短期行为虽然不影响业务迭代,但如果在一个大型架构活动中出现频繁,造成的后果将是灾难性的。
第二,大规模活动。分布式研发模式往往采用微服务架构。微服务架构有一个优势,就是服务之间可以独立做变更,在保持 API 稳定的情况下,团队之间很少需要协同。所以每个服务的维护者可以独立决定自己的发布流程和交付节奏。但是在互联网时代,为了最大化流量的传播,我们往往会通过一个大型商业活动来聚合和放大营销效果,比如 618 大促、双十一大促、春节红包、新品线上发布会等等。那么微服务相对独立自主的研发模式,对于制定跨团队统一流程和交付节奏就构成了一个巨大的挑战。
第三,分布式研发中心。互联网企业往往有多个分布在全球各地的研发中心。举个例子,我在 Lazada 做 CTO 时,我们团队分布在新加坡、印度的班加罗尔、越南的胡志明市,以及中国的北京、深圳与杭州。如果再加上需要协作的团队,分布就更广了。在这种跨国家、跨地域、跨语言的研发模式之下,每个研发中心内部可能有非常多的交流,但是各个研发中心之间的沟通,相比之下就是互相隔离的。时间长了,康威定律就开始发挥作用:“系统的结构和产生这些设计的组织的沟通结构是同构的”。也就是说,在我们不能改变一个组织的沟通结构的时候,架构活动产生的设计就会有很大的局限性。
第四,普遍存在认知差异:每个团队,甚至每个研发,平时都在自己的隔离环境下高强度地开发代码,所以大家一般没有统一的语言和全局的认知。这种情况在业务和产品团队也同样存在。因此,达成一个宏观的、完整的、可行的、被普遍认可的规划就变得非常困难。
第五,大型架构活动本身面临的挑战:在高风险和高回报预期的场景下,必须保障项目完成的高确定性和对目标的高保真性。互联网时代大多数公司都是在一个场景下通吃天下,所以一个大的架构活动背后的商业赌注一般会非常大。阿里巴巴的双十一就是典型的例子。在双十一的第一分钟,每秒就有几十万次的交易。而第一个小时的交易额接近 1000 亿,全天的交易额共有几千亿。如果双十一这天出了什么故障,不但影响投资者的信心,有些小企业也会因为备货太多销售不出去而在一夜之间破产。而且这个架构活动的交付日期根本没有变更空间,双十一之前必须完成。所以双十一那天必须保障业务和技术目标的高度保真。如此苛刻的要求也意味着巨大的成本。阿里相关技术团队为了准备双十一,大都从六月份就开始备战,接着是持续高强度的加班,直到双十一结束。有的方案甚至要在前一年的双十二做预演,第二年 618 时再做大规模尝试,最后到了第二年的双十一才全面铺开。虽然很少有架构活动能像双十一这样兼具高风险和高商业价值,但是几乎每个互联网公司的架构活动都面临着超高的风险、强度和复杂度。原因也很简单。如果一个架构活动不具备这样的性质,也没有一个超高预期的回报,那它就不会被提到一个足够高的位置上,公司也不愿意为这个架构活动配置专职的架构师,更不会大范围协调团队的优先级、投入多个团队的研发资源。取而代之的将会是敏捷的开发,用最小的组织、最短的时间成本、最少的代码迅速上线,在线上看效果。
架构师能在架构活动中起到哪些作用¶
第一,建设共识。架构师需要克服现有的分散的研发团队、普遍存在的认知差异、习惯于独立决策的研发团队所带来的认知局限,引导参与者在对架构活动的认知上达成共识。这里的共识包括对目标的共识、对决策方法的共识,对各自责任边界的共识、对资源分配的共识,以及对交付时间、内容和质量的共识等等。
第二,控制风险。架构师需要克服互联网企业在高度不确定性的商业环境、日常工作缺乏流程、团队成员高强度工作节奏和日常反射式研发所带来的混乱与质量问题,需要在架构活动的全生命周期持续收集、发现、评估、控制和传递风险。在持续变化的目标和竞争环境中不断提升对风险的理解,逐步完善预案。并在成本可控的情况下选择合理冒险,同时随时跟踪由外部环境和事件引起的风险变化,及时传递重大风险,最终把风险控制在可接受的范围内。
第三,保障交付。架构师需要尽量降低大型架构活动的不确定性和复杂度,最小化架构方案。要做到这点,架构师不仅需要提前行动,关注用户价值；还要不断提纯目标,保障交付的价值；以及,需要反复分解架构计划,持续去除盲区,提升 API 的鲁棒性。最后,以分领域、分阶段、最小化的交付来保障项目完成。
第四,沉淀知识。任何一个大型架构活动的背后,都有着巨大的时间成本、机会成本、商业资源和人力资源的投入。从这个视角看,架构师在架构活动中必须具备区别于其他参与者的宏观视角。一方面,需要完整记录架构活动的历史与决策逻辑；另一方面,需要通过文档来驱动理性思维,通过正式文档、Review 流程来提升企业的宏观思考与决策质量。最终,保证这些内容将会形成复盘的主要输入,为企业之后的类似活动积累经验。
备注
需要特别强调的是,这四个作用中,并没有包括写代码、项目管理、培训交流等工作。 事实上,这些工作往往占据了架构师的大部分时间。不过在我看来,这些工作都是为了服务于这四个作用。如果只写代码、只做项目管理,或者只做培训交流,在架构活动中都有专业人员可以轻松替代。但是通过这四个作用,架构师却可以创造出不可替代的价值。
架构师应该关注哪些关键节点¶
节点一:搭建架构环境。打个比方,架构环境是架构活动在企业真实物理环境中运行的虚拟机。我们的研发是在企业这个大的物理环境下进行的。这个物理环境包括决策环境、商业环境、软件研发环境、文化环境和有限的商业和研发资源等等。需要给架构活动搭建一个它自己的虚拟机,来模拟这些完整的环境。其中决策环境是更为重要的一环
节点二:确认目标。架构师不仅需要确认这个目标的赞助人,还需要确定目标是正确、合理、可达的,也就是一个定义清晰、满足 SMART 原则的目标。
节点三:可行性探索。这个环节的目标是,向所有合作方提前传递重大风险,并准备合适的预案,从而得到决策者的支持,以继续全力推进整个项目。当然,如果风险不可控,我们也可以选择叫停,避免重大损失。
节点四:架构规划。有了架构环境、确定目标和可行性探索的基础,我们就可以为架构活动做宏观规划了。这里有四个关键动作,分别是``统一语义``、
执行域映射、任务边界划分``和``规划确认。而这些动作的目的,就是进一步提升架构活动的高确定性和对目标的高保真性节点五:正式启动。启动,代表着合同正式签约生效。那么在正式签约之前,我们还有机会将之前未暴露的重大风险公之于众。这也是最后一个暂停或延后架构活动启动时间的机会。
节点六:阶段性价值交付。使用基于最小增量价值单元的交付策略,以保障架构活动的最终产出。
节点七:全面上线。
节点八:活动复盘和机会发现
节点四: 架构规划¶
架构规划之统一语义。统一语义的过程是一个循环往复的识别不同角色、不同场景、不同语境,然后逐渐建模、整合、修正语义的过程。直到所有参与者的需求能够被准确无损地表达、记录和传递,最终通过架构活动实现出来。
架构规划之需求确认和执行域映射。在统一语义的前提下,我们就可以确认架构活动的核心需求了。在架构规划之初,我们要梳理架构活动的用户角色,发掘每个角色的核心诉求,并从活动目标出发确认需求的正确性与合理性。同时,还要在统一语境下建立问题域模型,与执行者一起推导出从问题域到执行域的映射。在这个过程中,许多领域映射的冲突可能会被暴露,这个时候,我们必须及时将冲突上升,然后尽快解决,尽量避免将冲突带到任务边界划分中去。
架构规划之任务边界划分。任务边界划分是真正体现架构师思考力的地方,也是很多棘手问题集中爆发的地方。在这个环节,我们需要依照搭建架构环境的方法,先为团队建立一组任务边界划分的决策信条。接着,再进行用户需求和任务分解,尤其是对任务颗粒度的判断。最后,我们要确保任务相关的有限资源被提前锁定。
架构规划之任务规划确认。架构规划的最后一个环节是规划确认。在这个过程,我们需要把输入转成一个不但可行而且要有约束力的规划。除了要最小化项目交付风险外,还要确保所有参与者有能力、有意愿履行各自的责任,从而提升交付的确定性。
番外: 模块的学习建议¶
先固化,再内化,最后才优化。
初学时期,我会想办法把完整的流程多跑几遍,将每个节点及其底层逻辑烂熟于心。然后再根据具体项目、工作环境和参与团队来做精简。不要连基本的招数都没学会,一上来就想着无招胜有招。
在我们团队做规划时,我总会给团队 Leader 们一套固定的架构规划模版,帮助他们提升架构能力。一旦我看到某个人理解得很透彻,做得很到位。我反倒劝他丢掉模版。
16|通用技能.1:如何帮助团队达成共识与控制风险¶
建设共识¶
三个与沟通交流相关的重要挑战:
1. 分布式研发:日常工作中相对隔离的微服务研发模式；
2. 沟通障碍:分散在全球或全国多地的研发团队,以及由此带来的语言、文化和沟通障碍；
3. 认知差异:由于职能、工作背景不同而造成的认知差异,尤其是由于视角局限而带来的认知差异。
备注
达成一致的关键在于找到架构活动参与方的认知差异点,然后再想办法消除。
认知差异点的来源主要有三个方面:
1. 利益不同
2. 视角不同
3. 其他的内在差异。比如因为职能、工作背景和语言文化的不同
备注
这三种差异点的应对办法完全不同,其中利益差异最难解决。我们必须理解参与者的核心利益诉求,最终在一个相对公平且可以长期维持的机制下做利益边界的划分。
建设共识其实是个体力活。如果只做表面工作,拿一套 PPT 或者价值观来侃侃而谈,可能只需要半天时间。但如果想真正了解一个人的内心利益诉求,就需要在日常工作中下大量的功夫,建立信任关系。而且场景越复杂,人越多,那么需要投入的成本就越大。所以建设共识这件事,功夫要下在平时,而不是架构活动开始的时候。
控制风险¶
在架构活动的全生命周期里,架构师都需要持续收集、发现、评估和控制风险,把风险控制在可以接受的范围内。
三个关键动作:
1. 逐渐形成量化认知
2. 可以冒险
3. 但不能不说
第一个关键动作是逐渐形成量化认知。发现和评估风险是个极其耗时间的过程。在互联网企业,不仅每天都有新风险,而且现有的风险还在不断变化。要是把风险评估作为一次性的前置环节,不仅会占用大量宝贵时间,也不能有效控制风险。所以成本更低的做法是搭车制。意思就是架构师要在架构活动中持续预留一部分(比如 5% )的精力。任何时候都先关注已知的最大风险,然后随着时间的推移,不断对这些风险形成更深刻的认知。而这些更深刻的认知,最终也将转化成一个能够准确量化的风险控制成本和企业的预期损失。
第二个关键动作,可以冒险。在架构活动中,如果我们发现了一个风险,也对损失有了一定的预估,并准备好了预案以响应不确定性事件。这个时候,就可以 “冒一次有准备之险”。
第三个关键动作是不能不说。架构师的权责,还没有大到可以代替公司去决定风险政策的地步,所以必须向上及时传递重大风险和冒险行为,而不是直接采取冒险行为。。
备注
明智的冒险会带来价值的回报。冒险是有代价的,但我们作为架构师就是要对这个代价了然于胸。在互联网时代,竞争的压力意味着我们永远都不会有充足的时间去量化风险和设计预案。所以对风险的判断,是一项非常有价值的个人能力。
17|通用技能.2:架构师如何保障交付与沉淀知识¶
保障交付¶
保障交付意味着架构师能够降低大型架构活动的不确定性和复杂度,最小化架构方案,最终保障高质量的交付。
关键动作有三个:
1. 降低不确定性
2. 控制复杂度
3. 最小化架构方案
降低不确定性:
a. 目标的不确定性 详见18讲 b. 资源的不确定性 尊重人性,发掘参与者的利益诉求,最大化参与者的个人投入度 当架构目标与参与者个人及其团队利益并不完全一致时,就需要投入额外的激励来保障他们的投入度 在互联网的研发环境下,只要是有限的资源,最终都会变成稀缺资源 => 盘点并保障好稀缺资源的供给,对于项目的成败非常关键 c. 商业与技术环境的不确定性 => 最好的办法就是在缩短阶段性交付周期的同时,增加技术方案的抽象性 d. 用户需求的不确定性 => 除了从人性出发的设计思考外,还可以基于增量价值来交付单元
复杂度控制:
复杂性和不确定性的区别: 不确定性是指问题随时间推移,发生了不连续的、不可预测的变化。 复杂性则强调问题或者解决方案,很难用几个简单的维度去描述。 a. 从问题域层面分解架构规划和交付方案 b. 增加架构设计方案本身的结构性 c. 按照多种方式分割交付模块最小化架构方案:
=> 最小且必要原则,是提升交付成功率的最重要的方法
沉淀知识¶
在架构活动中,架构师有着区别于其他参与者的宏观视角,因而有必要通过有效的知识沉淀来保障架构活动的思考与决策质量,也有必要为企业未来的架构活动提供宝贵经验和方法论。一方面,架构师需要沉淀完整和真实的过程记录。另一方面,还要为企业注入逻辑思考,引导企业走向正确的决策。
备注
沉淀知识是通过各种文档工具、设计工具、沟通工具和复盘工具,为架构活动注入理性思考。
收集整理和编写文档,是一个数字化镜像的过程。真实世界的行为发生在前,数字化的过程发生在后。这是一个被动的过程。
注入理性思考的过程,是靠文档中的严密逻辑来驱动理性思考的过程。文档和设计发生在前,驱动我们及其他参与者理性的、基于事实的思考和决策,以期改变真实世界。这是一个主动的过程。
在被动的过程中,架构师就像一个自动化埋点和日志收集系统,忠实地记录着项目过程中的所有行为、现象和结果。
在主动的过程中,架构师更像是一台计算设备,通过文档来驱动架构活动参与者的思想实验,通过理论推演来提升思考质量,而不是通过写代码、发布、线上试错来完成架构方案的迭代。
在第五讲提到的性能优化的案例吗？在我们还没有动手改代码之前,我就先定义了性能损耗这个概念,在文档上推演和证明了性能损耗的公式,又在白板上讨论了不同页面、不同场景下的实际度量办法,等等。这个由文档推动的思想实验,使得我们出手之前就已经对它能产生的价值成竹在胸。
备注
一个理想的知识沉淀的过程,不仅包括一个被动的、通过文档来记录活动历史的过程,还包括一个主动的、通过文档来驱动思想实验的、创造历史的过程。
评论¶
卡尔·波普说,只有写下来的东西才是能够批判的东西。我们人脑并不是一台逻辑引擎,它只是一个信念和证据反复迭代的玻尔兹曼机,一个模式工具。我们头脑混乱、冲突却可以自以为和谐地相处,直到它被写下来接受自己的,他人的,历史的批判。
问一下老师,在加入一家新公司时,大约需要多长时间可以对这家企业的业务模式和技术架构有非常清晰的认识。=> 我过去一般不仅仅是进入一家公司,而是换一个行业。换了好几个行业了。 我进入之后,三个月之内不会有任何管理动作, 一般都是观察和理解。 三个月以后我会小范围出手,在我之前有经验优势的领域做一些团队和架构的建议。 然后看数据效果。 这时间开始我逐渐对我比较熟知的领域会有自己的决策建议, 但是不会行驶我的否决权。 我一般在一年到一年半之后形成自己的认知,会行驶否决权。也就是我对一个产品技术是否是公司现阶段所需要,有比较强烈的观点。
数据的最大价值体现在运用,而不是存储,如何真正地去运用文档、沉淀知识？=> 文档的召回其实非常关键。 不过我倒是觉得类似平台模式的机制, 也就是一个链接创作者和消费者的文档管理平台, 来提升一个组织内知识传播和利用是很高效的。 平台提供文档检索、推荐、标签、反馈机制（点赞/阅读数量）和激励机制, 通过时间沉淀高质量的创作者、知识、传播链已经被证明有效。 个人层面的知识积累我觉得更多要关注ROI, 而不是文档这样的技巧。
知识很多, 但是能够为你创造短期和长期价值的其实不多。
18|节点一:架构活动中为什么要做环境搭建¶
架构环境的完整定义：指的是在企业的商业、技术和文化环境中,架构师为架构活动所搭建的虚拟的工作环境,包括决策环境、激励环境、资源环境、团队构成、物理和虚拟的工作空间等。
环境搭建前的准备工作¶
使命 是一个企业存在的意义。
愿景 是对使命在不远的将来所能达成目标的一个具象化描述。对于一个企业而言,愿景是企业对中长期目标的相对清晰的描述。这也是我们衡量架构活动对企业价值创造的一个核心依据：架构活动对企业实现愿景的直接或间接贡献到底有多少。
价值观 是我们在多个选项中做权衡的决策依据。它强调在两个利益相冲突时,我们该如何做取舍。
环境搭建过程中的关键工作¶
决策环境：在多个参与方 / 团队无法达成一致或者产生冲突时,通过投票、把冲突向上升级、决策者拍板等方式,确保参与者能解决冲突,迅速拿到决策。注意,这里并不是要达成共识,而是拿到一个大家必须遵守的决策。
激励环境：能对参与者产生驱动力的激励,一般是额外的物质和精神上的奖励。比如我们在第 16 讲提到的通过双倍工资的激励,的确会大幅提升参与者的投入度和合作态度,提高活动成功的概率。
资源环境：企业中留给架构活动所支配的资源非常有限,这是架构活动的主要约束条件。
团队构成：参与架构活动的成员和团队大致构成。我们需要通过这个条件来确定架构活动的可行性。
工作空间：指物理上的工作空间。比如让所有参与者在同一个办公区内,或者建立一个虚拟的线上社区。这种空间会促进参与者之间形成深度交流,减少误解,以便及时解决问题或冲突。
王道: 如何搭建一个安全高效的决策环境¶
19|节点二:架构活动的目标为什么常常被忽略¶
架构师在目标确认这个节点上,不仅要保障目标的正确性和合理性,还要保障目标的可达性。也就是说,目标确认是以终为始的。
首先是目标正确（Correct）
其次是目标的合理性（Reasonable）, 指目标的设置是合理的：既具备足够的挑战性,但是又不会引起大面积的动作变形。
最后是目标的可达性（Achievable）,指目标最终可以被实现。
目标的正确性：站在企业决策者的角度去思考目标,从而帮助决策者做出正确取舍。
目标的合理性：以执行者的角度去审视目标,从而以乐观的心态给团队设置一个能带来成就感的合适的挑战。
目标的可达性：以赞助者的视角去审视目标,从而以悲观的心态来确保投资在重大风险发生时也能有回报。
目标确认需要从不同的视角来完成,其中最重要的三个视角分别是决策者、执行者和赞助者：要从决策者的视角来看目标是否正确,从执行者的视角来看目标是否合理,从赞助者的角度来看目标是否可达。
架构师在目标确认过程中的工作¶
目标的描述要符合SMART原则：具体（Specific）、可度量（Measurable）、可达（Achievable）、相关（Relevant）、有时效的（Time-bound）。
几个描述比较清晰的目标:
1. 三个月内,把 90% 的商家发布商品的时间,从平均每件 30 分钟降低到平均每件 1 分钟以内。
2. 三个月内,把导购下单的核心链路稳定性从三个九提升到四个九。
3. 12 月 31 日以前,完成电商、云、跨境业务的合规审计中所有高优先级整改项目。
20|节点二:架构师如何为企业找到一个正确的目标¶
目标的正确性¶
一个正确、合理且可达的目标,是靠多个职能之间反复讨论和反复演算得到的。这是一个发现的过程,而不是一个拍脑袋决策的过程。
目标的合理性和可达性¶
这个验证过程是一个快速的、基于经验和思想实验的判断,而不是一个耗时巨大的工程。
完成目标确认¶
完成目标确认后,有两个可能的结果,一个是输出符合 SMART 原则的正确目标（请参看第 19 讲）； 另一个是说服相关方放弃不正确的目标,重新设立一个正确、合理和可达的目标。
21|节点三:如何通过可行性探索来帮助架构活动避免重大失误¶
可行性探索是架构师帮助企业避免重大方向失误的最后一个节点。
什么是可行性探索¶
以我的个人经验来看,能达到既定目标的架构活动还不到十分之一,多数架构活动都是以失败收场。
可行性分析（Feasibility Analysis）是一个非常耗时、详尽的评估活动。然而互联网时代,重在行动,所以我们用“可行性探索”这个词,来特别强调在这个节点上要控制成本,尤其是时间成本。
在互联网时代,可行性探索过程的王道就是从项目赞助者的视角出发,在赞助者的风险承受度之内做理智的冒险。
小结¶
回顾架构活动最初的两个环节,一个是搭建架构环境,目标是建设一个安全的决策环境。另一个是目标确认,目标是锁定架构活动的目标是否正确、合理和可达。这是非常轻量的节点,除了架构师之外,公司还没有投入任何研发资源。
22|节点三:什么样的风险才算是重大风险¶
这个节点的重要价值在于你怎么帮助企业避免重大损失。在可行性探索的过程中,你需要站在赞助者的视角上,尽量发掘重大风险,寻找有效预案,确保项目目标最终的可达性。
备注
这是所有节点上,最后一个能够以相对较低的成本来避免损失的机会了。这个过程,并不需要花费很多时间,也不需要很多人的参与。重要的是你和活动参与者把注意力放在重大风险上。
你要形成完整的、全局的、量化的风险评估和重大风险列表,并及时与执行者、赞助者做沟通。最终,你需要站在决策者的视角上,以相对乐观和敢于冒险的心态,做出可行性的建议。
23|节点四:架构规划之统一语义¶
对于架构规划而言,统一语义的终极目标只有一个：项目所有参与方的需求能够被无损地表达、记录和传递,然后通过架构活动实现出来。
如何消除语义的分歧¶
第一步,发现不同的语境。
第二步,定义概念。
第三步,语义建模。建模过程中最难的一步,就是从不同语境中的主体那里,推导出一组统一语境中的实体。
第四步,反馈修正。
第五步,公布、维护和使用统一的语境。
24|节点四:如何减少语义上的分歧¶
作为架构师,所做的工作并不是收集汇总,而是发现不同的语境,找到其中存在的语义上的差异。然后把这些差异描述出来,再给出一个精确的语义定义。最后再和其他参与者一起使用这些更为准确的概念,来完成项目的规划和实施。这才是你在这个节点上真正要创造的价值。
25|节点四:架构规划之需求确认¶
需求确认前的准备工作¶
从产品定位的角度来梳理:
1. 客户
2. 用户
3. 核心场景
从执行者定位的角度来梳理:
1. 执行团队
2. 执行域划分
3. 需求承接方
取舍规则:
1. 需求优先级的决策信条
2. 必保需求
3. 隐含的技术需求
问题域划分¶
绿色,代表数字和实物商品整合之后的商品域；古铜色,代表实物商家域；蓝色,代表发行商域；紫色,代表货品和履约域；而黑色的部分,则属于数字商品域。¶
多数时候,问题域和执行域都是同构的,当然也有粒度不同的情况存在:
1. 在一个合并后的公司里,你会看到一对多的情况
2. 在一个收缩的公司里面,你会看到多对一的情况
3. 在一个架构和管理混乱的公司里,你也能看到多对多的情况
备注
问题域和执行域的划分,不能靠你这个架构师的想象。而必须在多方的参与下,对事实形成一个准确的描述。
从项目目标到需求的映射过程¶
评估需求¶
备注
需要准确区分最小必要的需求和无关紧要的需求。只有那些与项目目标形成因果关系的强依赖需求,才是属于架构活动的需求。
关注点应该放在如下五个方面:
1. 需求的必要性
2. 需求的正确性
3. 需求的合理性
4. 需求的可达性
5. 需求的承接方
砍需求是个非常得罪人的事情。你做这件事情必须要有个同盟,也就是与需求对应的、问题域映射到执行域的负责人。因为在砍掉不必要的需求上,你们两个人的利益是一致的。你为了整个架构活动的成功,他则是为了控制自己领域的风险。你可以站出来表达比较客观的立场,而他则可以帮助你证实这个立场的合理性。
需求到承接的映射¶
从目标到问题域再到执行域的映射大图¶
问题域和执行域中的冲突¶
架构活动中最常见的七种冲突:
1. 优先级的冲突
2. 定位的冲突
3. 团队和个人的冲突
4. 边界冲突
5. 问题域到执行域的映射关系的冲突
6. 生存空间的冲突
7. 决策权的冲突
从问题域到执行域的领域边界划分¶
在架构活动中你可能面临如下四个棘手的问题:
1. 多个团队争夺有限的资源
必须在这个时间和赞助方、决策方、参与方讲明白。
要么调整质量预期,要么调整上线时间
2. 多个团队争夺生存空间
务必请决策者迅速裁决,因为这是没办法调和的冲突
3. 无法调和的个人与团队之间的矛盾
躲开才是上策 or 请决策者进行处理
4. 短期内不合理的组织和决策结构
请相关参与者和决策者一起,来制定和确认一些决策信条
备注
总的来说,执行域划分是个压力非常大的环节。你这个架构师必须保持开放心态,要充分表达,大胆建议。不过也要注意,你并没有决策权,因为你能提供的仅仅是技术视角,而不是整个企业的视角。
26|节点四:任务边界划分应该遵循哪些信条¶
信条一：任务边界可以打破现有的执行边界。
信条二：任务边界划分有确定的决策优先级
信条三：最小化架构目标之外的抽象
信条四：任务边界划分时要最大化隔离
信条五：任务边界划分要面向未来最优
备注
总的原则是,在任务边界划分的过程中,从用户需求出发,在架构目标统一的信条下,最终达成切实可行的、从需求到任务到承接关系的划分。这才是边界划分的王道。
如果信条无法在限定时间内完成划分,那也可以采用霸道的方法。请决策者把任务强制部署下去,靠一些额外激励或者惩罚手段来达到目标。在这个阶段,时间非常宝贵,你不能耽误太久。
27|节点四:架构规划之划分任务边界¶
备注
总体而言,我个人不太主张在任务梳理、粒度控制和任务分配环节里,有太多的脑暴和发散。因为此时此刻,我们已经进入到执行环节了,那么就要尽量减少分散注意力的动作,尽快作出决策。
边界划分和任务分配¶
两个比较重要的结论:
在独立性假设之下,任务分配是个局部优化的过程,所以不需要在全局上做优化。
在独立性假设之下,真正导致失败的正是你的最软肋,也就是架构活动中成功概率最低的强依赖。这是架构师最重要的关注点,而不是大家都在注意的光环点。
评论¶
准确计算这些公式里的概率很难,因为我们是在预测一群人去交付一项他们之前没有执行过的任务的成功概率。
最难的部分是怎样估算出把一个任务分给某一组执行者成功概率
28|节点四:架构规划之确认规划完整性¶
是控制风险的重要机会。
是保障交付的重要手段。
是为团队和企业沉淀知识的重要时机。
备注
规划确认过程中的每一个交付项,比如用例文档、必保任务、领域模型、API 设计、消息和数据流、整体交付节奏和完整性验证等,都指向同一个目的,即提升交付的确定性。这也是架构规划的实质。
组织用例文档¶
备注
关注商业价值是架构师最重要的生存法则之一
用例文档是关于交付内容的最简洁的描述。它的作用是描述架构活动中某个团队或者小组要为某个用户角色,在某个场景中,创造出某种价值。
如：商家团队要为中小商户,在店铺经营过程中,提供有明确行动点的生意参谋功能,从而提升商家的经营效率和成交额。
需要格外注意的是,无论是写用例,还是用一张图来表示用例,都需要避免堆积。在一个架构活动中,不论是十个人还是上百人参与,最顶层的用例最多也不能超过十个。
可以把这些用例组织成一个树状结构,从粗到细有数百个节点。但是到了最顶层,节点最多不能超过十个。这些节点,是你作为架构师所要保障交付的价值,因而必须跟架构活动的目标相匹配。
这些用例描述的作用是,确保所有研发人员都能对各自所交付的单元目标有清晰的认知。
29|节点五:项目启动仅仅是一个仪式吗¶
在项目启动环节,我们真正想达到的是深度握手。各个参与方对所达成的架构目标、架构方案、架构环境、任务边界、交付节奏,以及资源投入,完成一次有约束效应的正式握手（Acknowledgment）。
30|节点六:如何保障高质量的阶段性交付¶
项目经理的工作就是将项目分割成几个更小、更容易跟踪和管理的交付模块,以降低团队之间的耦合,最大化项目成功的概率。经常会采用分时间段交付的方法来降低交付的风险。
作为架构师,我们对整个架构活动的目标、商业价值、用户价值了然于胸,清晰地知道用户价值点。架构师的注意力却要放在高用户价值点的任务交付上。
备注
【架构师的核心关注点】我们架构师要把注意力放在交付的增值上,而不是交付功能或者交付代码上。
那些职业非常成功的人,往往都是在更值得关注的事情上,做出了独到且高回报的决策。反过来,许多职业上不太成功的人,一个显而易见的共性就是相信“勤能补拙”,靠大量不分重点的高强度投入,试图补救决策上的短板。
31| 节点六: 如何组织阶段性的价值交付¶
这节课讲了怎么从架构师视角来组织阶段性的价值交付。
32|节点七:什么是有价值的复盘¶
备注
复盘,特指通过还原并深度思考架构活动的完整历程,来寻找可以提升未来架构活动成功概率的过程。
复盘的目的：寻找可以提升未来架构活动成功概率的机会。
复盘的对象：复盘的对象不仅包括失败案例,还包含成功案例。
复盘的视角：复盘可以有多个视角：一种是对他人的审视；一种是对自我的审视；还有一种是上帝的视角。
对他人的审视,简单来说就是一句话：谁造成了我的失败？
对自我的审视,简单来说也是一句话：我什么地方做得不完美？
33|节点七:怎么样做好一个有长期收获的复盘¶
复盘过程一般由如下六个环节组成:
1. 回顾架构活动
2. 搭建复盘环境
3. 梳理机会点
4. 挖掘根因
5. 寻找新的模式与机制
6. 产出跟进项
34|模块小结:架构师如何在架构活动中持续创造价值¶
架构活动总览¶
架构活动的四个核心角色,分别是决策者、赞助者、执行者和架构师。架构师的作用贯穿架构活动的整个过程,是架构活动的设计者、规划者和执行保障者。我用底部的绿色条,来表示架构师在架构活动中持续创造的价值。即：通过持续发掘和评估重大风险,来控制整体的交付风险；通过分析和解决差异点,促进尽可能多的参与者达成共识；通过不断分解问题,保障增量价值的交付；通过持续的文档沉淀,从而驱动科学的决策。¶
两个目标确认点:
1. 一个是在目标确认环节
2. 一个是在项目上线环节
三个放弃点:
1. 入口一是风险决策的时候,指的是发现无法控制的重大风险。
2. 入口二是架构规划确认的时候,指的是发现架构规划无法满足预期目标。
3. 入口三是规划正式确认的时候,指的是发现执行计划存在重大风险,无法满足预期目标。
四个主要角色:
1. 决策者
2. 赞助者
3. 架构师
4. 执行者
编辑加餐|十张图,带你回顾架构活动的完整过程¶
节点一：环境搭建¶
节点二：目标确认¶
节点三：可行性探索¶
节点四：架构规划之统一语义¶
节点四：架构规划之需求确认¶
节点四：架构规划之规划确认¶
节点四：架构规划之任务边界划分¶
节点五：项目启动¶
节点六：阶段性价值交付¶
节点七：复盘¶
03模块三:职业成长 (9讲)¶
35|模块导读:回过头来看,你觉得架构师到底是做什么的¶
架构师的定义¶
“A software architect is a software development expert who makes high-level design choices and tries to enforce technical standards, including software coding standards, tools, and platforms.” ——Wikipedia
“a person holding this position drives all critical decisions about the organization of the software system.”——Indeed
“A software architect defines software architecture.”——MSDN
软件架构师是一个复杂软件系统的设计者和规划者。——从架构师（dictionary.com architect）一词引申而来
软件架构师是软件架构活动的定义、规划和实施保障者。
软件架构师是一个以软件架构能力谋生的人。
软件架构师是一个具备软件架构能力的人。
软件架构师是一个主动的软件架构设计者。
架构师是一个具有架构思维的人。
备注
【定义】在一个充分竞争的市场里、在高度不确定性的商业环境中、在有高度的业务复杂度的情况下,引导整个企业的研发团队持续优化一个软件体系并且最终因此而带来企业成功的能力。
架构师的能力维度¶
架构师职业成长的五个阶段覆盖的五个核心的能力维度:
1. 结构化设计
2. 解决横向问题
3. 解决跨领域冲突
4. 正确的技术决策
5. 创造生存优势
36|能力维度一:如何提升结构化设计的能力¶
什么是结构化设计能力¶
在程序员时,可以在自己的决策范围内,也就是自己写的代码里面,寻找并给出结构化的解决方案。程序员对代码几乎偏执的洁癖就是对于结构性（Structuredness）的追求。这种追求,在一个程序员的职业发展中是具有连贯作用的。从程序员到 CTO,刚开始可能是对代码结构性的追求。随着职业的发展,这种结构性会扩展到更大的范围和更广的维度中,甚至延伸到公司软件研发的各个方面。最终,代码洁癖就会演变成对于软件系统甚至研发组织结构性的执着,而这种执着也会固化成对软件结构性的识别、改进和设计能力,贯穿整个职业生涯。
如何提升结构化设计能力¶
提升结构化设计能力的起点,其实就是代码的结构性。不过在结构性之前,还有个更朴素的起点,就是代码的整洁性。
对代码整洁性帮助很大的就是设计模式。设计模式的主要价值包括三个方面:
1. 沉淀经验 => 遇到某种场景,就采用某种设计模式 系统化且高效借鉴他人成功经验的过程 2. 传递设计原理 => 对代码背后思考的一种标准化注释 通过规范化的设计语言表达了自己的思想 3. 降低理解和维护代码的门槛 => 如果实现中经常采用常见的设计模式,就会大幅降低其他人理解和维护你的代码的成本
结构化设计过程中的具体关注点¶
想做好结构化设计,应该具体关注:
1. 设计理念
整体设计需要与公司或部门的理念保持一致:
整个公司都采用分层架构,那么你的设计也要尽量采用分层架构
整个公司都采用微服务的设计理念,那么你的设计也要采用微服务的设计理念
2. API 的结构性
API 的结构性体现在三个方面:
a. 语义表达的结构性
b. 功能组织上的结构性
c. 数据模型的结构性
3. 模块内部的结构性
a. Package Hierarchy 和 Package 的设计,体现了你对领域的理解和对领域的封装
b. Interface 的设计,体现了你对一个领域对外服务的理解
c. Class 的设计,体现了你对实体、状态和数据模型的理解
d. Function 的设计,则体现了你对计算封装的思考
37|能力维度二:如何提升解决横向问题的能力¶
备注
横向问题,简单来说就是软件系统内部与业务无关的技术债,比如性能、可扩展性、可用性、可测试性、可维护性和安全合规等问题。这些问题都属于非功能性需求
技术债的产生一般有两个原因:
你与周围同事在横向问题领域内有认知盲区
由于日常研发过程中的优先级取舍,导致一些技术债被短期搁置
六条经验原则:
1. Trust none！
2. Only rely on the most reliable.
3. Everything decays, especially data.
4. When it comes to survival, everything can be downgraded.
5. Availability without cost consideration is bullshit.
6. Save yourself!
38|能力维度三:如何提升解决跨领域冲突的能力¶
跨域架构师为多个子域的软件结构的合理性负责。跨域架构师是为冲突而生的,负责处理一个组织内在的,也就是局部和全局之间的冲突。跨域架构师的存在,是异构组织的需要；是因为某个领域内部的短期目标,与更大领域或者更长期的目标不一致。而这个冲突必须从更高层面看清楚,并结构化地解决。
一个跨域架构师的存在,就是让跨领域的结构性风险降到最低。你要通过设立跨领域的沟通和冲突解决机制,让不同子域的决策者和执行者能够预见、避免,并最小化子域与全局之间的冲突。此外,还要通过统一全局目标,引导所有子域整体的结构性。当然,更需要有足够的勇气去发现、面对和解决这些冲突。
39|能力维度四:如何从做技术到为企业创造生存优势¶
总架构师和 CTO 这两个角色上在决策角度的差异性。
总架构师的技术嗅觉非常重要,他要为整个公司软件架构的合理性负责,要面向未来的技术不确定性作出正确的判断。
CTO 的商业嗅觉更重要。技术不是 CTO 决策的第一优先级,企业的长期生存才是。
40|职业成长.1:架构师成长的必要条件是什么¶
架构师成长的五个阶段：在程序员阶段,主要关注需求实现的结构化,也就是一个模块内有关业务的部分。兼职架构师阶段,主要关注模块整体,以及与业务无关的横向问题。跨域架构师阶段,主要关注不同模块间结构合理性的问题。总架构师阶段,关注技术架构的长期正确性。CTO 阶段,关注企业的长期生存。¶
必要条件之一：思考力:
通过`独立`思考带来`有效`结论的能力。
必要条件之二：信息内化能力:
信息优势,就是你所在的环境有大量高质量的`信息`,或者你获取这些信息的能力比别人强,渠道比别人多
内化,是指能够从这些源头中有效总结,比别人积累了更多的`知识`
信息内化的过程,也就是从接触信息到消化吸收成个人知识的过程。
如果能更进一步把这些知识系统性地表达出来,你就是一个很了不起的知识传播者了。
大厂更有利于增加深度,小厂更有利于拓展宽度
如果你在大厂里,就要多解决难题,把这种信息优势转化成某个领域的深度。
如果你在小厂里做事情,就要把小厂提供给你的信息优势内化成所在领域的宽度。
必要条件之三：适应力:
所以架构师成长的一个必要能力就是适应能力 （Adaptivity）。
在不同的成长阶段,根据环境和场景不断调整和扩大自身的能力维度,目标是最大化自己的产出,以及对企业的增值。
程序员到 CTO 成长过程中所要经历的能力变迁：这些能力大致分为四组：第一组是伴随职责而扩大的岗位技能；第二组是个人技能；第三组是管理技能。第四组,每个角色的工作范围、工作重点和核心能力¶
备注
所谓战略,就是根据长期目标做合理取舍,要主动放弃一些能力,然后才能专注在另外一些能力上。
41|职业成长.2:架构师成长的充分条件是什么¶
架构师成长的充分条件:
1. 大量高风险的决策机会
2. 对架构师友善的环境
3. 正确的目标
一个公司中架构机会的密度与以下几个因素有关:
1. 赛道的竞争激烈程度
在一个竞争激烈的赛道上,短时间内会有大量新技术和新模式涌入,变化迅速
在一个硝烟散尽的赛道上,技术的迭代将会逐渐停止
2. 公司的成长阶段
一个处于成长期的公司中会有非常多的机会
一个已经开始老化的公司不但没有好的机会,甚至会非常糟糕
3. 公司的技术空间
在大多数公司和行业里,技术都是靠提升效率来创造价值:
一个人均交易额越大的公司或部门,技术的投入相对来说增值越多,机会就比较大
但是这种提升机会是逐渐收缩的,越到后期机会越少
例：现在互联网公司全年通过搜索推荐算法优化带来的大盘转化率提升已经很小了
也就是说这个领域的技术机会已经基本枯竭了
4. 部门内软件系统的成熟度
软件也是有生命周期的。
如果是一个刚刚诞生的软件,到处都有决策机会。
但是一个已经要老去的系统,不但没有决策机会,甚至会反过来霸占原本属于新生软件的机会。
对架构师友善的环境,需要做到如下三项:
1. 相对宽裕的决策时间
2. 对架构师意见的尊重
3. 对错误决策有足够的包容度
42|职业选择: 我应该去哪种类型的公司工作¶
随着企业的发展,其内部的机会密度会如何变化¶
选择行业要比选择企业更重要！当整个行业处在初创期和成长期,机会密度会一直维持在较高的水平,那么你最好的职业决策,就是在这样的行业里寻找一个高速增长的成长型企业。
43|模块小结:什么是架构师成长的关键能力¶
首先是程序员 / 代码的结构性,这是软件结构性的最小起点,指的是每个程序员提交的代码在设计上的一致性。
然后是兼职架构师 / 横向问题的解决方案
接着是跨域架构师 / 整体的解决方案
接下来是总架构师 / 决策原则
接下来是总架构师 / 决策原则
04模块四:思考力 (11讲)¶
44| 模块导读:假如我只能向上帝要一个技能¶
独立思考¶
首先是独特的视角。架构师经常需要以异于他人的视角来思考问题,比如我们在讨论跨域架构师时提到的全局视角,在讨论生存法则时候提到的人性视角,在讨论 CTO 角色时提到的企业长期生存的视角,等等。
其次是独立的证据组合。当选择好一个或多个维度切入思考后,选择的证据组合同样会对结论产生巨大的影响。
最后是独特的思维方式。每个人的思维方式都不一样,有的人喜欢在别人逻辑推导的基础上发现漏洞,并试图修复优化；有的人喜欢对问题进行层层分解,自己独立得出结论；也有的人喜欢从其他学科中寻找类似的问题,从而发现新的解决问题的思路；还有的人喜欢在跟别人的深度讨论和辩论中逼近真理。通常来说,不同的思维方式会带来不同的推导路径,从而得出不同的结论。
架构师这个职能有必要存在吗¶
架构师对公司而言,消耗的最大成本是人才培养的机会：同样一个架构决策机会,如果长时间交给同一个人做,其实也就剥夺了其他技术人员的决策机会。
备注
架构师所创造的长期价值,要大于公司对他的各种形式的投入。架构师必须选择一个以持续创造增值为目的的思维。
关于提升思考力的建议¶
这个模块将会讨论以下内容
第一部分,架构师的思维定势：思维定势指的是架构师在思考过程中的基本假设。从某种角度来说,思维定势就是你选择相信什么,或者说你在架构师的生涯中坚信和奉行的那些“主义”。
第二部分,架构活动中的思考维度：在一个具体的架构活动中,随着架构活动的推进,架构师能贡献的价值也在发生变化。因此,在架构活动中的不同生命周期,我们就需要不同的思考方法。
第三部分,判断思考的质量
第四部分,思考案例
45|思维定势.1:价值思维和实证思维¶
思维定势与思维模型¶
思维定势指的是当我们面临一个问题或一组选择时,所采取的固定的前提假设和思考路径。
思维模型指的是某种特定的思考过程,它是一种具体的思考方法。
过程正义的价值思维¶
备注
价值思维：具体的方法背后,如果说有一个思维模型贯穿的话,即架构师的每一个决策信条和最终行动,都要最大化自己为企业创造的长期价值。
架构师要面向组织、技术环境和商业环境的未来做最优设计。架构师应该是一个价值投资主义者,要尽可能地把软件架构设计和架构活动的重点,引导到未来 ROI 最大的方向上去。
架构师要有全局的理解和面向全局最优的决策原则,因此要对抗来自细分领域的短期行为和局部最优的决策。
架构师要通过提升软件系统的结构性,为公司创造更好的外部适应性,因此要对抗细分领域中因相对独立的研发决策而导致的熵增过程。
实证思维的思维模型¶
通过什么样的思维方式才能保障自己能够持续创造价值呢？答案是靠实证思维。
模型是实证思维的一个重要组成部分,意思是对现实的近似和抽象。一个好的模型,可以帮助我们更透彻地理解影响现实的不同因素,发现并确认其中的本质规律。而从这些规律推导出的结论,则对实践起指导作用。
模块一就是对一些基础规律的总结。因为这些规律对于架构活动来说具有普遍适用性,所以学习它们会帮助到你未来的架构活动。
模块一中的法则就来自关于模型的假设:
1. 架构活动是可以被建模的,这个过程会形成一组抽象的模型。
2. 从抽象的模型中可以推导出一些规律来指引我们的决策和行为。
3. 这些在规律指导之下的决策和行为,当应用到真实世界的时候,比缺乏规律指导的成功概率更高。
备注
模型思维的最核心理念是思考必须从模型开始。这个模型可以不完美,但不能不存在。之后就是以实证思维的方法不断修正对现实世界的抽象模型。
例-马斯洛的模型：对架构活动参与者的预期行为进行建模的过程,是对写代码的人的行为的抽象
例-域模型：对架构活动中具体的设计场景进行建模的过程,是对代码的抽象
模型最重要的特征在于它可以被证伪、被比较和被评估,这种评估甚至可以被量化。正是因为这些特征,模型才是可以被不断迭代和优化的。在同一个场景之下,最终胜出的模型只有一个。这也是为什么我认为架构是科学,而不是艺术。作为架构师,我们所追求的那个终极模型,就是在实践应用中被证实是更健壮（Robust）的模型。
实证主义¶
第一个特征,一个基于科学理论是可以被独立表述的。架构原则、设计模式和思维定势都属于这一类,重点是这个理论是独立于实践而存在的,能够被单独抽象出来,而且被表述出来。
第二个特征,这些理论是有一定的逻辑结构的,是完备和自洽的。举个例子,在完备性上,我们的架构法则试图覆盖所有影响架构活动的核心因素,但是它们在自洽性上,其实缺乏论证。
第三个特征,这种理论可以被浓缩成一组公理。通过这组公理和严格的逻辑推导,可以推导出其他的行为规律。公理越是简单,越是普适,规律本身的价值也越大。
第四个特征,这些理论是普适的,是可以复现、迁移的,也是可以被比较和验证的。实证思维是科学思维,一个理论要公开地表达出来,接受不同时间地点、不同场景、不同使用者的检验,才能够逐步提升。
小结¶
第一,企业需要架构师创造价值,且架构师是通过他人间接地实现增值的,因此架构师创造价值的方式是过程正义的价值思维。
第二,架构师创造价值的手段,是以实证思维的方法不断修正对现实世界的抽象模型。
这两个思维定势都是以企业的视角来谈架构师定位的。也就是说,架构师在一个企业的长期存在,要靠自己的持续增值来保障。
这两个思维模型,都是从企业视角推导出来的架构师所必须具备的思维定式。
46|思维定势.2:去中心化思维和成长思维¶
备注
上节描述了架构师应该具备价值思维和实证思维,从而最大化自己的生存。本节讲从架构师的角度来思考,必须具备这两个思维定势才能达到我们上节课提出的目标（决策信条和最终的行动）：去中心化思维和成长思维。前者可以提升架构师做事情的成功概率,后者可以放大他个人成长的机会。
去中心化思维¶
【定义】去中心化思维：指的就是引入更多的人,从更多的角度去思考同一个问题。这种思维方式是相对于中心化的思维而言的。后者是用尽量少的人,通过更频繁、更深层次的交流来统一认知后再思考问题的过程。
架构师这种去中心化思维并不等于无组织的发散性思维。去中心化的思考是在统一目标的约束之下完成的。在这个过程中,架构师的核心价值就在于定义统一的目标约束。
贯穿职业生涯的成长思维¶
【定义】成长思维：是以最大化能力成长为目标的职业选择思维。
这是一个基于冒险精神的思维方式。这种思维有这样一个假设：架构师无法在一个舒适的环境下最大化个人成长。
47|架构活动中的思维模式.1:协同式的全方位思维和批判思维¶
全方位思维¶
架构活动初期, 旨在控制风险
第一,关注整体。架构师处在一个能够了解全局的角色上,所以需要把更多的注意力放在整体的目标上,以及把整个架构活动作为一体来创造的最终价值上。
第二,关注平衡。也就是关注多种维度之间的平衡,而不能只关注单个维度。包括资源、人性、商业价值、技术先进性等,比起这些单独的维度,更重要的是关注这些维度之间的平衡性。
第三,关注链接,也就是关注领域之间的关系,而不是每个领域内部的细节。每个执行领域内部的思考,应该由负责该领域的领导者完成。你可以检查他们内部的工作,但更重要的是关注跨领域的划分、领域之间的接口和跨领域的数据标准。
备注
架构师的全方位思考不是一个人在独自战斗,而是通过协调和引导团队的关注点,让架构活动参与者共同完成全方位的思考。我将这种思维方式叫做协同式的全方位思维模式 （Synholistic Thinking）。你的角色跟一个交响乐团的指挥是类似的,价值在于确保所有音乐家能将一首交响乐以你所理解的形式完美地表达出来,而不是跑上跑下,去代替某个音乐家或者帮他们演奏得更好。
批判思维¶
架构活动中, 决策前的思维方式, 旨在提高成功率
第一,理性思维,也就是拒绝一切非理性思维。互联网企业很崇尚信仰驱动的文化,甚至整个执行团队都可以“但行好事,莫问前程”,但你这个架构师不可以！你必须理性分析自己听到的每一个断言,验证逻辑的正确性,最终得出断言是否成立的结论。这是批评思维的起点。
第二,价值导向。在一个架构活动中,我们的思考带宽和时间有限,所以要有选择地怀疑。而我们怀疑的内容,最终应该带来实用的知识。要在这些可怀疑的对象中间,首先选择那个价值最大的去怀疑。
第三,首先怀疑。这一条对于国内的互联网公司来说尤其重要。我们中国人深受儒家思想影响,同时也因为国内等级分明的管理制度,多数人都不愿意对上级和他人表达反对意见。所以批判思维在大企业里尤其缺乏。
48|架构活动中的思维模式.2:实用主义和反思思维¶
实用主义思维¶
执行阶段,
实用主义思维（Pragmatism）指的就是以实际增值作为检验架构设计唯一标准的思维方式。
反思和分析思维¶
复盘阶段-反思思维
首先,反思是批判思维的一个具体应用。反思是一个理性的思考过程,是基于逻辑思维的、理性的、怀疑的、公正的思维方式。
其次,反思过程的主要作用对象是你自己。反思首先是个自我批判的过程。
最后,反思的内容主要是自己的思考方式。在复盘过程思考的对象,就是你在架构活动中的思考过程本身。
复盘阶段-分析思维
第一,分解问题。分析思维本身就是把一个整体拆解成更小的、更容易理解的部分。在这个过程中,我们需要从多个维度上做拆解,把父问题拆解成更细粒度的子问题。
第二,发现重点。影响架构活动的因素太多了,多数时候,通过一次复盘得到的结论的有效性是存疑的。因而最重要的是找到 2-3 个高价值的改进点,而不是找到几百个不一定有啥效果的跟进项目。这是个深度思考和发现的过程,不是把任务简单地分配给不同领域执行者的过程。
第三,追溯本质。在复盘时,要在探索问题本质的过程中不断深入,发现抽象的、跨领域的、在更长周期中有效的不变量。在这些不变量上做提升,从而带来更具普遍性的价值。
49|往来无白丁:如何判断一个人的思考质量¶
对于思考力的判断,我们需要从以下五个方面来考虑。
第一,案例的真实性。是否是真实案例,看能不能将预期结果和实现方式之间的逻辑细节讲清楚。
第二,洞察的价值。洞察的价值可以用有效时间和资本回报来度量：1.所谓有效时间,就是这个洞察的有效的时间范围。2.资本回报,则是这个洞察能为企业创造的价值。
第三,思考者的贡献度。一个极端稀缺的洞察,往往有一个非常极端的前提条件,就是他能拿到别人拿不到的数据和知识。也就是说,如果一个高质量的洞察背后缺乏配套的周边,那么这个人可能只是听说并复述了别人的洞察。
第四,思考的难度。判断一个人的思考难度,必须以他当时所能接触的信息为基础。如：2015 年推行的 Docker,当时国内还没有流行,大多数人都没意识到 Docker 的真正价值。那时候,去尝试一个尚未在国内有任何成功案例的基础设施,就需要非常缜密的思考。但两年之后,国内 Docker 化做得如火如荼,成功案例比比皆是,思考的难度几乎就没有了。
第五,可重复性。
如何判断一个尚未验证的思考的质量
逼近本质。哪个思考的结论更接近问题的本质,哪个思考的价值就越大。
假设简单。哪个思考结论的前提假设少,哪个思考的价值就越大。
场景契合。哪个思考背后的模型和场景契合度高,哪个思考的价值就越大。
一个有深度思考洞察的人,经常是偏执的。他往往会形成相对完整且自洽的认知体系,得出的结论可能听起来非常武断。但是任何一个武断结论的背后,如果你深挖他的逻辑,就会发现背后有一套完整的逻辑推理。有时候这个逻辑起点或假设不一定正确,但是他的逻辑推理质量非常高,因此也是值得学习的。
这样偏执的人在公司里可能是不太讨人喜欢的,面试时也很有可能让面试官不太舒服,日常交流的过程也是。所以很多人哪怕见到有思考力的人,往往都是躲得远远的。
50|思考实例.1:探险家Amundson是凭什么胜出的¶
讲了一个关于去南极探险的故事
51|思考实例.2:南极探险的第一性要素是什么¶
第一性原理：”Meditations on First Philosophy, 1641”——笛卡尔
52|思考实例.1:中台既不是银弹,也不是哑弹¶
天下没有免费的午餐,中台也是一种平衡。中台仅仅在有限的场景和有限生命周期内能为企业建造竞争壁垒,但最终也要以企业的迭代速度为代价。
53|思考实例.2:到底是什么因素左右了中台的成败¶
中台的优势领域在第三象限,在这个象限中,技术具有高确定性,业务功能通用,比较好的例子是云计算、芯片、支付、物流等。¶
备注
中台的使用范围是有限的,仅仅限于技术演化相对慢,且功能通用性高的场景中。
历史证明,在没有合理的机制的情况下,市场机制就是个好机制。
54|模块小结:如何进一步提升自己的思考力¶
实证主义是科学方法,可以通过下面三种方法寻找不足之处
找反例
找逻辑缺陷
找冲突
思维模式其实是一个人内心相信的理念。如果同事与你持有相同的理念,那么这些方法实践起来就会很容易。反之,实践的过程就会很吃力,正所谓“道不同不相为谋”。
05结束语¶
达尔文的《物种起源》
笛卡尔的《第一哲学沉思集》
The thing about an architect is that your thinking can eventually materialize into a technological force that can fundamentally change our world. In an era that is driven by computing, this force is formidable. I wish you utilize this force with the sole purpose of benefiting others. For that, I wish you all the success!
架构师的真正作用就在于,你的思考将转化为一种技术力量,最终彻底改变我们的现实世界。在一个计算驱动的时代,这种力量来势汹汹,势不可挡。希望我们都能利用好这种力量,只为让世界更美好！
06加餐¶
对话于冰¶
快手高级副总裁于冰
任何一个公司,任何一个团队,资源都是有限的。我们在有限的资源下只能做有限的事情,做最重要的事情。
一个人的成长,关键在于你选择了什么,忽略了什么。而且选择得对,忽略得也对。
有些事情可以去探索,但是在一段时间内,一定要集中资源去做一件事。不要总想着做两件三件、四件五件事,那会浪费很多时间。
对话陈华良¶
每日优鲜的 CTO 陈华良老师
百度 Launch View 的邮件机制。里面会有很多内容,包括我做了什么事,用的什么技术方案,我是怎么实验的,结果是怎么样的。一开始看得比较累,有一些比较深的技术看不太懂。然后看多了突然就懂了,他们做的这些事我都明白了。这个时候就发现自己在技术的认知上会有一个很大的提升。
第二个心得,我还看 GitHub 的明星项目。通过看这种实战的项目,我会更立体地了解怎么样去做架构,帮助我更好地解决实际中的问题。
郭东白
加入亚马逊后,差不多花了半年的时间,把当时团队里 20 多个人的代码,以及他们所有依赖方的代码全都看完了。正好我当时的位置还比较特殊,我是数据架构师,所以我不写代码、只看代码,也是 OK 的。
看到后面,其实代码的细节看得越来越少,API 看得越来越多。我觉得 API 更能代表一个架构师的布局思考。
亚马逊有一个东西叫 COE。我们当时是全员开放的,能看到所有历史的 P0 故障,好像有 400 个。我把这些 P0 故障的复盘从头看到尾,那是我从亚马逊拿到的最大的宝藏。
直播加餐01| 技术战略到底是什么¶
【定义】the art of planning and directing overall military operations and movements in a war or battle（在战争中,如何计划和指挥整个军事行动和军事运作）
直播加餐02| 阿里速卖通是如何在竞争变化中做技术战略的¶
架构师的主要任务,就是通过架构活动帮助企业实现战略意图。这个过程要靠深度的业务理解,然后利用技术手段为企业注入外部适应性。