一次网关选型，对比表列了十二个维度：吞吐、尾延迟、协议支持、生态、许可证、学习曲线、社区活跃度……每一行都评了分。唯独没有一行是"我们团队里谁在半夜三点接它的告警"。半年后系统本身没出过问题，但每次升级都要两个人请假研究，值班表上排不出第二个人——这就是组织因素没进选型表的价格，它在一年之后才寄到。
这篇只给判据：哪些组织维度必须进评分、权重怎么排、技能缺口怎么处置，以及什么条件下它们该让位。
1. 选型表里缺的那一列
| 对比维度 | 谁在承担 | 何时寄到账单 |
|---|---|---|
| 吞吐与延迟 | 用户 | 上线当天 |
| 生态与文档 | 开发者 | 开发期 |
| 许可证 | 法务 | 采购时 |
| 可维护性 | 值班的那个人 | 第一次故障 |
| 技能覆盖 | 招聘与培训预算 | 招人时、离职时 |
前两行是短期账，后三行是长期账。多数选型表只做到前三行，因为它们的成本在立项周期内可见。
2. 组织因素的五个维度与权重
| 维度 | 观察什么 | 建议权重 | 缺失时的表现 |
|---|---|---|---|
| 人手技能 | 团队里能改配置、能读源码的人有几个 | 高 | 只能等外部支持 |
| 运维能力 | 会不会看它的指标、会不会热恢复 | 高 | 故障平均恢复时长按小时到天计 |
| 排障经验 | 有没有人处理过它的典型故障 | 中 | 每次故障都从零开始 |
| 招聘市场 | 招这个技术要求的人要多久 | 中 | 关键人一走，系统变成黑盒 |
| 时间预算 | 现在有多少窗口做迁移与培训 | 中 | 新组件永远停在 PoC |
权重不必精确，但必须排序。排序本身就是决策：把"运维能力"排在"性能"前面，结论常会换组件。
3. "最好"与"最合适"：可维护性优先于性能
性能差距在多数业务里落在可优化区间内：加一层缓存、改一次批量化、换一个索引，收益常常大于换组件。而可维护性差距不可优化——一个没人会运维的组件，性能再好也只是把风险换了个形态。
选型判断顺序（前面的不满足，后面的不进入比较）
1) 有没有人能维护？ → 没有 → 培训 / 招人 / 外包 / 换组件
2) 出故障时谁来修？ → 无人 → 换组件或买支持
3) 性能是否够用？ → 不够 → 优化，优化不到再换
4) 生态与成本是否可接受？ → 最后比较
这条顺序会砍掉一些"看起来很先进"的候选，砍掉的正是未来三年最贵的那部分。
4. 技能缺口的三种处置
| 处置 | 见效时间 | 成本形态 | 风险 |
|---|---|---|---|
| 培训 | 数周到数月 | 学习期产能下降 | 学完可能离职 |
| 招人 | 一到两个招聘周期 | 薪资溢价 + 上手期 | 市场供给紧时招不到 |
| 外包 / 买支持 | 立即 | 持续费用，按年计 | 供应商退出即断供 |
技能覆盖矩阵（每格填：能改 / 能读 / 只会用 / 无人）
组件A 组件B 组件C
成员甲 能改 能读 只会用
成员乙 能读 无人 无人
成员丙 只会用 能改 无人
矩阵里"无人"的列，就是这次选型真正的风险清单。
5. 运维复杂度是长期税
选型时看到的是一张采购单，实际支付的是一条年费。
三年总成本 ≈ 初始集成 + 年运维人力 × 3 + 年故障损失 × 3 + 退出成本
年运维人力 = 值班占比 × 人力成本 + 例行升级工时 × 人力成本
| 组件 | 初始集成 | 年运维 | 三年合计的量级感 |
|---|---|---|---|
| 单进程、无状态 | 低 | 几乎为零 | 最小 |
| 有状态、需备份还原演练 | 中 | 备份验证 + 升级窗口 | 中等 |
| 集群、分片、需容量规划 | 高 | 扩缩容、再平衡、故障演练 | 显著 |
| 需要自己编译/打补丁的分支版 | 高 | 每次上游发布都要跟 | 最高 |
每多一个组件，就多一份值班负担。这不是抽象说法：值班表按周轮，五个人轮三个组件和轮八个组件，疲劳程度完全不同。
6. 团队规模决定可承受的组件数量
| 团队规模 | 可长期维护的组件数量（经验量级） | 值班可行度 |
|---|---|---|
| 1–2 人 | 极少，尽量用托管 | 无值班，只有"谁有空" |
| 3–5 人 | 少量核心组件 | 勉强轮值，故障期全员上 |
| 6–10 人 | 可引入中等复杂度组件 | 可分组值班 |
| 10 人以上 | 可承担自建与平台化 | 需专职平台角色 |
这张表是量级参考，按团队排障经验核对。它的用处是反向约束：组件清单超过团队规模能承受的数量时，选型的正确动作是减法，而不是再评一个新组件。
7. 生态与文档质量对维护成本的实际影响
| 信号 | 对维护成本的影响 | 怎么验证 |
|---|---|---|
| 文档只有 quickstart | 边界场景全靠读源码 | 搜三个你一定会遇到的边界问题 |
| Issue 有官方回复 | 疑难可解 | 看近三个月 issue 的关闭方式 |
| 版本发布有迁移说明 | 升级可预算 | 看最近两个大版本的 breaking change |
| 有可运行的示例仓库 | 上手快 | 克隆下来按文档跑一遍 |
最实用的验证动作只有一个：让要接手的人按官方文档从零搭一次。搭不出来的部分就是未来三年的隐性工时。
8. 社区衰退时的退出成本
| 衰退信号 | 退出成本 | 预案 |
|---|---|---|
| 提交频率下降、issue 无人回 | 中：问题只能自己解 | 冻结版本、锁定依赖 |
| 主要维护者离开 | 高：安全修补断供 | 评估 fork 成本或替换 |
| 被商业公司收购后改许可 | 高：可能被迫迁移 | 提前确认许可变更条款 |
| 项目归档 | 最高：无修补 | 迁移，按季度排期 |
退出成本要在引入时估一次，而不是等信号出现。引入一个组件的同时就要写下它的退出路径：数据怎么迁、接口怎么抽象、依赖锁在哪一层。
9. 治理风险：许可证、停更、被收购
引入前的治理检查
[ ] 许可证类型与商用方式已确认（是否 copyleft、是否有附加条款）
[ ] 近 12 个月有发布，且 issue 有关闭
[ ] 主要维护者不止一人
[ ] 有明确的版本支持周期
[ ] 依赖树里没有同类的重复组件
最后一条常被忽略：同一职责装两套，维护成本是相乘而非相加——排障时要先判断"这次是哪一套在起作用"。
10. "我们已经会这个"是合法理由
它常被当成保守，其实是最被低估的选型依据。会，意味着故障时有人能修、升级时有人能预判、招聘时知道去哪找。
| 理由 | 是否合法 | 说明 |
|---|---|---|
| 我们会，能自己修 | 合法 | 直接降低故障恢复时长 |
| 我们不会，但它更快 | 不完整 | 快出来的收益要减去学习与运维成本 |
| 我们不会，但社区活跃 | 不完整 | 活跃度不等于你的排障能力 |
| 公司强制技术栈 | 合法（约束优先） | 组织因素让位于此 |
反向偏差同样要防：因为会，所以不评估。旧技术在新约束（数据量、并发、合规）下同样会失效。
11. 引入新技术的组织成本
| 成本项 | 具体形态 | 常被低估的原因 |
|---|---|---|
| 评审 | 方案评审、安全评审、架构评审 | 只算会议时间，不算返工 |
| 规范 | 编码规范、配置规范、发布流程 | 规范写了没人执行等于没写 |
| 培训 | 集中分享 + 实战带教 | 只算分享时长，不算产能下降 |
| 双轨并行 | 新旧两套同时跑一段时间 | 双份值班、双份监控 |
双轨并行期最容易被压掉，也是故障率最高的一段。压掉它，等于把风险集中到切换当天。
12. 选型评审该问的五个组织问题
1) 出故障时，第一通电话打给谁？他今天在不在？
2) 这个东西升级一次要多久？谁来做？上次做是什么时候？
3) 如果核心维护者明天离职，谁能接手？接手要几天？
4) 引入它之后，值班表上多几行？现有的人扛得住吗？
5) 三年后要退出，数据与接口怎么迁？
答案不必精确，但需要当场有人能答。答不上来的那一条，就是这次选型最薄的地方。
13. 度量
| 指标 | 定义 | 用途 |
|---|---|---|
| 组件数量 | 生产环境独立运维单元数 | 与团队规模对照，判断是否超载 |
| 值班负担 | 每周 on-call 工时 / 人数 | 衡量长期税 |
| 平均排障时长 | 从告警到定位根因 | 直接反映技能覆盖 |
| 技能覆盖矩阵空白数 | "无人"格的个数 | 单点依赖的量化 |
| 新人上手天数 | 到能独立发布的天数 | 文档与规范质量的代理指标 |
14. 排错
| 现象 | 常见原因 | 检查 |
|---|---|---|
| 选型通过，半年后没人敢升级 | 只有"能读"，没有"能改" | 看矩阵里能否找到两个"能改" |
| 故障恢复总要外部支持 | 排障经验集中在供应商 | 建立内部 runbook 与演练 |
| 值班抱怨集中在一两个组件 | 该组件运维复杂度被低估 | 统计它的告警量与处理工时 |
| 双轨并行期无限延长 | 缺少明确的切换判据 | 事先约定切换指标与日期 |
| 升级踩到 breaking change | 引入时没看迁移说明 | 锁定版本并订阅发布说明 |
| 同一职责两套组件并存 | 引入时没做依赖树检查 | 每次引入前扫同类依赖 |
15. 边界
| 场景 | 结论 | 理由 |
|---|---|---|
| 一次性项目、交付即结束 | 组织因素权重下调 | 没有长期运维期，维护成本不成立 |
| 明确外包运维并有 SLA | 组织因素让位于 SLA 条款 | 风险已转移，按合同约束 |
| 公司强制技术栈 | 组织因素让位于约束 | 选型空间本就不存在 |
| 团队 1–2 人 | 优先托管与少组件 | 规模决定可承受复杂度 |
| 合规要求指定实现 | 组织因素让位于合规 | 不可协商项优先 |
16. 自测
- 一张十二维度的选型表，最容易漏掉的是哪一类维度？为什么它总在一年后才出现？
- 为什么"可维护性"应该排在"性能"前面？性能差距在什么情况下可以靠优化补回来？
- 技能覆盖矩阵里的"无人"格，对应到选型决策上应该触发什么动作？
- 为什么"每多一个组件就多一份值班负担"会影响选型结论，而不只是影响心情？
- "我们已经会这个"在什么情况下是合法理由，在什么情况下会变成不评估的借口？
- 双轨并行期为什么最容易被压缩，压缩的代价落在哪个时点？