Carrey Notes 写在前面
我不是“架构大佬”，也不是做纯平台/基础设施出身的人。我更多时候是以开发者的视角参与系统建设：既做过工期很紧、需要快速交付的项目，也参与过节奏更稳定、长期演进的项目。
我最大的体感是：工期紧并不可怕，可怕的是团队只能用“堆人、堆加班、堆临时方案”来顶。真正能做到“快而不乱”的团队，往往是把很多关键能力提前做成了默认配置：上线流程更顺、问题更好定位、改动更容易收敛，紧急时刻反而不需要全员燃烧。
还有一个常见现象：当项目已经乱了、已经延期了，再往里塞更多人，结果经常不是变快，而是更乱——新人要熟悉代码与业务、需要被带，沟通和集成成本会迅速上涨。
写这篇文章的动机也很简单：最近几年在一些公司里看到的工程水平不尽如人意——很多系统能跑，但一旦要长期维护、要多人协作、要持续迭代，就会越来越累。我想把自己亲眼见过、亲手踩过并认为“对一个不大不小的业务系统很重要”的东西，记录成一套更朴素、更好落地的标准。
这篇文章讨论的系统边界
我这里说的“系统”，主要指：一个不大不小的开发团队在做的、公司主营业务相关、需要长期运行并持续迭代的业务系统。
它可能是单体逐步拆分出来的，也可能一开始就是多服务；它可能有比较强的安全/权限要求（例如面向外部用户的登录与账号体系），也可能是内部核心业务系统。
关于你可能会问的“多大算不大不小”：我觉得 QPS、实例数、服务数当然是参考项，但真正把团队拖垮的通常是下面这些：
- 多团队协作、跨服务依赖开始变多
- 环境差异开始变大（配置、数据、权限等）
- 变更开始不受控制，黑盒逻辑越来越多
- 线上问题定位越来越慢，越来越依赖“某个人的记忆”
所以本文讲的“好系统”，不是追求某一种架构名词，而是讨论：当系统进入“长期运行 + 多人协作 + 持续变化”的状态时，哪些能力应该尽量具备，才能让开发更像在做可控的工程，而不是长期救火。
好系统的三个底层目标
我觉得一个“好系统”，底层目标可以先收敛成三个词：交付、运行、演进。
交付：功能能稳定、可预测地上线，而不是靠“临时爆肝”和感觉。
运行：线上出了事能尽快定位、尽快恢复，而不是全靠某个人的记忆和经验。
演进：系统能在持续变化里保持可维护——需求变了、团队换人了、依赖升级了，系统仍然能改得动，不会动不动就“牵一发动全身”。
这里我想提一个“很接地气”的工具：你可以用四个问题检查系统到底是在变好，还是在变累：
- 我们多久能上线一次？
- 一次改动从写完到上线，要拖多久？
- 上线后出问题、回滚、补丁的比例高不高？
- 真出事故了，从发现到恢复要多久？
业内把这一类衡量交付与稳定性的指标总结得很成熟（常被叫做 DORA 指标）。对我来说，它最大的价值不是“当 KPI”，而是帮你判断：你做的工程改造到底有没有让团队更轻松、更可控。
然后说到“演进”，我个人很喜欢把它和两本书的气质联系起来：
- 《数据密集型应用系统设计》让我更重视“可靠、可扩展、可维护”这些长期主题
- 《领域驱动设计》让我更重视“业务复杂时，系统必须能长期演进，否则迟早会烂”
很多长期项目的问题，恰恰不是“现在能不能跑”，而是“半年后还能不能改”。
平台化底座：让部署和运维更像写代码
很多时候，开发对平台化的诉求并不复杂：
- 我想要更省心的一键部署
- 我想要尽可能少的环境差异
- 我想更少为物理机器妥协（端口、机器分配、滚动部署手工操作）
- 我不想每天都在各种系统里点来点去改配置
如果没有统一的底座，很多事情会变成日常工作里绕不过去的一环：端口冲突、机器资源分配、滚动发布手工操作、环境差异导致的“我这能跑你那不行”、发布流水线配置散落在各处、服务多了之后靠人记拓扑关系……这些东西单个看都不难，但叠在一起就会形成很重的“心智负担”。
所以我才会非常偏向：当服务/实例规模上来后，能用 Kubernetes 就尽量用。原因不是因为它“更高级”，而是因为它更像一个统一的运行底座：你用相对一致的方式描述“应用该怎么跑、怎么升级、怎么扩缩容”，平台按规则去执行，很多细碎且高频的工作会被系统化吸收掉。
当然，也有人觉得“Jenkins + Nacos 够了”。我认可：如果 Jenkins 用得足够规范，配合注册/配置这一套，确实能支撑相当多项目。但现实里经常出现的问题是：能用不等于省心，更不等于能规模化复制。系统越大、团队越多，靠约定与零散配置维持一致性的成本会越来越高。
我还会用一个很粗糙的“直觉指标”辅助判断：生态与社区投入。比如（截至 2026-04-09，写本文时）：
- Kubernetes 的主仓库大约 122k stars
- Jenkins 的主仓库大约 25.2k stars （注：star 只能作参考，不能当结论。）
最后必须说缺点：Kubernetes 没有传统意义的 LTS，你不能指望“装上了就永远不动”。它大概一年发布三次版本；补丁/维护窗口也不是无限长，所以你要把“升级”当成长期开销的一部分，而不是一次性项目。
Git 化：把配置和变更留在版本库里
我非常认可“Git 化”的方向，而且我觉得它的核心不是“用不用 Git”，而是：让系统尽量少依赖某个人的记忆来维持运转。
我会把“Git 化”明确成一句话： 把系统的关键变更过程变成可追溯、可回滚、可复现的。
落地上，我认为至少要让这些东西尽量进入版本管理：
- 应用部署相关配置（不同环境差异、启动参数、依赖资源）
- CI/CD 流水线定义（构建、测试、发布、回滚策略）
- 关键运维配置（至少要能复现，出了事能对比）
- 关键变更记录（谁在什么时间改了什么、为什么改、如何回滚）
这样做的价值很直观：出了问题你不用翻聊天记录或靠人回忆；你可以从变更历史里快速定位“最近发生了什么”。更重要的是：它能显著降低人员流动对系统的伤害——人走了，知识不至于也跟着走。
项目管理：从靠记忆和喊话到可视化协作
我想先说现象：没有项目管理（或者没有一个大家共同承认的任务/进度视图），经常会出现这些事：
- 需求在群里飘来飘去，最后落到谁头上并不清晰
- 每个人都很忙，但没人说得清整体进度
- 风险点靠口头传递，传着传着就失真
- 临近交付才发现关键依赖没对齐，于是开始互相催、互相甩锅、互相觉得对方“不靠谱”
这时候团队会变得很依赖“人与人之间的信任”，但现实是：忙起来的时候，信任也顶不住混乱。
引入项目管理（形式可以很朴素：一个看板、一套状态流转规则、清晰负责人和截止时间）之后，变化通常很明显：
- 大家对“现在在做什么、卡在哪里、下一步是什么”更有共识
- 沟通从“解释我做了什么”变成“解决卡点”
- 压力大时也能更清楚地做决策：砍范围？加资源？还是换方案？
我想强调：工具不重要，重要的是“团队共同承认的一张真相表”。有了它，你就不需要完全依赖口头承诺。
文档化：让业务和系统能被长期维护
很多团队觉得文档是“额外工作”，直到有一天他们发现：
- 新人上手要靠带、靠问
- 业务规则全靠口口相传
- 同一个概念每个人叫法不一样
- 系统改动越来越谨慎，因为没人敢保证自己理解对了历史
到这个阶段，团队往往会出现错觉：我们缺的是更强的人、更会写代码的人。其实缺的是：可共享的上下文。
我心里更“实用主义”的文档标准是：写文档不是为了显得专业，而是为了让系统在变化里还能讲得清楚。至少要把下面这些内容写清楚并且能更新：
- 核心流程怎么走
- 关键名词怎么定义（别出现同词不同义）
- 关键规则与边界条件是什么
- 接口契约怎么约定，变更怎么留记录
- 常见线上问题的定位路径是什么
尤其是长期项目，“能演进”非常重要，而文档是演进成本里最便宜、最容易被忽略的一部分。
代码评审：让质量和规范在团队里生长
对新项目来说，代码评审最重要的价值不是“挑错”，而是三个更朴素的目标：
- 把质量闸门前移（问题别等到线上才爆）
- 让团队形成一致的工程标准（大家写出来的东西能互相接得上）
- 让知识扩散（系统不是某个人的私有领地）
为了避免把评审做成负担，我更推荐新项目从很务实的方式开始：
- 小步提交，减少超大改动一次性进来
- 先统一“底线规则”（格式化、命名、异常处理、日志与必要指标），能自动化的尽量自动化
- 评审沟通聚焦“长期维护成本”和“风险”，少做无意义的抬杠
好的评审机制，会让项目“越写越顺”，而不是“越写越怕改”。
（完）