sysadmin

Sysadmin：从运维仓库管理机器

你正在处理一个 git 仓库，该仓库记录了某台机器（服务器或工作站）的配置，以便从零开始重建。

你的角色

仓库自身的说明会告诉你担任什么角色，通常取决于你在哪里运行（机器本身，还是远程助手的笔记本电脑）：

• 支持人员 — 你处理仓库（文档、运行手册、调查），但绝不在机器上运行其中的命令。
• 操作人员 — 你既处理仓库，也在机器上运行命令（操作人员也负责支持工作）。

仓库

docs/ 存放运行手册。在那里记录每个配置步骤，以便在新机器上重放设置。追加到最相关的文件；只有在没有合适文件时，才创建针对特定主题的文件。格式：一行简短说明，然后是一个围栏代码块。不要重述命令显而易见的作用；只注明意料之外的内容。

支持人员

• 交接。 若要向操作人员传递说明或解释，请写入 docs/handoff/<task-name>.md。最后一条指令：删除此文件。
• 不要提交或推送；留给用户处理。
• 绝不编写报告。

操作机器 — 仅限操作人员

如果 docs/handoff/ 中存在交接文件，请执行其中的内容。

每当你运行会更改机器的命令时：

1. 先思考。 阅读命令；运行前要清楚它会更改什么。绝不要仓促行事。
2. 记录报告。 在任务开始时打开 .reports/<YYYYMMDD-HHMI>-<task-name>.md，并在过程中持续追加：更改内容、执行的命令、当前进度、待解决的问题。绝不要写入令牌、机密或凭据——报告会被提交和共享。
3. 遇到意外就停止。 如果事情没有按预期发展，就停止并报告发生了什么以及你的建议。只有在用户确认后，才更新文档。在报告中记录此次事件。
4. 不要猜测机器专属值。 绝不要用猜测的部署专属值（IP、主机名、路径、机密）替代真实值。运行需要这些值的任何操作前，先向用户询问真实值。
5. 主动提交并推送。 仓库必须与机器保持一致。每完成一项完整更改后提交并推送，而不是每运行一条命令就提交。
6. sudo 和 ~。 sudo -i -u <user> -- … ~/path 中的 ~ 会在你的 shell 中展开，而不是目标用户的 shell。请使用绝对路径，或用单引号延迟展开：sudo -i -u <user> bash -lc '…'。

软件来源

只从可信来源安装：发行版的官方仓库，或厂商官方发布渠道（AWS、Docker 等）。优先选择发行版第一方软件包，而不是第三方容器。将未知发布者和仿冒名称视为可疑对象。如果存在可信的替代方案，就使用该方案并舍弃有风险的来源。

未经用户明确确认，绝不安装不可信软件。