郭东白的架构课_25_15模块导读互联网时代架构师都面临哪些新挑战
你好，我是郭东白。
在上个模块，我们讲了架构师的六条生存法则，提到了架构师的重要工作呢就是组织架构活动和制定架构方景。
我么具体来说，一构活动的完整过程是什么呢？架构师一般会面临什么样的挑战呢？又需要关注哪些节点呢？在这个模块里我们就来回答一下这些问题。
这节课呢是整个模块的导读，我们先来介绍一下模块的整体背景，然后再来介绍具体内景。
我们首先来看看架构师在互联网时代都面临哪些新挑战。
架构活动简单来说就是围绕一个架构目标而采取的行动。
一个架构活动可能有上百人，甚至有上千人的参与。
在这么大的人员协同之中，架构师就要找准自己在其中的定位，明确什么事情是自己应该做的这节课呢？是其他参与者应该做的。
需要说明的是，真对这些我会提出非常具体的行动建议。
上个模块讲的基本法则，相对而言，能适应的时间跨度和技术体系的跨度会更长一些。
但是在这个模块里，这些行动建议有着非常强的时效性。
主要针对现在的主流计算方式，也就是分布式技术为主的互联网研发活动，二个时代的计算方式都不一样，差别很大。
在企业软件时代，软件研发主要靠传统介质，比如说光碟平均发布间隔呢是每半年一次，甚至是更长，数据迁移也非常复杂。
那么企业用户对软件质量的要求就非常高。
二零零五年，我在甲骨文数据库内核部门工作的时候，代码发布前测试覆盖率的底线呢是百分之九十五，一个大版本的研发周期呢是一年半。
另么企业文档在研发开始前就基本成型了，甚至已经跟大客户完成了多轮的调研和交互搞反馈。
而到了互联网时代，多数企业是边打边学，别说产品文档了，连商业模式都很难保证。
持续一年团队每天有上千次发布，有的模块代码测试的覆盖率还不到百分之二十五。
时代的变化呢导致了研发方式的变化。
在互联网时代，敏捷开发成了开发模式的主流。
不过，敏捷的行为方式在帮助业务高速迭代的同时，也导致了大量的短期行为，也就是所谓的技术债。
这些技术债就构成了架构活动所面临的主要技术挑战。
那么他们主要有五种第一反射式的研发行为。
不论是初创公司还是大企业里的初创行队，往往面临着持续的巨大的交付压力，导致一种反射式研发行为，也就是写代码，就像起跳反射一样，研发人员的日常工作都是在接需求、写代码、上线修故障之间循环，很少有时间去思考和追求长远的设计。
这种短期行为虽然不影响业务迭代，但是如果在一个大型架构活动中频繁出现，那造成的后果肯定是灾难性的。
第二，大规模活动分布式研发模式呢往往采用微服架构，微服架构有个优势，就是服务之间可以独立做变更。
在保持API稳定的情况下，团队之间很少需要协同。
所以每个服务的维护者可以独立决定自己的发布流程和交付节奏。
但是在互联网时代，为了最大化流量的传播，我们往往会通过一个大型商业活动来聚合和放大营销效果。
比如说六幺八大促双十一大促春节红包、新品线上发布会等等。
那么微服务相对独立自主的研发模式，对于制定团队统一流程和交付节奏来说，就构成一个巨大的挑战。
第三，分布式研发中心。
互联网企业往往有多个分布在全球各地的研发中心。
举个例子，我在拉扎达做CT to的时候，我的团队分布在新加坡、印度的班加罗尔，越南的胡志明市以及中国的北京、深圳和杭州。
如果再加上需要协作的团队分布就更广泛了。
这种跨国家、跨地域、跨语言的研发模式之下，各个研发中心内部都有可能有非常多的交流。
但是各个研发中心之间的沟通，相比之下就是互相隔离的时间长了，康威定律就开始发挥作用。
系统的结构和产生这些设计的组织沟通结构是通构的。
也就是说，在我们不能改变一个组织的沟通结构的时候，架构活动产生的设计就会有非常大的局限性。
第四，普遍存在的认知差异。
每个团队甚至是每个研发平时都在自己的隔离环境下高校强度的开发代码。
所以大家一般没有统一的语言和全局的认知。
这种情况下，业务和产品团队也同样存在，因此达成一个宏观的、完整的、可行的，且被普遍认可的规划就变得非常困难。
第五，大型架构活动本身也面临着挑战，在高风险和高回报预期的场景下，必须保障项目完成的高确定性，以及对没目标的高保证性。
互联网时代大多数公司都是在一个场景下通吃天下。
所以一个大的架购活动背后的商业赌注呢一般会非常大。
阿里巴巴的双十一就是最典型的例子，在双十一的第一分钟每秒就有几十万次的交易。
而第一个小时的交易额接近一千亿，全天的交易额总共几千亿。
如果双十一出了什么故障，不但影响投资者的信心，有些小企业也会因为备货太多而销售不出去，而在一夜之内破产。
而且这个架构活动的交付日期根本没有变更空间，双十一之前必须完成。
所以双十一那天必须保证业务和技术目标的高度保障，那么苛刻的要求也就意味着巨大的成本。
为了准备双十一，阿里相关的技术团队要从六月份就开始备战，持续高强度的加班，直到双十一结束，有的方案甚至要在前一年的双十二做预演，第二年六幺八时再做大规模尝试。
到了第二年的双十一呢才全面铺开。
虽然像双十一这样兼具高风险和高商业价值的架构活动非常少，但是几乎每个互联网公司的架构活动其实都面临着超高的风险强度和复杂度。
原因呢很简单，如果一个架构活动不具备这样的性质，也没有一个超高预期的回报，那他就不会被提到足够高的位置上。
公司呢也不愿意为这个架构活动配备专职的架构师，也不会大范围的协调团队的优先级，投入多个团队研发资源，取而代之的将会是敏捷的开发，用最小的组织，最短的时间成本、最少的代码迅速上线在线上看效果。
在这些挑战之下，架构师要发挥的作用其实就非常明显了。
我们需要帮助团队抵抗反射式的研发行为，独立决策的研发模式，分散的研发团队普遍存在的沟通障碍、认知差异以及高风险高强度的工作和高复杂度的场景，最终保证架构活动难以高确定性完识。
综合这些挑战呢，我们可以总结出架构师在互联网时代架构活动中所要发挥的作用的。
第一是建设共识。
架构师呢需要克服现有分散的研发团队普遍存在的认知差异，习惯性独立决策的研发团队所带来的认知局限，引导参与者在架构活动的认知上达成共识。
这类共识呢包括对目标的共识，对决策方法的共识，对各自责任边界的共识，对资源分配的共识，以及对交付时间、内容和质量的共识等等。
第二，控制风险。
架构师呢需要克服互联网企业在高度不确定的商业环境、日常工作缺乏流程，团队高强度的工作节奏以及反射式研发带来的混乱，还需要在架构生命的全生命周期中持续的收集、发现、评估、控制和传递风险。
更需要呢在持续变化的目标和竞争环境中呢，不断提升对风险的理解，逐步完善预案，并且还要在成本可控的情况下选择合理冒险。
同时呢随时要跟踪外部环境和事件引起的风险变化，及时传递重大风险，把风险控制在可以接受的范围内。
第三，保障交付架构师呢要尽量降低大型架构活动中的不确定性和复杂度最小化架构方案。
做到这点呢，架构师不仅要提升行动，关注用户价值，不断提纯目标，保障交付的价值，还要反复分解架构计划，去除盲区，提升ABI的鲁班性。
最后呢分领域分阶段最小化的交付来保障项目完成。
第四沉淀知识。
任何一个大型架构活动的背后呢，都有巨大的时间成本，机会成本、商业资源和人力资源的投入。
在这个视角来看，架构师在架构活动中必须具备区别于他人参与者的宏观视角，一方面呢需要完整记录架构活动的历史和决策逻辑。
另一方面呢，你需要通过文档来驱动理性思维，通过正式文档review流程来提升企业的宏观思考或决策质量。
最终呢保证这些内容将形成复盘的主要输入为企业之后的类似活动积累经验。
架构师所起的这四个作用，建设共识、控制、风险保障、交付和沉淀知识。
其实在前互联网时代呢也一样重要，只不过在互联网时代有着不同的特性，具体的挑战和应对措施。
我会在第十六十七节做详细的拆解。
需要特别强调的是在这四个作用中，并没有包括写代码、项目管理、培训、交流等工作。
事实上，这些工作往往占据了架构师大部分的时间。
不过在我来看，这些工作呢都是为了服务于这四个作用。
如果只写代码，只做项目管理或者是做培训交流，在架构活动中呢都有其他人员可以替代。
但是通过这四个作用，架构师却可以创造出不可替代的价值。
总的来说呢，这四个作用呢是从价值创造维度来思考架构师的工作。
除此之外呢，我们还需要从架构师活动的全生命周期的维度呢去挖掘架构师在每个生命周期节点的具体工作。
我在文档里放了一张图，展示了架构师视角下架构活动全生命周期。
在整个生命周期中一共有八个需要关注的节点。
针对这八个节点，我会通过案例来描述每一个节点要达到的环标，并提出具体的行动建议。
这节课呢我先来大致描述每个节点的背景和内涵节点。
一、搭建架构环境。
架构师在架构活动的第一步就是为架构活动搭建一个环境。
遗憾的是说，很多架构师都没意识到架构环境的内在价值，所以常常忽略了这一步。
打个比方，架构环境是架构活动，在企业真实物理环境中运行的虚拟机。
我们先要在企业的物理环境之上搭建一个完整的虚拟环境，然后才能开始架构活动。
这些物理环境包括物理环境、生化环境、软件研发环境、文化环境和有限的商业和研发资源等等。
我们在模块一呢已经有了线统系统的介绍。
这个环境呢是全集团共享的一个物理机，而你需要给你的架构活动搭建它自己的虚拟机，模拟这些完整的环境。
而你这个虚拟机如果宕机了，架构活动也就一块当掉了。
其中决策环境是最为重要的一环，也是我们在这个课程中会重点介绍的目标。
看看怎么在一个不那么友善的环境中搭建一个相对安全的架构环境节点。
二、确认目标。
我们在模块一就提到过，架构师需要保障整个架构活动，有且仅有一个正确的内标。
在这个节点上，架构师不仅需要确认这个目标的赞助人，还需要确认目标是正确合理可达的架就是一个定义，相信且满足smart原则的目标。
在这个过程中呢，切记简单相信，而是要通过事实数据和严密的逻辑来保障决策者、赞助者和执行者等干系各方的利益，为企业找到一个正确、合理可达的目标。
在这个过程中，我们也要试图从中发现一些具有长期价值的行动点，从而吸引那些坚持长期主义的同时，也投入到我们的架构活动中来。
节点三，可行性探索。
接下来呢是可行性探索架构师，必须要确定最终的目标可达很多团队会把这一步放置在架构规划之后，我们会在这节课里详细解释为什么不应该这样做。
反过来在这个节点呢，我们要最大程度的发现那些有可能叫停整个项目，或者迫使项目目标发生改变的重大风险。
那么怎么在最短的时间内识别尽可能多的风险？怎么从全局视角锁定最大风险呢？这就是我在这个节点要着重阐述的问题。
在这个环节的目标呢，是从向所有的合作方提前传递重大风险，并且得备合适的预案，从而得到决策者的支持，以继续全力推进整个项目。
当然，如果风险不可控，我们也可以选择叫停，避免重大损失节点。
四、架构规划有了架构环境，确定目标和可行性探索的基础。
我们就可以为架构活动制定宏观规划了。
这里有四个关键动作，分别是统一语义执行与映射任务、边界划分和规划确认。
而这些动作的目的呢就是进一步提升架构活动的高确定性，以及对目标的高本征信。
我们先看第一个动作，统一语义。
统一语义的过程是一个循环往复的识别、不同角色、不同场景、不同语境的过程，以及逐渐建模整合、修正语义的过程，直到所有的参与者的需求能够被准确无误的表达记录和传递，最终通过架构活动实现出来。
第二个关键动作呢是需求确认和执行与映射。
在统一语义的前提下，我们就可以确认架构活动的核心诉求了。
在这个规划的初期，我们要梳理架构活动的用户角色，发掘每一个角色的核心诉求，并且从活动目标出发，确认需求的正确性与合理性。
同时呢还要在统一语境下建立问题与模型，与执行者一起推导出问题，与到执语义的应射。
在这个过程中呢，许多领域映射的冲突呢可能会被暴露。
在这个时候呢，我们必须及时将冲突上升，然后尽快解决，尽量避免将冲突带到任务边界划分中去。
第三个关键动作呢是任务边界划分。
任务边界划分呢是真正体现架构师思考类的地方，也是很多基础问题集中爆发的地方。
在这个环节呢，我们需要依照搭建架构环境的方法，先为团队建立一组任务边界划分的决策信条，接着再进行任户需求和任务分解，尤其是对任务力度的判断。
最后呢我们要确保任务相关的有限资源被提前锁定。
第四个动作呢是任务规划确认，架构规划的最后一步是规划确认。
在这个过程，需要把任务转化成一个不但可行而且有约束力的规划，除了最小化项目交付的风险之外，还要确保所有参与者有能力、有意愿履行各自的责任，从而提升交付的确定性节点。
五正式启动。
很多人呢误以为启动会只是一个仪式性的工作，走过过程而已。
这是对启动的一个大误解。
启动呢代表着合同正式签约生效。
那么在正式签约之前，我们还将有机会将之前未暴露的重大风险公之于众。
这也是最后一个暂停或者是延后架构活动启动时间的机会。
是在这个环节呢，我们需要与执行团队完成一次深度的握手。
在接下来的实施环节，提供问题预警和冲突解决的机制还保执行过程中呢，可能发生的问题能够被及时解决，团队间的冲突能够被及时化解。
有了这些准备，我们才能以高质量的技术内容和充分的信心来开启项目节点。
六阶段型价值交付活动启动之后，我们就进入了阶段性交付这一环。
过去我们经常见到的都是项目，按照时间段被划分成多个里程碑。
这种划分方式虽然可以降低整体目标交付的不确定性，但是不能保障架构活动最终交付预期的增量价值。
我们将提出一种基于最小增量单元的交付策略来保障架构活动的最终产出。
这样做的目标呢是把问题尽早提给市场，让市场给我们指点迷津。
此外呢，我们还根据线上效果的评估和分析来调整阶段性目标，甚至是整个架构活动的目标节点。
七、全面上线节后呢就是全面验收的庆祝环节了。
如果这些工作都做到位，毋庸置疑，这将是最轻松的一个环节了。
值得一说，是在这个隆重最具仪式感的环节。
我们其实可以把高光时刻留给项目经理和各个产品研发以及运营团队的一线人员。
我们架构师呢反倒要站在幕后这个环节呢，没有其他的赘述了，课程里也不会单独交钱节点。
八、活动复盘和机会发现复盘呢是最频繁被提起，但很少被认真执行的一个话题。
不过在我看来，这是一个架构师成长的关键。
对架构活动来说，复盘的真正目的呢是要为企业的未来架构活动提升成功概率。
那么，在复盘工作中，架构师需要平衡好不同的审查视角和分析维度，通过搭建安全的复盘氛围，充足的前期准备，对复盘过程中针对性的控制。
对机会点的梳理和把控，以及对讨论过程中的深度剖析，从而发现生产在流程和假设中的问题，并找到有效的行动点，确保之后的架构活动能够吸取之前的失败教训。
好了，这呢就是互联网时代一个大型架构活动的全过程，以及架构师在每个节点上应该关注的事情。
我把这些内容整理成了一张思维导图，放在了文稿里。
听完音频之后你可以去查看，最后呢是两个小小的番外。
第一个番外呢是关于这个模块的学习建议。
你可能会问，这些步骤似乎有点多，有点繁琐啊，在敏捷开发的时代里，难道我不应该小步快跑吗？事实上，在实际的架构活动中，我也没有按照步骤一个一个执行。
不要在学习初期，我会想办法把完整的流程烂跑几遍，把每个节点的底层逻辑烂熟于心，然后再根据具体项目、工作环境以及参与团队来做精简。
不要连基本的招数都没学会，一上来就想着无招胜有招。
在我做团队规划的时候，我总会给团队leader们一套固定的架构规划模板，帮助他们提升架构能力。
一旦我看到某个人理解的很透彻，做的也很到位，我反倒劝他们丢掉模板，这就是先固化再内化，最后再优化。
第二个贩卖呢，我想再解释一下这个模块内容案例的背景。
模块里的案例呢都是以电商为背景的，主要是我们日常生活中会频繁接触电商选择这样的案例。
我不需要介绍那么多背景知识了。
案例的大背景是这样的，一个大企业呢有很多国际化的电商业务，各自的业务形态不同。
不过在细分领域内有很多相似的部分。
我们架构师呢需要在三个月内交付支持多个部门的国际化电商平台项目，让各个国家和地区的业务得以快速去启动、升级或者是增长。
我在四家电商企业做过几十个超百人参与的大型架构项目，模块中的案例呢均来源于我的经历。
不过呢跟任何一个具体的经历无关，我的目标呢是构造一个假想的案例，来覆盖更多的细分场景。
否则案例覆盖的细分场景有限，会让你陷入关键见到细节，复盘当中不利于观点的阐释。
用计算机语言来讲，我使用的呢不是单个案例，也就说instance,而是一个类类，也就是class.有的时候呢这种在类层面的讨论呢会引起一些理解上的困难。
那呢我建议你把这些类聚化成某一类类下面的有成有败的具体的场景，也就是案例。
这样呢会容易理解的多好了，就讲这么多，那么就开始架构活动的学习吧。
啊，这节课呢如果对你有帮助，欢迎你把你的课程转发给你的同事或者是朋友。
今天呢我顺别做一个广广告，我刚开了个人抖抖音，请大大在抖抖音上搜索郭东白。
并且关注我呢会在定期在上面发表一些比较新的，但是不一定那么成熟的观点，也欢迎大家批评指正，互相交流。
好了，今天我们就讲到这里，我们下节课再见。