收益：
- 能够利用人工智能从分散的笔记中生成运行手册、事后分析和架构文档框架
- 能够执行“禁止制造”的纪律，并在真实环境中彻底测试和标记每个运行手册
- 能够理解错误的操作手册比没有操作手册更危险，并在变更过程中保持文档的活力
文档和信息管理：运行手册、架构和机构记忆与人工智能
系统管理中最被忽视但却最重要的任务是文档。当一个系统崩溃并且构建它的人正在度假并且没有关于如何恢复的书面文字时，这对每个人来说都是一个漫长的夜晚。文档是一种机构记忆，它记录了系统的设置方式、工作方式以及出现问题时的应对措施。这种记忆中最关键的类型是操作手册：一个操作指南，它逐步告诉您在给定情况（服务崩溃、磁盘已满、备份失败）下该怎么做。在这里，人工智能解决了“空白页”和“懒惰”问题，这是编写文档的最大敌人：它从分散的笔记中生成一个有组织的操作手册，从命令历史记录中生成一个过程，从架构中生成一个描述。但关键原则是：人工智能产生蓝图和骨架；您负责测试和验证每个步骤，看看它是否确实正确 - 错误的操作手册比根本没有操作手册更危险。
在本单元中，操作手册、事后调查（事后调查报告）、架构文档和知识库编写；用人工智能生成草稿；最重要的是，您将了解未经验证的文档的风险。
为什么错误的操作手册比没有操作手册更糟糕？
这是本单元最重要的概念。没有操作手册的团队在恐慌时会变得谨慎和多疑；对每个命令都要三思而后行。但拥有“官方”操作手册的人却盲目地相信它——在半夜，在压力下，毫无疑问地执行步骤。如果该操作手册在未经人工智能生成和测试的情况下发布，并且有一个步骤错误（错误的命令、缺少先决条件、跳过后备步骤），那么结果将是灾难性的。这就是为什么每一个用人工智能制作的操作手册都必须在真实环境中从头到尾运行，并且每一步在发布之前都必须经过验证。未经测试的操作手册就像一个令人放心但空洞的承诺。
注意：在运行手册上标记“已测试：[日期]，[人员]”。用标签“草稿 - 未验证”清楚地标记未经测试的草稿。因此，没有人会在真正的危机中安全地采取未经验证的步骤。
剖析优秀的操作手册
一个好的操作手册由特定的部分组成，人工智能擅长构建框架：标题和目的（针对什么情况）、先决条件（什么访问权限、需要什么工具）、症状（何时使用此操作手册）、步骤（带有编号、可复制的命令）、验证（如何在每个步骤后识别成功）、回滚（如果步骤出错如何撤消）和升级（如果我无法弄清楚，我该给谁打电话）。你可以把你零散的笔记交给AI，并要求它把它放入这个结构中；您只需保证内容的准确性。
一步一步：利用 AI 进行文档制作
- 收集原材料。你的命令历史记录、你的笔记、一封旧电子邮件、一份聊天记录——真实的材料，即使很混乱，也比人工智能制造的要好。
- 求结构。 “将其制作为包含以下标题的操作手册：目的、先决条件、症状、步骤、验证、回滚、升级。”
- 禁止捏造。 “不要添加我没有给你的任何命令、IP、版本或步骤；将任何缺失的部分标记为[待填充]。”这可以防止最危险的错误——看似合理的虚构步骤。
- 面具。使用占位符代替实际的主机、IP、用户；如果文件被共享，秘密就不应该被泄露。
- 测试一下。在真实（最好是测试）环境中从头到尾运行 Runbook。修复任何不起作用、缺失或不清楚的步骤。
- 盖章并出版。添加测试日期、测试人员和上次更新。文档很生动；当系统发生变化时，必须进行更新。
三个迷你箱子
案例 1 — 工作 2 小时 15 分钟。管理员几个月来一直推迟记录备份恢复过程。他向 AI 提供了终端命令历史记录（屏蔽的）和一些零散的注释，并将其插入到 Runbook 框架中。 AI 在 15 分钟内就生成了清晰的轮廓。接下来的 45 分钟，管理员在测试服务器上从头到尾运行了草稿，并修复了两个缺失的步骤。结果是：一份经过测试、可靠的操作手册。
案例2——被误抓。一个团队让 AI 编写了一份服务重启运行手册，但忘记禁止“捏造”。 YZ 添加了“首先清除缓存”命令，这似乎合乎逻辑，但该服务中不存在。幸运的是，工程师在测试环境中运行了Runbook；该命令给出了一个错误。该测试步骤捕捉到了一个虚构的步骤，该步骤会在真正的危机中造成混乱。
案例 3 — 加速尸检。在一次重大停机之后，团队需要写一份事后分析报告，但没有人能够开始。他们将事件时间线和屏蔽日志交给人工智能，并要求提供一个无可指责的事后分析框架——摘要、影响、时间线、根本原因、纠正措施。 AI蓝图将一小时的工作减少到十分钟；该团队致力于核实事实并澄清行动项目。
四个可复制模板
1) 生成 Runbook 骨架：
您的角色：高级 SRE。根据下面的屏蔽注释/命令历史记录创建操作手册。标题：目的、先决条件、症状（何时使用）、步骤（编号，可以复制）、每一步验证、回滚、升级。规则：不要编造任何我没有给你的命令/IP/版本/步骤；写下缺失的部分[待填充]。材质：【蒙面纸条】
2）事后无责备：
您的角色：事件调查协调员。根据以下掩盖的时间线和日志编写无责备的事后分析草图：摘要、影响（持续时间/范围）、时间线、根本原因（如果经过验证）、影响因素、纠正措施（所有者+优先级）。不要责怪人，而要关注系统。不要在没有证据的情况下写下根本原因。数据：[...]
3）架构/服务描述：
根据以下屏蔽配置/图表信息编写服务文档：服务做什么、它由哪些组件组成、它的依赖项是什么、数据如何流动、有哪些端口/协议。保持技术性但可读性。将您不确定的关系标记为“需要验证”。信息：[蒙面]
4）文件复习审核：
查看以下现有文档并检查当前情况：(1) 哪些部分缺失/模糊，(2) 哪些步骤似乎未经测试，(3) 哪些信息可能已过时？写下我应该针对每个发现询问/验证的内容。文档：[蒙版文档]
弱提示/强提示
弱提示：
给我写一份服务器维护操作手册。
没有真正的材料。人工智能完全根据自己的常识生成文本，该文本不适合您的环境，甚至包含虚构的步骤。这是虚假信心的危险来源。
强力提示：
您的角色：高级 SRE。下面是我在“支付服务磁盘已满”事件中实现的屏蔽命令历史记录和我的笔记。根据以下内容创建运行手册：目的、先决条件（访问/工具）、症状、编号步骤（使用我的命令）、每个步骤的验证、回滚、升级。不要让我服从我没有下达的命令；空白处[待填充]。在末尾添加“未测试”警告。材料：【被屏蔽的命令历史】
文件类型
人工智能的贡献
人的强制性贡献
运行手册
骨架+布局
真实环境测试，准确度
尸检
概要+结构
验证事实和根本原因
建筑文件
描述+流程
确认关系和依赖关系
知识库文章
快速草稿
当前性和准确性检查
常见错误
- 发布未经测试的操作手册。危机中盲目采取未经证实的措施；错误的操作手册是一场灾难。
- 不禁止捏造。如果你不告诉AI“不要添加我没有给出的东西”，它就会产生合理但不切实际的步骤。
- 跳过掩蔽。当包含真实主机、IP 和用户的文件被共享时，秘密就会被泄露。
- 不更新文档。随着时间的推移，系统更改时未更新的文档会变得具有误导性。
- 不加盖邮票出版。目前尚不清楚没有测试日期和状态的文件是否可靠或草稿。
提示：保持文档“实时”的最佳方法是将其与变更流程联系起来：当系统发生变更时，让更新相关操作手册成为变更的完成标准之一。 AI加速更新，但你是触发过程。
总之
文档是机构记忆；该操作手册是在危机时期拯救生命的操作指南。人工智能从杂乱的笔记中生成有条理的草稿，解决了空白页和懒惰的问题。但最关键的事实是：错误的操作手册比没有更危险，因为它在危机中被盲目应用。因此，禁止人工智能“捏造”，掩盖它，并在真实环境中彻底测试和标记每个运行手册。当系统发生变化时，保持文档的活力。 AI构建框架；您是保证准确性和测试的人。
应用任务
选择您的团队中未记录的过程（例如，重新启动服务或恢复备份）。屏蔽您的相关命令历史记录和注释，并让 AI 使用上面的“Runbook 骨架生成”模板创建草稿；一定要严禁捏造。在测试环境中运行草稿并标记并修复任何损坏/丢失的步骤。将测试日期和测试人员信息添加到运行手册中。写下 AI 产生的差异以及您在此过程中纠正的 5 项差异。
清单
- [ ] 我根据真实材料（注意，命令历史记录）创建了操作手册，这不是我从头开始编写的吗？
- [ ] 我是否禁止AI“添加我未给出的命令/IP/步骤”？
- [ ] 我是否屏蔽了主机、IP 和用户等敏感信息？
- [ ] 我是否在真实/测试环境中运行并验证了 Runbook？
- [ ] 我是否添加了测试日期、测试者和上次更新信息？
- [ ] 我是否计划将文档链接到系统变更流程并使其保持最新？