3. 自动化运维平台需求分析与架构设计
自动化运维平台不是“把脚本集中起来跑”的工具集合，而是一套面向生产环境的工程系统。它的需求来源通常有三类：业务侧对交付速度与稳定性的诉求、运维侧对重复劳动与风险控制的诉求、合规与审计侧对操作可追溯的诉求。需求分析的任务，是把这些诉求翻译成可设计、可实现、可验证的条目，再据此推导功能模块与架构约束。
一、从业务需求到功能模块
以一台 RHEL 服务器的日常运维为例，业务侧真正关心的是“变更是否快速、失败是否可控、结果是否可查”。这三句话可以拆成若干可落地的功能需求：
- 资产与配置管理：记录主机名、IP、OS 版本、所属业务、负责人、SSH 端口、凭据引用等，作为所有自动化任务的输入源。
- 任务编排与执行：支持批量命令、脚本下发、Playbook 执行，具备并发控制、超时、重试与中断。
- 变更与发布：支持灰度批次、暂停确认、回滚触发，避免一次性全量失败。
- 巡检与合规：按周期采集磁盘、服务、内核参数、SELinux 状态，输出可对比的基线报告。
- 审计与通知：记录谁在何时对哪些主机执行了什么，结果如何，并推送到邮件或 IM。
这些功能不是并列堆叠，而是有依赖关系的。资产是输入，编排是执行引擎，审计是旁路记录，通知是结果出口。设计时先确定“最小可用闭环”：资产 → 编排 → 执行 → 审计 → 通知。其余功能在此基础上扩展。
二、非功能需求：决定架构形态的硬约束
非功能需求往往比功能需求更能决定架构。对自动化运维平台，需要重点明确以下指标，并给出可验证的示例值（以下为教学示例，非实测数据）：
| 维度 | 示例指标 | 对架构的影响 |
|---|---|---|
| 并发规模 | 500 台主机，峰值 200 并发任务 | 执行器需水平扩展，任务队列需削峰 |
| 可用性 | 控制面 99.9%，单节点故障不影响已排队任务 | API 与调度器需多副本，数据库需主从 |
| 可扩展性 | 新增 1000 台主机无需改代码 | 资产模型与执行器解耦，支持插件式连接 |
| 安全性 | 凭据不落盘明文，操作可追溯到人 | 引入 Vault 类凭据管理，审计日志独立存储 |
| 可观测性 | 任务成功率、耗时、失败原因可查询 | 指标、日志、追踪三件套需在架构中预留 |
这些指标一旦确定，架构就不能只画一个“Web + 数据库 + 脚本”的三层图。并发与可用性要求执行层无状态、可复制；可扩展性要求资产与执行解耦；安全性要求凭据与业务数据分离。
三、高可用与可扩展性设计
高可用的核心思路是“消除单点，并让失败可恢复”。控制面（API、调度器）采用多副本 + 负载均衡，任一副本宕机后由健康检查摘除；数据库采用主从复制，主库故障时切换从库；任务队列使用持久化消息中间件，执行器从队列拉取任务，宕机后任务可重新入队。执行器本身无状态，可随时增减。
可扩展性分两个方向：纵向扩展单机并发能力，横向扩展执行器数量。纵向靠异步 IO、连接池、批量 SSH 复用；横向靠队列分区与执行器分组。资产规模增长时，只需增加执行器并调整队列分区，不需要修改业务代码。
四、架构视图：从需求到模块的映射
下图把上述需求、非功能约束与模块关系放在同一张架构视图中，便于对照检查“每个需求是否有模块承接、每个模块是否受非功能约束”。
五、需求到架构的落地检查
完成架构设计后，建议用一张“需求—模块—约束”对照表做一次闭环检查。例如：
- “失败可控可回滚”对应“变更与发布”模块，约束是“执行器无状态、任务可重新入队”。
- “操作可追溯”对应“审计与通知”模块，约束是“审计日志独立存储、不可被业务库覆盖”。
- “并发 200”对应“任务编排与执行”模块，约束是“队列削峰 + 执行器水平扩展”。
如果某个需求找不到承接模块，说明功能设计有缺口；如果某个模块找不到约束，说明它可能在高并发或故障场景下成为单点。架构设计不是一次画完的图，而是随着需求澄清不断修正的工程决策记录。