智能运维核心场景经常被概括为监控、告警和自动化修复，但这三件事不能混成一个能力清单。监控负责发现异常，告警负责判断优先级和责任归属，自动化修复只适合在证据充分、动作可控、结果可回滚的场景中执行。
场景边界：这篇文章不讨论AIOps平台选型，而是回答企业做智能运维时，三类核心场景分别应该解决什么问题、需要哪些证据，以及哪些地方不能越界。
先把三个场景拆开，智能运维才不会变成口号
很多企业开始做智能运维时，会把“监控更全、告警更准、故障能自动修”放在同一个目标里。这个目标方向没错，但执行时必须拆开，否则很容易出现两种问题。
第一种问题是监控很多，却没有形成事件判断。指标、日志、链路和看板都接入了，但故障发生时仍然需要人工在多个系统之间切换。
第二种问题是自动化修复太早上线。没有明确根因、没有影响范围、没有回滚条件时，自动脚本可能比故障本身更危险。
核心判断：智能运维不是从自动修复开始，而是从可观测证据和告警责任开始。监控、告警和修复之间要形成顺序，而不是互相替代。
场景一：监控要回答“发生了什么”
监控是智能运维的入口，但监控不等于大屏。企业真正需要的是能在故障发生前后快速回答：哪个应用、哪个版本、哪个集群、哪个依赖、哪个指标发生了异常。
一个可用于智能运维的监控场景，至少要覆盖四类证据。
- 资源层：节点、CPU、内存、磁盘、网络、Pod状态和副本数
- 应用层：错误率、延迟、吞吐、实例健康、发布版本和配置变化
- 调用链：入口、服务调用、数据库、中间件和外部依赖
- 事件层：发布、扩缩容、重启、告警、工单和人工操作记录
如果监控只停留在资源利用率，就很难支撑后续AIOps分析。因为智能判断需要知道异常是否影响业务、是否关联变更、是否只发生在某个版本或某个依赖上。
监控场景的验收标准也不应只是“接入了多少指标”。更实用的验收方式，是拿一次真实故障复盘，检查平台能否在同一视图中看到异常指标、错误日志、链路变化和最近变更。
场景二：告警要回答“现在谁该处理”
告警是从监控走向运维行动的转折点。监控告诉团队发生了什么，告警要告诉团队这件事是否重要、优先级是什么、归谁处理、是否需要升级。
很多企业告警体验差，并不是因为告警系统功能少，而是告警规则没有经过治理。重复告警、误报、无责任人、级别混乱和缺少抑制规则，会让值班人员逐渐忽略告警。
告警治理可以按以下问题检查。
| 检查问题 | 合格表现 | 不合格风险 |
| 是否去重 | 同一故障只生成一个事件簇 | 告警风暴淹没真正风险 |
| 是否分级 | 按业务影响和范围区分优先级 | 关键故障被普通告警掩盖 |
| 是否归属 | 能找到服务Owner和值班组 | 告警转派和无人响应 |
| 是否闭环 | 有确认、处置、恢复和复盘记录 | 平台无法持续改进规则 |
典型误区：告警越少不一定越好。真正好的告警体系，是让该出现的告警及时出现，让不该打扰人的噪音被抑制，并让每条重要告警都有下一步动作。
场景三：自动化修复要回答“能不能安全执行”
自动化修复是智能运维最容易被高估的场景。它的价值很高，但前提是故障类型清楚、动作边界清楚、结果可以验证、失败可以回滚。
适合优先自动化的动作，通常是低风险、重复性高、人工判断稳定的动作。例如触发诊断脚本、收集日志、重启无状态实例、扩容低风险服务、回滚灰度版本或通知对应值班组。
不适合直接自动化的动作包括修改数据库结构、批量删除数据、关闭安全策略、修改核心网络、变更权限、在未知根因下重启关键组件。这些动作可以由平台生成建议，但不能直接交给自动化执行。
风险提醒：自动化修复必须有前置条件、审批策略、执行日志、验证方式和回滚点。缺少其中任一项，都不应进入生产自愈。
三个场景之间要形成证据链
监控、告警和自动化修复不是三个独立工具，而是一条证据链。
监控提供事实，告警把事实变成事件，自动化修复在事件边界清楚时执行动作。修复完成后，结果还要回到监控和告警规则中，形成复盘闭环。
以下是一个发布后错误率升高的例子。
1. 监控发现某服务新版本上线后5xx错误率升高，链路追踪显示下游数据库调用变慢。
2. 告警系统把多个实例错误聚合成一个事件，标记影响范围、版本和服务Owner。
3. 平台关联最近发布记录，提示该服务刚完成灰度发布。
4. 自动化剧本只执行低风险动作，例如暂停继续放量、触发诊断、建议回滚灰度。
5. 人工确认后执行回滚，复盘记录补充到规则和剧本中。
从这个例子可以看出，自动化动作能否执行，取决于前面的监控和告警是否给出了足够证据。如果只看到“错误率升高”一个指标，就不适合直接修复。
建设智能运维场景的顺序
企业落地智能运维时，可以按三步推进。
第一步，先统一监控对象。把应用、服务、版本、集群、命名空间、负责人和依赖关系统一起来，让指标、日志、链路和事件能互相引用。
第二步，治理告警规则。选择高频告警做去重、分级、归属和闭环，先让值班人员信任告警，再谈智能关联。
第三步，选择低风险自动化场景。不要追求全自动修复，先把诊断、通知、灰度暂停、无状态实例重启等动作做成可审批、可回滚的剧本。
这三个步骤可以按业务域逐步扩展。每扩展一个场景，都要重新确认数据、责任、流程和风险边界。
下一步建议
如果正在规划智能运维核心场景，建议先选一个高频故障类型做复盘：它是否有足够监控证据，告警是否能准确聚合，责任人是否清楚，是否存在低风险自动化动作。能回答清楚这些问题，再进入平台选型或AIOps体系建设会更稳妥。
下一步可以先复盘一类高频故障，再按监控证据、告警闭环和自动化边界分别阅读 AI运维监控系统 、 AIOps智能运维落地 与 AI智能运维管理平台选型 ；更多内容可回到 可观测与稳定性分类 。
常见问题
智能运维一定要包含自动化修复吗？
不一定。监控数据治理、告警治理和事件闭环本身就是智能运维的重要阶段。自动化修复只有在场景低风险、动作可回滚、证据充分时才适合上线。
监控和告警有什么区别？
监控关注事实，例如指标、日志、链路和事件；告警关注行动，例如是否需要处理、优先级是什么、谁负责、是否升级。没有告警治理的监控，通常只能提供信息，不能稳定驱动响应。
如何判断一个场景适合自动化修复？
先看四个条件：根因是否清楚、影响范围是否可控、动作是否可回滚、结果是否可验证。如果任何一项不满足，应先让平台给出诊断建议，而不是直接执行修复。
原创声明：本文为 Alauda 原创技术内容，非商业转载须注明出处：https://www.alauda.cn/blog/615/。
文中图示和文章内容未经许可不得用于商业转载、培训课件、营销材料或二次分发。
