运维可扩展性有哪些坑

运维的“可扩展性（Scalability）”通常不是单点问题，而是人、流程、架构、工具链四方面一起放大后才暴露的坑。下面按常见维度梳理，偏实战视角：

一、架构层面的坑

1. 单点架构被“默认继承”

• 早期为了快，用了单机 DB / 单机调度 / 单机网关
• 流量上来后，发现不是不能扩，而是根本没设计扩的位置
• 典型：cron 定时任务、自研agent、内部配置中心

✅ 坑点：可扩展性不是“以后再加”，而是“一开始就不阻止扩”

2. 有副本，但无分片

• 数据库主从有了，但单表 5 亿行
• Kafka 有集群，但 topic 单分区
• 服务能水平扩容，但依赖共享大状态

✅ 扩机器 ≠ 扩系统能力

3. 隐式耦合

• 服务A直接读服务B的数据库
• 运维脚本依赖“某台机器一定在”
• 发布顺序写死在人的脑子里

✅ 扩展性卡点经常不在服务，而在“隐藏依赖”

二、运维流程的坑

4. 人肉运维可复制性差

• 老员工“敲几条命令就好”
• 新环境一建，发现：
  • 内核参数没记
  • 防火墙规则靠经验
  • 目录结构不统一

✅ 人越关键，系统越不可扩展

5. 环境不一致（DEV / TEST / PROD）

• PROD 能跑，UAT 崩
• 扩容时新节点“和老节点不一样”

✅ 不可重现 = 不可扩展

6. 变更无灰度 / 无回滚

• 扩容量 ≠ 变更安全量
• 一次扩容引发连锁故障

✅ 扩展性前提：任何操作都能“小步快跑”

三、监控与容量的坑

7. 监控只看“机器”，不看“能力”

• CPU 很低，但连接数爆了
• 磁盘没满，但 inode 没了
• QPS 没涨，但 P99 飙升

✅ 没有业务视角的容量模型，扩也是瞎扩

8. 容量评估靠拍脑袋

• “再加 10 台应该够”
• 没有：
  • 单实例上限
  • 瓶颈组件
  • 线性 / 非线性区

✅ 不可预测的系统无法规划扩展

四、组织与协作的坑

9. 运维边界模糊

• 谁负责扩容？开发？SRE？平台？
• 扩了没人管成本，缩了没人敢动

✅ 没有 ownership，扩展性会“卡在会议里”

10. 工具链只服务“当前规模”

• Ansible 管 50 台爽，500 台卡
• 自研平台只支持一种发布模式
• 告警系统一扩就风暴

✅ 工具自己也要可扩展，否则成为瓶颈

五、成本与认知的坑

11. 只扩不缩

• 流量高峰过去，资源还在
• 云账单成为隐藏技术债

✅ 真正可扩展 = 双向弹性

12. 过度设计

• 一开始上 Service Mesh、多活、混沌工程
• 团队根本 hold 不住

✅ 扩展性要匹配“组织成熟度”

一句话总结

运维可扩展性的坑，大多不是“不能扩”，而是： 架构不允许、流程靠人、监控看错、组织没人管。

如果你愿意，我可以：

• 按你当前规模（比如 10 / 100 / 1000 台）给具体建议
• 或针对某一块（如 Kubernetes / 数据库 / 发布系统）深挖