Back to Details

knowledge-ops

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

knowledge-ops

knowledge-ops

Company SOP + internal runbook authoring, 5W2H completeness validation, and KB hygiene reporting for Head-of-Ops / Knowledge-Manager / TPM-Internal personas.
面向运营主管/知识经理/内部技术项目经理的企业SOP+内部运行手册创作、5W2H完整性验证及知识库卫生报告工具。

Purpose

用途

An ops organization three years in accumulates a sprawl: 600 Notion pages, 200 Confluence runbooks, three Obsidian vaults, a 
Drive/SOPs/
folder, and a 
Slack #ops-questions
channel that exists because nobody can find the canonical doc. Predictable failure modes:
  1. No owner — 40% of SOPs name "the team" instead of a person. When the doc rots, nobody is accountable.
  2. No last-reviewed date — a 2023 vendor-offboarding SOP still references a procurement tool sunset in 2024.
  3. Vague success signals — runbook step 4 says "verify the service is up". A new operator can't tell what that means.
  4. No rollback path — incident-comms cascade runbook tells you how to send the alert. It doesn't tell you how to retract it when the alert was wrong.
  5. Orphan pages — half the KB has no inbound links. Nobody finds them via navigation; they only exist because somebody knew the URL.
  6. Glossary drift — "CSM" means Customer Success Manager in three docs and Customer Solutions Manager in five. New hires guess wrong for six months.
  7. Happy-path-only SOPs — the doc covers what happens when everything works. It doesn't cover the 30% case where it doesn't.
This skill answers the operator's actual question: "Which 20 docs do I fix first, and what specifically is wrong with each?" — with deterministic logic, not intuition.
运营组织成立三年后，会积累大量分散的文档：600个Notion页面、200个Confluence运行手册、三个Obsidian库、一个
Drive/SOPs/
文件夹，还有一个
Slack #ops-questions
频道——因为没人能找到权威文档。常见的失效模式包括：
  1. 无负责人——40%的SOP只写“团队”而非具体个人，文档过时后无人负责。
  2. 无最后审核日期——2023年的供应商离职SOP仍引用2024年已停用的采购工具。
  3. 成功信号模糊——运行手册第4步写“验证服务已启动”，新运维人员无法明确具体标准。
  4. 无回滚路径——事件沟通流程手册只说明如何发送警报，未提及警报错误时的撤回方式。
  5. 孤立页面——半数知识库页面无入站链接，无法通过导航找到，仅靠知晓URL的人才能访问。
  6. 术语漂移——“CSM”在3份文档中指客户成功经理，在5份文档中指客户解决方案经理，新员工半年内都在猜测正确含义。
  7. 仅覆盖理想流程的SOP——文档只描述一切顺利时的操作，未覆盖30%的异常场景。
本工具解决运维人员的真实需求：“我应该优先修复哪20份文档，每份具体存在什么问题？”——采用确定性逻辑，而非直觉判断。

When to use

使用场景

  • Authoring a new SOP for a cross-functional company process (procurement intake, vendor offboarding, incident-comms cascade, employee onboarding, expense reimbursement, customer-escalation playbook, security-incident comms, system-access provisioning).
  • Validating an existing internal runbook before it goes into rotation (every step must have a named owner, expected duration, observable success signal, observable failure signal, rollback path, escalation contact).
  • Ingesting a multi-document KB export (Notion zip, Confluence space export, Obsidian vault, 
    Drive/SOPs/
    directory) and surfacing what's broken: orphan pages, stale pages (no edit > 12 months), glossary drift, missing-owner pages, cross-link map.
  • Onboarding a new ops hire by generating the SOPs and ops-handbook pages they need to read in week 1.
  • Wiki cleanup sprints — quarterly hygiene work where the org decides which 30 docs to archive, rewrite, or merge.
  • 为跨职能企业流程创作新SOP，包括采购申请、供应商离职处理、事件沟通流程、员工入职、费用报销、客户升级处理手册、安全事件沟通、系统权限配置。
  • 在现有内部运行手册投入使用前进行验证，确保每个步骤都包含指定负责人、预期时长、可观测成功信号、可观测失败信号、回滚路径、升级联系人。
  • 导入多文档知识库导出文件（Notion压缩包、Confluence空间导出、Obsidian库、
    Drive/SOPs/
    目录），识别问题：孤立页面、过时页面（12个月以上未编辑）、术语漂移、无负责人页面、交叉链接图谱。
  • 生成新运维人员入职第一周需要阅读的SOP和运维手册页面，辅助入职培训。
  • 知识库清理冲刺——每季度的卫生整理工作，确定需要归档、重写或合并的30份文档。

Workflow

工作流程

Four-step deterministic flow (matches the ops org's actual workflow, not an abstract process):
  1. Ingest KB. Run 
    kb_ingester.py --input <vault-dir>
    on the existing wiki export. Output is a markdown health report: orphan pages, stale pages, glossary drift, missing-owner pages, cross-link map, prioritized cleanup list. The report ranks the top-20 docs to fix first — usually a mix of high-traffic stale docs and compliance-relevant missing-owner docs. Take this list to the cleanup sprint.
  2. Validate existing runbooks. For each runbook in the cleanup list (or any new runbook before it goes into rotation), run 
    runbook_validator.py --input <runbook.md>
    . The validator scores each step against six checks (named owner, expected duration, observable success signal, observable failure signal, rollback path, escalation contact) and produces a per-step traffic-light + overall validity score 0-100 + MUST-FIX issue list. A runbook scoring < 60 is not safe to use in an incident.
  3. Generate missing SOPs. For SOPs that need to be written from scratch (or rewritten because the existing one is unsalvageable), run 
    sop_generator.py --input <metadata.json> --profile <ops|support|finance|hr|it|regulated>
    . Output is a 5W2H-structured SOP scaffold: Who (RACI), What (process steps), When (triggers + frequency), Where (system + tool), Why (purpose + regulatory basis), How (step-by-step), How-much (cost + time per execution). The 
    regulated
    profile adds version control, signoff, and audit-trail sections (ISO 9001 / FDA 21 CFR Part 211 / SOC 2 / HIPAA).
  4. Cross-link + close the loop. Re-run 
    kb_ingester.py
    after the cleanup sprint to verify orphan-page count is down and glossary drift is resolved. The metric that matters is "unfindable docs" (orphans) and "unsafe runbooks" (validity score < 60) — not page count.
四步确定性流程（匹配运维组织实际工作流，而非抽象流程）：
  1. 导入知识库：对现有知识库导出文件运行
    kb_ingester.py --input <vault-dir>
    ，输出markdown格式的健康报告，包含孤立页面、过时页面、术语漂移、无负责人页面、交叉链接图谱、优先级排序的清理清单。报告会列出优先修复的前20份文档——通常是高流量过时文档和合规相关的无负责人文档组合。将此清单用于清理冲刺工作。
  2. 验证现有运行手册：对清理清单中的每份运行手册（或新创作的运行手册投入使用前），运行
    runbook_validator.py --input <runbook.md>
    。验证器会针对六项检查（指定负责人、预期时长、可观测成功信号、可观测失败信号、回滚路径、升级联系人）对每个步骤打分，生成逐步骤的红绿灯标识、0-100的整体有效性得分，以及必须修复的问题列表。得分低于60的运行手册不适用于事件处理场景。
  3. 生成缺失的SOP：对于需要从头创作（或现有文档无法修复需重写）的SOP，运行
    sop_generator.py --input <metadata.json> --profile <ops|support|finance|hr|it|regulated>
    。输出采用5W2H结构的SOP框架：Who（RACI职责分配）、What（流程步骤）、When（触发条件+频率）、Where（系统+工具）、Why（目的+合规依据）、How（分步操作）、How-much（每次执行的成本+时间）。
    regulated
    配置文件会添加版本控制、签字确认和审计追踪章节（符合ISO 9001 / FDA 21 CFR Part 211 / SOC 2 / HIPAA要求）。
  4. 交叉链接+闭环验证：清理冲刺完成后，重新运行
    kb_ingester.py
    ，验证孤立页面数量是否减少、术语漂移是否解决。关键指标是**“无法找到的文档”（孤立页面）和“不安全的运行手册”（有效性得分<60）**——而非页面总数。

Scripts

脚本说明

scripts/sop_generator.py
 — Reads a JSON metadata file describing an SOP (process owner, triggering event, audience role, frequency, regulatory overlay, inputs, outputs, steps outline) and emits a full 5W2H-structured SOP in markdown (or normalized JSON). The 
--profile
flag tunes the output: 
ops
(general internal ops), 
support
(customer-support runbook style), 
finance
(controls + reconciliation focus), 
hr
(sensitive-data flagging), 
it
(system + access focus), 
regulated
(adds version control, signoff matrix, audit-trail). Regulatory overlays (
SOC2
, 
HIPAA
, 
ISO13485
, 
GDPR
, 
SOX
) attach the appropriate compliance preamble. 
--sample
prints a complete vendor-offboarding SOP example. Stdlib only.
scripts/runbook_validator.py
 — Reads a runbook (markdown file or JSON) and validates each step against six required attributes: (1) named owner (not "the team", not "ops"), (2) expected duration (concrete number + unit), (3) observable success signal (e.g., "HTTP 200 from 
/healthz
" — not "service is up"), (4) observable failure signal, (5) rollback path (or explicit "this step cannot be rolled back, escalate to X"), (6) escalation contact (named person or named on-call rotation). Output is a per-step traffic-light (GREEN/AMBER/RED), an overall validity score 0-100, and a MUST-FIX issue list. Verdict: ≥ 80 = SAFE-TO-USE, 60-79 = USE-WITH-CAUTION, < 60 = NOT-SAFE. 
--sample
prints a deliberately-broken incident-comms runbook to demonstrate failure detection. Stdlib only.
scripts/kb_ingester.py
 — Walks a directory of markdown files (Notion export, Confluence space export, Obsidian vault, 
Drive/SOPs/
directory). Extracts: (a) cross-link map (which page references which, via markdown 
[link](path)
syntax), (b) glossary candidates (frequently used proper nouns and acronyms that recur in 3+ docs without a single canonical definition page), (c) orphan pages (no inbound links from anywhere in the vault), (d) glossary drift (the same term defined or used inconsistently across docs — e.g., "CSM" expanded differently in two places), (e) stale pages (no edit in > 12 months, detected via filesystem mtime or YAML 
last_reviewed
frontmatter), (f) missing-owner pages (no 
owner:
field in frontmatter). Emits a KB health report markdown with a prioritized top-20 cleanup list ranked by 
staleness × inbound-link-count
(high-traffic stale docs first). 
--sample
builds a tiny synthetic 8-page vault in a tmpdir and runs the full pipeline against it. Stdlib only.
scripts/sop_generator.py
 — 读取描述SOP的JSON元数据文件（流程负责人、触发事件、受众角色、频率、合规要求、输入输出、步骤大纲），输出完整的5W2H结构SOP（markdown或标准化JSON格式）。
--profile
参数可调整输出风格：
ops
（通用内部运维）、
support
（客户支持运行手册风格）、
finance
（侧重控制与对账）、
hr
（敏感数据标记）、
it
（侧重系统与权限）、
regulated
（添加版本控制、签字矩阵、审计追踪）。合规覆盖项（
SOC2
、
HIPAA
、
ISO13485
、
GDPR
、
SOX
）会附加相应的合规前言。
--sample
参数可打印完整的供应商离职SOP示例。仅依赖Python标准库。
scripts/runbook_validator.py
 — 读取运行手册（markdown文件或JSON），针对六项必填属性验证每个步骤：(1) 指定负责人（不能是“团队”或“运维”）、(2) 预期时长（具体数字+单位）、(3) 可观测成功信号（例如“
/healthz
返回HTTP 200”——而非“服务已启动”）、(4) 可观测失败信号、(5) 回滚路径（或明确标注“此步骤无法回滚，升级至X”）、(6) 升级联系人（指定个人或轮值团队）。输出逐步骤的红绿灯标识（GREEN/AMBER/RED）、0-100的整体有效性得分，以及必须修复的问题列表。判定标准：≥80=可安全使用，60-79=谨慎使用，<60=不可使用。
--sample
参数可打印一份故意设置错误的事件沟通运行手册，演示故障检测功能。仅依赖Python标准库。
scripts/kb_ingester.py
 — 遍历markdown文件目录（Notion导出、Confluence空间导出、Obsidian库、
Drive/SOPs/
目录），提取以下信息：(a) 交叉链接图谱（哪些页面引用了哪些页面，通过markdown 
[link](path)
语法识别）、(b) 术语候选（在3份以上文档中重复出现但无统一权威定义的专有名词和缩写）、(c) 孤立页面（库内无任何入站链接的页面）、(d) 术语漂移（同一术语在不同文档中的定义或使用不一致——例如“CSM”在两处的全称不同）、(e) 过时页面（12个月以上未编辑，通过文件系统修改时间或YAML 
last_reviewed
前置字段检测）、(f) 无负责人页面（前置字段中无
owner:
项）。输出markdown格式的知识库健康报告，包含按
过时程度 × 入站链接数
排序的前20份优先清理文档（高流量过时文档优先）。
--sample
参数会在临时目录中构建一个小型的8页合成库，并运行完整流程演示。仅依赖Python标准库。

References

参考资料

  • references/5w2h_sop_canon.md
    — Kaoru Ishikawa's 5W2H method, Toyota standard-work discipline, Atul Gawande's checklist manifesto, Atlassian Confluence SOP guidance, ISO 9001 SOP requirements, ITIL v4 Service Operation, FDA 21 CFR Part 211. Eight cited sources covering SOP authoring canon.
  • references/runbook_canon.md
    — Google SRE Workbook (runbook chapter), Atlassian incident-management runbooks, PagerDuty Incident Response taxonomy, AWS Well-Architected operational excellence pillar, Charity Majors on observability-runbook integration, Susan Fowler on production-ready microservices, ITIL v4 Operations. Seven cited sources covering runbook design canon.
  • references/kb_hygiene_anti_patterns.md
    — Eight anti-patterns drawn from Notion/Confluence wiki industry research, Mozilla SUMO knowledge-base lessons, Stack Overflow community-management research, the Atlassian Team Playbook, MIT TIK org-wiki studies, Cynthia Lee on glossary drift, and Adam Wiggins on "documentation rot".
  • references/5w2h_sop_canon.md
    — 石川馨的5W2H方法、丰田标准作业规范、阿图·葛文德的《清单革命》、Atlassian Confluence SOP指南、ISO 9001 SOP要求、ITIL v4服务运营、FDA 21 CFR Part 211。涵盖SOP创作规范的8个引用来源。
  • references/runbook_canon.md
    — Google SRE工作手册（运行手册章节）、Atlassian事件管理运行手册、PagerDuty事件响应分类、AWS架构完善框架卓越运营支柱、Charity Majors关于可观测性与运行手册集成的观点、Susan Fowler关于生产就绪微服务的内容、ITIL v4运营。涵盖运行手册设计规范的7个引用来源。
  • references/kb_hygiene_anti_patterns.md
    — 8种反模式，来自Notion/Confluence知识库行业研究、Mozilla SUMO知识库经验、Stack Overflow社区管理研究、Atlassian团队手册、MIT TIK组织知识库研究、Cynthia Lee关于术语漂移的内容、Adam Wiggins关于“文档过时”的观点。

Assumptions

前提假设

  1. The KB is in markdown (or can be exported to markdown — Notion, Confluence, Obsidian, and Google Docs all support this). HTML-only or PDF-only KBs require a conversion pass first; out of scope.
  2. The user has authority to commission rewrites or archives. Producing a cleanup list nobody acts on is wasted work — route findings to a named owner before running the ingester.
  3. Owner metadata lives in YAML frontmatter (
    owner: alex@company.com
    ) or in a top-of-page "Owner:" line. Tribal-knowledge ownership (the person who last edited the page) is treated as missing.
  4. "Stale" defaults to 12 months. Override with 
    --stale-days
    on 
    kb_ingester.py
    . Some compliance regimes (FDA, ISO 13485) require shorter review cycles; use 
    --profile regulated
    and 
    --stale-days 365
    .
  5. The user is not asking for a personal PKM. Personal Karpathy-style second-brain work belongs in 
    engineering/llm-wiki
    .
  1. 知识库采用markdown格式（或可导出为markdown——Notion、Confluence、Obsidian和Google Docs均支持此功能）。仅HTML或PDF格式的知识库需先进行转换，不在本工具范围内。
  2. 用户有权安排文档重写或归档。生成无人执行的清理清单是无效工作——在运行导入工具前，需将结果提交给指定负责人。
  3. 负责人元数据存储在YAML前置字段（
    owner: alex@company.com
    ）或页面顶部的“Owner:”行中。仅靠部落知识（最后编辑页面的人）认定的负责人视为缺失。
  4. “过时”默认定义为12个月。可通过
    kb_ingester.py
    的
    --stale-days
    参数覆盖。部分合规体系（FDA、ISO 13485）要求更短的审核周期；使用
    --profile regulated
    和
    --stale-days 365
    参数。
  5. 用户并非需要个人PKM工具。Karpathy风格的个人第二大脑工具属于
    engineering/llm-wiki
    范畴。

Anti-patterns

反模式

  • Generating SOPs in bulk without owners. A doc with no owner has a half-life of 6 months. Refuse to generate a batch of 30 SOPs unless each one is assigned to a named human.
  • Using 
    runbook_validator.py
    as a checkbox.     The validator catches missing structure. It does not catch wrong content. A runbook can score 100 and still tell the operator the wrong thing.
  • Treating orphan pages as garbage by default. Some orphans are reference pages found only via search — not all orphans should be archived. The cleanup list is a priority queue, not a delete list.
  • Confusing knowledge-ops with 
    process-mapper
    .     Process-mapper documents the flow of work between stages (BPMN, cycle time, bottleneck). Knowledge-ops documents the artifacts operators consume to execute the work (SOP, runbook, glossary). Both can apply to the same process.
  • Letting glossary drift accumulate. Two definitions of "CSM" in three years becomes seven definitions in five. Fix glossary drift the moment it surfaces in 
    kb_ingester.py
    output.
  • Skipping the regulated profile under regulated workload. If the process touches PHI, SOX-relevant financial controls, or ISO 13485 device QMS, use 
    --profile regulated
    . Missing version control on a regulated SOP is an audit finding.
  • Hand-writing 5W2H sections from memory. The 5W2H scaffold exists because operators forget "How-much". Use the generator; edit the output.
  • 批量生成无负责人的SOP：无负责人的文档半衰期为6个月。除非每份SOP都分配给指定个人，否则拒绝批量生成30份SOP。
  • 将
    runbook_validator.py
    用作形式化勾选工具    ：验证器仅检查结构完整性，无法检测内容错误。一份得分100的运行手册仍可能给出错误操作指引。
  • 默认将孤立页面视为垃圾文档：部分孤立页面是仅通过搜索找到的参考页面——并非所有孤立页面都应归档。清理清单是优先级队列，而非删除列表。
  • 混淆知识运营与
    process-mapper
    ：Process-mapper记录工作在各阶段的流转（BPMN、周期时间、瓶颈）。知识运营记录运维人员执行工作时使用的文档（SOP、运行手册、术语表）。两者可应用于同一流程。
  • 放任术语漂移累积：三年内出现两种“CSM”定义，五年内会演变为七种。一旦
    kb_ingester.py
    输出中出现术语漂移，立即修复。
  • 在合规场景下跳过regulated配置文件：如果流程涉及PHI（受保护健康信息）、SOX相关财务控制或ISO 13485设备质量管理体系，需使用
    --profile regulated
    参数。合规SOP缺失版本控制会导致审计不合格。
  • 凭记忆手写5W2H章节：5W2H框架的存在就是为了避免运维人员遗漏“How-much”项。使用生成工具，再对输出内容进行编辑。

Distinct from

区别于其他工具

  • engineering/llm-wiki
     — Karpathy-style personal PKM second brain where one human ingests sources into their own interlinked vault. Knowledge-ops is organizational: many authors, many readers, named owners per doc, formal review cycles, compliance overlays.
  • engineering-team/runbook-generator
     — system-ops runbook for debugging a production system (logs, alerts, k8s, on-call). Knowledge-ops runbooks are operator runbooks for business processes (incident-comms cascade, vendor offboarding, employee onboarding). The audience is fellow operators, not engineers tailing logs.
  • project-management/*
     — Jira / Confluence delivery tracking, sprint ticket workflow, project-status reporting. Knowledge-ops is the content in those Confluence pages, not the tracking of who edits them.
  • business-operations/process-mapper
     (sibling) — BPMN process design: where the stages are, where work waits, which stage is the bottleneck. Knowledge-ops is process documentation: the SOP and runbook artifacts that tell an operator how to execute the process the mapper described.
  • business-operations/internal-comms
     (sibling) — broadcast announcements, all-hands messaging, change-management comms. Knowledge-ops is the durable reference artifact; internal-comms is the broadcast.
  • ra-qm-team/*
     — formal regulatory compliance authoring (ISO 13485 QMS, MDR technical files, 21 CFR Part 820). Knowledge-ops borrows the regulatory checklist but is not a substitute for a notified-body audit.
  • engineering/llm-wiki
     — Karpathy风格的个人PKM第二大脑，由个人将资源导入自己的关联库。知识运营是组织级工具：多作者、多读者、每份文档指定负责人、正式审核周期、合规覆盖。
  • engineering-team/runbook-generator
     — 用于调试生产系统的运维运行手册（日志、警报、k8s、轮值）。知识运营的运行手册是针对业务流程的运维人员手册（事件沟通流程、供应商离职处理、员工入职）。受众是其他运维人员，而非查看日志的工程师。
  • project-management/*
     — Jira/Confluence交付跟踪、冲刺工单流程、项目状态报告。知识运营关注这些Confluence页面中的内容，而非谁编辑了页面的跟踪功能。
  • business-operations/process-mapper
    （同类工具）—— BPMN流程设计：包含哪些阶段、工作在哪里等待、哪个阶段是瓶颈。知识运营是流程文档：告诉运维人员如何执行流程设计工具所描述的流程的SOP和运行手册文档。
  • business-operations/internal-comms
    （同类工具）—— 广播通知、全员消息、变更管理沟通。知识运营是持久化的参考文档；内部沟通是广播消息。
  • ra-qm-team/*
     — 正式合规创作（ISO 13485质量管理体系、MDR技术文件、21 CFR Part 820）。知识运营借鉴合规检查清单，但不能替代公告机构的审计。

Forcing-question library (Matt Pocock grill discipline)

强制问题库（Matt Pocock审查规范）

Before invoking the tools, the orchestrator (or 
/cs:grill-bizops
) walks the user through these questions one at a time, with a recommended answer + canon citation. Never bundled. Walk depth-first — do not open question 4 until 1-3 are locked.
  1. "Who is the named owner of this SOP / runbook, and do they know they own it?" Recommended: a single human (not "the team"), and yes — they have agreed in writing. Canon: Gawande 2009 (The Checklist Manifesto) — checklists without an owner rot within 12 months. Ownership is the discipline.
  2. "When was this doc last reviewed, and what is the review cadence?" Recommended: reviewed within the last 12 months (90 days if 
    --profile regulated
    ); cadence written in the frontmatter. Canon: ISO 9001:2015 §7.5.3 — controlled documents require review-cycle metadata. ITIL v4 echoes this for Service Operation runbooks.
  3. "For each runbook step: what is the observable success signal — by which I mean, what specific output tells you the step worked?" Recommended: a concrete observable ("HTTP 200 from 
    /healthz
    ", "Slack thread closed with 
    done
    reaction", "Salesforce opportunity moved to 
    Closed-Won
    stage") — not "the service is up" or "it works". Canon: Beyer et al. 2018 (Site Reliability Workbook, Ch. 8) — observable signals are the entire point of a runbook. Vague success criteria are the leading cause of runbook misuse during incidents.
  4. "What is the rollback path for each runbook step that can fail?" Recommended: every step that mutates state has either a rollback path or an explicit "cannot roll back — escalate to X" line. Canon: AWS Well-Architected Framework, Operational Excellence pillar — "you cannot run a process you cannot reverse without first agreeing what 'reverse' means".
  5. "Where does this doc live, and what other docs link to it?" Recommended: in the canonical wiki, and at least 2 inbound links from related docs. An orphan SOP is an unfindable SOP. Canon: Atlassian Team Playbook on documentation health — orphan rate > 20% is the leading indicator of a wiki sprawl problem.
  6. "What is the regulatory overlay on this process — SOC 2, HIPAA, ISO 13485, GDPR, SOX, none?" Recommended: explicit answer. If "none", confirm by checking the data classes the process touches. Canon: FDA 21 CFR Part 211.100 (Written procedures; deviations) — regulated SOPs require version control, change history, and signoff. Skip this step and the doc is an audit finding.
  7. "Is the happy path the only path documented, or are the 2-3 most common failure modes also documented?" Recommended: the top-2 failure modes per process are documented with their own recovery sub-procedure. Canon: Fowler 2016 (Production-Ready Microservices) — operations docs that cover only the happy path are responsible for 60%+ of incident-time waste.
After all 7 are locked, invoke 
kb_ingester.py
→ 
runbook_validator.py
→ 
sop_generator.py
in sequence.
在调用工具前，编排器（或
/cs:grill-bizops
）会引导用户逐一回答以下问题（提供推荐答案+规范引用）。切勿批量提问，采用深度优先方式——在1-3题确认前，不要展开第4题。
  1. “这份SOP/运行手册的指定负责人是谁，他们是否知晓自己的职责？” 推荐答案：单个具体人员（而非“团队”），且负责人已书面确认。 规范引用：葛文德2009年《清单革命》——无负责人的清单会在12个月内过时，明确职责是核心规范。
  2. “这份文档最后一次审核是什么时候，审核周期是多久？” 推荐答案：过去12个月内审核过（如果使用
    --profile regulated
    则为90天）；审核周期已写入前置字段。 规范引用：ISO 9001:2015 §7.5.3——受控文档需包含审核周期元数据。ITIL v4对服务运营运行手册也有相同要求。
  3. “对于运行手册的每个步骤：可观测成功信号是什么？即，什么具体输出能表明步骤已完成？” 推荐答案：具体可观测指标（“
    /healthz
    返回HTTP 200”、“Slack线程已关闭且带有
    done
    反应”、“Salesforce商机已移至
    Closed-Won
    阶段”）——而非“服务已启动”或“操作成功”。 规范引用：Beyer等人2018年《站点可靠性工作手册》第8章——可观测信号是运行手册的核心价值。模糊的成功标准是事件期间运行手册误用的主要原因。
  4. “每个可能失败的运行手册步骤的回滚路径是什么？” 推荐答案：每个修改状态的步骤都有回滚路径，或明确标注“无法回滚——升级至X”。 规范引用：AWS架构完善框架卓越运营支柱——“在未明确‘撤销’的定义前，无法运行无法撤销的流程”。
  5. “这份文档存储在哪里，哪些其他文档链接到它？” 推荐答案：存储在权威知识库中，且至少有2个来自相关文档的入站链接。孤立的SOP是无法找到的SOP。 规范引用：Atlassian团队手册关于文档健康的内容——孤立页面占比>20%是知识库分散问题的主要指标。
  6. “此流程的合规覆盖是什么？SOC 2、HIPAA、ISO 13485、GDPR、SOX，还是无？” 推荐答案：明确回答。如果是“无”，需确认流程涉及的数据类型。 规范引用：FDA 21 CFR Part 211.100（书面程序；偏差）——合规SOP需包含版本控制、变更历史和签字确认。跳过此步骤会导致文档在审计中不合格。
  7. “文档是否仅覆盖理想流程，还是也记录了2-3种最常见的故障模式？” 推荐答案：记录每个流程的前2种故障模式及其对应的恢复子流程。 规范引用：Fowler 2016年《生产就绪微服务》——仅覆盖理想流程的运维文档导致60%以上的事件时间浪费。
所有7个问题确认后，按顺序调用
kb_ingester.py
→ 
runbook_validator.py
→ 
sop_generator.py
。