系统上线时是四个专家搭的：他们懂这套编排、懂那套一致性协议、也懂为什么某个参数必须是那个值。两年后团队只剩一个入职半年的新人守着，系统照常跑，但每次告警都变成一次集体求助，每次改动都要先确认"改了会不会炸"。系统没坏，是维护能力和系统复杂度之间的匹配断了。
要谈的不是"技术水平够不够"——技术水平是绝对量，匹配是相对量。同一套架构，在十人平台团队手里是常规资产，在一个人手里是持续负债。
判断匹配是否成立有个粗糙的除法：列出"出问题时需要知道的东西"，再数团队里知道其中六成以上的人有几个。这个数小于 2，系统就已处在断裂带上——只是它还跑着，没人报修。
1. "维护得起"的三个判据
判断一个系统在当前团队手里是否维护得起，不看架构图好不好看，看三件事能不能做到。
| 判据 | 具体检验 | 做得到的样子 | 做不到的样子 |
|---|---|---|---|
| 能不能定位故障 | 从告警到定位到具体环节 | 有明确的第一、第二步动作 | 先翻群聊记录、再问原作者 |
| 能不能安全改动 | 改一处是否知道影响面 | 有小范围可回滚的路径 | 每次改动都当高风险操作 |
| 能不能解释行为 | 能说清"为什么是这个值/这个顺序" | 关键参数有理由与约束记录 | 只能回答"当时就这么配的" |
其中第二条最容易被误判成"人不够熟练"。实际上"不敢动"多半是系统属性：没有回滚路径、没有隔离环境、没有可观测手段，换谁来都不敢动。
维护性自检（任一为否，就不是人的问题，是系统的问题）
─── 定位故障：能否在 30 分钟内说出是哪个组件、哪一步变慢
─── 安全改动：能否在不动生产配置的前提下验证一次改动
─── 解释行为：能否说出三个关键参数各自的约束来源
─── 若第二条为否 → 先补隔离与回滚，再谈培训
2. 能力缺口与能力集中度
能力缺口最常见的表现不是"不会做"，而是回避做：需求排到这块就往后拖、改动被拆到最小、能绕开就绕开。
| 缺口表现 | 表面解释 | 真实含义 | 试探方法 |
|---|---|---|---|
| 改动一拖再拖 | 排期问题 | 无人能评估风险 | 问"改这一处的影响面有哪些" |
| 只敢改配置不敢改代码 | 流程要求 | 代码层无人能读 | 让新人讲一遍主流程 |
| 出故障只能重启 | 习惯做法 | 缺定位手段与知识 | 追问上次故障的根因 |
| 所有问题都找同一个人 | 他比较熟 | 能力高度集中 | 统计近三个月谁在改该模块 |
能力集中度是同一问题的另一面：单点依赖的人也是单点。他休假、离职、或者只是太忙，系统就进入不可维护状态。
$ for m in scheduler consistency router; do
echo "--- $m"
git log --since='12 months ago' --pretty=%an -- "src/$m" | sort | uniq -c | sort -rn
done
--- scheduler
41 alice
2 bob
--- consistency
18 alice
16 carol
─── scheduler 只有一人动过，其维护能力等于该员工的可用性
对应动作是把"关键路径"定义清楚，再要求每条关键路径至少两人能改，且其中一人不是原作者——原作者在场时最容易跳过理解直接照抄。
3. 引入新技术前的三个问题
技术选型清单里通常有性能、生态、许可，但决定两年后能不能维护的是另外三个问题。
| 问题 | 好答案的样子 | 坏答案的样子 |
|---|---|---|
| 谁学？ | 指名的人 + 计划学的时间 | "大家都会用得到的时候学" |
| 多久能独立改？ | 有可验证的里程碑（如独立改一次配置） | "看情况" |
| 出问题谁兜底？ | 明确的内部 owner 或可购买的支持 | "社区很活跃" |
第三个问题上最常见的错误是把文档可用性当成支持可用性。社区文档能帮你解决白天遇到的常规问题，不能帮你解决凌晨三点的集群分裂。
第一个问题的常见错误是"谁学"写成岗位而不是人名：写岗位时匹配关系落在组织上，出问题无人具体负责。实践做法是指名一人 + 指定一人为后备，后备不要求同等熟练，只要求"真人不在时能按手册恢复运行"。
兜底能力的三层（按响应速度排序，越往下越慢）
─── 内部有能直接上手的人 → 分钟级
─── 厂商/供应商有 SLA 支持通道 → 小时级
─── 社区 issue / 论坛 → 天级，且不保证有答复
─── 只有官方文档 → 无兜底，等于自己扛
"先在边缘试"是把上面三个问题变成可验证动作的标准做法：选一个非核心、可回滚、故障影响可控的场景先上，而不是拿核心链路做第一站。
| 阶段 | 目标 | 可观测的回报 | 常见周期量级 |
|---|---|---|---|
| 边缘验证 | 有人能跑通并在故障时恢复 | 独立完成一次故障恢复 | 数周 |
| 第二场景 | 能改动、能解释行为 | 独立提交一次变更并回滚 | 数月 |
| 核心试点 | 有人能兜底夜间问题 | 有一次夜间自主处理记录 | 一到两个季度 |
回报不是"技术变先进"，而是能独立处理的人从 1 个变成 2 个。试点跑完人数没变，说明学到的是操作步骤而非可迁移的理解，此时停下比继续铺开更划算。
4. 外部支持、文档失效与双向调整
"我们照文档做就行"这句话的失效点在于：文档描述意图，不描述约束。文档会说"把副本数设为 3"，不会说"为什么不是 5：因为跨区带宽在高峰期不够"。后者才是改动时真正要判断的东西。
| 文档里写的 | 文档里通常没写的 | 后果 |
|---|---|---|
| 推荐参数值 | 该值成立的前提条件 | 环境一变就出事 |
| 标准操作步骤 | 为什么是这个顺序 | 顺序被优化掉后出现静默错误 |
| 架构图 | 哪些地方是刻意留的不一致 | 被"顺手统一"后性能下降 |
所以能力匹配的抓手是把约束显式化，而不是把文档写得更长：
constraint:
id: replica-count
current: 3
reason: 跨区带宽在业务高峰期接近上限，副本增加会压缩同步余量
valid_while: 跨区带宽峰值 < 70%
breach_signal: 同步延迟 p99 连续 10 分钟上升
owner: platform
revisit: 每季度或用例变化时
另一个方向常被忽略：调整是双向的。能力与复杂度里，复杂度是快变量——它随一次选型或一次"顺手加个中间层"而变，而能力是慢变量，以季度为单位变化。用快变量去追慢变量，是这类错配无法收敛的根本原因：每次觉得"人跟不上"就再加一层抽象，缺口反而变大。
能力补不上来时，降系统复杂度是合法解，而且常常更快。
| 方向 | 动作 | 见效速度 | 代价 |
|---|---|---|---|
| 补能力 | 招人、培训、结对阅读 | 慢（季度级） | 培养周期长，人可能走 |
| 降复杂度 | 去掉一层抽象、合并组件、用托管服务 | 快（周级） | 可能牺牲部分能力与灵活性 |
| 换托管 | 把自建换成有支持的服务 | 中 | 成本与绑定风险 |
| 缩范围 | 只保留核心能力，砍掉边缘特性 | 快 | 功能减少 |
招聘与培训的时间尺度其实接近，差别在风险形态：招聘解决"有没有人"，培训解决"这个人能不能改"，两者都不解决"夜里谁接"。所以判断要不要买外部支持，先看响应时间要求，而不是预算。
5. 排错：五种"系统在跑但没人维护得起"
| 现象 | 真实原因 | 第一步动作 |
|---|---|---|
| 改动一拖三个月 | 无人能评估影响面 | 补回滚路径与隔离环境 |
| 每次故障只能重启 | 缺定位手段与知识 | 补最小可观测集，再补运行手册 |
| 所有问题都找同一个人 | 能力集中 | 强制结对，第二人独立执行一次 |
| 新人照文档做却出事 | 文档缺约束 | 把约束条目写进配置旁 |
| 引入新技术后无人敢动 | 缺兜底与试点路径 | 回退到边缘场景，先建立第二持有人 |
| 关键路径一改就出问题 | 约束未被显式化 | 把约束条目写进配置旁并标注失效信号 |
排错顺序也很重要，不要跳过前两步直接进入"招人"：
─── 1 补隔离环境与回滚路径 → 再看"不敢动"是否消失（系统问题）
─── 2 补最小可观测集 → 再看故障定位时长是否下降（工具问题）
─── 3 仍不行 → 才是能力问题：结对、培训、补第二持有人
─── 4 能力短期补不上 → 降复杂度或换托管，而不是加抽象层
6. 度量与边界
能力匹配是慢变量，度量要选能反映趋势的项，而不是一次性盘点。
| 度量 | 含义 | 观测方式 |
|---|---|---|
| 关键模块持有人数 | 能独立改动该模块的人数 | 提交统计 + 独立变更验证 |
| 故障定位时长 | 从告警到定位到环节的耗时 | 事故记录的时间戳差值 |
| 新人首次改动时长 | 入职到完成首次独立改动 | 入职记录与提交记录对比 |
| 文档化约束条目数 | 已显式化的约束数量 | 约束文件条目计数 |
| 边界场景 | 结论 |
|---|---|
| 系统规模极小（单进程、无依赖） | 匹配压力低，无需专门治理 |
| 变更频率极低（一年数次） | 可以接受更低的能力覆盖，靠手册兜底 |
| 已有厂商支持且响应满足要求 | 内部能力要求可下调，重点转为接口与成本 |
| 系统即将被替换 | 只做维持性投入，不补深度能力 |
一句话判据：当"能不能安全改动"这一条长期为否时，无论团队技术水平如何，这套系统都已经和维护能力脱节了——要么补人，要么降复杂度。
自测
- "维护得起"的三个判据中，哪一个最容易被误判成人的问题，为什么？
- 能力缺口的典型表现是什么，为什么它不像"不会做"？
- 为什么单点依赖的人是单点风险？用什么方式能把这个风险降下来？
- 引入新技术时，把"社区很活跃"当成兜底能力会带来什么问题？
- 文档说"把副本数设为 3"，它通常没说什么，缺了会怎样？
- 能力补不上来时，降系统复杂度为什么常常比培训更快见效？