订单号在服务端是合法的 int64，到了浏览器却少了一位；请求仍成功，只是更新错了记录。根因常在“JSON 数字如何解析”没有写进接口契约。先定清取值范围、语义和编码，才能避免静默的数据损坏。
把 SLO 用起来：用错误预算设计可靠性目标与告警
“服务可用”常常只是一句模糊的期待：出了故障才发现用户受影响，告警又多到没人相信。SLO（服务等级目标）把这种期待变成可度量的承诺；错误预算则告诉团队，在不牺牲可靠性的前提下还能承受多少失败。
SQL 为什么没有走索引：用 EXPLAIN 读懂执行计划并定位慢查询
慢查询并不总是“少了一个索引”。优化器会在顺序扫描、索引扫描和各种连接算法之间估算成本；即使索引存在，它也可能判断直接读表更便宜。与其凭感觉加索引，不如先读取执行计划，确认数据库实际做了什么，再用数据验证改动是否有效。
把配置加载做稳：分层覆盖、显式优先级与启动校验
配置出错往往不像代码缺陷那样立刻抛出堆栈：测试环境的地址被线上变量覆盖、超时值从 5000 变成字符串、临时命令忘记撤销，服务仍能启动，却在流量进入后表现异常。要让配置可靠，关键不是再增加一个 .env 文件，而是让来源、优先级、类型和生效结果都可解释。
用 Transactional Outbox 把领域事件发布做稳
创建订单后既要提交订单数据，又要通知库存、积分或搜索系统；这两件事若分两步完成，就会留下危险的中间态：数据库成功而消息没发出，或消息已发出而事务随后回滚。Transactional Outbox（事务外盒）把“待发布事件”与业务数据放进同一事务，让可靠性先落在最擅长提交的数据库里。
把 Webhook 接稳：签名校验、重放防护与可追溯处理
Webhook 把“定时去问对方有没有变化”变成“变化发生时由对方通知我”，很适合支付结果、代码仓库事件和订阅状态同步。但它的入口暴露在公网，收到一段看似正确的 JSON 并不等于事件可信：攻击者可以伪造请求，网络也会带来重复投递和乱序。要把 Webhook 接稳，应把验真、限时、去重和异步处理视为同一条防线。
把 SSH 隧道用明白：本地转发、远程转发与 SOCKS 代理
数据库只允许内网访问、本地服务需要临时给远端联调、浏览器要经过跳板机访问测试环境——这些场景不一定要先搭一套 VPN。SSH 端口转发可以借用已有的登录链路建立加密通道，但三个常用参数 -L、-R、-D 的方向很容易混淆。本文从“监听发生在哪里”出发，把它们一次讲清。
把 API 限流做对：令牌桶、分布式配额与降级响应
限流不是简单地把“每秒 100 次”写进网关。突发请求是否允许、配额按用户还是按接口计算、多个实例如何共享计数、拒绝后客户端怎样恢复，都会决定系统是在高峰期有序降速，还是制造更多重试。可靠的限流应该既保护容量，也保持公平，并给调用方清晰、可执行的反馈。
把常驻进程交给 systemd：Unit、重启策略与最小权限
把程序放进后台运行并不难，难的是让它在机器重启后自动拉起、崩溃时按规则恢复、日志有处可查，还不能拿着不必要的 root 权限。与其维护 nohup、PID 文件和自制守护脚本，不如把进程生命周期交给 systemd，用一份 Unit 文件明确启动条件、资源边界和失败策略。
用 Git Bisect 二分定位回归：把“哪次改坏了”交给自动测试
功能昨天还正常，今天却悄悄坏了。面对几十甚至几百个候选提交，逐个回退既慢又容易漏掉环境差异。git bisect 会在一段提交历史上执行二分查找；只要能稳定判断某个提交是“好”还是“坏”，就能用很少的检出次数逼近第一个引入问题的提交。