Python 调用遗留命令乱码又卡死：字节解码、超时与安全参数实践
适用场景 本文适用于 Python 3.11 及以上版本。业务程序需要调用数据库备份工具、硬件厂商 CLI、Windows 遗留程序或内部运维命令，但这些程序的输出编码不是 UTF-8，并且可能出现长时间无响应、非零退出、输出管道堵塞或参数注入风险。 目标不是再封装一层 subprocess.run()，而是建立一个可
Tag
#自动化
包含这个标签的文章。
PostgreSQL 并发建索引失败留下 INVALID：从等待取证到在线修复
适用场景 本文适用于 PostgreSQL 13 及以上版本的生产库：为了避免普通 CREATE INDEX 长时间阻塞写入，运维或开发人员改用 CREATE INDEX CONCURRENTLY，但命令执行数十分钟后失败、被取消，或者发布系统超时退出。重新执行时又提示索引已存在，查询计划却仍然走顺序扫描。 本文重点处
Kubernetes HPA 指标显示 unknown 且不扩容：从指标链路到计算条件的排查实践
Kubernetes HPA 指标显示 <unknown> 且不扩容：从指标链路到计算条件的排查实践 服务流量已经升高，Pod 的 CPU 也明显繁忙，但 kubectl get hpa 中的 TARGETS 长时间显示 <unknown>/60%，副本数始终不变。这个现象不能直接归因于 HPA 控制器故障：资源指标要
Go OAuth 令牌过期瞬间请求雪崩：用 singleflight 合并刷新并隔离超时
调用第三方 API 的 Go 服务通常会在内存中缓存 OAuth 访问令牌，并在令牌即将过期时刷新。单实例、低并发时，这段逻辑看起来很简单；并发升高后，几十个请求可能同时发现令牌失效，又同时访问认证端点。结果不是更快拿到新令牌，而是认证服务返回 429 Too Many Requests，业务请求批量失败，甚至出现“较
Webhook 签名校验通过仍被重复执行：时间窗、幂等键与防重放实践
适用场景 支付回调、代码仓库事件、消息推送和第三方审批通知通常通过 Webhook 进入业务系统。很多服务已经实现了 HMAC 签名校验，却仍会遇到重复发货、重复记账或重复触发流水线的问题。 这类故障的关键在于：签名只能证明请求内容来自持有密钥的一方，不能证明这次请求从未被处理过。 一个合法请求被代理层、第三方平台或攻
Python asyncio 优雅停机卡住：从取消信号被吞到结构化并发治理
适用场景与现象 异步消费者、WebSocket 网关或定时任务服务收到 SIGTERM 后，健康检查已经失败，进程却迟迟不退出，最终被 Kubernetes 在宽限期结束时强制 SIGKILL。常见伴随现象是： 停机日志只出现“开始关闭”，没有“后台任务已结束”； 某个任务仍处于 PENDING，但业务请求已经停止进入
Kubernetes ConfigMap 已更新，容器仍读旧配置：subPath 挂载的定位与修复
适用场景 应用把 ConfigMap 中的单个配置文件挂载到容器现有目录，例如 /etc/app/app.conf。运维修改了 ConfigMap，kubectl get configmap 显示新值，但运行中的应用始终使用旧配置。本文以一个单副本 Deployment 复现，并给出两种可验证的修复路径。以下命令以 B
Django 新订单偶发查询不到：Celery 任务早于事务提交的排查与修复
Django 新订单偶发“查询不到”：Celery 任务早于事务提交的排查与修复 适用场景与现象 下单接口先写入订单，再让 Celery Worker 发送确认邮件。接口返回成功，Worker 却偶发 Order.DoesNotExist；在管理后台查询，同一订单已经存在。失败多发生在数据库写入较慢、Worker 较空
PostgreSQL 插入新数据却主键冲突：从序列漂移到安全校准的排查实践
适用场景 本文适用于 PostgreSQL 表使用 serial、bigserial 或 identity 列生成主键，但执行正常 INSERT 时仍出现主键重复的场景。常见诱因包括数据迁移、手工补数据、COPY 导入、只恢复表数据却漏掉序列状态，或者在不同环境之间合并数据。 典型表结构如下： CREATE TABLE
Kubernetes CronJob 重复执行与漏跑：并发策略、截止时间和幂等治理实践
适用场景 本文适用于在 Kubernetes 中运行数据库备份、账单汇总、定时同步、报表生成等周期任务，并遇到以下问题的团队： 上一次任务尚未结束，下一次任务已经启动，两个 Pod 同时修改同一批数据； 控制面短暂不可用或 CronJob 暂停后恢复，任务突然补跑； 配置了 concurrencyPolicy: For