别再堆工具了:聊聊我理解的企业级 AIOps Skill 架构-夜雨聆风

别再堆工具了:聊聊我理解的企业级 AIOps Skill 架构

模型往往够用，真正卡脖子的是Skill：边界谁来画、谁能触发、出事能不能查到人。这篇按「现状 → 八大类 → 等级与升级规则 → Sub Skill 表」来写，方便你直接贴进评审材料里对照。

一、现状

监控、日志、链路、工单、ChatOps 都接上了，出故障时很多团队还是在群里喊、翻大盘、捞日志。这跟「有没有上大模型」关系不大，更像是能力从没被收敛成可调用的单元：叫什么、谁能跑、风险算哪一档、日志里有没有一条能对上。

我习惯把平台想成两层：大类给导航，占一页纸就能把行当分完；Sub Skill 才承载等级、审批和审计。不这么拆，后面自动化一加深，权限和合规一定乱。

二、我用的八块「地图」

完整 AIOps Skills在我这里是八大类：

观测与检测：指标、日志形态、链路、事件关联、SLO/SLI。
巡检与评估：资源、证书、配置漂移、安全扫描、数据库和中间件。
诊断与定位：多源拼根因、影响面、性能和代码位置。
修复与自愈：重启、扩缩、回滚、切流、驱逐、改规格。
工单与流程：建单、改状态、升级、关单、SLA、指派、变更审批。
知识库与协同：类案召回、诊断/复盘稿、通知、ChatOps。
预测与优化：容量或故障预判、成本与闲置资源、调度/规格建议。
治理与合规：鉴权、风险判级、审批、审计查询、合规报表。

有四条最基本的原则：可观测（跑完能看见前后状态）、可编排（多个 Skill 能按条件串起来）、可治理（策略统一）、可审计（谁、何时、对什么、结果如何）。它们和 Sub Skill 分级是同一件事的表里两面。

三、等级、场景、还有动态升级

光有八个目录名没用。P0～P3 回答有多急；ReadOnly / LowRisk / HighRisk 回答能不能自动；动态升级回答「同一个 Skill 换上下文还是不是同一个风险」。

1. 场景里谈等级（P0～P3）

等级	典型场景	响应节奏
P0	止损	分钟级
P1	显性风险	小时级
P2	巡检、治理项	天/周
P3	优化、还债	按月评审

运维、SRE、平台的人只要共用这套分级，就少一些「样样都 P0」的吵架。

2. 风险贴在 Sub Skill 上，别贴整个大模块

同一大类里，有的是只读分析，有的是动生产。审批要么绑死在整个模块上，低风险也被拖慢；要么全盘放开，高危动作混进去。所以我把风险钉在Sub Skill：

ReadOnly：默认自动，照常打审计。
LowRisk：要一次显式确认。
HighRisk：确认以外走审批链，链路也要落库。

举例：metric_anomaly_detection多半是 ReadOnly；restart_instance常归 LowRisk；traffic_switch、auto_rollback一类直接 HighRisk 更省心。

3. 动态升级不是可选项

线上有放大效应：同一个auto_scaling，平时是 LowRisk，扩得太猛就该当 HighRisk 对待。规则要写死、进引擎，别指望值班的临场判断能覆盖所有组合。常见几条：

auto_scaling：扩得太多或实例数过线，抬到 HighRisk。restart_instance：动到主库、核心链路，抬到 HighRisk。traffic_switch：跨机房/跨区切流，审批收紧。config_rollback：影响面超过阈值，抬风险档。

大类只在地图上分区；等级管多急；风险加升级规则决定能不能放手给机器。三条缺一条，平台要么慢死，要么不敢跑。

四、附录：各大类 Sub Skill 一览

（表内等级、风险仅为示例口径，落地时请按你们环境改一版。）

1. 观测与检测（Detection）

Sub Skill	功能描述	等级	风险等级	审计	依赖数据源
`metric_anomaly_detection`	时序指标异常检测（CPU、内存、QPS、错误率、延迟）	P2	ReadOnly	✓	Prometheus/InfluxDB
`log_pattern_clustering`	实时日志聚类，识别新增异常日志模式	P2	ReadOnly	✓	ELK/Loki
`trace_health_check`	调用链健康度分析，慢调用、错误链、依赖故障	P2	ReadOnly	✓	Jaeger/Zipkin
`event_correlation`	多源事件关联、告警风暴抑制、因果推断	P2	ReadOnly	✓	事件总线
`slo_sli_calculation`	SLO/SLI 达成率、错误预算消耗	P2	ReadOnly	✓	指标/日志/链路
`topology_discovery`	动态依赖拓扑、服务地图	P2	ReadOnly	✗	CMDB/链路数据
`baseline_learning`	指标历史基线学习	P2	ReadOnly	✗	时序数据库

2. 巡检与评估（Inspection）

Sub Skill	功能描述	等级	风险等级	审计	依赖数据源
`resource_inspection`	CPU/内存/磁盘/网络/连接池等巡检	P2/P3	ReadOnly	✓	云 API/监控系统
`cert_expiry_check`	SSL/TLS 证书与密钥过期	P2	ReadOnly	✓	证书管理系统
`security_scan`	漏洞、CVE、合规检查	P3	ReadOnly	✓	漏洞扫描器
`config_drift_detection`	配置与标准不一致（漂移）	P2	ReadOnly	✓	CMDB/配置中心
`version_audit`	中间件/依赖版本审计	P3	ReadOnly	✓	CMDB/应用信息
`database_health_check`	连接数、慢查询、死锁、索引健康	P2	ReadOnly	✓	数据库监控
`middleware_inspection`	Redis、Kafka、MQ 等健康检查	P2	ReadOnly	✓	中间件监控
`backup_validation`	备份完整性、恢复验证	P2	ReadOnly	✓	备份系统
`compliance_check`	等保、SOC2 等合规检查	P3	ReadOnly	✓	合规数据库

3. 诊断与定位（Diagnosis）

Sub Skill	功能描述	等级	风险等级	审计	依赖数据源
`root_cause_analysis`	指标/日志/链路/变更等多源根因推断	P0/P1	ReadOnly	✓	综合数据
`impact_assessment`	影响范围（上下游、业务）	P0/P1	ReadOnly	✓	拓扑/CMDB
`log_search_analysis`	关键词、上下文、日志聚合	P1	ReadOnly	✓	日志系统
`anomaly_explanation`	异常的可解释描述	P0/P1	ReadOnly	✓	指标/算法输出
`code_stack_analysis`	堆栈定位代码、关联 Git	P1	ReadOnly	✓	Git/APM
`performance_bottleneck_analysis`	SQL、代码、中间件、网络瓶颈	P1/P2	ReadOnly	✓	APM/数据库

4. 修复与自愈（Remediation）

Sub Skill	功能描述	等级	风险等级	审计	依赖数据源
`restart_instance`	重启单个实例（非核心、非主）	P0/P1	LowRisk	✓	K8s/云 API
`auto_scaling`	弹性伸缩	P0/P1	LowRisk→HighRisk	✓	云 API/K8s
`auto_rollback`	回滚到上一稳定版本	P0	HighRisk	✓	发布系统/K8s
`config_rollback`	配置回滚	P0	HighRisk	✓	配置中心
`traffic_switch`	机房/AZ/服务级流量切换	P0	HighRisk	✓	负载均衡/网格
`pod_eviction`	驱逐异常 Pod 并重调度	P0/P1	LowRisk	✓	K8s
`connection_pool_reclaim`	回收异常连接池	P1	LowRisk	✓	中间件 API
`cache_clear`	清理特定缓存（非全局）	P1	LowRisk	✓	Redis/Memcached
`batch_delete_resources`	批量删除闲置资源	P3	HighRisk	✓	云 API
`resource_spec_adjustment`	实例规格升降配	P1/P3	HighRisk	✓	云 API
`database_optimization`	索引、碎片等数据库优化	P2	LowRisk	✓	数据库

5. 工单与流程（Workflow）

Sub Skill	功能描述	等级	风险等级	审计	依赖数据源
`create_ticket`	创建工单（标题、优先级、指派人等）	P0–P3	ReadOnly	✓	工单系统
`update_ticket`	更新状态、内容、指派人	P0–P3	ReadOnly	✓	工单系统
`escalate_ticket`	超时升级通知	P0/P1	LowRisk	✓	工单系统
`close_ticket`	关闭工单	P0–P3	ReadOnly	✓	工单系统
`sla_monitor`	停留时间监控与超时告警	P0/P1	ReadOnly	✓	工单系统
`query_tickets`	按服务/等级/状态/时间查询	P1–P3	ReadOnly	✓	工单系统
`ticket_auto_assignment`	按规则自动指派	P0–P2	ReadOnly	✓	工单系统/值班表
`change_approval`	变更审批自动化	P1	LowRisk	✓	变更系统

6. 知识库与协同（Knowledge & Collaboration）

Sub Skill	功能描述	等级	风险等级	审计	依赖数据源
`similar_incident_retrieval`	相似历史故障召回	P0/P1	ReadOnly	✗	知识库
`diagnostic_report_generate`	自动生成诊断报告	P0/P1	ReadOnly	✓	诊断结果
`knowledge_qa`	运维知识问答	P2/P3	ReadOnly	✗	知识库/文档
`postmortem_generate`	复盘报告模板与自动填数	P0	ReadOnly	✓	工单/诊断
`notify_user`	钉钉/企微/飞书/邮件/短信/电话等	P0–P2	LowRisk	✓	通知渠道
`chatops_execute`	聊天工具内执行运维命令	P1	LowRisk	✓	聊天 API
`handover_summary`	值班交接汇总	P2	ReadOnly	✓	工单/告警

7. 预测与优化（Prediction & Optimization）

Sub Skill	功能描述	等级	风险等级	审计	依赖数据源
`capacity_prediction`	资源消耗趋势（7/30/90 天等）	P1/P2	ReadOnly	✓	时序数据库
`failure_prediction`	潜在故障预测（磁盘、泄漏等）	P1	ReadOnly	✓	时序/日志
`cost_optimization_suggestion`	成本优化建议	P3	ReadOnly	✗	云账单/监控
`cost_optimization_execute`	执行降本/释放等资源变更	P3	HighRisk	✓	云 API
`idle_resource_detection`	闲置资源识别	P3	ReadOnly	✓	云 API/监控
`scheduling_optimization`	Pod 调度策略优化	P2	LowRisk	✓	K8s
`right_sizing_recommendation`	规格升降配建议	P3	ReadOnly	✓	监控/云 API
`anomaly_prediction`	未来异常事件预测	P1	ReadOnly	✓	时序/ML

8. 治理与合规（Governance）

Sub Skill	功能描述	等级	风险等级	审计	依赖数据源
`permission_check`	是否有权执行某 Skill	P0–P3	ReadOnly	✓	权限系统
`risk_assessment`	动态评估操作风险	P0/P1	ReadOnly	✓	规则引擎
`approval_workflow`	多级审批、超时升级	P0/P1	LowRisk	✓	审批引擎
`audit_log_query`	审计日志查询	P2/P3	ReadOnly	✓	审计系统
`compliance_report_generate`	合规报告	P3	ReadOnly	✓	审计/巡检
`sla_dashboard`	SLA 达成率看板	P2	ReadOnly	✗	工单/告警

五、落地顺序（个人习惯）

先把「八大类」叫法在组内对齐，减少会上歧义。
ReadOnly 和 LowRisk 的 Sub Skill 先跑通观测、诊断、工单。
HighRisk 配审批和回滚预案，再放开执行。
动态升级写进规则引擎，和「核心服务 / 主节点 / 是否跨区」这类标签挂上钩。

全自动占比可以后谈；我更在意每一步能不能说清谁批的、凭什么批、翻车时怎么撤。

六、总结

再接十个界面不如把Skill 字典写清楚：大类给人看 roadmap，Sub Skill 给人写策略。动态升级要是摆设，要么什么都得人工点一遍，要么高危动作混在脚本里没人知道。把人留在审批和例外处理上，让机器吃确定性高的那一截，这是我眼里比较健康的分工。

个人观点，仅供参考。