SOP 编写规范是什么
SOP（标准作业程序）的编写目标是可执行：用祈使句、一步一动作，每一步标注预期结果与失败分支；涉及路径与命令要能直接复制使用，需要替换的内容用占位符明确标出。写给自己看的笔记不能当 SOP，因为它的前提是“我已经知道流程”。
怎么保证真的能照着做
发布前由未参与编写的人按文档试跑一遍，凡是卡壳的地方就是需要补说明的地方；文档要标注适用系统版本、最后验证时间与责任人。把易错点写成显式提醒（例如修改配置前先备份、验证失败如何回退），比笼统写“注意安全”有用得多。
基本信息
| 语言 | 祈使句、主动语态、一步一动作 |
|---|---|
| 要素 | 动作、预期结果、异常分支、记录要求 |
| 验证 | 由未参与编写者按文档试跑一次 |
| 维护 | 标注适用版本、最后验证时间与责任人 |
典型使用场景
- 例行运维作业：备份、巡检、日志归档的固定动作
- 变更操作：发布与回滚的步骤化清单
- 账号与权限管理：开通、变更、离职回收的流程
- 财务或对账类作业：要求每次结果一致并可复核
- 应急处置：把止血动作写成可照做的短清单
- 新人培训：作为上手材料，并暴露文档本身的缺口
写法对比示例
写法对比示例
不推荐：备份数据库，注意安全
推荐：执行 pg_dump -Fc 导出至 /backup/db/ # 可直接复制
预期：生成文件名含日期，大小 > 1GB
校验：pg_restore -l 能列出对象清单
异常：磁盘不足 → 清理 7 天前备份后重试；仍失败则升级要素与常见缺失
| 要素 | 要写清什么 | 常见缺失 |
|---|---|---|
| 动作 | 具体命令或操作位置 | 只有目标没有做法 |
| 预期结果 | 成功时能看到什么 | 执行后无法判断是否成功 |
| 异常分支 | 失败如何处理与升级 | 只写顺利路径 |
| 记录 | 需要留什么证据 | 事后无法证明执行过 |
SOP 长度不是优点：能被照着做完、出错率低的短文档，胜过长篇但需要人来解读的说明。