AI 目前是最热门的话题之一，大家普遍认为 AI 非常有用，但其实际应用仍没有现象级产品。基于我收集的信息，关于 AI 的应用有以下几个观点：
- AI 并不存在能力问题，而是集成问题：AI 本身的能力足够，但如何将其集成到现有系统中是一个挑战。例如，在软件开发中，AI 可以帮助生成代码，但如何理解现有代码和需求的上下文是一个难点。
- 关于效率 AI 更适合做提取工作，而非生成工作：相较于内容生成，AI 在数据提取和分析上更能提升效率。比如，让 AI 进行内容续写，生成的结果大多不可用，但让它提取和总结文章内容则非常有价值。function calling这种通过上下文信息来决定调用哪个方法的做法 ，实际也是一种数据提取。
- AI 成本越来越低，可以多次调用以获得更佳答案 ：例如，当你与 AI 互动生成代码时，第一次的结果可能不够理想，而给出建议再次生成的结果往往会更好。借鉴 Agent 设计我们可以让 AI 自我评估生成的内容后进一步优化。
因此，想要有效利用 AI，首先需要深入了解业务，从单个环节的突破开始，然后逐步扩展到整个流程的优化，最终实现全面的改进。
Tips：如果你已经对事件管理有了解，请直接跳到 “AI的应用想法” 段落。
什么是事件
事件指的是任何计划外的中断或服务质量的下降，影响到客户使用系统或服务的能力。举例来说，网络服务接口响应异常、通知管道受损、系统部分不可用等都属于事件。
严重性定义
事件根据影响范围和严重性分为以下几个等级，每个等级对应不同的响应措施：
| 严重性 | 描述 |
|---|---|
| SEV-1 | 严重问题，需公开通知和高层团队介入，影响大量客户 |
| SEV-2 | 关键问题，影响大量客户，需快速处理 |
| SEV-3 | 一般问题，需立即关注，有升级为更严重问题的可能 |
| SEV-4 | 轻微问题，不影响客户使用产品功能 |
| SEV-5 | 外观问题或非紧急BUG，不影响客户使用产品功能 |
为了确保事件能被及时有效地处理，需要注意以下两点：
- 响应灵活性：即使事件不在严重性定义范围内，但你认为需要响应，那么它就应当被响应。基于实际判断进行响应，而不是严格按照严重性标准。
- 就高原则：如果无法确定事件的具体严重程度，默认将其视为更高级别。在事件处理过程中，优先假设为最高级别，避免争论。事后可通过复盘对严重性进行调整。
什么是事件响应
事件响应是团队处理计划外事件或服务中断的流程，旨在快速恢复服务，减少损失。
角色和职责
确保事件响应团队每个成员明确职责，能够提高响应速度和质量
| 角色 | 主要职责 | 次要职责 |
|---|---|---|
| 事件指挥官 (IC) | 协调团队工作，确保团队了解情况，推动事件解决，对外沟通把关 | 处理未分配的职责，全面管理事件 |
| 副手 (Deputy) | 协助 IC，处理辅助任务和记录工作，必要时接替 IC | 确保 IC 工作连贯性 |
| 记录员 (Scribe) | 记录时间线、关键数据和决策 | 维护事件进展日志 |
| 领域专家 (SME) | 快速诊断和解决问题，向 IC 提供关键信息 | 解决问题，参与事后分析 |
| 外部联络人 (Customer Liaison) | 与客户沟通，撰写发布外部消息 | 与客户支持团队联系，传递客户反馈 |
| 内部联络人 (Internal Liaison) | 与公司内其他团队沟通，确保他们及时了解事件最新情况，动员响应人员 | 向内部相关者报告最新状态，保持团队专注 |
生命周期
生命周期分为三个阶段：事前 、事中 和事后 。每个阶段都有特定步骤，以确保团队可以有效管理和应对各种事件。常见如下：
| 阶段 | 步骤 | 参考操作 | 参考实践 |
|---|---|---|---|
| 事前 | 值班 | 明确值班职责并制定计划，进行定期培训和演练 | SRE On-Call |
| 检测 | 使用监控工具管理警报，确保及时、准确 | ||
| 事中 | 沟通 | 创建专用沟通群，明确沟通角色，确保信息传递及时准确 | 沟通实践、外部沟通指南 |
| 分析 | 评估事件影响，制定响应策略，进行根本原因分析 | 有效的故障排除 | |
| 止血 | 快速修复问题，跟踪处理进展，持续更新状态 | ||
| 事后 | 复盘 | 分析事件各环节，召开复盘会议，记录问题和改进措施 | 从失败中学习、5Whys 分析 |
| 改进 | 落实改进措施，进行培训和演练，提升团队应变能力 |
现实模拟
为更好理解事件响应流程，以下通过一个AI生成的现实模拟演示整个事件处理周期：
事前阶段
值班排班
在SunnyTech公司，每周例会中制定值班计划，本周指挥官为张伟，副手为李婷。
监控预设
监控负责人晓华检查数据中心日志和监控规则，配置自动化监控，确保异常报警及时通知值班人员。
事中阶段
事件爆发
周三清晨，客户API响应异常，大量用户无法登录，触发SEV-1级警报。晓华紧急通知张伟。
紧急沟通
张伟在IM工具上创建专用沟通群，召集团队迅速行动。
- 张伟（IC）：“我是IC，副手李婷，晓华记录汇报。”
- 李婷（副手）：“收到，我会随时提供支持。”
- 晓华（记录员）：“我会实时更新事件日志。”
初步分析
张伟与团队快速讨论了影响范围，确认事件的严重性为SEV-1。他指示晓华实时更新事件进展。
- 王明（数据库专家）：“发现这个API问题似乎与最近几次部署有关。” 王明分析了数据，并发现最近几次部署API模块时出现异常。
快速止血
张伟决定立即回滚到上一个稳定版本，并指示负责服务器运行的专家刘鹏进行操作。同时，他让晓华继续监控修复进展，实时更新状态。
- 张伟（IC）：“刘鹏，请立即回滚。”
- 刘鹏（服务专家）： “回滚完成，请大家注意观察系统状态。”
经过几分钟的监控，系统状态逐渐恢复正常，用户可以重新访问服务。
对外沟通
外部联络人王琳在社交媒体和公司官网上发布公告：
- 王琳（外部联络人）：“目前我们遇到了一些技术问题，正在积极修复中。我们的团队已经采取了紧急措施，服务即将恢复正常。” 这一透明声明缓解了客户的疑虑。
内部同步
内部联络人赵强将事件详细信息和当前状态，更新给公司内部所有相关团队，确保全员信息同步。
事后阶段
事后复盘
两天后，张伟完成了复盘报告并组织了一次复盘会议，团队成员一起详细回顾了事件处理过程，分析原因，并讨论改进措施。会议期间，团队还评估了整个事件响应过程，指出哪些环节良好，哪些需要改进。
改进跟踪
在复盘会议结束后，张伟将所有议定的改进措施记录下来，并指派相关负责人进行跟踪落实。
ChatOps
简单来说，就是将IM与工作流程结合，提供高效透明的协作环境。在事件管理中，ChatOps 可以帮助团队快速响应、有效沟通并做好事后分析。
事件响应在 ChatOps 的用例
在实际操作中，ChatOps 通常通过一系列预设的命令和自动化脚本来进行，例如：
!ic：列出当前待命的现场指挥官!ic page：呼叫所有待命的现场指挥官并启动事件响应流程。!ic responders：列出所有服务团队的待命人员。!ic page responders：呼叫所有待命的响应者团队。!ic who <user>：获取特定用户的联系信息。!ic page <user>：呼叫特定的用户。!status：查看系统的当前状态。
根因定位
根因定位（Root Cause Analysis, RCA）是事件响应中的关键环节，旨在找出导致系统故障的原因，快速止损。根据业界经验以及谷歌多本 SRE 书籍中提到，70% 左右的故障是由变更引起的，因此变更相关的信息在根因定位过程中尤为重要。
根因定位的基本步骤：
- 收集数据：首先，获取尽可能多的信息，包括用户反馈、告警、指标、日志等。
- 分析症状：从数据中识别出系统表现出的各种症状。
- 生成假设：基于症状和已知信息，生成可能的故障原因假设。
- 验证假设：逐一验证假设，通过实验或进一步的数据分析排除不合理的假设。
- 找到根因：最终确定导致问题的真正原因。
有助于排查的有效信息包括：
- 告警：实时监控系统的异常提示，有助于快速发现问题区域。
- 变更：记录系统的所有变更，包括CI/CD、配置修改和新功能发布等。
- 事件：所有与问题相关的事件记录，包括开始时间、影响范围和处理步骤等。
- 指标：系统性能和健康状态的各项指标，如CPU利用率、内存使用率、网络流量等。
- 日志：系统的日志，详细记录了系统的运行状况和错误信息，是排查问题的核心数据。
- 链路：系统各组件之间的调用关系和数据流动情况，帮助理解问题在系统中的传播路径。
事后复盘
故障的发生难以避免，系统正常，只是该系统无数异常情况下的一种特例。在事件解决后，事后复盘是确保从每次故障中汲取经验教训并改进系统的重要环节。
故障细节
记录故障的详细信息，包括发生时间、影响范围、受影响的系统和服务、以及初步响应措施等等。
时间线
完整的时间线有助于深入了解故障发生过程及处理步骤。
- 发现时间：监控系统或人为发现故障的时间。
- 关键操作：记录所有关键操作的时间和具体内容（如回滚、修复等）。
- 沟通记录：所有内部、外部沟通的时间和内容。
- 解决时间：故障完全解决的时间。
根因分析
深入挖掘并分析导致故障的根本原因，一个有效的方法是“5Whys”，通过连续提问“为什么”，逐步深挖问题的本质。大多数情况并非代码、架构等表象原因，而是关于流程和机制不完善。
影响范围
评估故障对业务和客户的全方位影响，便于后续改进。常见的评估指标包括：
- 用户影响：受影响的用户数量及后果。
- 业务影响：订单、收入、客户满意度等的影响。
- 中断时间：服务中断的总时间。
吸取的经验教训
讨论事件响应中哪些方面进展顺利，以及哪些方面有改进的机会。
改进措施
根据复盘结果，制定并实施改进措施，防止类似问题再次发生。
参考
AI 的应用想法
AI Agent是一种可以自主完成任务的软件或机器人，就像一个智能助手。它的工作方式可以分为三步：
- 感知：从环境中收集信息，比如用摄像头看东西或者接收你的输入。
- 思考：收集到信息后，会用它的算法和知识来分析这些信息，决定接下来该做什么。
- 行动：根据分析结果，会执行相应的操作，比如回答你的问题、控制设备或者给你提供建议。
示例：
你有一个智能家居助手，它是一个AI Agent。当你问它"现在房间温度是多少？"时，它会通过传感器获取当前温度，并告诉你："房间温度是22度。"如果你接着说"调高温度到24度"，它会自动调节恒温器到24度。
AI 驱动的 ChatOps
在传统 ChatOps 体系中，团队需要通过固定指令如 !status 或 !ic who <user> 查询系统健康状况或用户情况，而且每次提问都需完整的上下文参数，智能程度低。而引入 AI 后，用户可以使用自然语言进行交互，系统能够理解上下文并更智能地处理和返回信息。
示例：
在团队工作中，通过聊天机器人查询系统状态，以前你需要输入固定指令
!status。现在有了AI，你可以直接问："系统现在运行得怎么样？"机器人会理解你的问题，获取系统状态并回复："系统一切正常。"
自动记录
- AI 可以通过事件关联信息、告警、用户反馈等数据快速生成事件描述。
- AI 能够实时监控并自动记录事件处理的所有细节，生成详细的时间线。
- 事件处理完毕后，AI 可以快速生成一份故障报告草稿。同时，对即将审查的报告进行评分并提供改进建议。
示例：描述生成
当监控系统触发一个SEV-1级别的警报时，AI会实时收集相关数据，进行初步的事件描述并推送到事件群。通过减少人为数据收集的步骤，团队可以直接进入问题解决阶段。
示例：记录时间线
在事件处理过程中，AI会自动记录关键操作和决策点，如“6:45 AM，回滚到上一个稳定版本”，并在事件结束后自动生成一份完整的时间线供事后复盘使用。
示例：复盘报告生成
AI根据事件的上下文生成一份故障报告草稿，包括事件描述、处理时间线、根因分析及影响范围评估。随后，AI基于数据完整性和分析为该报告打分 “80分”，并建议补充更多的用户反馈数据以提高报告质量。
根因定位
根因分析通常需要大量的线索分析，利用 AI 的能力可以缩短根因分析（RCA）时间，减少故障时间。
示例：
当出现告警时，AI 会第一时间通过分析最近的告警、变更和事件数据提出假设。然后，它调用监控、日志和链路等工具验证这些假设。这个过程反复进行，直到得出最有可能出现问题的结论，并将结论发送到群组中，加快事件解决。
5Whys 复盘
AI 可以利用“5Whys”方法，通过对话形式引导团队成员一步一步分析故障的根本原因。
示例：
AI： "为什么数据库连接失败？ 团队成员： 因为最近的一个配置变更未能正确生效。 AI： "为什么最近的一个配置变更未能正确生效？ 团队成员： 因为变更过程中缺乏必要的校验步骤。"
总结
随着软件系统的重要性不断提升，稳定性保障成为主要关注点。AI 在事件管理中的应用，如自动记录、根因定位和复盘等，可以有效提升效率。此外，AI 还有更多潜在应用空间。通过从单点突破到全局整合，最终构建一个 AI 驱动的高效事件管理体系。 希望这些建议对您有所帮助！
