Running只能说明进程在，不能证明查询没有排队或丢包。间歇超时、几秒自愈，最可能是高峰排队、单节点链路丢包或查询被放大，先按下面顺序缩小范围，再决定扩容还是修链路。 第一步：先看故障是不是集中出现记录超时发生的 Pod、所在节点、时间和查询域名。如果只集中在个别节点，优先查该节点；如果全集群在业务高峰一起抖，再看 CoreDNS 整体压力；如果只有外部域名抖、集群内服务名正常，再看上游转发。 第二步：在故障 Pod 里做两次对照先用完整域名测，再用短名字测： dig xxx.default.svc.cluster.local +time=2 +tries=1如果完整域名稳定、短名字才抖，重点是 search 域和 ndots 放大：一次调用可能变成多次查询，业务高峰时很容易把请求量放大。业务代码优先用完整域名，必要时再收紧 Pod 的 dnsConfig。再分别查 Service IP 和 CoreDNS Pod IP： dig @10.247.3.10 xxx.default.svc.cluster.local +time=2 +tries=1 dig @ xxx.default.svc.cluster.local +time=2 +tries=1Service IP 抖、Pod IP 稳，查 Service 转发和节点数据面；两者都抖，查 CoreDNS 和节点网络。 第三步：看 CoreDNS 是不是被限流节点 CPU 不高，不等于 Pod 没被限流。重点看 CoreDNS 副本分布、重启次数、CPU 是否贴近 limit、故障时段请求量和延迟是否同步抬升、日志里有没有 SERVFAIL 或转发失败。副本集中在同一节点时，该节点一抖就会影响大批查询。 第四步：看节点 UDP 链路在异常节点看 conntrack 使用量和内核丢包日志。UDP 查询量大时，连接跟踪表满或 UDP 丢包都会表现为随机超时，扩 CoreDNS 副本解决不了这一段。另外要确认 UDP 和 TCP 53 都放行，大响应被截断后需要走 TCP 重查。 调整建议确认是 CoreDNS 压力时：保持至少 2 个副本并打散到不同节点，按峰值请求量评估副本数，合理设置 CPU 和内存的 request 与 limit；重复查询多的场景可适当开缓存，但 TTL 不宜过长，避免服务地址变更后长期拿到旧记录。确认是节点链路或跨节点 UDP 压力时：评估部署节点本地 DNS 缓存，让本节点先缓存和转发，减少跨节点查询。验证时不要只看一次成功，要在多个节点连续测试并看超时率和延迟分布是否回到正常。

结论先说清楚：7天保留期不等于只能回到7次备份时刻。在保留窗口内，只要全量备份和binlog都还在，就能恢复到窗口内的某个时间点；恢复出来的是一个新实例，不会直接把原实例覆盖掉。 为什么能到任意时间点RDS的时间点恢复一般是“最近一次全量备份 + 之后的binlog重放”。全量备份定了一个起点，binlog补上起点之后的变化，所以可选时间点是连续的一段，而不是只有备份时刻那几个点。 三个前提，缺一个就不行1. 目标时间点要在保留期内，也要在已有备份和binlog覆盖的范围内；超过7天、或者binlog提前清理了，就回不去了。2. 恢复前实例已经有过成功的自动备份；刚建好还没备份过的实例，没有起点可恢复。3. 新实例的规格、存储和网络要能承载恢复后的数据，恢复后先核对数据再切换业务。 操作建议先在控制台的备份恢复里查看可恢复的时间范围，再选择比误操作稍早一点的时间点，避免把误操作本身也重放回来。恢复完成后，先在新实例上查关键表的数据量、最新时间戳和业务关键记录，确认无误后再改应用连接；原实例先保留一段时间，不要急着删除，等确认新实例稳定后再处理。 生产环境建议把自动备份保留期适当调长，并在重要变更前再做一次手动备份，这样可恢复窗口更宽，误操作后的选择也更多。

先不要直接调大超时时间。60秒这个数值很整齐，通常是某一层默认超时，而不是随机变慢，建议按下面顺序定位到具体阶段。 第一步：用分段计时确认卡在哪一步curl -w "dns:%{time_namelookup} tcp:%{time_connect} tls:%{time_appconnect} firstbyte:%{time_starttransfer} total:%{time_total}" -o /dev/null -s https://api.example.com/v1/data 读法是看相邻两项的差值，而不是只看总时间：dns本身大就是解析慢；tcp减dns大就是建连受阻；tls减tcp大就是握手受阻；前面都小、只有firstbyte大，说明连接已经建立，问题在服务端处理或中间层挂起请求。 第二步：按阶段做对照 如果卡在解析：检查 /etc/resolv.conf 的DNS是否可达，用 dig 或 nslookup 看解析耗时，换一个可用DNS对照；也可以临时用 curl --resolve 把域名指向已知IP，看是否恢复。 如果卡在建连：ping通只代表ICMP通，不能证明443通。用 nc -vz 或 curl -4 测试443，重点排查云服务器出方向安全组、本地防火墙、代理出口是否放行443，以及是否解析到了不可达的IPv6地址。 如果卡在握手：用 openssl s_client -connect 域名:443 -servername 域名 看握手能否完成、证书是否过期或链不完整；再用 curl --tlsv1.2 和 --http1.1 对照，排除协议协商问题。 如果卡在首字节：查服务端和网关日志，看请求是否到达应用、处理耗时多少、上游是否超时；同时检查反向代理、负载均衡、WAF的超时设置，60秒常常就是其中一层的默认值。 第三步：排除浏览器和curl的环境差异 浏览器在本地电脑，curl在云服务器，两者DNS、出口、代理可能完全不同。先在同一台服务器上执行 env | grep -i proxy 检查代理，再用 curl --noproxy "*" 对照；同时补上浏览器常见的请求头和 --http1.1 对照，排除服务端按请求头或协议版本做特殊处理的情况。 定位到阶段后再改对应配置，比直接加大 --max-time 更可靠。

平衡的关键不是一次选到最大，而是先定一条性能底线，再用最低总成本满足它，多余的闲置就是浪费。 1. 先定底线，再选规格先写清三项：峰值大概多少并发、P95 延迟要到多少、允许单点故障吗。达不到底线的规格再便宜也不选，远超底线的规格就是在为闲置付费。没有业务数据时，先用能跑起来的小规格上线，用监控看一周真实水位再升降，比凭感觉一次买满更省。 2. 按瓶颈选族，不要只看核数- CPU 先到顶：计算型；内存先到顶：内存型；磁盘或网络先到顶：先升级云盘类型或带宽，加 CPU 解决不了。- 突发型、轻负载站点可以考虑共享型，但长时间满负载的生产服务不建议用积分制的共享型，积分耗尽后性能会明显回落。 3. 把稳态和峰值分开买每天都有的基线负载适合用包年包月锁定单价；周期性高峰交给弹性伸缩和负载均衡，不要为短时峰值常驻大规格。无状态、可重试的离线任务，可以再单独评估可中断的计费方式，但要先确认任务能从中断点续跑。 4. 算总账，不要只比实例价云盘、公网带宽或流量、快照备份、负载均衡都要一起算。静态资源走对象存储和 CDN 后，ECS 只留动态计算，往往比直接升配更划算。 5. 上线后定期复核每月看一次 CPU、内存、磁盘 IOPS 和出网带宽的 P95：长期都只有两三成，就降一档；某一项长期贴顶，再针对那一项升配。选型是一个持续调整的过程，不是买一次就定型。

这个报错的意思是：传给 gzip 的数据开头不是 gzip 格式。先按“文件到底是什么、是不是被截断、压缩方式是否对得上”三步查，不要先反复换解压参数。 1. 先看文件类型，再测完整性```bashls -lh backup.tar.gzfile backup.tar.gzhead -c 16 backup.tar.gz | od -An -tx1```正常 gzip 文件开头是 1f 8b。如果 file 显示 ASCII text、HTML、empty，或者开头根本不是 1f 8b，说明拿到手的文件本身就不是 gzip 包，可能是空文件、报错文本或下载错了内容，先回到源端重新确认文件。 2. 区分“没压缩”和“用了别的压缩”```bashtar -tf backup.tar.gzfile backup.tar.gz```- 如果 tar -tf 不加 z 能列出内容，说明它就是普通 tar，只是扩展名写成了 .tar.gz，解压用 tar -xf，不要加 z。- 如果 file 显示 XZ 或 bzip2，对应改用 tar -xJf 或 tar -xjf。- 如果 file 显示 gzip data，再跑 gzip -t 看完整性：```bashgzip -t backup.tar.gz; echo $?``` 3. 判断是否截断、能不能抢救```bashls -lh backup.tar.gzmd5sum backup.tar.gz# 在源端和目标端各跑一次，对比大小和校验值```源端和目标端大小或校验值不一致，基本就是传输中截断或损坏，先重新传输，尽量用校验过的拷贝方式。如果只是尾部不完整，可以先试着把前面能解的部分导出来排查，但不要指望一定完整：```bashgzip -dc backup.tar.gz > backup.tar 2>gzip.err || truetar -tf backup.tar```能列出部分文件，说明前面内容尚可；列不出或报错很多，就不要继续凑，先用源端完好的备份重新传。 最常见的三个原因总结：文件根本不是 gzip 包、压缩方式与解压参数不匹配、传输中截断或损坏。按 file、校验值、压缩类型这个顺序，基本能一次定位。

前面几位已经把权限、端点、分段上传和计费讲得很全了，我补充几个新手最容易在上线后才发现的坑，侧重命名、改动方式和清理这三类。 一、对象没有改名和原地修改，改名等于复制加删除。OBS 里对象一旦写入就不能像本地文件那样改名或追加内容，所谓改名、移动目录，其实是先复制出一个新对象，再删掉旧对象。程序里如果直接按新名字写、又忘了删旧对象，桶里就会同时留着两份，既占空间又容易让旧链接继续被访问到。需要改名时，先确认新对象能正常读取，再删旧对象；批量改名先在测试桶里跑一小批验证。 二、键名里的中文、空格和大小写，迟早会在另一端出问题。 键名区分photo.jpg 和 Photo.JPG 是两个对象；中文、空格和特殊字符在浏览器、签名 URL 和不同 SDK 里编码方式不一样，经常出现本地能打开、线上签名后 404 的情况。建议键名只用小写字母、数字、短横线和斜杠作分隔，日期和业务前缀写在前面，例如 uploads/2026/10/26/xxx.jpg，这样按前缀列举和做生命周期规则都方便。 三、删对象不等于立刻不计费，版本和未完成的分段最容易漏。 开了版本控制后，删除通常只会产生一个删除标记，历史版本还在计费；大文件分段上传中途失败或取消后，未完成的分段也会继续占用空间。清理时要同时检查三处：当前对象、历史版本、未完成的分段上传，并给日志桶、备份桶单独配生命周期规则，避免备份越攒越多。删桶前也要先确认桶已清空，否则会删不掉。 OBS 地址当网站静态资源地址用，流量和防盗链都没算好。 公开读的桶地址谁拿到都能直接下载，图片、视频被别的站点引用时，流量费算在自己头上。正确做法是：源站桶保持私有或只对可信方开放，公开访 CDN 并配好防盗链和缓存规则；临时分享用带过期时间的签名链接，过期后自动失效，不要为了图方便把整个桶长期公开。 五、不 OBS 当数据库、文件系统或消息队列用。OBS 不支持文件锁、原地追加和目录级原子操作，高频小文件读写、频繁列举整个桶都会很慢且请求费很高。适合它的场景是存放图片、安装包、日志和备份这类写一次、读多次的对象；需要频繁修改、查询和事务的，放数据库或块存储里。列举对象时也要按前缀分页取，不要一次拉全桶清单。 一句话总结：先定好区域、键名和权限，再定好版本、生命周期和公开方式，最后再上线；多数坑不是功能不会用，而是上线前没把命名、清理和公开范围这三件事想清楚。要拿问走四、直接把大小写，  

这个场景的关键不在 Redis 本身慢，而在一次命令要处理的数据量太大：HGETALL 要把 50MB、几万个字段一次性取出来、序列化并回给客户端，期间主线程被占住，其他请求只能排队，所以表现为偶发卡顿。治理思路是先让读变小，再把大 Key 拆掉，最后用阈值防复发。 先止血：把后台任务 HGETALL 改成按需取字段，需要单个字段就用 HGET，需要遍历就用 HSCAN 分页，COUNT 从 100 起步，根据延迟再调大；后台任务分批、限流、错峰，不要在高峰期全量遍历。 确认嫌疑的命MEMORY USAGE 活动配置的 keyHLEN 活动配置的 keySLOWLOG GET 全量摸底不 KEYS，低峰期或从节点上用：redis-cli --bigkeys 不停机迁移的做法：先按活动或分组 key，例如 config:活动ID:分组，写入侧改为双写新旧 key，读侧先读新 key、读不到再回落旧 key；等新 key 的数据对齐并观察一段时间后，再把读全部切到新 key，最后用 UNLINK 异步删旧 key，不要用 DEL 直接删 50MB 的 key。 预防阈值要写进代码和巡检，而不是靠自觉： Hash 字段数超过几千就告警，MEMORY USAGE 超过 10MB 就告警并触发拆分；配置里的大段文本、长列表本来就不适合长期塞在 Redis，大配置放数据库或对象存储，Redis 只留热点字段。 验证标准： key 的 MEMORY USAGE 和 HLEN 明显下降，慢查询里不再出现大耗时 HGETALL，卡顿时间点与后台任务不再重合，才算治理完成。同一单个建新要用 令：里的

先用隔离法定位：先在函数所在同一 VPC、同一子网里起一台临时 ECS，用同样的内网地址和端口连一次 RDS。如果 ECS 能连、函数不能连，问题在函数侧的 VPC 配置；如果 ECS 也超时，问题在 RDS 侧或网络本身，再往下查。 1. 确认函数和 RDS 在同一个区域、同一个 VPC。跨 VPC 即使安全组放通也不会通，需要对等连接或换到同一 VPC。函数配置里选的子网要有剩余 IP，函数创建弹性网卡需要占用子网 IP，子网 IP 耗尽时也会表现为超时。 2. 安全组要双向对齐。RDS 安全组入方向放通函数网卡所在安全组或函数子网网段，而不是只放某一台测试机；同时检查函数所在安全组的出方向没有被收紧，默认出方向放通全部时不用动，改过出方向的要放通数据库端口。 3. 用内网地址连接，不要用公网地址。函数在 VPC 内没有公网出口时，访问 RDS 公网地址会超时。用内网域名时先确认子网 DNS 能解析，解析失败可先用内网 IP 验证连通性，再回头修 DNS。 4. 检查 RDS 自身状态：实例是否正常运行、连接数是否打满、参数里是否限制了访问来源。连接数打满时新连接会排队或超时，这时要先看监控和慢日志，而不是只调函数超时。 5. 临时把函数超时调大再测一次，排除冷启动干扰。确认链路通了之后再根据业务把超时调回合理值，并在代码里给数据库连接设置比函数超时更短的超时，避免函数先被平台掐断、日志里只剩超时。 排查顺序建议：同子网 ECS 测通不通 → VPC/子网/IP → 安全组双向 → 内网地址与 DNS → RDS 连接数与状态。这样能最快区分是函数配置问题还是数据库侧问题。

先说结论：df 和 du 本来就不是一个口径。df 读的是文件系统元数据里“已分配了多少块”，du 是遍历目录树把看得见的文件逐个累加。两者对不上，说明空间藏在 du 遍历不到的地方。按下面顺序查，基本都能定位。1. 先确认 du 没漏统计du 默认会跨文件系统统计，权限不足的目录会被静默跳过。用 root 跑，加 -x 限定同一文件系统，同时别丢掉报错信息：sudo du -x -h --max-depth=1 / 2>&1 | sort -rh | head -20注意看有没有 “Permission denied” 报错——被跳过的目录最容易漏掉大头。2. 已删除但仍被进程占用的文件（最常见）文件被 rm 后，如果还有进程拿着它的文件描述符，磁盘块不会释放：df 照样计入，du 已经看不见了。sudo lsof +L1        # 只列链接数为 0 的（即已被删除但仍打开的）# 或：sudo lsof | grep deleted | sort -k7 -rn | head关键：必须用 sudo。普通用户只能看到自己的进程，系统服务的句柄会漏掉——你之前 lsof 没查到明显问题，很可能就是权限原因。处理不一定要杀进程。拿到 PID 和 FD 号后，直接截断释放：: > /proc//fd/空间立刻回来，服务不用停。长远看，给这类日志加上 logrotate 的 copytruncate，别直接 rm 正在写入的大文件。3. 挂载点把旧数据“盖住”了典型场景：先往 /data 写了几十 GB（日志、备份），后来又把一块云硬盘挂载到 /data。旧文件还占着父文件系统的空间，但 du 走的是挂载后的目录树，看不见了。findmnt -R /        # 看完整挂载树，找可疑的挂载点# 或 bind 挂载绕过挂载点直接看：sudo mount --bind / /mnt/rootviewsudo du -sh /mnt/rootview/data   # 对比 du 直接看 /data 的结果4. inode 耗尽海量小文件（缓存、会话文件、邮件队列）会把 inode 吃光，表现也是 df 显示满但 du 找不到大文件：df -i5. ext4 预留块ext4 默认给 root 预留 5% 空间，普通用户看 df 会显示 100%：sudo tune2fs -l /dev/vda1 | grep -i reserved数据盘可以适当调低预留比例。按“du 漏统计 → 已删未释放 → 挂载遮挡 → inode → 预留块”这个顺序查一遍，绝大多数情况都能命中。

Docker 默认用的 json-file 日志驱动，会把容器 stdout/stderr 的日志写到宿主机文件：/var/lib/docker/containers/容器ID>/容器ID>-json.log所以日志涨得快的话，系统盘就是被它占满的。1. 先找出占空间的大户du -sh /var/lib/docker/containers/*/*-json.log 2>/dev/null | sort -rh | headdocker system df     # 顺带看镜像、容器、卷的整体占用2. 应急清理：用截断，别直接 rm日志文件正被 dockerd 进程打开着，直接 rm 删掉文件，进程还占着文件句柄，磁盘空间并不会释放，还得重启 docker 才能腾出来。正确做法是截断文件：truncate -s 0 $(docker inspect --format='{{.LogPath}}' 容器名或ID>)3. 给单个容器设上限（答案是：可以）docker run 时加上日志参数：docker run -d --log-opt max-size=10m --log-opt max-file=3 your-imagemax-size=10m：单个日志文件到 10MB 就轮转；max-file=3：最多保留 3 个文件，超了自动删最旧的。这样单个容器的日志最多占 30MB。注意两点：已在运行的容器改不了这个参数，只能删掉容器带参数重建（数据放在挂载卷里的话不会丢）；用 compose 的话在 service 下写：logging:  driver: json-file  options:    max-size: "10m"    max-file: "3"4. 一劳永逸：改 daemon.json 全局默认/etc/docker/daemon.json 里加：{  "log-opts": { "max-size": "10m", "max-file": "3" }}然后 systemctl restart docker。只对重启后新建的容器生效。5. 治本如果日志涨得快，先看看应用是不是在刷无意义的 debug 日志，把应用日志级别调上去；业务日志建议写进挂载的数据卷或发到日志服务，别全走容器 stdout。