技术人三要素

本文是专栏《成为会带团队的技术人》的笔记,自己以前也有带团队经验,但自我感觉做得不够好,这个专栏给我很多启发。

技术人三要素:稳定性、债务、架构

稳定性

怎么衡量系统稳定性?

一般来讲,通过统计系统不可用的时长或次数就可以对稳定性进行量化,比如业内常说 4 个 9 的可用性(即 1 年内 99.99% 的时间系统是可用的,不可用时长仅为 52.6 分钟)。

针对稳定性的提高也可以看作围绕事故的治理,可以从事故发生的前、中、后分阶段来看对应的关键点。

  • 事故的类型:可用性事故、资损类事故。
  • 事故前预防:主动治理减少系统的风险隐患,重点在变更管控、可用性设计、应急预案与演练。
  • 事故中应急:“止血、恢复”是原则。
  • 事故后复盘:目的不是追责,查根因、改进架构、完善应急、总结经验才是我们想要的。

事故的类型

从事故特性上看,我们可以分为可用性事故和资损类事故。

可用性事故:技术原因导致系统部分或者全部功能不可用,业务没办法正常完成对应流程或者提供对应服务。比如因为网络、DB、接口 Bug 等原因,用户没办法登录、商品列表不显示等。

资损类事故:系统的功能都能正常使用,但因为逻辑、计算等原因让业务的某一方产生了资金损失。比如用户支付一律为 0 元、错发 999 无门槛优惠券、商户清结算少打款给商户等等。

故障处理的生命周期

故障处理的生命周期,可以分为 4 个阶段:发现异常、排查问题、判断决策、恢复处理。这 4 个阶段对应的行动并不是完全串行的,虽然有一定的依赖关系,但在实际的处理过程中应该并行展开。类似 fork/join 的模式,不断完成小任务、不断汇总信息,不断做出判断与决策,形成循环直到故障恢复。

1. 故障发现

故障发现

总的来说,人工的被动反馈在时间和速度上有较强的不确定性,很容易出现“小故障 * 长时间 = 大事故”的情形。而纯粹的技术指标监控又会忽略掉接口正常响应,但是业务异常的场景,只有两者结合,通过监控告警,最大程度上缩短故障感知的时间,才能早发现早解决,减少业务影响。

2. 故障排查

  • 直接锁定:最近的变更点与异常现象间有直接的逻辑关联,进而可以直接锁定到故障点。比如,刚对下单接口进行了发布变更,接口的 QPS 曲线就暴跌,可以基本断定是刚才的发布导致。

  • 排除法:当干扰因素过多(用户、订单等几个系统同时发生变更,引起订单下跌),很难直接锁定到故障点,就要结合业务场景,让整条架构链路上的所有关联方进行自查自证,通过排除法锁定故障。

3. 故障决策

业务决策非常复杂,能否第一时间止损很大程度上取决于技术 Leader 的现场反应和操作, 要注意故障决策的两个关键点 :

一定要有明确的决策人、主导者和有效的沟通方式(钉钉群、多人电话会议、紧急作战会议室等),让信息可以通畅地交流出来,并且决策人可以根据情况做判断与取舍,形成所有人明确的处理结论。 比如,第一时间停止错误红包的发放,确保故障没有增量,并把决策第一时间同步给团队成员,并同步相关负责人后续的动作,对已发放的红包,明确要求负责人汇总各类关键信息(红包数量、涉及金额、涉及用户数、有效时长、可能资损等)。

所有的信息一定要数据化,不同的数据量级会导致决策不同,比如红包错发 50W 可能只是暂停发放,但是存量红包依然可以核销,损失公司可以承担。但是如果错发 5000W,大概就要涉及一系列的调整,这是非常影响决策的。

4. 故障恢复

应急“三板斧”:变更回滚、服务重启、降级&限流。

故障恢复

如何有价值地做事后复盘?

你可以从时长、现象、处理时间轴、根因、改进计划这几个维度进行复盘, 在以下几个方面进行深究:

事故时长:1-5-10(即 1 分钟发现、5 分钟响应、10 分钟恢复) 是否达成,如果没有是为什么?哪个环节用时最多,如何提高和改善?

事故根因:根因不等于直接原因,一个事故的直接原因往往并不复杂,但是根因可能是多个维度的缺失,需要像剥洋葱一样一层层找下去。拿库存接口变更这个Case来说,直接原因就是某段代码逻辑变更导致,但是应该在测试、发布、监控、应急影响、预案设计等多个环节展开去看,根因的挖掘并不忌讳“吹毛求疵”。

事故改进措施:由点推到面、明确到人、明确时间。与根因类似,要结合多个维度形成组合拳的改进点,避免一次性动作,要将重点放在对未来、对同类问题的预防上。核心就是如果再一次发生类似的问题,这些改进措施是不是能起到作用。

关于事后复盘,你可以这样理解,我们要深挖事故如何发生的、如何处理的、未来怎么预防。但要避免情绪化,在复盘会上的反思、感悟、懊恼没有任何意义,如何带领团队把精力放在改进措施的落实以及事故前的治理上更有价值, 另外,你需要留出时间让团队伙伴进行内部的 Review,避免为了开会而复盘。

没有质量的交付,再多再快都毫无意义。

稳定性

变更会引起90%以上的故障

1. 变更需要监控

有效的监控要回答三个问题:

是否有问题发生?

哪里发生了问题?

发生了什么问题?

2. 有效灰度必须有耐心

灰度从来不是为了测试,也不等于 A/B Test。它本身是为了对抗“未知的不确定性”。

要想实现灰度的有效性,关键点在于时间和流量。

时间:每个灰度阶段至少有 5 ~ 10 min 的观察,在监控、日志和各方反馈没有异常后再扩大灰度范围,确保一些运行时异常或量变积累质变的问题可以暴露出来。

流量:有时一些业务场景需要特定的触发条件,比如满足某些条件的用户或满足某些条件的订单,那么在灰度时就不能仅通过单位时间内有没有异常来判断,还要确保有足够的有效流量。

3. 回滚就是变更的“后悔药”

要知道,系统并不是天然可以无缝回滚的,想要系统具备回滚的能力,在设计与实现阶段需要付出额外的精力。可回滚的本质是系统的兼容性设计与实现,比如常见的“只增不改”,一个 API 内要调整很多实现逻辑才能满足新业务的需求,此时不妨直接新增一个 API ,两个 API 保持参数一致,那么一旦新 API 有异常直接切换回旧的 API 即可。

所以,不论是灰度计划还是回滚策略都应该在架构设计阶段就去考虑,结合排期、风险程度、成本投入这些方面,要做好评估与平衡。

坚守 Design For Failure 的架构理念

“Design for failure and nothing will fail”,最早是 AWS 的一条最佳实践,即面向失败进行系统设计。可以理解为:考虑系统所有可能发生故障或不可用的情形,并假设这些可能都会发生,倒逼自己设计足够健壮的系统。

1. 将经验教训沉淀下来

历史是最好的老师,我建议你总结并分析过去发生过的事故,并结合常规分布式系统的可用性风险,以此梳理出一个围绕事故隐患的风险点 Checklist,在需求迭代或者架构设计时,通过它高效地找到系统实现的薄弱环节。

除了完善 Checklist,在团队普及这种设计理念之外,更关键的是将这些解决方案沉淀成设计原则,让研发人员可以在实际中落地。

2. 通过演练验证预案设计

设计并实现了自己的故障演练系统,日常主动制造事故上下文来验证我们的设计与系统是否可靠。

把稳定性当作机制与文化去建设

系统稳定性结果好坏很大程度上取决于技术 Leader 的重视程度,如果一个团队的管理者都不能身体力行的去重视它,而仅仅只是喊喊口号,那就不要指望团队成员能认真地对待这件事。

1. 新人 Landing 从稳定性学习开始

2. 每人不低于 35% 的稳定性 KPI

3. 好的坏的都要在阳光之下晒一晒

可用性治理与预防

建立资损概念的宏观认知

从广义上来看,存在理论损失也应该算资损, 比如因为搜索推荐系统出问题(不论什么原因)导致这一阶段广告的收入减少,或者因系统 Bug 导致用户取消订单的申请被默认同意(虽然原本商户可能也会做同意处理,但是申诉的话平台依然要赔付),类似预计收益减少或者因系统问题产生赔付的场景都应算为资损。

资损定义和分类

资损防控的三个关键

1. 防:资金视角做风险点识别

资损风险点识别

2. 监:一致性与正确性双核对

针对资损感知的核心思想是:基于线上业务结果收拢进行监控,基于线下业务场景扩散进行核对。

与可用性监控围绕接口的技术指标不同,资损更关注的是数据核对,监控的并不是运行状态而是运行结果,并且资损监控的粒度要求非常高,精细到每一笔交易、每一次金额计算、每一个红包发放。所以资损监控的有效性很依赖于场景的覆盖率,仅覆盖几个关键场景是不足以规避资损风险的,除了要定期梳理外,每次系统有变更或者新功能时,都需检查是否有新的核对点,以及旧有核对公式是否需要调整。

资损监控核对

3. 控:资金拦截 + 资产控制

除了防和监,资损防控的关键主要在“控”字上,我们希望在问题发生后第一时间止损,这就需要技术在系统层面对资金和资产有很强的控制能力。这种能力的表现就是: 不仅可以通过预案将某些场景与链路降级,还可以拦截资金的流出和资产的使用,同时具备快速订正错误数据的能力。

在我们开始处理资损事故时,会有三个共性的需求。

问题止血不新增:核心是关闭问题产生源头,往往通过业务场景降级来实现,比如对错误红包或者满减活动进行下线。

控制资金流出:核心是对资金和资产进行拦截与冻结,避免外流后损失无法修正,比如禁止用户下单时勾选使用有问题的红包。

存量数据订正:核心是捞取问题数据后可以快速地批量处理,比如批量更改红包的金额、甚至直接将红包无效。

虽然其中一些操作对用户体验是有损的,但有而不用是一回事儿,无能为力则是另外一回事儿,其中:

资金拦截的能力主要从资金的流入和流出这两端进行把控。以红包而言就是管控其创建与核销。在红包创建时,有预算系统进行管控,避免无限制地生成红包进而超发。在红包核销时,由交易和营销系统进行验证,确保订单上下文以及红包合法,避免问题红包被核销进而造成无法挽回的资损。

资产管控的能力则是资产的快速锁定和数据订正展开,以红包而言,如果不同模版不同活动的红包都有一个统一的批次号,就可以通过这个标记快速捞取某一批有问题的数据。同时如果提前准备批量订正的脚本,或者有订正数据的平台,就可以快速修改红包金额、使用时间、使用门槛等关键信息,甚至批量无效所有问题红包。

你需要注意,这些能力的实现更多依赖于技术 Leader 在日常需求迭代和架构设计时,是否有意识引导团队加强这方面的建设。大部分的预案思路来源于过去已经发生的问题,或者对未来可能发生问题的假设,将预案常态化是你重点关注并推进落地的。

除了建设预案,还要有预案演练,以此保证预案的有效性。技术 Leader 更应该鼓励测试和开发的同学主动做攻防演练,寻找漏洞、验证止损方案、及时发现并修复问题。

资源预案止损

技术债务

技术债务在研发领域类似于“金融债务”的概念,大部分情况下是说因为人为妥协,系统的设计和实现没有遵循最佳实践,所以虽然在短期做到了快速交付,但也制约了系统未来的可扩展性,并且埋下了稳定性的风险隐患。就好比你信用卡分期消费,虽然可以立刻满足自己的购买意愿(得到眼前的好处),但同时也会背上一定的负担,在未来必须得偿还。

技术债务

重视技术债务的原因

  • 影响系统扩展和需求交付
  • 恶性循环导致人员流失

技术债务的恶性循环会影响开发团队的生产力,并降低团队的士气和成员的驱动力,而低生产率导致团队只能优先交付功能,这就推迟了技术债务的解决,从而进一步增加技术债务。

如何从循环的债务困境中突围而出?

1.债务的 Owner 是技术 Leader

要想解决技术债务,你需要找到技术与业务的平衡点,我的经验是“内外双修”:

内:加强团队的战斗力,减少债务产生的机会,增强债务处理的能力。

外:要深刻地理解业务,并且做好与其他协作方(尤其是产品、业务)的沟通。这样你才能理解协作方想解决什么问题,他们以为要么A、要么B才能解决的问题,既懂技术又懂业务的你能否找到方案C?

我建议你,面对选择题时不要只看到可选项,要永远寻找第三条路。 如果实在没有其他选择,在技术妥协的同时,做好沟通,让协作方明白方案的临时性以及对未来的影响,争取到承诺在未来给你足够的空间解决这些问题。

2. 通过 CheckList 识别债务

建立一个债务 Review 的 CheckList ,并且不断完善。技术债务从表象上可以做一些细分(我整理了一张图):

技术债务划分

通过现象我们就可以反推出一些导致现象的原因,将这些原因结合系统的架构进行分类,就会形成一个个具体的关注点。这些关注点往往是结合我们之前踩过的坑、发生过的问题,以及编码、架构上广为遵守的一些最佳实践所形成的,这样你就可以制定出一个较为详细的 CheckList 用以具体的债务识别(下图供你参考)。

债务细分

3. 有计划地分级偿债

  • 关键链路优先: 并非所有糟糕的设计与实现都能产生严重后果,即使能,它们发生的概率也不一样,而关键链路意味着业务影响最大,同时日常的改动频率和事故风险也较高,优先解决它的收益是最大的。

  • 历史事故命中优先: 一些设计与实现在过往导致过线上真实问题的发生,不管是否发生在本系统还是当前团队,都相当于已经被证实过的这类债务的严重性,所以应该尽早修复它们,避免类似问题反复发生。

  • 可扩展性优先: 在 CheckList 以及债务现象中我们可以发现,有些问题影响了系统未来的演进,增加了迭代成本,有些问题影响系统的维护,比如代码风格没有统一、缺少文档,在处理时应该优先处理影响可扩展性的问题,后续逐步处理影响可维护性的问题。

权责清晰优先: 一些问题在处理时受到历史架构、组织分工(康威定律)的影响,会导致系统的权责不清晰,这类系统的推进和改造往往需要花费更多的时间精力,并且从顶层设计出发去重新考量,所以权责清晰的部分可以优先处理。

总的来说,通过对技术债务进行分级,实质上也是一个问题分治的过程,将大问题切分成一个个小问题,这样就可以将它们加入日常的迭代中,形成一个分期偿还技术债务的计划,逐步减少技术债务,减轻负担让团队与系统可以轻装上阵。

4. 正视债务做好预防

除此之外,预防永远胜于治疗,技术债务汇总预防的关键点在于那些“原本未知”的技术债务要逐渐减少,大家对于实现质量的追求不能止步于“测试没有明显 Bug”,写出能运行的代码是不够的,还要易维护易扩展。而你可以从几个方面着手:

  • 提升团队认识,通过项目复盘、系统重构、事故 Review 等各种机会,通过实际的案例让研发同学清楚技术债务对团队产生的负担,以及对个人能力提升的影响。

  • 建立机制流程,比如在方案设计阶段向下深挖一下实现的要点,更多资深的开发参与到架构评审,或者促进团队形成 code review 的习惯并且达成一个共识标准以提升系统质量。

  • 确保资源投入,在通过债务识别和分级后,将还债的投入提前计算到每次迭代中,确保有一定的资源投入其中。

5. 一些常见的误区

通过 CheckList 做债务识别,然后定期诊断、水平扫描、债务定级、分期偿还来做技术债务的处理,最终在团队认识、机制氛围、资源保障上下功夫做预防,这就是技术债务管理的核心思路。

而这个过程中,有一些问题是日常你很容易走入误区的,我简单总结了一下几个注意点:

  • 存在即合理,动态变化才是王道。 不要总想着毕其功于一役,也几乎不太可能有完美的实现或系统,接受技术债务一定会存在的事实,重点在于控制债务积压的程度,欠债本身不可怕,欠债不知且不还才可怕。

  • 不积跬步无以至千里。我们往往过度轻视日常微小积累,又过度重视“大事件”产生的影响。日常这里凑合一下,那里妥协一点,没人关注小问题发生的原因。而一旦发生重大的影响,则恨不得把之前的系统全盘推翻重做一遍。

  • 机制流程外还要讲策略和方法。很多技术 Leader 觉得这件事很重要,讲的同时设计了很多流程和机制,不遵守就要承担怎样怎样的后果,这样往往事半功倍。机制流程不是越多越好,也不能光有惩罚而没有激励,同时最重要的是你不能只追杀要结果,要给帮助、给方法、给支持。

债务总结


大项目:把握关键点,谋定而后动

认清异同,做到心中有数

项目迭代周期

在这个常规流程中,技术团队的重心是把执行做到位,你要更关注过程管控,确保系统交付。

大项目与常规项目的核心差异点,我认为主要在于这个“大”字上,你可以从三个方面去理解。

  • 出发点不同,业务期望更大
  • 规模不同,复杂度更高
  • 结果评判标准不同,影响更大

把握关键点,谋定而后动

关注效果更重于关注交付,这是大项目的核心特征。

不要为了重构而重构,要知道你要的结果是什么。

大项目的失败存在一个共性的问题:围绕业务结果的思考、计划不足,目标的定义不清晰或没有充分同步给所有相关人,项目同学知其然而不知其所以然。连目标都没有共识,何谈执行到位,项目成功?

所以我认为越是重大的项目,在计划、设计、准备上投入的精力就应该越多,谋定而后动。

  • WHY(项目为什么做)

  • WHAT(项目做成什么样)

what

  • WHO(哪些人来一起做项目)

  • HOW(启动项目后如何做)

    • 合理拆分任务(模块)是项目成功的一半

    • 保持风险意识,敬畏墨菲定律

做好充分的准备之后,可以召开立项会,将 WHY、WHAT、WHO、HOW 的信息与思考同步给项目相关人员。通过 Kick Off 会议确定项目的基调、同步必要信息,为项目推进扫清障碍。

如何处理棘手问题

问题一:缺兵少将怎么办?

项目组人时你要注意以下几点。

  • 当项目开始时,从更大的范围内寻找合适的同学,而不是看你团队有哪些人。

  • 将参与项目的同学在一定时间内的汇报关系和绩效考核汇总到项目组中,由项目负责人根据实际情况重新安排每个人的权责,并确定绩效的绑定关系与比例。

  • 项目交付并不等于结束,所有人的绩效结果都应和项目目标的达成情况紧密且长期关联。

最后,有时不仅要解决“缺兵”的问题,还要认真考虑是否“少将”?要充分考虑当前的人员是否适合做项目的 Owner,以我的经验来看,项目 Owner 几乎决定了项目成败的 80%,如果 Owner 能力不足,你要给予帮助和支持,或者另找他人,乃至上级的帮助,不要在 Owner 的人选上妥协,毕竟项目成败才是关键。

问题二:推不动的到底是人还是事?

  • 搞明白冲突现象下的利益诉求: 不同关联方产生观点冲突的现象背后其实是利益冲突,你要搞清楚彼此的顾虑。比如我不愿想让某个系统字段落到订单中,主要是考虑到订单系统的可维护以及稳定性,如果你能解决我的顾虑,会容易说服我。

  • 为项目结果适当妥协: 在很多情况下,我们无法做出完美的方案,可能就是要在系统内通过很糟糕的实现去实现需求。项目没有 100% 完美,抓住核心原则不放弃,可控部分适当妥协换取项目前进是很好的策略。

  • 通过项目地位和决策机制推动项目: 大项目往往是公司重大战略下的产物,一般情况下,不会有人去反对公司的某项既定战略,而你可以通过大项目的重要性在体系内争取更多的资源和帮助。如果你面临一些冲突,要学会利用决策机制,通过更高级别成员的沟通决策拿到解决方案。

问题三:一定会有项目变更吗?

常见的变化往往有两种:

  • 项目演进过程中识别出之前未能识别或考虑缺失的点,导致方案需要调整。

  • 出自老板的需求变更,很多情况下都是要新增内容。

3个重点

  1. 驾驭大项目是你的试金石和分水岭,对自己职业规划有一定要求的同学一定不要放过打磨修炼的机会。

  2. 在大项目中,往往人的问题会比技术与系统的问题难解决,因为与人相关的问题未必完全理性和逻辑,那么此时你也不妨看看感性的沟通与交流是不是有更好的效果。

  3. 时刻牢记你将项目按时上线没有故障只是做到了60分,更关键的是业务效果,所以除了盯紧开发过程外,还要在最开始的业务与产品设计阶段就投身其中。

项目

业务理解:深入业务是做好架构的前提

为什么技术要理解业务?

产品需求不等于业务诉求

同样的,技术 Leader 可能会花时间参加各种会议,尤其是产品需求的会,在会上如果仅仅是听“自己团队应该做什么”,而没有思考和探究业务的根本诉求,那么就我的经验来说,技术团队不可避免的会成为工具人。Leader 缺乏独立思考,人云亦云,最后整个团队都会被拖累,这也是为什么大多数研发团队被产品以及业务按在地上摩擦的原因!

领域建模的前提是理解业务

正因为没有仔细看业务的现状、推测业务的发展、去思考业务上对交易的诉求,我们认识的只是一个个需求,而非整体的从业务维度思考系统的设计,导致系统复杂度越来越高。所以要想设计可靠、简单、真正可持续迭代的系统,深度理解业务就是前提,你对业务的理解程度影响了你对系统未来发展的预判程度。

提升技术团队的使命感

你写的每一行代码,线上的每一次发布,都会改变用户的体验,解决实际的问题,你就会发现这份工作的意义。

如何理解业务?

  1. 不要盲信产品(不要盲信产品与 PRD,在讨论 PRD 和执行开发任务之前学会独立思考,深入理解业务想要解决什么问题,需要什么效果或作用,严格把控那些伪需求和无价值需求,防止它们侵占团队的技术资源。)
  2. 建立走进业务的机制
  3. 业务上多参会多画图(参加评审会,梳理流程图等等)

理解业务

架构设计:治理好系统复杂度才最务实

治理好系统复杂度才最务实

C.A.R. Hoare曾说过:“软件设计有两种风格,一种是将软件设计得很复杂,以使其缺陷没那么明显;一种是把软件设计得很简单,以使其没有明显的缺陷”。

系统的结构清晰、即使整体繁杂但是每个局部都相对简单、链路干脆直接,没有不必要的冗余。

衡量复杂度

  • 理解成本高:需要很长时间才能理解系统模块的组成及运作,比如新同学加入或系统交接时,老同学很难讲完整、新同学不容易听明白,要几周甚至1~2个月才能完全了解系统的实现和运作机理。

  • 变更牵连多:哪怕是实现一个小的需求都要改造系统的多个部分、甚至多个系统(上下游等),有的还需要协调其他团队或部门,结果导致迭代成本高,并可能引入更高的风险。

  • 一张图装不下:即你无法在一块白板上清晰且完整地画出系统主要功能场景的架构图,可能是牵连的系统、服务、组件过多或者链路设计不合理导致的。

  • 加人无法解决问题:即便你增加人员也难提高系统的交付速度和产出质量,比如原本3个人负责系统,增加到 6 个人的交付产出可能和 3 个人时所差无几,原因在于复杂度过高并且系统结构模糊,很难通过清晰的分工让生产力最大化。

而你可以结合这 4 点表现特征以及自己的主观感受进一步判断系统的复杂度是否过高,如果系统复杂度过高,可能带来一系列问题:迭代压力大、经常延期、稳定性问题频发等。这时,你要着手治理复杂度,尽力不让问题扩大到难以解决只能重做系统的程度。

复杂度治理的思路

“高内聚、低耦合”,系统简化和分治。

简化就是去掉不必要的复杂,让设计与实现保持简单。

分治则是将原本难解决的问题,拆分到可解决的粒度,然后再逐一击破。

常见的拆分方式是垂直拆分和水平分层: 垂直拆分把差异明确可以独立迭代的业务拆分开;水平分层把共性的能力下沉隔离。比如电商场景中,购物车和订单可以分成两个服务,它们虽然在业务流程上前后关联,但是各自具备独立完整的业务场景和生命周期,商品加入购物车未必会交易生成订单,可以各自独立存在;而库存和商品则是强依赖的关系,库存无法独立于商品存在。

拆分与合并不绝对,过度地拆分会导致系统无法高内聚,零散分离的系统,会增加稳定性风险和治理与迭代的代价,并且造成大量的协作成本。Linus也曾说过:把复杂系统拆分成模块,似乎没有降低整个系统的复杂度,它降低的只是子系统的复杂度。而整个系统的复杂度,反而会由于拆分后的模块之间,不得不进行交互,变得更加复杂。

复杂度治理实践

  1. 相比 coding 更重视设计
  2. 永远做 2 套以上的方案
  3. 从 MVP 的视角考虑设计:从 MVP (最小完整业务的角度)去考虑系统要如何设计与实现,先做减法再做加法
  4. 关注上下游的实现
  5. 坚持“日拱一卒

没必要一定把系统做成中台

没必要一定把系统做成中台,不做中台就会落后更是无稽之谈,不过,你可以借鉴中台的思路作为系统设计与演进上的形态参考。

复杂度