（1）概要叙述参与开发的信息系统项目以及承担的主要工作。
我参与的是某股份制银行"交易链路可观测与智能运维平台"的建设，项目目标是在不替换既有 Prometheus、ELK 监控底座的前提下，为支付与转账核心链路叠加一层 AIOps 能力，解决"告警多、定位慢、处置靠人"的运维瓶颈。该行当时面临的典型问题是：一次数据库连接池耗尽会同时触发健康检查超时、多个微服务 5xx 升高以及 SLO burn rate 告警，每条告警在各自系统内都成立，但值班人员需要耗费大量时间在跨系统拼图而非判断根因上。我担任平台的后端与算法工程负责人，主要工作包括：设计"采集---检测---收敛---诊断---处置"五段式数据与决策管线；实现基于动态基线的异常检测与五类降噪机制的工程落地；构建以 CMDB 和调用链为骨架的运维知识图谱，支撑根因候选排序；以及设计带预校验和回滚的自动化处置执行框架。项目上线后，P0 级故障的根因锁定时间从人工排查的 15 分钟以上压缩至 4 分钟以内，日常可行动告警量下降约四成，支付核心链路的 MTTR 由小时级进入分钟级。
（2）简述 AIOps 架构组成：指标、日志、链路采集、异常检测、根因分析、自动处置。
本项目采用"采集---检测---诊断---处置---反馈"的分层架构，与业界通行的 AIOps 闭环逻辑一致。采集层以 OpenTelemetry 为统一语义规范，将指标、日志、链路三类信号在字段和时钟上对齐，避免多源数据"各说各话"。异常检测层不依赖单一静态阈值，而是按指标形态分类建模：波动型采用 EWMA 平滑与 3-sigma，趋势型引入孤立森林，季节型使用同比与预测残差，并以多算法投票降低单一模型的系统性偏差。根因分析层以 CMDB 拓扑和调用链 DAG 为基础构建运维知识图谱，将指标异常、日志模板突变和链路延迟跳变挂载到图节点上，通过带权 PageRank 式的因果传播推理对候选根因排序，使"哪个异常是源头、哪些是衍生"在图上可计算、可解释。自动处置层以标准化 Playbook 为执行单元，覆盖重启、扩容、流量摘除、日志清理等高频动作，同时为每一个动作绑定 dry-run 预检和回滚路径，确保"机器先试修"不越过安全边界。最外层是反馈层，将每次检测的命中率、根因排序的准确率以及处置的成功率与回滚率写入知识库，驱动模型和规则的迭代。
（3）结合项目论述告警降噪、智能根因定位、运维自动化落地的挑战与方案。
告警降噪：从"字段去重"走向"根因语义收敛"。 项目初期，我们最先遭遇的认知误区是认为对告警做指纹哈希去重即可解决问题。实际运行后发现，压垮值班的并非完全相同的告警，而是来自不同对象、不同指标、根因相同的一串告警------数据库连接池耗尽会同时触发上游多个微服务的健康检查失败和 SLO 告警，字段哈希无法将它们合并。我们最终采用的方案是五类机制叠加：自动去重 基于告警源、对象、指标、等级四字段生成事件 ID，消解完全重复项；关联聚合抑制 在同一业务对象和指标维度上合并相关告警，避免同一根因在不同层级反复"变脸"；防抖抑制针对 CPU、网络流量等高抖动指标设置"周期内出现指定次数才放行"，过滤瞬时毛刺；此外，动态基线承担了"检测层降噪"的职能------用按指标形态适配的无监督模型替代固定阈值，从源头减少因业务昼夜节律产生的误报。需要强调的是，降噪的底线是"可回退"：每一条抑制规则都必须配有一键回滚机制，当发现真实告警被误抑制时能够快速恢复并修正规则，而非让降噪本身成为一个新的故障源。
智能根因定位：拓扑可依，但拓扑本身会"骗人"。 根因定位最大的挑战不是算法精度，而是运维环境的结构性缺失：大量故障发生在拓扑关系没有覆盖到的路径上，或者 CMDB 中的依赖边已经滞后于实际部署变更。项目初期我们直接用静态拓扑图跑 PageRank，结果在多次故障中把"告警最多的节点"排为根因，而真正的源头是一个拓扑上不存在的连接池耗尽。改进方案的核心是让图谱动起来：以调用链的实时 span 数据补充静态拓扑中缺失的动态依赖边，同时将日志模板突变作为独立信号挂载到图节点上，使根因排序同时利用"结构关联"和"内容突变"两条线索。在算法上，我们采用子图裁剪加幂法迭代，只对异常节点周围的局部子图做实时 PageRank，避免全图计算带来的延迟；排序结果以"根因候选 + 推理路径"的形式输出，而不是一个黑箱分数，让值班工程师能够判断模型是否"讲得通"。此外，根因定位必须容忍"找不到根因"的情况：当所有候选的分数差距低于阈值时，系统主动降级为"疑似关联事件列表"，而不是强行给出一个高置信度错误结论。
运维自动化落地：最难的不是"能执行"，而是"敢执行"。 自动化处置的挑战在项目推进中逐步暴露，而非一开始就清晰。最初我们实现了基于规则的重启和扩容，但在一次夜间批处理窗口，自动扩容因指标滞后而过早触发，造成了不必要的资源争抢。这暴露出自动化落地的三个核心矛盾：误动作的代价不对称 ------一次错误的重启可能比人工晚处理十分钟造成更大损失；知识的形式化缺口 ------老师傅的很多判断依赖"手感"和上下文，难以写成确定性规则；闭环不完整 ------检测、诊断、处置各自为政，没有形成从动作执行到效果验证再到策略修正的回路。我们的方案围绕"安全护栏 + 闭环反馈"展开：所有写操作强制经过dry-run 预检 ，在隔离环境中模拟执行并校验系统就绪状态和依赖健康度；生产环境的自动化动作设置黑白名单和分级放行，P0 级动作保留人工审批，P2 级动作在 dry-run 通过后自动执行；每一次处置后由验证器自动比对关键指标是否恢复，失败则触发回滚并升级人工，同时将本次动作的上下文、结果和回滚原因写入 Runbook 知识库，作为下一轮策略调优的依据。这一设计使自动化处置的成功率逐步收敛，而不是在"全自动"和"全人工"之间摇摆。
综上，AIOps 在本项目中的价值并非来自某一个突出的算法，而是来自将采集、检测、诊断、处置和反馈串成一条每一段都可观测、可回退的工程闭环。降噪让信号可信，根因定位让方向可信，自动化让动作可信------三者缺一，平台就退化为另一个告警展示面板。