AI DevOps
这周的内容主要是AI DevOps（人工智能开发运维）。AI DevOps 是将人工智能技术整合到DevOps实践中，以自动化、优化和增强软件开发和交付流程的方法。
Why
在生产环境中监控软件系统仍然是一项至关重要的任务。当软件编码上线完成之后，并不意味着可以就此安心，实际上，后续在生产环境中安然运行代码才是真正的难点。当前存在的难点在于：现代系统的复杂性，各种工具间的孤立性，成员只是不对称，系统组件的复杂依赖关系等。
因此，管理生产环境通常需要SRE（站点可靠性工程师）进行繁琐的软件分类和故障排查工作。SRE需要手动处理大量的告警、日志和事件，进行故障诊断和根因分析。这种人工分类工作耗时且容易出错，正是AI可以发挥作用的领域。
SRE的传统职责
SRE不仅需承担繁重的7×24小时待命、手动故障排查及基础设施管理等职责，还需在信息孤岛中跨团队拼凑碎片化信息，并依赖往往过时的操作手册；随着云原生架构（容器、Kubernetes）的普及，系统产生的数据量、依赖关系及复杂性呈指数级增长，导致SRE因高压轮班频发职业倦怠，且由此引发的系统停机每年给全球企业造成约4000亿美元的经济损失，从而有力论证了从人工被动运维向AI驱动自动化转型的紧迫性。
DevOps过程
四个黄金指标
- Latency - 延迟：衡量处理请求所需的时间
- Errors - 错误率：失败请求的比率
- Traffic - 流量：系统当前的需求负载，比如每秒请求数，会话数，事务数，宽带使用量等
- Saturation- 饱和度：系统资源的满载程度，比如CPU使用率，内存使用率，IO带宽，线程池使用率等
生产环境中，一般会追踪请求在微服务架构中的完整路径。
故障处理的标准流程
1 确认同时评估当前的问题。评估当前问题的严重程度，检查上述四个黄金指标（优先数据库）。
2 检查数据库层和应用层的健康状态，定位问题的具体位置。
3 识别最近的部署。比如部署，数据库迁移，功能开关变更，扩容事件等。如果有关联，立即回滚/还原。
4 定位影响范围。比如数据库读写操作，主从库，分片示例，应用侧数据库侧等
5 执行缓解措施。
6 稳定并监控。观察错误率，延迟，流量等是否恢复正常。
7 沟通相应的团队反馈操作和问题。
8 文档记录。记录时间线，根本原因，后续改进等
AI DevOps改进
核心指标
- Mean-Time-To-Repair (MTTR) - 从故障发生到完全修复的平均时间
- How many engineers are pulled into incident（参与事件的工程师数量）
- Reported SLA for customers（向客户报告的SLA）
AI SRE系统核心特征
- Dynamic mapping of a knowledge graph（知识图谱的动态映射）：表示系统组件、依赖关系、历史故障的结构化知识。AI理解系统架构，知道"如果A出问题，可能影响B和C"
- Agentic system across observability stack and clouds（跨可观测性栈和云的代理系统）：AI不仅能分析，还能自主行动。AI像真正的SRE一样，能登录不同系统、执行命令。
- Generates real-time narratives…（生成实时叙事…）：给出具体的、可操作的修复建议（prescriptive remediation）
- Heavy emphasis on explainability and auditability（强调可解释性和可审计性）：AI的决策过程必须透明，不能是"黑箱"
Limitations
1 Complexity of incidents that can be resolved（可解决事件的复杂性）
中等复杂度的事件AI仍然表现良好，但高度复杂、多因素交织的事件：仍需要人类专家
2 Heterogeneity of modern production stacks（现代生产栈的异构性）
现代系统使用多种技术栈，AI需要适配这种多样性，目前可能覆盖不全
3 Ability to remediate actual code based on what has been detected（基于检测结果修复实际代码的能力）
AI擅长诊断，但自动修复代码还在早期阶段，并且判断原因不一定全面，权限不能太多
4 Good root cause analysis requires good monitoring gardening（好的根因分析需要好的监控基础）
AI需要：完善的指标收集，清晰的日志格式，准确的追踪配置，合理的告警阈值
5 Security could be a new attack vector（安全可能成为新的攻击向量）