2核4G够不够用主要看业务：个人博客、官网、小型Web应用、开发测试环境，跑1到2个服务（如Nginx+PHP或Node+MySQL）完全够用；如果用Docker跑多个容器、Java应用（JVM吃内存）或数据库压力较大，建议升级到4核8G。买之后用free -h和top观察内存，available长期低于20%就该扩容；可先加2G swap应急（fallocate、mkswap、swapon）。带宽按需选：个人站3到5Mbps足够，或按流量计费；系统盘建议40GB起步，数据多就另挂数据盘。选Linux镜像更省资源，并做好定期快照备份。

OBS新手常见坑总结：1）区域和endpoint要一致，桶在哪个Region就用对应endpoint，否则报301或签名错误；2）公共读不要乱开，推荐用桶策略精确授权，或用临时授权URL，避免数据被盗刷产生流量费；3）存储类别要选对，低频和归档有最短存储时长和取回费用，频繁访问的数据放标准存储；4）出公网流量要计费，同区域内网访问ECS免流量费，可配合CDN降低成本；5）大文件用obsutil或分段上传，不要用浏览器上传，支持断点续传；6）AK/SK不要写进代码或提交到仓库，使用IAM子账号并只给最小权限；7）开启版本控制和生命周期规则，自动清理过期对象和碎片，避免产生不必要的存储费用。

建议按这个顺序排查：1）确认登录用户名：公共镜像一般是root，部分镜像是ecs-user/ubuntu/centos，用错用户会直接Permission denied；2）私钥权限：chmod 600 key.pem，Windows导出的.ppk需转成OpenSSH格式；3）控制台确认实例确实绑定了这个密钥对；4）安全组入方向放通22端口；5）通过控制台VNC登录，检查~/.ssh/authorized_keys是否有公钥，.ssh目录权限700、authorized_keys为600；6）查看/etc/ssh/sshd_config里的PubkeyAuthentication yes、PasswordAuthentication、PermitRootLogin，改完执行systemctl restart sshd；7）本地用ssh -i key.pem -v root@公网IP看详细日志，能看到具体在哪一步被拒。密码也被拒绝，多半是sshd禁用了密码登录或PermitRootLogin为no，用VNC改配置即可。

建议按这个顺序排查：1）确认登录用户名：公共镜像一般是root，部分镜像是ecs-user/ubuntu/centos，用错用户会直接Permission denied；2）私钥权限：chmod 600 key.pem，Windows导出的.ppk需转换为OpenSSH格式；3）控制台确认实例确实绑定了这个密钥对（创建时选的，之后换需重置）；4）安全组入方向放通22端口，源地址别写错；5）通过控制台VNC登录，检查~/.ssh/authorized_keys是否有公钥、权限为600，建议按这个顺序排查：1）确认登录用户名：公共镜像一般是root，部分镜像是ecs-user/ubuntu/centos，用错用户会直接Permission denied；2）私钥权限：chmod 600 key.pem，Windows导出的.ppk需转换为OpenSSH格式；3）控制台确认实例确实绑定了这个密钥对（创建时选的，之后换需重置）；4）安全组入方向放通22端口，源地址别写错；5）通过控制台VNC登录，检查~/.ssh/authorized_keys是否有公钥、权限为600，.ssh目录700；6）查看/etc/ssh/sshd_config里的PubkeyAuthentication yes、PasswordAuthentication、PermitRootLogin，改完systemctl restart sshd；7）本地用ssh -i key.pem -v root@公网IP看详细日志，就能看到是哪一步被拒。密码也被拒绝多半是sshd禁用了密码登录或PermitRootLogin为no，用VNC改配置即可。.ssh目录700；6）查看/etc/ssh/sshd_config里的PubkeyAuthentication yes、PasswordAuthentication、PermitRootLogin，改完systemctl restart sshd；7）本地用ssh -i key.pem -v root@公网IP看详细日志，就能看到是哪一步被拒。密码也被拒绝多半是sshd禁用了密码登录或PermitRootLogin为no，用VNC改配置即可。

安全组放通只说明“实例之间的端口策略允许”，函数访问同 VPC 的 RDS 超时，通常还有四层网络没配对。建议按这个顺序看，不要反复改安全组。 1. 函数必须打开 VPC 访问，并且子网和 RDS 在同一个 VPC。只在函数配置里填了 RDS 内网地址、但没绑定 VPC，请求会走公网出口，内网地址不可达，表现就是超时而不是立刻拒绝。绑定的子网要有足够的可用 IP，子网 IP 耗尽时函数实例起不来，调用也会一直等到超时。 2. 安全组是双向的，而且要加在对的资源上。RDS 安全组的入方向要允许函数所在安全组访问数据库端口，例如 MySQL 3306、PostgreSQL 5432，来源写成函数子网的网段，或写成函数使用的安全组。函数侧如果绑定了安全组，出方向也要允许访问该端口。只在函数安全组放通、RDS 安全组没放行，包到不了数据库。 3. 网络 ACL 和路由容易漏。子网如果关联了网络 ACL，它是无状态的，入和出都要放行数据库端口以及回程的临时端口。再看函数子网的路由表是否有指向 RDS 所在子网的本地路由，跨 VPC 则要有对等连接路由，并且对端也要回程。安全组放通只说明端口策略允许，函数访问同 VPC 的 RDS 超时，通常还有几层网络没配对。建议按这个顺序看，不要反复改安全组。 1. 函数要真正进入 VPC。只填了 RDS 内网地址、但函数没有绑定 VPC 和子网时，请求走的是公网出口，内网地址不可达，表现是一直等到超时，而不是马上拒绝。绑定的子网还要有剩余 IP，IP 耗尽时函数实例起不来，调用同样会超时。 2. 安全组要加在 RDS 上，并且出方向也要通。RDS 安全组入方向允许函数子网网段访问数据库端口，例如 MySQL 的 3306 或 PostgreSQL 的 5432。函数如果绑定了安全组，出方向也要允许访问该端口。只改函数侧、RDS 侧没放行，包到不了数据库。 3. 检查网络 ACL 和路由。子网关联了网络 ACL 时，它是无状态的，入方向和出方向都要放行数据库端口以及回程临时端口。函数子网的路由表要有到 RDS 子网的本地路由；跨 VPC 还要有对等连接，并且对端有回程路由。 4. 用一台同子网 ECS 把问题拆开。在函数同一个子网里用同一内网地址和端口做连接测试。ECS 也不通，就是网络或安全组；ECS 通、只有函数不通，再看函数的 VPC 配置和超时时间。函数默认超时只有几秒时，跨可用区第一次建连可能不够，可先调到 30 秒排除误判，通了再按业务改回去。 5. 再确认 RDS 本身。使用的是当前 VPC 的内网地址；如果实例要求 SSL，客户端也要配上；最大连接数打满时，有的客户端同样表现为一直等到超时。 多数“安全组明明放了还是超时”，是函数没有真正进入 VPC，或只放了一侧安全组，或子网 ACL 把回程掐掉了。 4. 用地址区分是网络问题还是账号问题。在函数所在 VPC 里找一台同子网的 ECS，用同一个内网地址和端口做连接测试。ECS 也不通，就是网络或安全组；ECS 通、函数不通，再回头看函数的 VPC 配置、子网和超时时间。函数默认超时如果只有几秒，跨可用区首次建连可能不够，可以先把超时调到 30 秒排除误判，确认通了再按业务改小。 5. RDS 自身还要确认：内网地址用的是当前 VPC 的 IP，不是只开了公网；实例不是只允许 SSL 而客户端没配；最大连接数没满。连接数满时有的客户端也会表现为等超时。 这个链路里，安全组只是其中一环。多数“安全组明明放了还是超时”，是函数没真正进 VPC，或只放了一侧安全组，或子网 ACL 把回程掐了。

df 看到的是文件系统已分配的块，du 看到的是目录树里还能遍历到的文件，两边口径不一样，所以会出现“盘满了但 du 找不到大文件”。在华为云 ECS 上建议按下面顺序查，不要一上来就扩容。 第一，确认是哪一块盘，并排除 inode 用满。df -hT 看 100% 的是系统盘还是数据盘，再跑 df -i。inode 用满时容量可能还剩，那是海量小文件，不是大文件。 第二，用 root 并且加上 -x，避免漏目录、避免跨盘。du -xhd1 / 或 du -xhd1 /data。非 root 会跳过无权限目录；只 du 家目录会漏掉 /var，这是最常见的误判。 第三，查已删除但仍被进程打开的文件，这是 ECS 上最常见的原因。lsof +L1 能列出删除后仍占空间的文件。日志切割后 nginx 或 java 没重新打开日志就会这样。处理是重启对应进程让它释放，不要再 rm 一次。暂时不能重启时，确认 /proc/PID/fd/N 指向的就是那份已删除日志，再对这个 fd 做截断。 第四，检查挂载是否把旧数据盖住。数据盘挂到 /data 之前如果已经写过文件，挂上之后当前目录树看不到，但系统盘空间仍被占着。可以用 mount --bind / /mnt/rootdisk 后查看 /mnt/rootdisk/data。确认无用再删，然后卸载这个 bind。卸载数据盘之前不要直接删除 /data。 第五，单独看容器日志和 journal。docker system df 能分清镜像、容器和卷；json 日志单文件几十 GB 很常见，daemon.json 里给 json-file 加 max-size、max-file，只对新建容器生效。journalctl --disk-usage 过大就 journalctl --vacuum-size=200M。 第六，ext4 默认给 root 预留大约 5%。普通用户看到 df 已满时，用 tune2fs -l 看 Reserved block count。数据盘可以调低预留，系统盘不要改成 0。 控制台快照不占这块盘的 df。如果是扩容后 df 容量没变，那是没做 growpart 和 resize2fs/xfs_growfs，和这次“df 已满”相反。上面几步对完再决定要不要升盘。

df 和 du 对不上，多半不是有个 du 找不到的神秘大文件，而是两边统计口径不同。在华为云 ECS 上按这个顺序查，确认没有被进程占住、也没有被挂载盖住之后，再考虑扩容。 1. 先确认满的是哪一块盘，并排除 inode。执行 df -hT，看 Use% 到 100% 的是系统盘还是数据盘，再执行 df -i。如果是 inode 用满、容量还剩不少，那是海量小文件，后面不要按大文件去删。 2. 用 root 统计，并且不要跨文件系统。非 root 跑 du 会跳过没权限的目录，数字天然偏小。对满的挂载点执行 du -xhd1 / 或 du -xhd1 /data，-x 保证不钻进其他盘。只 du 家目录、漏掉 /var，是最常见的误判。 3. 已删除但仍被进程打开，这是 ECS 上最常见的原因。文件被 rm 之后，只要还有进程握着文件描述符，空间就不会还给 df，du 也遍历不到。执行 lsof +L1。日志切割后 nginx 或 java 没有重新打开日志，就会这样。不要再 rm 一次，重启该进程让它松手。暂时不能重启时，确认 fd 指向的就是那份已删除日志，再对 /proc/PID/fd/N 做截断。容器还在写、宿主机上日志已被删，也是同样现象。 4. 挂载把旧数据盖住了。数据盘挂到 /data 之前如果已经往 /data 写过文件，挂载之后这些文件从当前目录树上看不见，但仍然占着系统盘。先 mkdir /mnt/rootdisk，再 mount --bind / /mnt/rootdisk，然后 du -sh /mnt/rootdisk/data。确认没用再删，最后 umount。卸载数据盘之前不要直接删 /data，否则删的是数据盘里的文件。 5. 容器日志和 journal 单独看。docker system df 能分开看镜像、容器和本地卷。容器 json 日志单文件到几十 GB 很常见，可在 daemon.json 里给 json-file 加上 max-size 和 max-file，改完只对新建容器生效。journalctl --disk-usage 过大时，用 journalctl --vacuum-size=200M。这两处用 du -xhd1 /var 都能看到。 6. ext4 默认大约预留 5% 给 root。普通用户看到 df 已满、自己的 du 对不上时，用 tune2fs -l 查看 Reserved block count。数据盘可以把预留调低，系统盘不建议改成 0，避免磁盘真满时 root 无法写日志。 7. 和控制台扩容区分开。快照不占用这块盘在系统里的 df。如果控制台已扩容但 df 容量没变，那是分区或文件系统没延伸，需要 growpart 后再 resize2fs 或 xfs_growfs，现象和这次相反。当前 df 已经 100%，先把上面几步查完，再决定要不要升云硬盘。清理前看清楚文件属于哪个业务。

df 和 du 对不上，多半不是“有个 du 找不到的神秘大文件”，而是两边统计口径不同。在华为云 ECS 上建议按这个顺序查，查完再决定删还是扩容。 1. 先确认满的是哪一块盘，顺手排除 inodedf -hT 看 Use% 100% 的挂载点是系统盘还是数据盘。再跑 df -i。如果是 inode 用满、容量还剩不少，那是海量小文件，和“du 找不到大文件”不是同一类问题，后面不要按大文件去删。 2. 用 root、并且不要跨文件系统非 root 跑 du 会跳过没权限的目录，数字天然偏小。在该挂载点上执行 du -xhd1 /（或 du -xhd1 /data），-x 保证不钻进其他盘。只对业务目录做 du，漏掉 /var 是最常见的误判。 3. 已删除但仍被进程打开（ECS 上最常见）文件 rm 之后，只要还有进程握着文件描述符，空间就不会还给 df，du 也遍历不到。执行 lsof +L1，或 lsof 2>/dev/null | grep deleted。日志切割后 nginx、java、业务进程没有重新打开日志，就会出现这种情况。处理时不要再 rm 一次，而是重启该进程让它松手；如果暂时不能重启，确认 fd 指向的就是那份已删除日志后，可以对 /proc/PID/fd/N 做截断。Docker 场景里，容器还在写、宿主机上对应 json.log 已被删，也会是同样现象。 4. 挂载把旧数据盖住了数据盘挂到 /data 之前，如果已经往 /data 写过文件，挂载之后这些文件在原目录树上看不见，但仍然占着系统盘。用 mkdir /mnt/rootdisk && mount --bind / /mnt/rootdisk，再 du -sh /mnt/rootdisk/data。这里能看到被盖住的内容。确认没用再删，然后 umount /mnt/rootdisk。卸载数据盘之前不要直接删 /data，否则删的是数据盘里的文件。 5. 容器和 journal 这两处单独看docker system df 能分开看镜像、容器、本地卷各自占多少；/var/lib/docker/containers 下的 json.log 单文件到几十 GB 很常见。限制方式是在 daemon.json 里给日志驱动加 max-size 和 max-file，改完只对新建容器生效，旧容器要重建。journalctl --disk-usage 看系统日志，太大就 journalctl --vacuum-size=200M。这两处 du -xhd1 /var 都能看到，如果之前只 du 了家目录，就会觉得“没有大文件”。 6. ext4 给 root 预留的块ext4 默认大约预留 5% 给 root。普通用户看到 df 已满、自己 du 出来的总和对不上时，用 tune2fs -l /dev/对应设备 | grep -i reserved 核对。数据盘可以把预留调低，系统盘不建议改成 0，避免 root 在磁盘真满时无法登录。 7. 和云硬盘扩容区分开控制台快照不占用这块盘的 df。如果是“控制台已扩容但 df 容量没变”，那是分区或文件系统没延伸（growpart 之后再 resize2fs 或 xfs_growfs），现象和这次相反。当前是 df 已经 100%，先把 1 到 6 查完，确认没有已删除未释放、没有被挂载盖住的数据，再考虑升云硬盘。清理前看清楚文件属于哪个业务，避免把还在写的日志或数据盘里的库文件清掉。

积分耗尽本身不是故障，而是突发性能实例在告诉你：这段时间用掉的 CPU 已经超过该规格预付的基准算力。该不该换，建议用下面四步判断，而不是看到余额为 0 就立刻升配。 1. 先确认是不是「被基准卡住」打开云监控，把 CPU 使用率、CPU 积分余额（cpu_credit_balance）和业务的 P95 延迟放在同一时间轴。如果余额接近 0 的同时，CPU 使用率被压在该规格的基准性能附近、接口延迟和队列长度一起变差，基本可以认定是积分限制。注意基础监控大约 5 分钟一个点，短尖峰会被平均掉，所以要结合业务侧延迟，不要只看控制台一条曲线。 2. 用 7 天平均值决定去留算出这 7 天 CPU 使用率的平均值，和规格表里的基准性能比较。平均值长期高于基准，积分一定会持续见底，t 系列不适合这个负载，应该换。平均值明显低于基准，只是每天有一两小时高峰，并且低峰时余额能涨回来，说明积分缓冲还在起作用，可以继续用 t 系列，把高峰错开或缩短批任务即可。如果余额曲线一天比一天低、低峰也补不回来，一般几天内就会长期触底，建议提前变更，不要等业务投诉。 3. 换到哪一档只升一档 t 系列往往不够：基准百分比可能差不多，业务量如果不变，绝对算力变多，但只要平均使用率仍高于新基准，积分还是会光。CPU 平均高、内存水位不高，优先变更到计算型 c；内存也经常接近上限，变更到通用型 s。S 系列不要和 T 系列的积分限制混为一谈，变更前以目标规格的产品说明为准。 4. 成本上什么时候划算t 系列便宜，买的是「基准算力 + 积分缓冲」。一旦需要长时间跑满，把 t 的小时价除以基准性能比例，才是你为了拿到 100% CPU 付出的真实成本，这时通常已经不如直接买 c 或 s。偶发高峰如果实例详情里提供无性能约束一类开关，先看清透支怎么计费再开，它适合偶尔超出，不适合每天把积分透支光。 变更规格会重启实例，放在低峰做，变更前给系统盘打一份快照。换到 c/s 之后连续看 3 天：CPU 稳定落在 70% 以下、P95 不再随整点飙升，就可以认为这次变更是有效的。

同 vCPU 对比 c 系列和 s 系列，建议把「规格表上能确定的差异」和「你的业务能不能感知」拆开看，不要直接套别人测出来的百分比。 1. 规格表上先核对三列，而不是只看 vCPU以同代 c7 / s7 为例，型号后缀就是内存配比：c7.large.2 大约是 2vCPU/4GiB（1:2），s7.large.4 大约是 2vCPU/8GiB（1:4）。购买页「规格详情」里还要同时看内网最大带宽、收发包 PPS、云硬盘带宽基线。这三项才是同 vCPU 下 c 通常高于 s 的地方，而且不同区域条目会有差别，以当前区域规格表为准。 2. 瓶颈在哪，差距才出现在哪CPU 或小包 PPS 是瓶颈时（网关、鉴权、加解密），c 系列更容易把延迟压住。堆内存、本地缓存、连接数是瓶颈时（常见于 Java 或带本地缓存的服务），s 多出来的内存能避开 Full GC 和 OOM，实际吞吐可能更高。云硬盘打满时，先看磁盘吞吐有没有顶到该规格的存储基线，这时换 c 还是 s 帮助有限，应升盘类型或升到存储基线更高的规格档。 3. 同可用区、同镜像、同盘类型做一轮对比计算用 sysbench cpu，线程数等于 vCPU 数，看 events/s，不要只看单线程。网络在同可用区用 iperf3 测带宽，再用 64 字节小包看 PPS；业务侧用 wrk 记录 P99 和错误率，而不是只看 QPS。磁盘用 fio 做顺序读写和 4k 随机，确认有没有顶到规格的磁盘带宽上限。压测时同时看云监控里的 CPU 使用率、网络流入流出、磁盘读写带宽。 4. 用「达标 QPS / 小时价」做取舍先定一个 P99 阈值，分别测出 c7.large.2 和 s7.large.4 能撑住的最大并发，再除以小时价。内存够用且 CPU 持续高于约 70%、P99 变差，再从 s 升到 c。内存先接近水位时留在 s 或加大内存更合适，硬上 c 会把钱花在用不满的算力上。 5. 两个容易误判的点突发性能实例（t 系列）才有 CPU 积分，c/s 没有「积分耗尽」，不要用积分解释抖动。跨代对比（例如 c6 对 s7）没有参考价值，CPU 代次和网络基线都变了。另外购买页的最大带宽是上限，小规格的基线带宽更低，小规格上测出的差距经常来自基线带宽而不是 CPU 本身。