简介：面向企业 IT 运维团队与运维平台规划者的《IT自动化运维平台建设解决方案》演示文稿，围绕从人工运维到自动化、再到智能化运维的演进路径，梳理一套可落地的平台建设思路。内容从自动化运维与 AIOps 的概念、IT 运维所处发展阶段切入，归纳过程缺乏回溯、日常作业依赖人工、告警处理被动等痛点，再给出覆盖数据整合、任务调度、智能监控、自动运维、风险诊断五个阶段的总体规划与应用蓝图，并展开监控管理、运维作业、任务调度、智能诊断、规则管理等中心模块的功能架构，附告警同步、脚本下发、创建工单等流程示意，便于对照自身环境做方案裁剪与汇报。整套材料为 1 个 PPT 文件，压缩包约 4.35MB，篇幅紧凑、图文结构清晰，可直接用于内部立项汇报或技术分享。已有 1024 人学习下载，适合运维工程师、架构师在规划自动化运维平台时参考借鉴。
1. 凌晨两点的那条告警，暴露出来的问题不在监控
凌晨两点十五分，一台数据库主机的磁盘水位越过阈值，监控把告警推给业务网管，业务网管按规则发了一条消息，然后就没有后续了。第二天早上值班的人翻监控曲线，发现那台机器在凌晨三点自己缓过来了，但中间那四个小时里究竟发生了什么，谁也不知道。这就是这份 IT 自动化运维平台建设解决方案要面对的真实处境：一万五千台主机和数通设备的日常作业与告警处理，全靠人盯人接。它不是一份代码仓库，而是一份把现状痛点、总体规划、本期功能架构和数据流程全部画完的建设方案，适合正在做运维平台立项、写技术方案，或者手里已经有一套监控告警体系、想把它改造成自动化闭环的开发和运维负责人。
2. 现状拆解：一万五千台设备的告警闭环卡在哪三个地方
2.1 一条告警从产生到恢复走了整整六手
方案里把现状链路写得非常直白。监控采集侧用 Zabbix 拿到指标，触发阈值后生成告警，输出到业务网管系统；业务网管负责通知，方式是电话加移动端消息；运维工程师接到后人工分析，判断是自身能处理的还是需要协调研发；处理完成后，指标回落，告警恢复，这条记录才算闭合。
这条链路上的承载量是实体机、虚拟机、网络设备、数据库、中间件加起来一万五千台主机和数通设备的基础作业维护加应用故障维护。六手传递里每一手都是人：人接电话、人判断、人执行脚本、人确认恢复。流程本身没有错，Zabbix 负责采集和告警上报，业务网管负责通知和分发，职责划分清楚，做的也是标准的监控闭环。
问题出在吞吐量和一致性上。一万五千台设备的告警量，按千分之一的日告警率算，一天也有几十条要处理；如果是业务高峰期或者一次网络抖动引发的告警风暴，同时涌进来几十条 P2 级告警，值维和运维工程师根本不可能逐条看完再逐条判断。人一多、事一杂，处理顺序就靠主观经验排，重要告警被淹掉是常事。
2.2 三个卡点在真实值班表上的样子
方案里点出的三个痛点，本质上是同一件事的三个切面。整理成表格看更清楚：
| 卡点 | 现场表现 | 直接后果 |
|---|---|---|
| 周期性任务执行结果无法监控 | 定时脚本和配置散落在各工程师手里，各管各的 | 任务跑没跑、跑成没跑没人知道，无统一管理 |
| 告警处理过程缺少监控记录 | 定位分析靠人，处理动作无痕 | 根因和经验不沉淀，人员流动即断档 |
| 被动式告警处理，非工作时间无人保证 | 夜间告警靠电话叫醒 | 响应慢，故障窗口被动拉长 |
第一条最容易被低估。周期性任务听起来不起眼——巡检、日志清理、配置备份、证书续期，这些事每个运维手里都有几套 crontab。但当几十台机器、上百个任务分散在十几个人的账号下，实际状态是：任务在不在跑看运气，跑失败了没人收到通知，某个人离职了他那批 crontab 就变成没人认领的孤儿任务。这不是自动化，这是把不确定性藏进了服务器里。
第二条是审计和传承问题。故障处理完了，处理过程没有落痕，等于每次都是从头再来一遍。同类的磁盘告警，A 处理过三次、B 处理过两次，但两个人的经验都在各自脑子里，谁也没沉淀成一条能复用的规则。等到 A 休假、B 转岗，同样的告警再来一次，接手的人还是得重新翻日志。
第三条是响应时效。非工作时间的告警处理无法保证第一时间有人响应，这个是排班和流程问题，靠加人加班解决不了，只能靠平台把明确可判定的告警直接自动处理掉，把人的注意力留给真正需要判断的那部分。
2.3 脚本到底放哪儿：两个方案与一次选型
整个方案里技术含量最集中、也最容易在会上吵起来的一个决策，是脚本执行路径怎么走。Zabbix 下发指令有两条路，方案里把两条都摆出来了，优缺点也写得明白：
| 方案一：脚本预置在服务器端 | 方案二：脚本集中在平台侧维护 | |
|---|---|---|
| 做法 | 执行脚本提前预置在各服务器端侧，作业平台与 Zabbix server 做指令通讯 | 脚本在自动化作业平台统一维护配置，客户端通过接收 Zabbix server 远程命令执行 |
| 优点 | 脚本固化出错概率低；对 Zabbix agent 账号所需权限较小，无需提前赋权 | 集中管理可管可控；改动即时生效；高风险脚本可先审批；执行过程详细记录可追溯 |
| 缺点 | 灵活性低，改一次要全网服务器同步；配置变更由工程师控制，需单独赋权后批量部署；脚本存服务器端有被篡改风险 | 对 Zabbix agent 账号所需执行权限较高，需提前赋权 |
方案给的建议是走方案二，理由三条：改脚本不用全网同步、高风险脚本能走审批、执行过程留痕。这三条正好对应上面三个痛点里的后两个——过程留痕解决经验沉淀，审批加即时生效解决变更失控。
但方案二是有代价的，代价就写在它自己的缺点栏里：agent 账号要拿更高的执行权限，并且需要提前赋权。这个代价在后文会变成一个非常具体的坑——Zabbix agent 以什么身份执行远程命令、sudo 免密怎么配、配错了脚本会静默失败且返回成功。选方案二没错，但选完之后权限这一关必须单独设计，不能顺手用 root 一把梭。
3. 总体架构：五层能力蓝图与三期建设节奏
3.1 从数据整合到智能诊断的分层设计
总体规划架构是自上而下分层的，从上往下依次是前端应用、业务能力中心、能力层、数据整合层和对接系统。这份分层不是画着好看，它决定了后面每一个功能模块应该挂在哪一层、由谁负责。
| 层 | 组成 | 职责 |
|---|---|---|
| 前端应用 | 自动化运维门户、运维管理门户、企业 IM、大屏监控 | 面向一线运维、值班主管、运维主管、主管领导提供操作与视图 |
| 业务能力中心 | 监控管理中心、运维作业中心、任务调度中心、智能诊断中心、规则管理中心、运维分析中心 | 平台的业务主体，承担监控、作业、调度、诊断、规则、分析六类能力 |
| 能力层 | 大数据能力、AI 能力 | 非结构化数据处理、数据建模与标注、机器学习与深度学习、规则模型 |
| 数据整合层 | 数据采集、抓取、导入、过滤、清洗、标注 | 把告警数据、指标数据从对接系统拉进来并标准化 |
| 对接系统 | 业务网管、日志平台、Zabbix、大数据平台、机器学习平台、CMDB、云管平台、工单系统 | 数据源与执行通道 |
值得单独说的是业务能力中心的六个分中心。监控管理中心管的是监控对象、监控指标、监控任务、监控告警四件事，把「监控什么」这件事从 Zabbix 配置里抽出来，变成平台里的可管理对象；运维作业中心管资源、参数、脚本、工单；任务调度中心管任务创建、调度、执行监控、执行报告；智能诊断中心管风险类别、趋势识别、事件识别、模型诊断；规则管理中心管技术规则、业务规则、规则作业、规则模型；运维分析中心出告警故障统计、运维作业分析、故障风险报告和系统优化建议。
这个拆法的好处是把「监控配置」和「执行动作」彻底解耦了。传统做法是监控项和触发器都写在 Zabbix 模板里，想加一个自动修复动作就得改模板、重启 agent、全网同步。分层之后，监控归监控、规则归规则、脚本归脚本，三者靠规则表关联，改一处不动其他两处。
3.2 三期节奏：自动化、自主化、智能化
方案把建设路径明确切成三个阶段，每个阶段的判定依据不一样，这个划分方式比笼统讲「从自动化走向智能化」要实在得多：
| 期次 | 判定依据 | 典型能力 |
|---|---|---|
| 一期 自动化运维 | 基于故障告警及所配置的周期性任务等明确指令 | 告警触发自动执行修复命令、周期性任务脚本执行 |
| 二期 自主化运维 | 基于趋势型等规则，根据指标数据自动发现故障并自动修复 | 基于趋势自动运维、基于趋势扩容缩容 |
| 远期 智能化运维 | 基于历史故障与日志等数据，通过自学习模型发现潜在问题与风险并自行处理 | 基于历史重大事件的自动运维、基于历史数据分析的主动运维 |
一期和二期的分界线是触发条件：一期等的是「明确的指令」，告警发生或者定时到点；二期等的是「趋势」，磁盘还没满但增长曲线不对，就该动了。这条线划得很关键，因为它意味着二期需要的是时序数据和趋势识别模型，而不是更复杂的规则堆叠。很多团队在这里翻车，把趋势判断硬写成阈值规则的组合，最后规则表膨胀到没人敢改。
方案对现状的判断也很克制：大部分组织的 IT 运维正处在从人工运维向自动化运维的发展阶段，部分组织已经基本实现自动化正在向智能化升级，少量企业已构建初步的智能化体系。对应到这份方案本身，重点落在本期建设，也就是一期——先把自动化这一层做扎实，别急着上模型。
3.3 本期功能架构：五大服务加四个引擎
本期功能架构落到具体模块上，就是五大业务服务加四个公共引擎：
自动化运维平台（本期） ├── 告警管理服务 同步业务网管告警信息 ├── 脚本管理服务 脚本导入/导出/新增/编辑/查询，支持 shell、bat、Perl、Python、PowerShell ├── 任务管理服务 定时任务配置与自动执行，责任人确认执行结果 ├── 工单管理服务 需要沉淀的故障自动生成工单 ├── 参数管理服务 系统接口、邮箱配置等全局参数 ├── 规则引擎 技术与业务规则、规则作业、规则模型 ├── 流程引擎 审批、工单流转 ├── 消息引擎 告警通知、执行结果通知 └── 系统管理 用户管理、任务调度、消息管理、日志管理、安全管理脚本管理服务支持的脚本类型是 shell、bat、Perl、Python、PowerShell，覆盖了 Linux 和 Windows 两侧的常见运维场景。这一点在实际落地时比看起来重要：很多自动化平台默认只考虑 Linux，结果 Windows 资产上的巡检任务永远只能手工做，最后一统计，自动化覆盖率卡在 70% 上不去。
参数管理服务看起来最不起眼，管的只是系统接口、邮箱配置这类全局变量，但它是脚本能复用的前提。脚本里如果硬编码 IP、路径、邮箱地址，同一个脚本换个环境就得改一遍，改完还得重新审批。把这些提成全局参数，脚本只引用参数名，环境差异放到参数里，脚本本身就能跨环境复用。
4. 核心链路落地：告警进来、脚本出去、工单闭环
4.1 告警接入与规则匹配
数据流程方案里画得很清楚：业务网管平台收集到告警后推送到自动化运维平台；平台根据规则服务和调度配置判断是否有对应的处置方案；有则调用 Zabbix server 发送执行指令并监控执行过程；对于需要生成故障工单的告警，自动推送至工单系统，工单系统处理完成后完成闭环。
第一步是告警接入。业务网管推过来的告警需要统一成平台内部的结构，字段至少要能支撑规则匹配：来源、主机、IP、触发项、当前值、级别、发生时间、标签。一个够用的报文长这样：
{ "event_id": "20240517-000231", "source": "business-nms", "host": "db-master-03", "ip": "10.20.33.41", "trigger": "disk_usage_pct", "value": 92.6, "level": "P2", "occur_time": "2024-05-17 02:15:33", "labels": {"env": "prod", "app": "order"} }trigger是规则匹配的核心键，必须和 Zabbix 侧的触发器名称保持稳定对应，不要用带变量的动态名称，否则规则表永远对不上。level参与匹配是为了区分同一触发项的不同严重程度——磁盘 92% 可以直接清日志，磁盘 99% 就应该先告警再执行，避免清理动作把正在写的文件搞坏。
规则表的设计决定了后面能扩展多远。最小可用的规则表大概是这样：
CREATE TABLE ops_rule ( id BIGINT PRIMARY KEY AUTO_INCREMENT, rule_name VARCHAR(64) NOT NULL COMMENT '规则名称', match_source VARCHAR(32) NOT NULL COMMENT '告警来源，如 business-nms', match_trigger VARCHAR(128) NOT NULL COMMENT '匹配的触发项', match_level VARCHAR(8) NOT NULL COMMENT '匹配级别 P0-P3', script_id BIGINT NOT NULL COMMENT '关联脚本ID', timeout_sec INT DEFAULT 120 COMMENT '执行超时，秒', need_ticket TINYINT DEFAULT 0 COMMENT '是否需要生成工单', approve_required TINYINT DEFAULT 0 COMMENT '是否需审批后执行', enabled TINYINT DEFAULT 1 COMMENT '启用状态', create_time DATETIME DEFAULT CURRENT_TIMESTAMP );匹配逻辑按来源、触发项、级别三个字段做精确匹配，命中多条时取最精确的一条：
def match_rule(alert, rules): """三要素匹配，级别精确优先，其次通配级别""" exact = [r for r in rules if r["enabled"] and r["match_source"] == alert["source"] and r["match_trigger"] == alert["trigger"] and r["match_level"] == alert["level"]] if exact: return exact[0] # 没命中精确级别时，退化到只匹配来源和触发项 loose = [r for r in rules if r["enabled"] and r["match_source"] == alert["source"] and r["match_trigger"] == alert["trigger"]] return loose[0] if loose else None优先级不能反。先精确后宽松，是因为精确规则往往是人工审过的、动作更保守；宽松规则是兜底，动作范围更大。反过来先跑兜底规则，精确规则就永远轮不到执行，等于白配。参数上timeout_sec默认给 120 秒，这个值要结合脚本实际耗时定，巡检类脚本可以给 300，清理类脚本超过 60 秒基本说明它在做不该它做的事。
4.2 脚本下发：Zabbix 远程命令怎么配
方案选的是方案二，脚本放平台侧，通过 Zabbix server 远程命令下发。这条链路要通，需要三处配置对齐，缺一处就会静默失败。
第一处是 agent 侧允许远程命令。在 agent 配置文件里打开开关并记录日志：
# zabbix_agentd.conf 关键项 EnableRemoteCommands=1 LogRemoteCommands=1EnableRemoteCommands不开，server 下发的命令会被 agent 直接丢弃，且不会回传明确错误；LogRemoteCommands建议一定开，排查时 agent 日志里能看到实际执行的命令行，这是唯一能还原现场的地方，没有它等于盲猜。
第二处是 agent 运行账号要能免密执行指定脚本。不要给全量 sudo，按脚本逐个授权：
# /etc/sudoers.d/zabbix-ops Defaults:zabbix !requiretty zabbix ALL=(root) NOPASSWD: /opt/ops/scripts/clean_disk.sh zabbix ALL=(root) NOPASSWD: /opt/ops/scripts/restart_service.shDefaults:zabbix !requiretty这行是血泪经验，缺了它 sudo 在非交互环境里会直接报错，而错误又不会传回平台，表现就是「命令发了、没反应、没报错」。逐条授权而不是NOPASSWD: ALL，是为了把「能执行什么」限制在脚本清单内，脚本本身还能走平台审批和审计。
第三处是 Zabbix server 那边的远程命令配置。在主机或模板上配置 action，操作类型选 Remote command，执行目标选对应 agent，命令填脚本绝对路径加参数。这里有个容易忽略的点：命令里的参数来自告警事件，应该用 Zabbix 的宏拼装，而不是写死。
三处都配好之后，一条完整链路是：业务网管推告警 → 平台匹配到规则 → 调用 Zabbix API 触发对应 action → server 下发远程命令 → agent 以 zabbix 账号 sudo 执行脚本 → 脚本输出结果。
4.3 执行结果判定与工单闭环
命令发出去了不等于执行成功了，这是自动化平台和脚本合集最本质的区别。方案里专门画了「执行后的指标获取权限」这一步，意思是在脚本执行完之后，平台要回到监控侧确认指标是否真的恢复，用结果反推执行是否有效。
状态流转大致是这几个状态：
| 状态 | 含义 | 下一步动作 |
|---|---|---|
| 待匹配 | 告警已接入，规则未命中 | 转人工，通知值班 |
| 待执行 | 规则命中，脚本已排入队列 | 调度器下发 |
| 执行中 | 命令已下发，等待结果 | 超时则转失败 |
| 待确认 | 脚本返回成功，指标待复核 | 拉取监控指标比对 |
| 已闭环 | 指标恢复且责任人对结果确认 | 归档，写入知识库 |
| 待工单 | 需要人工介入或需沉淀故障 | 推送工单系统 |
「待确认」这一状态是闭环的关键。脚本返回 0 只说明它跑完了，不说明问题解决了。平台应该在一个可配置的延迟窗口后回查指标，比如清理类脚本执行完 5 分钟后拉一次磁盘使用率，没降下来就判为未生效并自动转工单。
工单管理服务承担的是沉淀职责：当任务需要生成故障工单时，自动发送工单给工单系统，工单派发的同时系统根据策略自动执行任务。也就是说执行和工单是并行的，不是等工单处理完再执行——夜间场景下等工单响应，黄花菜都凉了。等工单系统处理完成，状态同步回平台，这条告警才算彻底闭环。
5. 避坑与排查：脚本下发这条路上最容易翻车的四个地方
5.1 平台显示下发成功，服务器上什么都没发生
现象：规则命中、任务状态走到「执行中」然后变「成功」，但去机器上看，日志文件还是满的，脚本根本没跑。
原因基本都在EnableRemoteCommands上。这个开关默认是关的，关着的时候 server 把命令发过去，agent 收到后按配置直接忽略，不回错误、不写日志，server 侧只看到命令已投递。整条链路对「没执行」这件事完全静默。
解决：先确认 agent 配置文件里开关已开并且服务重启过，再打开LogRemoteCommands=1。之后每一次远程命令都会在 agent 日志里留一行实际执行的命令，拿这行命令手工在服务器上跑一遍，能复现就说明是脚本自身问题，不能复现就说明是权限问题。这个日志开关建议在测试环境就打开，不要等出事了才想起来。
5.2 sudo 报错被吞掉，脚本半路退出
现象：脚本手工执行完全正常，走平台就是不行；或者脚本前半段做了，后半段没做。
原因有两种。一是 agent 运行账号在 sudoers 里没配免密，非交互环境下 sudo 要密码，直接失败；二是缺!requiretty，sudo 在无 tty 环境下拒绝执行。这两种失败都有一个共同特点：agent 只把脚本的退出码回传，标准错误里的 sudo 提示信息不在回传范围内，于是平台看到的就是一个不明原因的非零退出。
解决：sudoers 里按脚本逐条配NOPASSWD并加Defaults:zabbix !requiretty，配完用sudo -u zabbix sudo -n /opt/ops/scripts/xxx.sh验证一次，-n参数的作用就是强制非交互，能跑通才说明配置生效。另外脚本开头统一加set -euo pipefail，让它在出错时立刻退出并把错误写进自己的日志，而不是带着错误继续执行后面的清理动作。
5.3 一条告警打出去五遍脚本
现象：磁盘告警持续了十分钟，平台那边同一个清理脚本被执行了五次，日志被清了五遍。
原因是告警侧没有做去重和抑制。Zabbix 在阈值持续超限期间会周期性重复产生事件，业务网管原样转发，平台按「一条告警一次执行」处理，自然就重复下发。
解决：在平台侧加一层执行窗口控制，同一个host + trigger组合在 N 分钟内只允许执行一次，N 取脚本生效所需的观察时间，清理类给 10 到 15 分钟比较合适。同时脚本本身必须写成幂等的——清理脚本判断目标文件是否还存在、服务重启脚本判断进程是否已经在跑，重复执行也不能产生副作用。这一条比去重更重要，因为去重逻辑总有漏网的时候，幂等是最后一道保险。
5.4 执行超时判成失败，其实脚本还在跑
现象：平台标记任务超时失败并自动转了工单，结果十分钟后指标自己恢复了，工单成了无效工单。
原因是超时时间设得太短，或者脚本里有阻塞操作（比如等一个服务优雅停止）。平台侧超时后终止的是自己这边的等待，杀不掉服务器上已经在跑的进程，于是出现「平台认为失败、机器上还在执行」的错位。
解决：超时时间按脚本类型分档配置，纯查询类 60 秒、清理类 180 秒、涉及服务重启的 300 秒，别用一个全局值套所有脚本。另外超时后不要立刻转工单，先做一次状态复查：重新拉一遍指标，恢复了就标记为「超时但已生效」，只记录不告警。这个逻辑看起来是给自己找麻烦，但能省掉大量无效工单，值班的人会感谢你。
6. 二次开发：把执行层做成可插拔，别写死 Zabbix
这套方案落地时最容易被写死的地方是执行层。一期只对接 Zabbix 远程命令，代码里到处是「调 Zabbix API 下发命令」，等到二期要接入云管平台做扩容、或者要对接容器平台做 Pod 重启，就会发现每一处调用都要改。我一般在第一期就把执行器抽成一个接口，Zabbix 只是其中一种实现：
class Executor: """执行器抽象：新增执行通道只需实现 execute""" def execute(self, host, script_path, params, timeout): raise NotImplementedError class ZabbixRemoteExecutor(Executor): def execute(self, host, script_path, params, timeout): # 走 Zabbix 远程命令通道 cmd = " ".join([script_path] + params) return self._call_zabbix_api(host, cmd, timeout) class CloudApiExecutor(Executor): def execute(self, host, script_path, params, timeout): # 云管平台提供的能力，如扩容、快照 return self._call_cloud_api(host, script_path, params, timeout)规则表里加一个executor_type字段，匹配到规则后按类型选执行器，上层调度逻辑一行不用改。script_path在不同执行器下语义不同：Zabbix 通道下是服务器上的脚本绝对路径，云管通道下可以是一个动作标识。把语义差异封装在执行器内部，规则和调度层只认「要做什么」，不认「怎么做」。
改造之后的验证方法也有讲究，别一上来就全量放开。我通常分三步走：先在测试环境用真实告警回放跑通端到端，确认脚本、权限、结果回查三处都对；再挑三到五台非核心主机开灰度，把规则表里这几台主机的规则单独启用，观察一周的成功率和误判率；最后按业务域逐步放开，每放开一个域，把「脚本执行成功率」和「工单转人工率」两个指标拉出来看，后者不降反升就说明规则配得太激进，得退回去调阈值。
灰度期间有个细节值得盯：把每一次自动执行的原始命令、执行账号、退出码、耗时都落一张执行流水表，字段不多但足够事后复盘。我吃过一次亏，规则配错把生产库的归档日志清了，事后想追是哪条规则、什么时候改的、谁审批的，结果只有一行「执行成功」，什么都查不到。从那以后我每次上线新的自动执行规则，都强制走一遍「流水表能查到完整命令」这个检查，查不到就不许启用。
希望帮到你。
本文还有配套的精品资源，点击获取
