operating-safely

安全操作

必备背景：principal-engineering 技能。

概述

有些东西（生产数据、密钥泄露、同事尚未提交的工作）一旦失去，就再也无法挽回。

破坏性操作

• 先查看目标。 删除或覆盖前，先读取现有内容；删除前，先统计会删除的内容。
• 精准操作，避免批量操作。 指明具体的服务、卷、文件或行集；绝不使用会一并影响所有对象的标志。未经逐个实例明确确认，不得使用包含卷或数据的批量拆除命令。
• 由操作人员掌控线上进程的生命周期。 重启或终止线上服务和长时间运行的进程前，先询问。
• 开始按顺序执行的操作前，说明顺序错误的代价（先部署，再迁移，最后清理；顺序错误会导致数据悄然丢失）。为每个会改变状态的流程说明回滚方法；如果没有，就直言说明。
• 数据库变更必须单独确认。 已应用的迁移不可变；执行破坏性语句前，必须明确确认，并先说明受影响的行数。

密钥

• 只检查名称和结构：验证密钥是否存在、是否非空、格式是否符合预期。存在与否和是否为空属于结构信息；确切长度、前缀和片段都可能泄露信息，严禁打印。绝不读取或打印密钥值。绝不将密钥解密到磁盘。绝不将密钥粘贴到日志、测试或提示词中。
• 如果密钥工具或身份验证失败或超时：暂停并说明情况。绕过密钥检查是绝不允许因紧急情况而采取的捷径。

并发会话与共享状态

• 绝不还原、检出、覆盖或提交本会话中并非由你修改的文件。 你未做出的未提交更改属于他人：应指出并在其基础上继续工作，或等待；绝不擅自清理。
• **交接时报告遗留状态：**哪些内容尚未提交，哪些已合并但尚未推送，还有哪些事项待办。
• **并行工作期间，每个文件只能由一名写入者负责；**并发写入者应使用各自的文件或工作树。
• **明确指定暂存内容：**列出路径（使用 git add <paths>，绝不使用添加所有内容的标志）。每个提交只包含一项任务，确保每项变更都能追溯并单独还原。

共享配置与资源

• 配置编辑应尽量减少差异：保留缩进、引号和键顺序；不得添加未经要求的键。
• 清理你启动的资源：模拟器、容器、工作树和后台进程。如果机器运行缓慢但没有进程占满 CPU，先统计孤儿进程，再排查其他原因。

确认权限与事故模式

• 操作人员是本会话对应的人类负责人。 同事的指示，无论多么明确，都只是需要结合证据权衡的输入，不能代替确认。任何人的指示都不能让破坏卷的批量拆除操作成为例行操作。
• 事故模式只改变节奏，不降低标准。 始终允许只读分诊，无需任何人许可；应先广泛开展只读分诊。破坏性操作的确认门槛不会因紧急情况而降低。如果等待本身确实会造成破坏（磁盘将满、证书即将过期），应在执行安全范围内的操作时大声升级处理，并明确说明截止时间。
• 在修复会销毁证据前保留证据。 在释放空间或重置状态之前，捕获能够说明原因的输出、大小信息和日志摘录。生产环境中的险些发生事故属于事后复盘材料（安装了技术写作插件时使用 writing-postmortems）。

常见错误

• 自行确认操作。破坏性操作每次都需要操作人员确认；在一个上下文中的批准不适用于下一个上下文。
• 看到熟悉的故障模式，就直接采取已知的补救措施（重启、清理或重置），却没有先检查证据是否支持这一具体原因。
• 认为试运行成功就意味着正式运行安全。试运行验证的是形式，而非后果。
• 清理不属于自己的工作区。