CPU突增却查不到热点进程，因短命进程、内核线程或容器子进程未被top捕获；需用ps、pidstat、/proc/pid/stack多维度排查。
服务扩容时 CPU 突增却查不到热点进程？top 和 htop 不够用
说明：业务流量一涨，top 显示 CPU 使用率飙升，但排序后前几名进程加起来只占 30%，剩下 70% “黑盒”里跑着啥？常见于短生命周期进程、内核线程、或容器内未暴露的子进程。
实操建议：
- 先跑
ps -eo pid,ppid,comm,%cpu --sort=-%cpu | head -20，看是否有大量同名短命进程（比如curl、sh、python脚本） - 用
pidstat -t 1观察线程级 CPU，确认是否是某个进程内部线程打满（如 Java 应用 GC 线程、Node.js 事件循环阻塞） - 检查
/proc/（需 root）看内核栈，排除/stack nf_conntrack打满、ext4 日志锁、或 NFS 客户端卡住等内核态问题
横向扩容器后连接数不均，iptables SNAT 规则成瓶颈
说明：K8s 或自建集群加节点后，新 Pod 的出向连接集中在少数宿主机上，netstat -s | grep -i "conn failed" 出现大量 connection failed，本质是 iptables 的 CONNMARK + SNAT 规则在高并发下哈希冲突+锁竞争。
实操建议：
- 避免在
POSTROUTING链中对所有流量做 SNAT；改用ip rule + ip route基于源地址路由，或启用nf_conntrack_hashsize调大哈希桶（需重启模块） - 若必须用 iptables，把 SNAT 规则拆到不同链（如
SNAT-0、SNAT-1），配合ipset分流，降低单链匹配开销 - 检查
sysctl net.netfilter.nf_conntrack_max和当前连接数（cat /proc/sys/net/netfilter/nf_conntrack_count），超 80% 就要调或清理老化连接
Ansible 批量部署失败，Connection refused 却能 ssh 手动连通
说明：Ansible 报 Connection refused，但人肉 ssh user@host 没问题——大概率是 Ansible 默认用 paramiko 实现 SSH，而目标机 sshd_config 中禁用了 PubkeyAuthentication no 或启用了 UsePAM yes 导致 paramiko 认证路径异常。
实操建议：
- 在
ansible.cfg中强制走 OpenSSH：添加[defaults]下transport = ssh - 检查目标机
/var/log/secure，搜索Failed password或authentication failure，确认是否被 PAM 拦截（比如pam_faillock锁了用户） - 避免在 inventory 中混用密码和密钥认证；统一用
--private-key指定密钥，并确保权限为600，否则 OpenSSH 会静默拒绝
systemd 服务依赖启动慢，systemctl start 卡住 90 秒
说明：写了个新服务 A，After=B.service，但 B 已运行，A 启动仍卡住。根本原因是 B.service 的 Type=notify 但没发 sd_notify("READY=1")，systemd 等超时（默认 DefaultTimeoutStartSec=90s）才放弃。
实操建议：
- 查
systemctl show A.service | grep TimeoutStartSec确认实际超时值 - 对
Type=notify服务，必须在代码中调用sd_notify(0, "READY=1")（C）、systemd.daemon.notify("READY=1")（Python）、或用systemd-notify --ready（Shell） - 若无法改代码，临时改
A.service：加Wants=B.service但去掉After=，再用ExecStartPre=/bin/sh -c 'while ! systemctl is-active --quiet B.service; do sleep 1; done'主动轮询
业务扩展不是堆机器，是让每台机器的资源、连接、部署、启动都可预期。最容易被跳过的，永远是 systemd 的 notify 信号、nf_conntrack 的哈希大小、以及 Ansible 底层到底走的是哪个 SSH 实现。
