运维团队里最容易失控的资产，往往不是机器，而是散落在聊天记录、个人终端历史和 Wiki 角落里的命令。OpsFlash v0.3.0 新增了指令库，并将本地 Terminal 与 SSH 远程执行纳入同一套命令执行引擎，目标很明确：让常用操作可管理、可复用，也更容易在正确的环境中执行。
指令库不只是“收藏命令”
v0.3.0 的指令库提供命令的增删改查、环境分组、搜索筛选与排序。它解决的是命令从“某个人会用”到“团队能找到、能理解”的管理问题。
命令归属的环境复用已有的环境管理能力，并且与脚本库同源。这样做的价值在于，环境不再是命令文本里的注释，例如“这是生产环境命令”，而可以成为命令资产的结构化归属。排查问题时，操作人员可以先收敛到目标环境，再查找对应指令，减少把测试命令带到生产环境的机会。
一个可维护的指令条目，通常至少应具备以下信息：
- 清晰的名称，例如“查看 Nginx 最近错误”。
- 目标环境，例如测试、预发或生产。
- 执行方式，例如本地 Bash、PowerShell、cmd 或 SSH。
- 可搜索的标签或说明，用于表达用途、风险和前置条件。
- 稳定、可审阅的命令正文，避免把临时变量和个人路径固化进去。
一套入口覆盖本地与远程
OpsFlash v0.3.0 覆盖两类执行模式：本地 Terminal 和 SSH 远程执行。本地 Terminal 支持 cmd、PowerShell 与 Bash，适合处理开发机诊断、构建工具、容器命令等；SSH 模式则面向远程主机上的巡检、日志查看和服务维护。
版本中提到的命令执行引擎支持三种命令类型，其中已明确的非交互式命令采用同步执行，并能流式实时输出和停止执行。对于耗时操作，这比等待一个“执行完成”的黑盒结果更实用：运行者可以从输出判断卡在哪一步，也可以在发现目标或参数错误时及时终止。
尤其值得注意的是，cmd 的多行命令会自动逐行执行。Windows 环境里不少排障操作本来就是连续的数条命令，逐行执行能让输出与命令建立更直观的对应关系，也降低一整段命令因某一步失败而难以定位的问题。
可以这样组织一组可复用的巡检指令
以下示例是实践建议，并非 OpsFlash 的导入格式。可以把每一段保存为独立指令，并按实际环境分别归类到本地 Bash、PowerShell 或 SSH 执行模式中。运行前请将服务名、日志路径和主机信息替换为自己的实际值。
本地 Bash：检查容器与最近日志
#!/usr/bin/env bash
set -euo pipefail
SERVICE_NAME="api"
CONTAINER_ID="$(docker ps --filter "name=${SERVICE_NAME}" --format '{{.ID}}' | head -n 1)"
if [ -z "${CONTAINER_ID}" ]; then
echo "未找到名称匹配的容器: ${SERVICE_NAME}" >&2
exit 1
fi
echo "== 容器状态 =="
docker ps --filter "id=${CONTAINER_ID}"
echo "== 最近 100 行日志 =="
docker logs --tail 100 "${CONTAINER_ID}"
这类命令适合放在开发或测试环境分组中。set -euo pipefail 会让脚本在变量未定义或关键步骤失败时退出，避免后续命令带着错误上下文继续执行。
PowerShell：检查 Windows 服务状态
$ServiceName = "MyApiService"
$service = Get-Service -Name $ServiceName -ErrorAction Stop
Write-Output "Name: $($service.Name)"
Write-Output "Status: $($service.Status)"
if ($service.Status -ne "Running") {
Write-Error "服务未运行: $ServiceName"
exit 1
}
对于 Windows 主机，建议把“查询状态”和“重启服务”拆成两条指令。前者可作为低风险巡检，后者则应在名称、说明和环境归属中明确标记影响范围。
SSH：远程查看磁盘、内存与服务状态
set -e
echo "== Host =="
hostname
echo "== Disk =="
df -h /
echo "== Memory =="
free -h
echo "== Service =="
systemctl is-active my-api.service
将这段内容配置为 SSH 指令后，应由对应环境关联实际的远程连接目标。它只读取状态，适合作为生产环境的基础巡检指令；涉及 systemctl restart、删除文件或修改配置的命令，应单独建库，并在描述中写明回滚方式和执行窗口。
让流式输出真正服务于排障
非交互命令的实时输出并不只是体验功能。它适合处理输出连续增长、执行时间不确定的任务，例如日志跟踪、镜像拉取、依赖安装或批量健康检查。
不过，实时输出不等于可以无限制执行。团队在建立指令库时，建议把边界写进命令设计中：
- 为可能长期运行的命令提供可停止的执行路径，并避免默认执行无限日志跟踪。
- 将只读巡检与变更操作分开，名称中直接表达动作，例如“检查”“重启”“清理”。
- 不在命令正文中硬编码密码、Token 或私钥路径；凭据应交给环境或受控的密钥管理机制处理。
- 对生产命令增加明确的目标确认信息，避免同一条命令被错误地用于相似环境。
- 保持命令足够小。一条指令应该能完成一个可验证动作，而不是把整套事故处置流程压进一段不可读的 Shell。
从高频只读命令开始迁移
采用 OpsFlash v0.3.0 时，不必急着把所有历史脚本搬进指令库。更稳妥的顺序是先整理高频、低风险、输出明确的只读命令，例如服务状态、磁盘使用率、容器日志和版本查询。
当团队逐渐形成环境分组、命名规则和说明规范后，再引入带副作用的操作命令。指令库的核心收益不在于替代终端，而在于让终端操作从个人记忆变成可搜索、可分组、可复用的团队资产。