监控系统开始变慢时，团队常先增加内存，却忽略了真正的放大器：标签。一个看似普通的 user_id，可能把一条指标扩成百万条时间序列。治理基数不是少采指标，而是让指标只承担聚合判断，把细节留给更合适的信号。
Linux 文件锁别只看锁文件：用 flock 与 fcntl 做可靠互斥
定时任务、备份脚本和本地索引程序经常用一个空文件表示“正在运行”。但文件存在不等于锁仍被持有，检查后再创建也存在竞争窗口。可靠互斥的关键，是让内核管理锁的归属和释放，而不是自己猜测另一个进程是否活着。
程序崩溃别只重启：用 Core Dump 与 GDB 保全 Linux 现场
线上进程收到 SIGSEGV 后退出，日志往往只留下“Segmentation fault”。立即重启能恢复服务，却也抹掉了最有价值的寄存器、调用栈与线程状态。Core Dump 是进程崩溃时的内存快照；把它与原始可执行文件、调试符号配对，就能从“它挂了”推进到“哪个线程、哪一行、哪个参数导致了崩溃”。
API 报错别只返回一句话：设计稳定、可诊断的错误响应
接口成功时，调用方关心数据；接口失败时，它还要决定提示用户、修正参数、重新登录还是稍后重试。如果服务有时返回字符串、有时返回 HTML、有时把所有失败都塞进 200，每个消费者只能靠猜。错误响应同样是公开契约，应当稳定、可解析，也能帮助值班人员快速定位请求。
布隆过滤器不是万能去重器：容量、误判率与落地边界
布隆过滤器常被一句话概括为“省内存的集合”，但真正上线时，容量估小、哈希不一致或误把“可能存在”当成事实，都可能让它从优化组件变成故障来源。理解它的概率语义，先算容量，再设计兜底，才是安全用法。
TCP 连接为何建不上：半连接队列、Accept 队列与 TIME_WAIT 排障
接口突然出现连接超时，第一反应常常是“网络抖了”。但请求到达服务器后，要先经过 TCP 握手，再进入等待应用接收的队列；任何一段跟不上，都可能表现成连不上或偶发超时。把监听端口拆成两道队列观察，比盲目调大内核参数更容易找到真正瓶颈。
分布式定时任务别重复跑：租约、围栏令牌与幂等收口
单机上的 cron 很直接：时间到了就执行。但服务扩成多个副本后，每个实例都会在同一分钟醒来；日报被发三次、账单被结算三次，往往不是“锁没加好”，而是没有先界定谁有资格执行、资格失效后旧执行者还能不能写入。可靠的方案要同时处理抢占、失联和重复副作用。
别让正则拖垮服务：识别 ReDoS 与输入防线
正则表达式很适合做格式校验和文本提取，却也可能把一次普通请求放大成数秒甚至更久的 CPU 计算。问题通常不在“用了正则”，而在回溯型引擎遇到含糊模式和恶意输入时，必须反复尝试大量失败路径。这类正则拒绝服务（ReDoS）值得像数据库查询一样被审查和限额。
把 CLI 设计成可组合组件：标准流、退出码与机器可读输出
命令行工具不只是给人敲的快捷入口，更是脚本、CI 与其他程序会调用的小型接口。只能打印漂亮文本的命令，第二次自动化时往往就得重写；输入、输出和失败语义清晰的 CLI，则能自然接进管道，成为可靠工作流的积木。
别把 CSV 当作文本：构建可校验、可恢复的数据导入流水线
CSV 常承载批量创建客户、更新库存和迁移历史记录等高风险动作。难点不在解析一行文本，而在表头被改名、日期格式混杂、同一文件重复上传，以及第 8 000 行失败后如何处理。把导入做成有边界、有记录的流水线，错误才可解释、结果才可追溯。