\documentclass[a4paper]{article}

% Basic packages
\usepackage[fontset=fandol]{ctex}
\usepackage{amsmath, amssymb}
\usepackage{graphicx}
\usepackage[margin=2.5cm]{geometry}
\usepackage[most]{tcolorbox}
\usepackage{etoolbox}
\usepackage{listings}
\usepackage{hyperref}
\usepackage{booktabs}
\usepackage{subcaption}
\usepackage{float}

% Highlight boxes
\newtcolorbox{knowledgebox}[1]{
    enhanced, colback=blue!5!white, colframe=blue!75!black, colbacktitle=blue!75!black,
    coltitle=white, fonttitle=\bfseries, title=#1, attach boxed title to top left={yshift=-2mm, xshift=2mm},
    boxrule=1pt, sharp corners
}

\newtcolorbox{importantbox}[1]{
    enhanced, colback=yellow!10!white, colframe=yellow!80!black, colbacktitle=yellow!80!black,
    coltitle=black, fonttitle=\bfseries, title=#1, sharp corners
}

\newtcolorbox{warningbox}[1]{
    enhanced, colback=red!5!white, colframe=red!75!black, colbacktitle=red!75!black,
    coltitle=white, fonttitle=\bfseries, title=#1, sharp corners
}

% Listings
\lstset{
    language=Python,
    basicstyle=\ttfamily\small,
    keywordstyle=\color{blue},
    stringstyle=\color{red!60!black},
    commentstyle=\color{green!60!black},
    breaklines=true,
    frame=single,
    numbers=left,
    numberstyle=\tiny\color{gray},
    captionpos=b,
    extendedchars=false
}

% Front-page metadata
\newcommand{\notetitle}{CS146S Week 9: Agents Post-Deployment (DevOps)}
\newcommand{\noteauthors}{基于 Mihail Eric + Mayank Agarwal (Resolve CTO) 授课内容整理}
\newcommand{\notedate}{2025年11月}
\newcommand{\videochannel}{Stanford CS146S}
\newcommand{\videopublishdate}{Fall 2025}
\newcommand{\videoduration}{1 lecture (Mon)}
\newcommand{\videourl}{https://themodernsoftware.dev}
\newcommand{\videocoverpath}{}
\newcommand{\repourl}{https://github.com/hqhq1025/ai-course-notes}


% Footer with repo info
\usepackage{fancyhdr}
\pagestyle{fancy}
\fancyhf{}
\fancyfoot[C]{\thepage}
\fancyfoot[R]{\footnotesize\color{gray}\href{\repourl}{AI Course Notes}}
\renewcommand{\headrulewidth}{0pt}
\renewcommand{\footrulewidth}{0pt}

\begin{document}

\begin{titlepage}
\centering
{\Large 课程笔记\par}
\vspace{1.2cm}
{\huge\bfseries \notetitle\par}
\vspace{0.8cm}
{\large \noteauthors\par}
\vspace{0.3cm}
{\large \notedate\par}
\vspace{1.2cm}

\ifdefempty{\videocoverpath}{
\vspace{3cm}
}{
\includegraphics[width=0.82\textwidth,height=0.45\textheight,keepaspectratio]{\videocoverpath}\par
}

\vfill
\begin{tcolorbox}[width=0.9\textwidth, colback=black!2!white, colframe=black!60, sharp corners]
\textbf{课程}：\videochannel\par
\textbf{学期}：\videopublishdate\par
\textbf{讲次}：\videoduration\par
\textbf{网站}：\href{\videourl}{\nolinkurl{\videourl}}\par
\textbf{项目主页}：\href{\repourl}{\nolinkurl{\repourl}}\par
\end{tcolorbox}
\end{titlepage}

\tableofcontents
\newpage

%% --- 正文内容开始 --- %%

\section{生产环境运维的挑战}

\subsection{为什么 DevOps 是软件工程的``更难的 70\%''}

\begin{importantbox}{编码只占工程时间的 30\%}
编码仅占工程师总时间的约 30\%。更难的 70\% 是在生产环境中运行代码——复杂性、工具孤岛（tool silos）、知识鸿沟和系统间的相互依赖在这里全面碰撞。
\end{importantbox}

监控和维护生产系统仍然是一项关键（mission-critical）任务，通常由 SRE（Site Reliability Engineer）承担。

\subsection{SRE 的传统职责}

\begin{itemize}
    \item 运维监控：值班（on-call）、故障排查（troubleshooting）、基础设施管理和安全
    \item 事件解决需要从多个不同来源和团队拼凑信息
    \item 维护经常过时的 runbook（操作手册）
    \item 云原生架构（容器化 + Kubernetes）引入了更多数据、依赖和跨系统复杂性
\end{itemize}

\begin{warningbox}{SRE 的职业倦怠}
SRE 经常因为频繁的值班轮班而职业倦怠（burnout）。凌晨 3 点被 PagerDuty 叫醒处理 500 错误激增是许多 SRE 的日常。AI SRE 的一个重要价值就是减轻这种人力负担。
\end{warningbox}

\subsection{本章小结}

生产环境运维是软件工程中最耗时且压力最大的部分。SRE 面临信息碎片化、文档过时和职业倦怠等多重挑战，这为 AI 介入创造了巨大空间。

\section{基础设施与 DevOps 原则}

\subsection{监控的四个黄金信号}

\begin{importantbox}{Google SRE 的四个黄金信号}
\begin{enumerate}
    \item \textbf{Latency}（延迟）：请求的响应时间
    \item \textbf{Errors}（错误）：失败请求的比率
    \item \textbf{Traffic}（流量）：每秒请求数（requests/sec）
    \item \textbf{Saturation}（饱和度）：资源利用率，接近极限时系统性能急剧下降
\end{enumerate}
此外，还需要监控生产环境的 traces（请求追踪链路）。
\end{importantbox}

\subsection{事件响应实战：凌晨 3:12 的数据库 500 错误}

当 PagerDuty 告警显示数据库查询出现 500 错误激增时，标准的响应流程（playbook）如下：

\begin{enumerate}
    \item \textbf{确认与评估}（Acknowledge and assess）
    \item \textbf{检查数据库 + 应用}（Check DB + app）
    \item \textbf{识别近期变更}（Identify recent changes）
    \item \textbf{定位影响范围}（Localize blast radius）
    \item \textbf{执行缓解措施}（Execute mitigations）
    \item \textbf{稳定 + 监控}（Stabilize + monitor）
    \item \textbf{沟通}（Communicate）
    \item \textbf{文档记录}（Document）
\end{enumerate}

\subsection{关键度量指标}

\begin{itemize}
    \item \textbf{MTTR}（Mean Time to Repair）：平均修复时间
    \item \textbf{参与事件的工程师数量}
    \item \textbf{客户 SLA 合规报告}
\end{itemize}

\subsection{本章小结}

四个黄金信号（延迟、错误、流量、饱和度）是监控生产系统的基础框架。事件响应遵循标准化的 playbook，关键度量是 MTTR 和影响范围。

\section{AI SRE：智能运维的新范式}

\subsection{主要工具}

\begin{itemize}
    \item \textbf{Resolve AI}：本周嘉宾 Mayank Agarwal 是其 CTO
    \item \textbf{DataDog Bits AI Agent}：基于 DataDog 监控数据的 AI 分析
    \item \textbf{Splunk Observability Assistant}：Splunk 的 AI 可观测性助手
\end{itemize}

\subsection{AI SRE 的核心特征}

\begin{enumerate}
    \item \textbf{动态知识图谱}：动态映射服务间的依赖关系和状态
    \item \textbf{跨可观测性栈的 Agentic 系统}：横跨多个云和监控工具
    \item \textbf{实时叙述生成}：生成正在发生什么的实时叙述，定位可能的根因并提供支持证据，推荐具体的修复步骤
    \item \textbf{可解释性和可审计性}：重点强调预测/推理的透明性
\end{enumerate}

\begin{knowledgebox}{AI SRE 解决信息孤岛问题}
AI SRE 最重要的价值之一是打破组织内的知识孤岛。传统模式下，关于未文档化的依赖关系、脆弱的遗留服务和只在高压事件中暴露的系统怪癖，往往只存在于少数工程师的脑中。AI SRE 将这些分散的组织知识和服务级知识系统化，使其对整个团队可用。
\end{knowledgebox}

\subsection{AI 带来的改变}

\begin{itemize}
    \item 自动化减少审查时间，及早发现问题
    \item 开发者通过 AI 建议学习最佳实践
    \item AI 对所有代码审查应用相同标准
    \item AI 处理常规检查，让人类专注于复杂逻辑
    \item AI 系统随数据积累持续改进
    \item 现代 AI 代码审查工具提供上下文分析和模式识别
\end{itemize}

\subsection{当前局限}

\begin{warningbox}{AI SRE 的核心局限}
\begin{itemize}
    \item 可解决的事件\textbf{复杂度}有限——AI 目前更适合已知模式的问题
    \item 现代生产技术栈的\textbf{异构性}增加了 AI 理解的难度
    \item 基于检测结果\textbf{修复实际代码}的能力仍在早期——目前所有提供商都从根因分析入手
    \item 好的根因分析依赖于\textbf{好的监控基础设施}（监控园艺/monitoring gardening）
    \item 安全可能成为新的攻击向量
\end{itemize}
\end{warningbox}

\subsection{从告警系统到运维系统的演进}

Week 9 的关键洞见之一是：AI SRE 不应该只是“更聪明的告警摘要器”，而应逐步演化成真正的运维协作系统。

\begin{itemize}
    \item 第一阶段是\textbf{信息聚合}：把日志、指标、traces 和变更记录拉到同一视图
    \item 第二阶段是\textbf{根因推断}：给出更像工程师思路的因果链和证据
    \item 第三阶段是\textbf{建议执行}：推荐缓解动作、回滚路径和沟通模板
    \item 更长期才是\textbf{受控自动修复}：在明确边界下自动执行低风险修复动作
\end{itemize}

\begin{knowledgebox}{成熟的 AI SRE 系统首先要学会 ``少做错事''}
在生产环境里，错误的自动化往往比慢一点的人类操作更危险。因此 AI SRE 的成熟度，不只是看它能自动做多少事，更看它能否稳定识别哪些事不该自动做。
\end{knowledgebox}

\subsection{本章小结}

AI SRE 通过动态知识图谱、跨栈 Agent 系统和实时叙述生成来辅助运维。其最大价值在于打破信息孤岛、降低 MTTR。当前的局限在于只能处理中等复杂度的已知模式问题，从检测到自动修复仍有较长的路要走。

\section{值班室的实践手册}

\subsection{事件文档化与复盘的标准化}

Week 9 还有一个强调：SRE 的工作不能只靠记忆，必须把事件、假设、调试步骤、决策理由都写入文档。

\begin{itemize}
    \item 每次 incident 产生的 alert、trace、 metric spike，必须关联到一个 ticket
    \item 每条 ticket 记录触发时间、影响范围以及后来做出的缓解动作
    \item 事件结束后编写 post-mortem，标注 root cause、lessons learned、future mitigations
    \item AI SRE 可以自动生成初稿，但仍需人为校对、补充背景和验证
\end{itemize}

\begin{warningbox}{不写 post-mortem 就不算彻底经历了一次 incident}
单纯把监控数字压回来的行动可能只暂时压住火苗。真正的安全能力来自把事件记录成知识——下次再发生类似问题，团队能快速知道上次是怎么处理的。
\end{warningbox}

\subsection{值班体系的三个阶段}

将 Week 9 的思路向下分解，可以形成一个三阶段的成熟度模型：

\begin{table}[H]
\centering
\begin{tabular}{p{0.22\textwidth} p{0.28\textwidth} p{0.28\textwidth}}
\toprule
阶段 & 主要任务 & AI SRE 的角色 \\
\midrule
观察阶段 & 统一监控+日志、门槛告警 & 提供实时摘要、highlight 可疑模式 \\
响应阶段 & 快速定位 root cause、执行缓解 & 建议命令、引用操作记录、验证方案 \\
复盘阶段 & 编写 post-mortem、更新 runbook & 自动整理 evidence matrix、提醒 follow-up tasks \\
\bottomrule
\end{tabular}
\caption{AI SRE 在值班体系中的三阶段角色}
\end{table}

\subsection{本章小结}

事件不仅要快速处理，也要写成知识。Week 9 告诉我们：AI SRE 介入值班流程时，最初的价值来自 observation + suggestion，后续再扩展到 controlled execution 和 incident learning。

\section{生产落地：怎样让 AI SRE 真正进入值班体系}

\subsection{AI SRE 首先是协作工具，而不是替班工具}

课程里一个很重要的现实判断是：短期内 AI SRE 更像“更强的副驾驶”，而不是“完全替代值班工程师的驾驶员”。

\begin{itemize}
    \item 它最擅长的，是在高压场景下快速整合分散信息
    \item 它能帮助工程师更快看见依赖链、近期变更和潜在 blast radius
    \item 但最终是否回滚、是否扩容、是否宣布重大事故，仍然需要人类判断
\end{itemize}

\begin{importantbox}{值班体系中的关键问题不是 ``能不能自动修''，而是 ``什么时候绝不能自动修''}
在生产环境里，少数错误自动化动作的代价可能远大于人工慢几分钟的代价。因此成熟团队会先定义自动化禁区：哪些服务、哪些时段、哪些动作、哪些权限绝不能让 AI 直接执行。
\end{importantbox}

\subsection{把 AI SRE 接入值班流程的三步法}

\begin{table}[H]
\centering
\begin{tabular}{p{0.18\textwidth} p{0.24\textwidth} p{0.32\textwidth}}
\toprule
阶段 & AI 的角色 & 团队关注点 \\
\midrule
观察阶段 & 汇总告警、日志和 traces & 看它是否真的减少排障时间，而不是制造新噪音 \\
建议阶段 & 提供根因假设和缓解动作建议 & 建立建议的准确率、误报率和可审计性 \\
受控执行阶段 & 自动做低风险、可回滚操作 & 明确权限边界、审批门槛和回退机制 \\
\bottomrule
\end{tabular}
\caption{AI SRE 进入值班体系的典型路径}
\end{table}

\begin{warningbox}{没有高质量运行数据，AI SRE 很容易沦为 ``幻觉放大器''}
如果指标命名混乱、trace 覆盖不全、变更记录缺失、runbook 过时，那么 AI 得到的不是更好的上下文，而是一堆更快被拼接起来的噪音。AI SRE 的效果上限，直接受制于团队原有 observability 基础。
\end{warningbox}

\subsection{本章小结}

AI SRE 要真正进入生产值班体系，必须先从观察和建议做起，再逐步进入受控执行。它的上限由模型能力决定，但它的下限几乎完全由监控基础设施和组织边界决定。

\section{实战落地：事件复盘与信任恢复}

\subsection{为什么“复盘”是 AI SRE 成熟的第二阶段}

事件处理完并不意味着工作结束。关键在于“复盘和信任恢复”：

\begin{itemize}
    \item 记录所有 Agent 交互、工具调用、自动建议和人工决策
    \item 分析为什么 AI 没能给出正确建议（数据缺失、prompt 注入、模型 hallucination）
    \item 补回缺失的文档、hooks 和监控信号
    \item 向团队公布经验教训，更新 runbook 和审批政策
\end{itemize}

\begin{warningbox}{没有复盘就没有信任}
运行中的团队对 AI 的信任来自连续的成功案例和透明的错误处理路径。如果每次 AI 出问题都只是“回滚并忘记”，团队就不会允许它承担更多权限。
\end{warningbox}

\subsection{事件复盘的可视化流程}

\begin{table}[H]
\centering
\begin{tabular}{p{0.2\textwidth} p{0.25\textwidth} p{0.28\textwidth}}
\toprule
步骤 & 产出 & 关键指标 \\
\midrule
收集证据 & 命令历史 + prompt + tool outputs & 覆盖率、日志完整性 \\
归因分析 & 根因链 + 证据矩阵 & 误差区间、关联度 \\
补救方案 & 新 hook / 新测试 / 调整权限 & 执行次数、Rollback 次数 \\
知识沉淀 & 更新 runbook、加标签、分享会议 & 文档完成度、审计验证 \\
\bottomrule
\end{tabular}
\caption{事件复盘的可视化流程}
\end{table}

\subsection{本章小结}

事件处理的最后一公里是复盘与信任恢复。记录原始决策链条、分析根因、修补监控，并把教训转化为可操作的 runbook，是 AI SRE 真正进入生产的前提。

\section{总结与延伸}

Week 9 将视角从``写代码''转向``运行代码''。DevOps 和 SRE 是软件工程中最耗时的部分，AI SRE 正在通过知识图谱、跨栈 Agent 和实时分析来降低运维负担。

\subsection{关键要点}

\begin{itemize}
    \item 编码只占工程时间的 30\%，运维是更难的 70\%
    \item 四个黄金信号：延迟、错误、流量、饱和度
    \item 事件响应遵循标准化 playbook，核心度量是 MTTR
    \item AI SRE 的四大特征：动态知识图谱、跨栈 Agent、实时叙述、可解释性
    \item 最大价值：打破知识孤岛，降低 MTTR
    \item 当前从根因分析入手，自动修复仍在早期
\end{itemize}

\subsection{运维落地清单}

\begin{enumerate}
    \item 先统一监控口径和日志质量，再引入 AI SRE，不要让 AI 替代混乱的数据基础
    \item 把 MTTR、误报率和升级准确率作为核心指标，而不是只看模型回答是否“像样”
    \item 在受控范围内自动化低风险操作，把高风险修复留给人工审批
\end{enumerate}

\subsection{值班角色分工表}

\begin{table}[H]
\centering
\begin{tabular}{p{0.18\textwidth} p{0.26\textwidth} p{0.3\textwidth}}
\toprule
角色 & 在 AI SRE 体系中的职责 & 不能放弃的人类责任 \\
\midrule
值班工程师 & 审阅 AI 汇总、决定缓解动作、协调升级 & 对重大操作负责最终确认 \\
AI SRE 系统 & 聚合证据、给出根因假设、建议低风险动作 & 不能越权执行高风险修复 \\
平台/基础设施团队 & 维护监控、日志、runbook 与权限边界 & 保证 AI 有高质量运行数据可用 \\
\bottomrule
\end{tabular}
\caption{AI SRE 场景下的人机角色边界}
\end{table}

\subsection{Postmortem 闭环为什么更重要了}

AI SRE 并不会让事故复盘变得不重要，反而会让它更重要。因为每一次事故处理，都会同时暴露两类问题：

\begin{itemize}
    \item 系统本身的问题：监控缺口、依赖不清、runbook 过时、权限边界模糊
    \item AI 系统的问题：它遗漏了哪些信号、放大了哪些噪音、在哪一步给出了不可靠建议
\end{itemize}

因此，成熟团队需要把 postmortem 的产出重新写回监控、告警规则、AI 提示词、runbook 和审批边界，让 AI SRE 不是一次性的事故助手，而是可持续进化的运维系统。

\subsection{拓展阅读}

\begin{itemize}
    \item Resolve AI：\url{https://resolve.ai}
    \item Google SRE Book：\url{https://sre.google/sre-book/table-of-contents/}
    \item DataDog Bits AI：\url{https://www.datadoghq.com/product/platform/bits-ai/}
    \item ``The Four Golden Signals'' (Google SRE Book, Chapter 6)
    \item PagerDuty Incident Response Guide：\url{https://response.pagerduty.com}
\end{itemize}

%% --- 正文内容结束 --- %%

\end{document}
