Tech Workbench

同一份源码在不同机器上得到不同结果，会让发布问题很难定位。可重复构建的第一步不是引入复杂平台，而是减少隐含输入。 锁定工具链 记录编译器、运行时和包管理器版本，依赖清单必须包含精确版本与校验值。构建脚本不应默默下载未固定版本的工具。 保留产物证据 发布时保存源码提交、构建命令和产物摘要。重新构建后先比较目录结构和哈希，再分析时间戳、压缩参数等非业务差异。 在干净环境复验 定期在没有本地缓存的环境执行完整构建。只有离开开发者工作站仍能成功，构建说明才真正可靠。

当一个问题只在近期版本出现，逐个阅读提交既慢又容易受主观判断影响。git bisect 可以把搜索范围按提交历史不断折半。 准备稳定判据 先找到一个确定正常的提交和一个确定异常的提交。测试命令必须用退出码清楚表达通过或失败，偶发测试不适合作为二分依据。 自动执行 使用 git bisect run 调用最小化测试脚本。脚本应只验证当前回归，避免无关检查增加耗时或产生错误结论。 结束后复核 定位到首个异常提交后，阅读上下文并在当前分支复现。二分结果是线索，不自动等同于根因。

set -euo pipefail 能暴露未定义变量和管道失败，但它不能替代对失败场景的设计。条件表达式、命令替换和不同 Shell 版本仍有细微差异。 把关键结果显式判断 配置检查、数据导出和服务重启应使用清晰的 if 分支，并输出失败原因。依赖隐式退出行为会让回滚路径难以阅读。 小心清理逻辑 临时文件和后台进程适合用 trap 清理。清理命令自身不应掩盖原始退出码，也不能删除未经确认的目录。 在目标 Shell 测试 脚本声明使用 sh 时，不应依赖 Bash 数组等扩展。持续集成环境要与生产解释器保持一致。

一次性脚本通常只考虑理想路径。真正用于维护的脚本必须允许中断后重跑，并且不会重复追加配置或破坏已经正确的状态。 先读取当前状态 创建用户、目录或规则前先判断是否存在。对于结构化配置，优先使用解析器更新目标字段，而不是依赖文本替换。 使用原子替换 新文件应先写入同一文件系统的临时路径，完成语法检查和权限设置后再替换正式文件。失败时保留旧版本。 验证业务结果 命令退出成功只是第一层信号。脚本还应检查服务状态、监听端口和真实健康接口。

只设置一个很大的总超时，往往会让故障请求长期占用连接和工作线程。调用链需要把可接受的总延迟分配到各个阶段。 拆分超时类型 DNS、TCP 连接、TLS 握手、首字节和响应读取具有不同故障含义。客户端库支持时应分别设置，并在日志中标明超时阶段。 重试必须消耗预算 重试不能重新获得完整超时时间。每次尝试都应读取剩余期限，并加入有限抖动，避免多个实例同时再次请求。 让服务端知道截止时间 内部调用可以传递 deadline。下游发现预算不足时尽早停止昂贵工作，比完成一个上游已经放弃的请求更合理。

把普通文本换成 JSON 并不会自动改善排障。结构化日志的价值来自稳定字段、统一语义以及可以跨服务关联的上下文。 固定核心字段 时间、级别、服务、事件名称、请求标识和耗时应保持一致。错误类型使用有限集合，详细原因放在独立字段中。 控制高基数字段 完整 URL、堆栈和用户输入会迅速扩大索引。保留必要上下文，但不要把令牌、密码或完整请求体写入日志。 让日志支持行动 一条错误日志应帮助回答发生了什么、影响哪个操作以及下一步检查哪里，而不只是重复异常文本。

进程存在不代表服务可用，但健康检查也不应执行完整业务流程。检查过重会额外消耗资源，并可能在依赖短暂波动时触发重启循环。 存活与就绪分开 存活检查回答进程是否需要重启；就绪检查回答实例是否应该接收流量。数据库迁移或缓存预热期间，实例可以存活但尚未就绪。 检查自身能力 服务的健康接口应验证事件循环、关键线程或本地存储，而不是强制所有外部依赖同时成功。 设置合理窗口 启动慢的服务需要启动宽限期。间隔、超时和连续失败次数应依据真实启动时间和故障恢复目标设置。

自动生成升级合并请求很容易，确认它是否适合生产环境更重要。版本号变化只是入口，实际影响可能来自传递依赖或默认配置。 阅读兼容性信息 先确认运行时最低版本、废弃接口和配置默认值。安全修复应关注受影响条件，而不是只看漏洞标题。 比较锁文件 锁文件能显示新增、移除和替换的传递包。突然出现的构建脚本、原生扩展或网络下载值得单独审查。 分层验证 先运行单元测试和静态检查，再验证构建产物，最后用真实依赖执行关键流程。高风险升级应独立发布，便于回滚。

代码看起来复杂的地方不一定消耗最多资源。没有基线的优化很难证明收益，也容易把瓶颈移动到其他组件。 选择代表性负载 输入规模、并发度、缓存状态和数据分布都应接近真实场景。只运行几次微基准无法代表完整请求链路。 同时观察资源 CPU 剖析需要结合内存分配、I/O 等待和锁竞争。火焰图显示的是采样占比，不直接说明某个函数逻辑错误。 一次改变一个变量 记录修改前后的吞吐、延迟和资源占用。收益不稳定或可读性代价过高时，应保留证据并撤销实验。

简单任务使用 cron 足够，但当任务需要网络依赖、失败状态和统一日志时，systemd timer 通常更容易维护。 服务与计划分离 实际命令写入 oneshot service，timer 只定义时间。这样可以手动启动服务进行演练，也能单独查看退出状态。 处理错过的任务 Persistent=true 可以在机器重新启动后补执行错过的计划。对备份任务有用，但不适合会产生重复副作用的操作。 避免同时启动 多台主机使用相同计划时加入随机延迟。任务自身仍需加锁或具备幂等性，防止上一次运行尚未结束。