自动化平台自身的高可用与扩容怎么规划

结论先行：自动化平台一旦成为变更主通道，它自身的可用性就等同于变更能力的可用性。建议按三层规划：应用与任务层做多节点与队列持久化、数据层用独立数据库并纳入备份、接入层保留一条绕开平台的应急通道；扩容按纳管设备数、采集频次与留存期三个变量估算，并按年度复核。同时把"平台停摆时怎么变更"写成书面预案，而不是默认它不会停。

平台停摆意味着什么

平台集中了设备配置、策略模型、拓扑关系、工单记录与审计留痕。它不可用的时候，影响不只是"少了一个工具"：变更要退回人工逐台登录、存量策略无法分析、审计取证的完整轨迹查不到。

更棘手的是，平台停摆对业务的冲击是延迟显现的——当天可能只是"变更排队"，一周后就会积累成一堆无法按时交付的开通需求。因此高可用规划要按业务的容忍时长来定，而不是按 IT 系统的常规标准。

三层高可用设计

任务层的队列持久化最容易被忽略。下发任务在内存里排队，节点一重启任务就没了，而发起方看到的却是"提交成功"。这类静默失败比宕机更难发现，需要把任务状态做成可查询、可追溯。

扩容看三个变量

• 纳管设备数。决定采集与下发的并发量，是最直接的变量。按当前规模估算时要把两年内的增长算进去，否则很快又要重构。
• 采集频次与留存期。决定数据量与存储压力。采集周期从每天一次改成每小时一次，数据量是数倍关系；留存期与合规要求绑定，扩容时必须一起算。
• 并发任务数。护网或集中变更期间，任务量可能是平常的十几倍，需要预留峰值余量而不是按均值配置。

三个变量建议写进一张估算表，每次扩容前重新填一遍。很多容量问题是"慢慢长出来的"：设备数增加了、留存期延长了，但资源配置一直没动，直到某次批量任务时集中暴露。

应急通道与降级

再周全的高可用也会遇到计划外停机，因此需要一条绕开平台的应急路径：保留设备本地账号与操作权限、保留最近一次的全量配置备份、把紧急变更的标准作业单与审批方式提前约定。应急通道平时不用，但必须定期验证一次，否则真到用时才发现账号已过期。

降级策略同样要写清楚：平台部分功能不可用时，哪些变更可以继续走平台、哪些必须转人工、由谁决定切换。这类决策如果留到故障现场讨论，通常会花掉最宝贵的时间。

落地清单

• 按接入层、应用与任务层、数据层分别设计冗余，并逐层验证一次。
• 任务队列持久化，任务状态可查询，失败可重试并告警。
• 按设备数、采集频次与留存期三变量建估算表，每年复核一次。
• 保留绕开平台的应急通道，含账号、备份与标准作业单，定期验证。
• 写清降级规则与切换决策人，纳入运维规范并演练一次。

三个常见坑

• 只做了应用多节点，数据层仍是单点，数据库一挂整体不可用。
• 按均值配置并发，护网或集中变更期间任务堆积、超时。
• 应急通道长期未验证，账号过期或备份不可读，故障时才发现不可用。

如果您正在规划相关建设，欢迎预约咨询，奇摩技术团队可结合现网情况给出可落地的清单与口径建议。