课程地图 — 六个部分,24 个模块

一张地铁线路图:先一眼看到所有线路,再一站一站地坐过去。

课程从思维走到实践。先讲架构师怎么思考(mindset)。再讲系统内部怎么搭(structure),以及系统分散到网络上之后会变成什么样(distribution)。接着是质量属性(quality attributes)、和人打交道(people),最后是这个职业的走向(future)。

怎么读:每个概念都有它的英文术语(查文档、面试时听到的就是它)、一个日常画面、一张图,以及一张带"是什么 / 例子 / 代价 / 关联"几栏的卡片。课程结尾有一份速查表,把所有概念放在一页里。

Long-term thinking — 架构师以年为单位思考

工程师造一座明天就有车开过去的桥。架构师则问:等卡车开始上桥会怎样、等隔壁起了一个新城区会怎样、等维修费比桥本身还贵会怎样。

工程师通常解决被提出来的那个问题。架构师则先检查这个问题有没有被提对。这不是清高,也不是想"聊点高深的"。只不过一个架构决策,通常比一行代码更难改、改起来更贵。

脑子里最关键的那个转变:你不再只问"我该怎么做 X",而开始问**"我们为什么需要 X、有哪些备选、会失去什么、三年后它会是什么样"**。

Reversible vs irreversible decisions — 为系统的形态负责

木匠把搁板装歪了,你能挪。设计师把承重墙放错了位置,房子要带着这个错误活上几十年。

架构师没有义务亲自做每一个技术决策。但他有义务为那些"定下系统形态"的决策负责:service boundary、数据模型、集成协议、scaling 策略、安全、observability、迁移路径。

这里有用的区分是 reversible decisions(可逆决策) 和 irreversible decisions(不可逆决策)。可逆决策一天或一周就能改:一个日志库、一个按钮颜色、一个小模块的内部结构。不可逆或难以撤销的决策,会改变系统的轨迹:数据库、tenancy 模型、一个 API contract、event 的存储方式、service boundary。

Trade-off — 脱离 context 的 best practice 是坏建议

泥泞路上 SUV 赢轿车。城里轿车赢 SUV。要是只走三个街区又没地方停车,自行车赢过两者。

你没法脱离 context 去评判一个架构决策。REST、GraphQL、Kafka、PostgreSQL、Kubernetes、microservices、monolith——全都是带价格的工具。一个 trade-off 是一次有意识的交换:latency vs throughput、consistency vs availability、time-to-market vs 可维护性、简单 vs 灵活。

架构师不说"Kafka 比 RabbitMQ 好"。他说:"我们需要按 key 的 event ordering、高吞吐、replay,以及一个持久化的 log;作为交换,我们付出 Kafka 的运维复杂度。"专业的语言,听起来就是这样。

Over-engineering vs under-engineering — 复杂度是一种税

每多一个抽象,就像房子里多一个房间。房间可能有用,但得打扫、供暖、维修,还得向客人解释。

当复杂度买来了重要的属性——故障隔离、独立发布、安全、扩展、可测试性——它就是有用的。但"为了未来"而加的复杂度,通常会变成一笔永久的税。

over-engineering 和 under-engineering 这两个词,只有放在一起才有用。Over-engineering:复杂度出现在真正的痛点之前。Under-engineering:系统已经撞上了上限,而架构没给增长留余地。架构师的工作不是选一个极端,而是守住中间。

Technical debt — 是贷款,不是垃圾

为买设备贷款,能让生意提速。为办派对贷款,只会留下宿醉和利息。

**Technical debt(技术债)**是一个"现在让我们更快、却在将来产生修改成本"的决策。有时这是对的:要试水市场、要赶截止日期、要留住客户。问题出在团队把所有东西都贴上"债"的标签:烂代码、缺测试、混乱的依赖、过时的库。

一个有用的模型是 Martin Fowler 的 Technical Debt Quadrant:deliberate / inadvertent(有意 / 无意),prudent / reckless(审慎 / 鲁莽)。有意且审慎的债:"我们暂时不做 multi-region,因为只有 200 个用户、一个市场。"无意且鲁莽的债:"我们不知道自己需要 transaction。"

Debt interest — 债是要付利息的

路坏了,每趟出行都多花五分钟。一个月后它就不再是个坑,而是对整座城市征收的一笔税。

技术债的利息,就是之后每一次改动都变慢。团队越常碰某个区域,这笔债就越贵。所以热点 domain 里的债,比一个很少用的后台管理页面里的债更危险。

架构师要谈出一套还债策略:到底什么算债、它带来什么风险、什么时候回头复查决策、什么信号说明"该还了"。没有这些,"技术债"就成了一种情绪化的争论,而不是一件被管理的工具。

Cognitive load — 架构必须装得进一个人的脑子

地铁线路图有用,不是因为它画出了隧道里的每颗螺丝。它画的是线路、换乘和行进方向。这就够做决定了。

**Cognitive load(认知负荷)**是系统要求工程师付出的脑力。有 intrinsic load:domain 本身的复杂度。也有 extraneous load:由糟糕的架构、不明显的联系、偶然的例外和"魔法"带来的额外复杂度。架构师消除不了业务本身的复杂度,但有义务降低偶然的复杂度。

好的模块可以单独理解。好的 bounded context 有自己的语言和自己的 invariant。好的团队拥有一块能装进自己脑子里的领域。

Conway's Law — 团队结构会变成系统结构

如果三个部门互不沟通,它们的产品几乎总是看起来像三个产品被硬塞进了同一个菜单。

Conway's Law 说:一个组织设计出来的系统,会复刻该组织内部的沟通结构。如果架构的边界和团队的边界对不上,团队就会不断闯进别人的地盘。

Team Topologies 给出了几个有用的标签:stream-aligned team、platform team、enabling team、complicated-subsystem team。这不是 HR 的时髦词——它是一件架构工具。有时,正确拆分系统要从正确拆分职责开始。

Cohesion & coupling — 按层切、按 domain 切,还是按数据流切

屠夫不会随便乱剁一头牲畜——他沿着关节下刀。好的拆分也在找自然的断点。

拆分不是"分到不同文件夹"。它是选择责任在哪里结束。**High cohesion(高内聚)**意味着组件里的一切都围绕同一件事。**Low coupling(低耦合)**意味着组件对其他组件知道得很少。

横向切得到 layers(层):UI、application、domain、infrastructure。纵向切得到 feature 或 bounded context:billing、identity、catalog、comments。真实系统两种都需要,但把一种当成另一种,很危险。

Bounded context — 糟糕的边界会在改动中暴露自己

如果换厨房水龙头得把卧室拆开,问题就不在水龙头。

拆分糟糕的一个迹象:一个小改动波及五个模块。另一个迹象:一个模块因为不同的原因而改——今天因为产品,明天因为数据库,后天因为某个集成。

DDD 里的 bounded context 正是用在这里。它是一条边界,边界内每个词只有一种含义。billing 里的"Customer"和 support 里的"Customer"可以是不同的模型。硬把它们并成一个,往往会造出一个脆弱的"万能"模型。

Dependency Rule 与 DIP — 依赖朝中心流动

地基不该依赖窗帘的颜色。要是依赖了,这房子就是反着设计的。

Clean Architecture、Hexagonal Architecture 和 Onion Architecture 说的是同一件事:重要的逻辑放在中心,细节放在外围。HTTP、SQLAlchemy、Next.js、Kafka、Redis、Stripe——这些都是细节。它们重要,但不该决定业务规则。

Dependency Inversion Principle 说:高层逻辑依赖抽象,具体实现从外部接入。落到代码上就是 port 和 adapter:service 接收一个 PaymentGatewayProtocol,而不是在内部自己构造一个 StripeClient。

Abstraction — 为吸收变化而存在,不是为了好看

adapter 该放在插头真正不一样的地方。如果你只因为喜欢 adapter,就在每个插座上都装一个,房子反而更不安全。

不是每个类都需要接口。但凡是碰到外部世界、时间、随机性、网络、文件系统或数据库的东西,在测试里都应该能被替换。否则你测的就不是业务逻辑——而是在单元测试里启动了一个小型的生产系统。

一层的代价是更多文件、更多字。回报是可测试性、可替换的基础设施、清晰的边界。如果没有回报,这一层就是累赘。

API contract — contract 比传输方式更重要

护照检查不在乎门是什么牌子。它在乎的是接受哪些证件、适用哪些规则、出问题时会发生什么。

REST、GraphQL、gRPC 和 WebSocket 是不同的沟通方式。REST 适合面向资源的 API 和简单的缓存。GraphQL 在不同客户端需要不同形状的读取时有帮助。gRPC 适合有类型的服务间通信。WebSocket 用于实时的双向事件。

选哪种传输方式是次要的。重要的是 API contract:schema、错误、idempotency、versioning、backward compatibility、deprecation policy。

Idempotency — 它让你在真实世界里不翻车

你按十次电梯按钮,电梯不该来了又走十次。它应该明白意图只有一个。

**Idempotency(幂等)**是指重复一次操作,产生相同的最终效果。在联网的系统里,重试不可避免:超时、retry、重复的 webhook、worker 重启。如果创建支付、订单或消息不是幂等的,系统迟早会多做点什么。

架构师在 contract 层面设计幂等:idempotency key、unique constraint、安全的重试、清晰的状态。

Data model — 数据比应用活得更久

外墙一周就能重刷。地基浇错了,会在整栋楼的寿命里一直提醒你。

语言、框架、UI 可能换好几轮。但表、event、key、关系和历史记录会留下来。数据模型里的一个错误,往往会变成产品每个未来版本里的错误。

**Normalization(规范化)**减少重复和数据不一致的风险。**Denormalization(反规范化)**加快读取,并简化 read model。OLTP 系统为事务优化,OLAP 为分析优化。你没法设计出一个模型,让它完美地同时服务这两类工作。

Event sourcing 与 CQRS — 一件强力工具,不是一种信仰

银行对账单不只存当前余额——它存的是操作的历史。正是这个,让你能解释余额是怎么来的。

Event sourcing 把变更存成一串 event,再从中重建当前状态。当历史、审计、状态恢复和 replay 很重要时,它很有用。代价很高:event schema 的演进、查询的复杂度、eventual consistency、要求很高的工具链。

CQRS 把写模型和读模型分开。它能大幅简化复杂的读取系统,但会带来同步和延迟。仅仅因为"听起来很有架构感"就引入 CQRS,是把一个问题变成两个问题的昂贵做法。

Single source of truth — 不等于只有一个数据库

一家公司可以有很多报表,但必须只有一份官方的工资名册。否则发薪日就成了一场闹剧。

Single source of truth 的意思是:对每一个重要的事实,你都知道权威版本住在哪里。缓存、搜索索引、read replica、materialized view——这些都是派生出来的副本。它们可以很有用,但不该假装自己是原始的真相。

**Stateful(有状态)**组件持有状态,需要小心对待:事务、锁、恢复、备份。**Stateless(无状态)**组件更容易扩展和替换,但它们依然依赖住在别处的状态。

Cache 与 locking — 偶尔会撒谎的第二份真相

冰箱上贴的日程很方便,直到有人在手机日历里把会议改了时间。

**Cache(缓存)**用新鲜度换速度。缓存最难的问题不是"怎么放进去",而是"什么时候失效"。TTL、explicit invalidation、write-through、write-behind、cache-aside——这些是在复杂度、新鲜度和负载之间的不同折中。

当两个操作争抢同一份状态时,就会出现 race condition。Optimistic locking 说:"冲突很少,我们在写入时检查版本。"Pessimistic locking 说:"冲突很危险,我们事先就加锁。"两者在不同条件下都是对的。

CAP 与 PACELC — 网络是不确定性的来源

monolith 是一间屋子里的对话。分布式系统则是身处不同时区的人之间的通信——信有时会丢,会到两次,或者迟到。

在分布式系统里,你不能只是"调用一个函数"。服务之间隔着网络、timeout、retry、partial failure、不同的时钟、不同版本的代码。在 monolith 里原本是本地事务的东西,变成了一套协调协议。

CAP theorem 常被糟糕地概括。实践中有用的版本是:在 network partition 期间,你要在 consistency 和 availability 之间二选一。PACELC 补充说:即使没有 partition,你依然要在 latency 和 consistency 之间选。

Consistency models 与 Saga — consistency 有不同的口味

两个人看同一份 Google Doc,几乎瞬间就看到相同的内容。两个人看一笔银行转账,可不能满足于"几乎"。

Strong consistency 给你新鲜的真相,但要付出 latency 和 availability 的代价。Eventual consistency 容忍暂时的不一致,但往往扩展得更好。Causal consistency 保留因果关系:如果 event B 依赖 A,B 就不该先于 A 变得可见。

Saga pattern 把一个长的业务事务拆成若干步骤,并配上 compensating actions(补偿动作)。Two-phase commit 能提供跨资源的原子性,但在真实的分布式系统里既昂贵又脆弱。架构师挑的不是"最严格"的模型,而是足以应对风险的那个。

Modular monolith — 常被低估的起点

一座组织得好的仓库,比十座小仓库更快——如果反正是同一个快递员在它们之间来回跑。

monolith 不是一句骂人话。糟糕的 monolith 是一团乱糟糟的依赖。好的 modular monolith 有严格的内部边界、分开的 domain、明确的接口,以及单一的 deployment unit。对小团队来说,这往往是最好的起点。

Microservices 在你需要独立发布、自治的团队、不同的扩展特征、故障隔离,或不同技术栈时有帮助。代价是:网络调用、observability、分布式事务、DevOps 开销、versioning、服务之间的安全。

Distributed monolith 与 Strangler Fig — 两头最糟的结合,以及出路

就像住在各自独立的公寓里,却每拿一把勺子都要跑去隔壁。

Distributed monolith 看起来像 microservices,但服务并不自治:共享的数据库 schema、同步调用链、只能一起发布的版本、牵一发动全身的改动。团队付出了分布式的成本,却没得到独立性。

Strangler Fig pattern 让你能小心地迁移:把旧系统包起来,逐步抽出能力,沿着真实的业务边界切,而不是沿着表去切。

打电话要求双方此刻都有空。信可以稍后再读——但它可能丢、可能迟到,或者要求回复。

**同步(sync)**调用容易理解:发出去,等回答。但如果接收方慢或者不可用,受苦的是发送方。通过 queue 或 pub/sub 做 async,能让你扛过故障和负载尖峰,但它要求另一套思维模型。

queue 通常把工作分给多个 consumer。pub/sub 则把一个 event 广播给许多订阅者。Kafka、RabbitMQ、SQS、Redis Streams——不同的工具,有不同的顺序、持久性、replay 和运维模型。

At-least-once delivery — exactly-once 几乎总是营销话术

如果一封信寄了两次,正经的会计不该把工资发两遍。

实践中,你按 at-least-once delivery 加上 idempotent consumer 来设计。一条消息可能到两次;handler 必须扛得住。Dead letter queue 用来存放在合理次数的尝试之后仍无法处理的消息。

Backpressure 是"接收方跟不上了"的信号。没有它,系统会优雅地接收一切,然后在内部死掉。

Tail Latency — 平均响应时间几乎总是在撒谎

如果九个人一分钟内拿到了餐,第十个人等了一个小时,平均值看起来还能忍。第十个人不这么认为。

这就是 tail latency 的概念。先说三个词。Latency 是单次操作的延迟。Throughput 是系统在单位时间内处理多少次操作。Percentile 展示分布:p50 是中位数,p95 表示 95% 的请求比这个值快,p99 是长尾。

用户感受不到平均值——他们感受到的是长尾。当一个页面依赖好几个后端调用时,tail latency 尤其重要:慢响应的概率会叠加起来。

Profiling — 先做 profile,再优化

不做 profile 就去修性能,就像只看一张鞋子的照片就给病人看病。

这就是 profiling 的实践:先度量,再优化。N+1 查询、多余的 round trip、糟糕的索引、序列化、锁竞争、GC 停顿、冷缓存——它们看起来都是"慢",但治法各不相同。

Amdahl's Law 提醒你:加速比受限于你真正优化的那部分系统。Little's Law 帮你思考队列:在吞吐不变的情况下,latency 越大,系统内部积压的在途工作就越多。

Vertical vs Horizontal Scaling — 它们买到的东西不同

你可以买一辆大卡车。也可以买十辆小的。前者更简单,后者更灵活——但需要一个调度员。

Vertical scaling(scale up)是把一台机器变强。在还有余量时很简单。Horizontal scaling(scale out)是增加更多实例。更灵活,但需要 stateless 的应用层、load balancing、一套共享状态的策略和 observability。

数据库比应用更难扩展。Read replica 帮的是读,不是写。Sharding 能拆分数据,但迫使你选一个 shard key。糟糕的 shard key 会把扩展变成负载失衡。

Scale Cube — 扩展功能和扩展负载同样重要

一座城市不只靠人口增长。它靠学校、医院、道路和规则增长。

系统要吸收的不只是更多流量,还有更多的产品面。如果每个新功能都要重写一个共享的 God-service,这个系统在组织层面就无法扩展。

这里有用的模型是 scaling cube:X 轴是克隆,Y 轴是按功能拆分,Z 轴是按数据或 tenant 分区。

Retry、Circuit Breaker、Bulkhead — 没有策略的 retry 是对自己的攻击

门打不开,敲一次是合理的。每秒敲一千次,就成了门和邻居的麻烦。

Retry 用于瞬时的故障。但 retry 需要上限、timeout、exponential backoff 和 jitter。否则,局部故障就会变成 retry storm。

Circuit breaker 会暂时停止对一个卡住的依赖发起调用。Bulkhead pattern 隔离资源:如果某个 downstream 挂了,它不会把你所有的 worker 线程和连接池一起拖下水。

SLI / SLO / SLA — SLO 把可靠性变成一份合约

"我们会尽力"不是列车时刻表。时刻表会说明什么算正常,什么算故障。

SLI 是你度量的东西:成功率、latency、新鲜度。SLO 是目标:30 天内 99.9% 的请求成功。SLA 是对客户的承诺,并附带后果。

Error budget 告诉你,你被允许花掉多少不可靠性。如果预算烧光了,团队就停止追功能,转而修可靠性。这是用业务语言讲出来的工程质量。

Authentication vs Authorization — 是两回事

护照证明你是谁。车票证明你可以去哪里。一个不能代替另一个。

Authentication(AuthN)回答"这是谁?"。Authorization(AuthZ)回答"他被允许做什么?"。把两者搞混很危险:一个用户可能正确地登录了,却依然无权查看别人的发票。

RBAC 通过角色授予权限。ABAC 考虑属性:资源所有者、tenant、地区、对象状态。基于 session 的 auth 更容易撤销;JWT 无需数据库就更容易验证,但更难撤销。选哪个取决于威胁和生命周期。

Threat Modeling — 职业性的偏执

好的架构师像攻击者一样思考,不是因为不信任人,而是因为信任现实。

Threat modeling 是在攻击发生之前,系统地寻找威胁。STRIDE 帮你去找:spoofing、tampering、repudiation、information disclosure、denial of service、elevation of privilege。Defense in depth 意味着多层保护:输入校验、authz、加密、audit log、rate limiting、least privilege。

Secrets management 不是"把密钥放进 env 就不管了"。你需要理解轮换、访问、审计、blast radius,以及泄漏时会发生什么。

Observability — monitoring 告诉你哪里不对,observability 帮你理解为什么

"check engine"灯很有用,但修理工仍然需要仪表、历史记录和诊断工具。

Monitoring 回答"有地方不对了"。Observability 回答"为什么"。observability 的三大支柱:logs、metrics、traces。Structured logging 让日志可以被查询。Metrics 展示聚合数据。Distributed tracing 跟踪一个请求穿过各个服务的路径。

Correlation ID 是个能救命的小东西:同一个请求 ID 贯穿 gateway、服务、queue、worker 和 downstream。

Symptom-based Alerting — 按症状告警

用户不在乎 CPU 是 92%。他们在乎的是结账用不了。

好的告警说的是用户的痛点——这就是 symptom-based alerting:错误率、latency、支付失败、数据过期。坏的告警说的是一个完全可能是正常的原因。如果告警嘈杂,团队就会不再信任它们。

Runbook 回答"凌晨 3 点该做什么"。Post-mortem 回答"我们怎么确保这不再发生"。Blameless:目标是改进系统,而不是找出罪人。

ADR — Architecture Decision Record 胜过记忆

口头约定,在第一次休假、第一次离职或半年后的第一次争论之前都管用。

Architecture Decision Record 记录 context、决策、备选方案和后果。ADR 不必是一部小说。好的 ADR 回答:我们在解决什么问题、选了什么、为什么没选其他备选、什么时候回头复查。

文档不是为了审计——而是为了下一次改动。新来的工程师需要理解的不只是"怎么做",还有"为什么"。

C4 Model — 图是工作工具,不是装饰

地铁线路图不画电线和螺栓。它画的是线路和换乘。这就足以不迷路。

C4 model 给你四个层级:Context、Container、Component、Code。通常前三个就够了。当交互的顺序很重要时,sequence diagram 很有用。很少需要完整的 UML;零散的几张图则是需要的。

**Living documentation(活文档)**和代码放在一起,在 PR 里更新,并被 review。被遗忘的 wiki 里的文档,很快就会变成历史小说。

Risk Translation — 把风险翻译成听众的语言

医生对病人不会只说拉丁文的名字。他会解释哪里会疼、疗程多长、要避免什么。

这就是 risk translation 的实践。你可以对工程师说:"支付 callback 上没有 idempotency。"业务需要听到的是:"如果 webhook 重试,我们可能重复扣款,或者把商品发两次;这是财务和声誉上的风险。"

Stakeholder mapping 帮你看清谁在乎什么:产品要 time-to-market,安全要降低风险,财务要可预测的成本,客服要可理解的行为,工程要可维护性。

RFC — 书面提案能给争论降温

白板前的争论,往往是嗓门最大的人赢。书面提案则迫使论点脱离嗓门,独立站得住。

RFC(Request for Comments)描述问题、约束、各种选项、选定的方案、风险和 rollout 计划。好的 RFC 会在决策变成规定之前,邀请大家来批评。

Disagree and commit 只有在一场诚实的讨论之后才成立。如果团队没被听见,那不是 commit——而是压制。

Influence without Authority

指挥不会演奏每一件乐器,但没有指挥,乐团很快就会变成一群各弹各曲的才子。

这就是 influence without authority 的概念。架构师不该成为每个决策的瓶颈。他的工作是定原则、讲清边界、培养人,并在犯错代价很高的地方出手。

架构师的 mentoring 不是"照我做的做"。而是教会提问:你见过哪些备选方案、放弃了什么、打算怎么验证风险、责任到哪里为止。

Delegation with Guardrails — 委派不等于转移责任

船长可以把舵交出去,但不能说船的航向不再是他的事。

一部分架构决策应该由各团队来做。否则架构师就成了一条队。但必须有 guardrails(护栏):原则、review、ADR、平台约束、quality gate。

当一个决策不可逆、破坏系统的 invariant、带来安全风险,或影响多个团队时,架构师出手。

Non-functional Requirements — 同样是业务需求

对一家商店来说,"黑色星期五结账能用"不是技术细节——而是钱。

Non-functional requirements(NFR)——性能、可用性、安全、合规、可运维性——不是"技术上的想要"。它们是产品的属性。架构师把它们翻译成业务影响:损失的收入、监管风险、客服成本、上市的速度。

Cost of delay 帮你讨论的不只是做这件事的成本,还有等待的成本。有时需要一笔没有即时 ROI 的架构投入,因为没有它,接下来的功能会开始变得更贵。

Build vs Buy — 不是面子问题

不是每家公司都该为了开灯,自己造一座发电站。

**自建(Build)**给你控制权和差异化。**购买(Buy)**给你速度,并降低运维负担。Vendor lock-in 是真实的风险,但它本身并不构成反对购买的论据。问题是:如果供应商改价格、改 API 或降质量,退出要花多少?

架构师帮助产品看清 capability map:哪些能力是业务的核心,哪些更适合买。

Specification-driven Development — spec 的质量成了瓶颈

如果施工队快了十倍,起约束作用的就不再是砌砖的速度。而是图纸的质量。

AI agent 加快了实现,但并没有消除架构。一个提得糟糕的任务,只是更快地变成糟糕的代码。Specification-driven development 的意思是:首要的产物是对行为、边界、invariant、测试和验收标准的规格说明。

在 AI-native 的流程里,架构师写更少的底层代码,写更多精确的文字。他审的是 diff、测试、架构边界,以及与 spec 的一致性。

Agent Output Review — agent 的代码值得和人写的 PR 同样的纪律

一个每小时写一千行的快手 junior,依然需要 review。速度不会让代码变对。

你不能因为 agent 的代码能编译就接受它。你需要测试、eval、import 边界、类型检查、安全 review。Scenario evaluations 尤其重要:系统必须通过真实的用例,而不只是 happy path。

AI-native 的组织,赢的不是"人人都在 vibe-coding"的地方,而是有强规格说明、小步迭代、自动化检查和架构负责人的地方。

Ivory Tower Architect

有人在山顶上画了一座完美的城市,却从不走下山去看看人们实际往哪儿走。

这就是 **ivory tower architect(象牙塔架构师)**反模式:决策是在远离代码、运维和团队的地方做出的。图很漂亮,实现却遭殃。解药很简单:读 PR、看 incident、和工程师聊天、亲自走一遍改动的路径。

Resume-driven Development 与 Cargo Cult

如果你既没有水也没有消防员,却因为能给邻居留下印象而买一辆消防车,那就怪了。

Resume-driven development 为了简历上多一行而选技术。Cargo cult engineering 照搬别人决策的形式,却没有它背后的理由。NIH 综合症(Not Invented Here)逼你在成熟的外部工具本可以做得更好的地方,自己再写一套。

另一个陷阱是 technical perfectionism(技术完美主义)。那个从未到达用户手里的完美架构,会输给一个足够好、能交付、还能演进的系统。

T-shaped / M-shaped Skills — 从系统中学习,而不是从 hype 里学

厨师不是靠看刀具广告成长的,而是靠理解食材、火候、时间和味道。

新技术值得用一连串问题去学:它解决什么问题、引入什么代价、已经在哪里失败过、有哪些备选方案、要满足什么条件它才会变得有用。

T-shaped skills 让你在一个领域有深度,在相邻领域有广度。M-shaped skills 出现在成熟的架构师身上:几根深的支柱——数据、分布式、安全、产品、AI 工具。

Learning in Public — 加速成熟

当你把一个决策写出来讲清楚时,你思维里的漏洞会在生产环境发现它们之前就暴露出来。

Learning in public 的意思是公开地、用文字来学习。写 ADR、RFC、工程笔记、post-mortem,以及对决策的简短复盘。向比你强的架构师学习——不只是他们选了什么,还有他们是怎么推理的。

人们会去模仿的那类架构师,通常不是懂最多术语的那个。而是在他身边,团队开始问出更好问题的那个人。

课程地图:一切如何相连

旅程终点的一张地铁线路图:现在你看到了线路在哪里交汇。

思维塑造结构、数据和质量。结构被记录进文档,质量由安全和运维来验证,文档和风险说服业务。这一切合在一起,扩展成 AI-native 的工作方式和个人成长。