郭东白的架构课_27_17通用技能下架构师如何保障交付与沉淀知识
你好，我是郭东白架构师。
在架构活动中主要有四个作用，分别是建设共识、控制、风险、保障交付和沉淀知识。
上节课呢我们讲了两个，这节课我们就来讲保障交付和沉淀知识。
先看看怎么保障架构活动的交付。
保障交付意味着架构师能够降低大型架构活动的不确定性和复杂度，最小化架构方案，最终保障高质量的交付。
其中呢关键动作有三个，分别是降低不确定性、控制复杂度和最小化架构方案。
事实上，这也是交付一个大型架构活动的主要困难点。
在互联网时代，所有研发行为都具有非常高的不确定性。
这是由竞争环境、技术、环境、监管环境和商业环境决定的。
除此之外，由于参与方众多，那么这些不确定性必然会从每个参与方在传递到架构活动中来，而且不确定性本来就会带来复杂度，再加上互联网天然存在的沟通障碍，那么复杂度就进一步会被放大。
所以说，不确定性和复杂度是交付架构活动所面临的两大难点。
那么我们先来看看怎么控制不确定性，不确定性的来源呢有很多方面。
首先呢是目标的不确定性，这主要是赞助方对目标的不确定导致的。
关于这点呢，我们下节课呢会讲系统的应对方法。
第二呢是资源的不确定性。
在我看来，这是互联网时代架构师所面临的最大挑战。
无论是国内还是国外的互联网公司，往往通过类似于虚拟机超卖的方案去刺激团队的产出企业往往会有多项研发活动。
而企业的整体研发资源不足以完成分配给所有研发活动的全部任务。
那么架构师就必须在有限的研发资源池里增强份额来保障架构活动的交付。
就拿国际化电商的项目来举例，一方面呢项目需要全球多个国家的运营产品研发和测试人员的配合。
但这些角色呢都有各自的KPI和必保项目。
另一方面，其他项目的负责人呢也在争取这些角色的支持和配合。
那么我们怎么能拿到应有的资源份额呢？我们之前强调的两个生存法则是必要条件。
那就是确保架构活动的目标正确，以及最大化项目的商业价值。
这呢是王道，当然还有其他的法则也要遵守。
比如说尊重人性，发掘参与者的利益诉求，最大化参与者的个人投入度。
否则，当架构目标跟参与者、个人或者团队的利益并不完全一致的时候，我们需要投入额外的激励来保障他们的投入度。
但曾经见过有个公司，为了保障一个为期半年的项目的成功，给所有参与者多方发了半年工资作为奖金。
所以如果你听说互联网公司的工作时间是九十一期，不要奇怪，重赏之下必有勇夫。
除了技术资源之外，运营资源、办公环境这些也是有限的资源。
我们需要跟合作的项目经理一起来保障。
这些项目资源是充足的。
比如项目上线之后，相关功能在多个场景下的入口的流量保障，像首页搜索、推荐、大促、承接页详情页等等，对项目的成败也至关重要。
其实在互联网的研发环境下，只要是有限的资源，最终都会变成稀缺资源。
发布窗口、物理机、计算机资源、算法、AB测试等等，都可能成为意想不到的交付障碍。
就像时间、窗口资源，经常是大企业里架构项目的瓶颈。
在电商类的项目中协调时间窗口是非常困难的。
每个国家都有固定的节假日，分布在全球各地的用户呢，还有不同的工作习惯和休假习惯。
而每个国家的业务呢，还有各自的大促时间和项目交付时间。
那么真正留给架构师去协调团队参与大规模集成测试和验收的窗口其实非常少，每月一般就有一两个。
而这种时间窗口呢，肯定也是各大项目拼抢的对象，所以我们务必要提前锁定并且看护好不只是国际化的项目面临时间窗口的挑战。
国内的项目呢也一样，假设一个电商项目在第四季度启动，那么肯定会撞到双十一和双十二大促时间，窗口呢就变得非常稀缺了。
总之，盘点保障好稀缺资源的供给，对项目的成败非常关键。
第三，商业和技术环境的确定性。
针对这一点呢，我们在法则五已经做了详细的应对方案的描述。
除此之外呢，我还从交付确定性的角度再来谈谈具体的应对办法。
最好的办法呢就是缩短阶段性交付周期的同时，增加技术方案的抽象性。
缩短阶段性交付周期怎么理解呢？在一个大项目的初期，无论是我们架构师还是其他参与者，对项目的理解都是非常有限的。
这个时候呢，我们有必要把架构活动拆分成多个阶段性的交付点，以便在线上看反馈。
那么我们可以根据线上的数据来看看商业技术环境的变化，对架构目标和商业效果的影响，而不是凭空猜测。
那增加技术方案的抽象性要怎么理解呢？它其实指的是尽量提升API设计对技术选型的鲁棒性，也就是提升接口和模型设计的抽象性。
那么在之后的交付阶段，我们就可以对次优的技术选型做更正或者是进行升级。
第四，用户需求的不确定性指的是用户需求跟我们期望不一致，或者用户需求呢随着时间推移发生了比较大的变化。
应对方案除了我们之前提到的从人性出发的设计思考之外，还可以基于增量价值来交付单元。
通过线上的用户的真实行为来判断用户需求是不是跟之前调研一致。
同时呢根据预期行为的偏差和效果分析，来决定是不是要对用户体验做出调整。
其他因素。
比如说文化环境和组织结构往往很少在架构活动内发生巨大变化。
所以我们一般呢不需要做相应的应对策略。
接下来呢我们看看怎么控制复杂度。
复杂性呢和不确定性呢？听起来是一码事情，其实差异很大。
不确定性呢是指问题随着时间发生了不连续的，并且是不可预测的变化。
但是复杂性呢它更强调问题或者解决方案，很难用几个简单的维度去描述。
那么怎么控制复杂度呢？第一呢，从问题域层面来分解架构规划和交付方案。
在这个过程中呢，我们需要把整个架构活动按照问题域分解成不定领域、不同领域的子问题。
然后呢，在每个问题域从粗到细，一步步分解成细腻度的执行方案。
事实上呢，研发团队日常的任务分割往往也是按照问题域拆解的。
所以呢你可以在最大程度上利用日常已经形成的沟通协作机制，最小化交付风险。
那我们还是看个例子吧。
假如呢我们在做一个大规模电商系统内容化升级的项目，需要根据日常的垂直域划分，也就是流量导购、搜索、推荐、交易资金评价、商品、商家服务、履约物流等等，把整体的任务呢分配到各个领域中去。
而各个领域呢会根据内容化的需求来决定各自领域的规划。
比如说流量与你领域呢，就需要有内容承接部分的定制投放和生成等。
而履约和物流领域呢就几乎跟这个项目没有任何关系。
不过在这个过程中呢，你可能会发现之前的领域划分不是最优的。
我们继续用刚才这个案例。
当每个领域都完成进一步的方案细化之后，你可能会发现流量、导购、商品、商家服务等领域呢存在着共性的模块，那就是内容的生成和其他的内容操作。
如果每个领域各自开发这些模块，那我们呢就会造成相当大的浪费。
这个时候呢，我们可能需要把这些跨多个垂直领域的内容相关的问题组合成一个新的内容域。
然后呢，由这个新的垂直域完成跟内容相关的所有规划和交付，从生成到审核、编码、投放、播放、买点、监控和分析等等。
第二呢是要增加设计方案本身的结构性。
结构性呢是指贯穿企业所有的软件实现方案的统一模式呢。
反在设计上呢就是结构化设计，意思呢是指不同的领域，不同的模块的设计呢是同构的。
举个很简单的例子，所有参与方呢都采用微服务设计，响应式设计，或者是前端的低代码设计。
那么这种结构化的设计到底有什么优势呢？除了运维测试等方面的优势之外，它最大的优势在于未来的改动成本比较低。
因为我们做架构永远都不是为了现在，而是为了未来。
只有适应未来环境的设计，才能最大化企业的生存，也就是我们第五条法则中重点强调的。
举个例子，如果做电商化系统，那么我们可以把整个技术架构分成三层，分别是业务层中台和没有业务语义的基础设施层。
随着我们对业务理解的深入，我们会发现中台需要被分为两层。
上面一层呢是业务中台，下面一层呢是数据中台和共享技术层。
这两个步骤呢都是水平区分。
然后呢，我们可以根据业务域进一步把业务模块切分成多个垂直的领域，在每个领域内再做新一部分的方案。
细化。
首然呢每个领域的商业逻辑有差异，但是他们使用同样的编程语言维复框架、测试框架和发布流程。
这种在企业层面上，宏观的结构性就是我们要追求的结构化设计。
需要注意的是呢，这个结构化设计的过程呢，不是你这一个架构师口头说说就可以了。
这种宏观上的结构性来自架构师和其他参与者在可以领领域上的决策，都对结构性有追求。
比如说交易模块，你先要对不同国家的业务需求做分类，从中抽象出共性需求到交易中台。
而个性的需求呢，就跟这个国家的特殊业务形态或者是监殊环境有关，需要留在业务层，避免复杂性呢侵入到业务中台。
但这个过程呢又会影响到数据中台和交易相关的实体。
比如说呢营销活动订单依赖和账号这些实体的抽象。
所以呢你对实体的建模肯定会通过数据中台，影响到营销中台和资金中台，以及依赖这两个中台的前台业务。
这时候呢持有专研到所有相关模块的领域模型，这个层次上才可能对整个架构活动的复杂性形成比较完整的认知。
如果你和团队呢都追求这种宏观的结构性，那么你在垂直切分的过程中，随着你和团队对细分场景的梳理，比如说API设计领域模型和消息机制都能会变得逐渐清晰，并且是合理结构化。
反过来呢，如果在这个过程中，如果一个人处于贪婪，试图破坏自己领域的结构合理性，那么这种行为呢就会传递到中台，并且扩散到其他领域中去。
这也就是我们为什么在第六条法则里反复强调求真和有良知的文化。
对于一个企业来说极其重要。
这个梳理的过程中，如果做的比较认真，它也会帮助你降低交付的风险。
而且随着梳理呢，你的方案会变得越来越完整，每个模块的交付时间确定性也不断的提升。
研发任务呢也从宏观的领域模型切分到库表切分，再到字段和消息的切分力度越来越细。
风险呢也从最开始相对宏观的大风险转到具体设计方案层面的风险，以及细细分模块的交付日期上。
事实上呢，许多架构活动的唯一目标呢就是提升企业软件的架构的结构性。
举个例子呢，你肯定参加过技术站，统一数据模型，统一全站买点标准化等等等等。
这样的项目。
这些项目的目标呢都是提升软件系统的结构性。
但是呢把一个混乱的系统重构成一个结构化系统的成本非常高。
所以呢我们应该通过日常架构活动的自律，来避免企业里软件结构性的退化。
可以这么说，任意破坏企业整体的软件，结构性的行为都是可耻的。
当然呢有些架构活动的首要目标就是构造新的商业模式或者最大化商业价值。
这种大的商业模式变化往往同时覆盖多个领域和软件架构的多个分层，而且时间非常紧迫。
在这种架构活动中，想提升软件设计的结构性呢就非常难了。
因为这种项目对结构性往往是有破坏性的。
所以在这个时候呢，如果你能想办法约束架构活动的爆炸半径，会间接减少软件结构性的破坏。
关于这一点呢，你可以看我第五讲给出的性能优化的项目案例。
在这个案例里呢，我对其性能优化的商业价值的抽象和准确度量，也就是性能损耗的概念约束了整个架构活动参与者的探索范围和探索深度。
同样呢可以避免无无义义的架构资源的破坏，同时呢也避免系统结构性的破坏。
而且通过这种强调单一的结果指标来约束架构方案的范围，其实呢是一个非常好的控制复杂度的办法，来维持结构性的办法。
第三，按照多种方式分割交付模块。
分割交付模块的理念呢跟小步快跑呢是类似的比较常见的办法呢是分期交付。
比如说按部门按领域或者按架构分层进行分期，按部门或领域交分，意思呢就是按垂直领域分别完成架构项目的交付。
按架构分层交付呢是指先完成最底层的变更，然后再逐渐往上每一层的交付呢都保持向后兼容，从而最小化对上层业务的侵入。
在后面的课程呢，我们还会讲到按最小价值单元交付的方法，就是呢只按用户场景和需求划分来交付模块。
不论呢是哪种交付方案，好处在于整个交付过程跟一个松耦合的灰度发布是类似的。
这样的话呢你可以在小范围内试错，提前发现问题。
另外一个好处呢可以降低联调和验收的复杂度。
最后呢，我们前面提到的很多不确定性和复杂度的问题也都可以迎刃而解。
我团队的技术项目呢几乎都是按照这种方式来交付的。
最后呢我们看看来怎么最小化架构方案，不论是分期交付，还是通过单一目标约束架构活动的范围。
这些呢都是最小化架构活动的例子。
这个最小且必要的原则是提升交付成功率的最重要的方法。
但是实际项目中呢，我们看到的往往是完全相反的好大喜功的行为。
这种行为呢在大厂里尤其常见。
有的项目负责人呢恨不得把整个项目呢铺开到整个企业，甚至呢为了扩大影响力，故意放大项目的工作半径。
这种行为呢是项目交付的大忌。
你可以在任何一本项目管理的入门书籍中看得到。
就像我们前面提到的，大多数的架构活动呢其实是以失败告终的。
虽然很多架构活动的负责人不这么对外讲，但真实的情况一定是败多胜少。
所以如果架构活动只有一个成功秘诀的话，那就是最小化一个非常重要的架构。
活动的用户体验指标也是跟最小化有关的，那就是被架构活动影响到的业务体量占比，这个比例呢是越低越好，最完美的情况呢是零。
也就是说呢，你的架构活动对上层业务完全透明，在交付架构活动的过程，中上层业务还可以持续迭代，不受任何影响。
反过来呢，最差的架构活动的交付体验就是完全阻断上层业务的迭代。
我曾经见过一个国际化中台项目，原本预期三个月交付之后呢，推迟到六个月，然后是九个月，最后做了一年就烂尾了。
最恐怖的是呢这个项目负责人的不听劝阻，选择了一个非常极端的阻塞式的交付模式。
那就是在项目进行的过程中呢，所有相关的上层业务都不能做任何交易和营销模式上的变更。
在这种情况下，上层业务呢就像是杨家将，在打仗三个月没有粮草就已经很艰难了。
等到被绝食了一年之后，根本不用对手跳落到马下，自己就饿死。
在挣钱了，所以请一定要记住，务必要最小化项目对上层模块的冲击。
讲完了怎么保障交付呢？那我们再讲最后一个话题，就是怎么沉淀知识架构。
活动中呢架构师呢有非常独特的宏观视角，跟其他参与者的视角都不同。
所以呢我们非常有必要通过有效的知识沉淀来保障架构活动的思考和决策质量。
也有必要呢为企业的未来的架构活动提供宝贵的经验和方法论。
一方面呢架构师需要沉淀完整和真实的过程记录，另一方面呢还要为企业注入逻辑思考，引导企业走向正确的决策。
有些人呢误以为沉淀知识，就是收集整理和编写文档，的确不断积累这些数据和文档记录非常重要。
从某种角度来讲，这个记录呢就是整个架构活动的数字化镜像，不但能为架构活动的参与者提供完整且全面的信息，而且也能为其他项目的架构师和依赖方提供宝贵的信验。
关于这点呢，有些商业化的文档工具已经做的非常成功了，比如说confluence.然而呢这不是沉淀知识的全部。
在沉淀知识上，我们更需要做的呢是通过各种文档工具、设计工具、沟通工具和复盘工具，为架构活动注入理性思考。
我们呢来比较一下这两者的差异。
收集整理和编写文档是一个数字化镜像的过程呢。
真实世界的行为发生在前，数字化的过程发生在后，这是一个被动的过程而注入理性思考的过程呢，这是一个主动的过程。
文档和设计发生在前。
文档驱动我们的架构式和其他参与者理性的基于事实的思考和决策，以及改变真实事件。
这是一个靠文档中严密逻辑来驱动理性思考的过程。
在被动的过程呢，架构师呢就像是一个自动化买减和日志收集系统，忠实的记录着项目过程中所有的行为现象和结果。
而在主动的过程中呢，架构师把自己变成了一台计算设备，通过文档来驱动架构活动参与者的思想实验，通过理论推演来提升思考质量，而不是通过写代码发布线上试错来完成架构方案的迭代。
还记得我在模块一提到的性能优化的案例呢，在我们团队还没有动手改代码之前，我们就先定义了性能损耗这个概念。
不仅在文档上推演和证明了性能损耗的公式，而且在白板上讨论了不同页面不同场景下实际的度量方法等等。
这个由文档驱动的思想实验，让我们在出手之前就已经对它能产生的价值沉竹在胸了。
你可能会说这个案例太特殊了吧。
事实上呢这是我作为架构师坚持了很多年的习惯。
只要是项目足够复杂，成本足够高风险，足够大我一定会要求自己或者是项目负责人做类似的推演。
这是我实践过的提升项目成功率。
最好的办法。
推演呢不一定是公示，也可以使文档，甚至是被污名化了的PPT.其实形式不重要，关键在于主动思考这四个字。
或许你还会说，在互联网时代，大家就应该试错，花这么多时间去推演，值得吗？我的回答是，不但值而且超值，还是我自己的经历。
我博士论文的主题跟计算机视觉在医疗领域的应用眼光。
一般来说呢，博士论文要有具体的公式，推导和结果呈现。
但是呢我有一个推导有误，写代码的时候没有发现，直到落笔写论文的时候，我才恍然大悟，最后呢只能倒回去改代码。
这个错误呢发生在图像分割之前的特征建模环节。
所以我被迫改了前后花费两年之间写的几乎所有的代码。
从特征提取到特征计算，到图像分割、三维可视化、三维建模、应力计算等等。
为了完成论文，大概有半年的时间，我从周五早上八点到周日下午七点，连续工作五十多个小时。
在高速上开车的时候，我睡着过三四次，现在回想真是后怕。
但事实上呢，在我重新写论文的时候，发现并且证明这个推导错误也只用了一天多的时间。
但是我却差一点，这因为这一天的大业而葬送了自己年轻的生命。
从那以后呢，我就养成了一个习惯，只要是足够复杂的项目和工作，我一定要在纸上把完整的公式思考逻辑和决策逻辑写下来，反复推敲，并且分享给周围的同事，让大家一起年轻的生命。
无论在纸上把逻辑推演多少遍，这个成本远远小于让几十个人喊着口号，开足马力，以血肉之躯冲向一个悬崖的成本。
我认为就是这个习惯，让我在架构师这个职业赛道上走得更好更远。
所以呢思想实验不仅仅帮助企业，更能帮助我们自己。
你可以在网上找到亚马逊的六页纸的鉴赏，这呢也是一个思想实验，这个流程呢非常耗时耗力。
我自己呢写过一篇文档，改版了十三遍才通过评审，而且这些呢都不是小的改版，每次改版呢都有十几个人参与评审，其中还包括一个技术VP.想想看，这个思想实验的成本有多大？在亚马逊的企业信条里，有一条叫做bias for action.翻译过来呢就是勇于试错。
这条信条的完整表述，其实应该是在充分的思想实验之后，勇于试错。
总结一下呢，一个理想的知识沉淀的过程，不仅包括一个被动的通过文档来记录活动的历史的过程，还包括一个主动的通过文档来驱动思想实验和创造历史的过程。
好了，今天的内容就是这些。
我们来简单总结一下，架构师呢要在整个架构活动中持续保障交付要做好这一点，你要持续控制不确定性和复杂度，同时试图最小化架构方象。
不确定性的根源呢来自于目标资源、环境和用户需求。
这些外在的影响因素随着时间会发生不连续的变化，而应对变化的不连续性，一方面呢我们要及早并且持续确认。
这些影响因素。
另外一方面呢，我们还需要寻找不变量，寻找一个更高更深层次的稳定抽象、复杂性呢来自于互联网企业业本身的业务模式的复杂度。
你可以通过对问题域的分割，对结构性解决方案的持续追求，以及对交付的合理分割来控制。
不过呢这些都是数更重要的保证交付方法呢还是最小必要，千万不要好大喜功，更不要把自己含在业务的前面，阻断上乘业务迭代。
最后呢我们还讲了知识沉淀一个理想的知识沉淀过程，既包括了一个被动的记录架构活动历史的过程，还包括一个主动的驱动价值创造的思想实验的过程。
这个虚拟世界的知识沉淀和现实世界的架构，活动本身就好像是DNA的两条链知识指导活动。
而在活动中，又可以不断创造和验证知识，这两者是互相激励、互相创造和互相影响的过程。
在我看来，这呢才是架构师工作的最美妙之处。
我们的工作永远都可以让自己的思考变得更加完美。
最后呢是我们的思考题环节，依旧呢是三个思考题，你可以任意选择一个来作答。
第一题呢你在项目中经历的最大的不确定性是什么？采取了什么应对方案呢？结果如何？第二呢，我们这两节课呢讲了四个基本职能，分别是建设共识、控制风险、保障、交付和沉淀知识。
除此之外呢，你认为还有哪些技能是架构师必须具备的呢？为什么？第三题呢，你见到或听说过的最成功的思想实验是什么？它为什么能成功呢？如果这节课呢对你有帮助，欢迎呢你把课程转发给你的同事或者朋友啊再次打个小广告。
我刚开了个人抖音号呢，我会定期发表一些比较新，但是不一定那么成熟的观点。
欢迎在抖音上搜索郭东白并关注，也欢迎您的批评和指正。
我们下节课再见。