运维实战与常见问题自救手册

那些让你凌晨三点惊醒的故障

做运维的人都知道，最怕的不是工作日的高峰流量，而是深夜的告警短信。我整理了过去两年客户遇到的高频故障，每个都有解决方案。这篇相当于一本“自救手册”，建议收藏。

场景一：EC2实例突然无法SSH连接

症状：SSH超时或连接被拒绝，但实例在控制台显示“running”。

可能原因及排查步骤：

安全组规则变更：检查安全组是否还允许你的IP访问22端口（或自定义端口）。可以在控制台“安全组”里查看入站规则，如果IP变了，添加新IP即可。

系统防火墙（iptables/firewalld） ：如果你在系统内改了防火墙规则，可能封掉了SSH。如果无法连入，可以用EC2 Instance Connect（浏览器SSH）或AWS Systems Manager Session Manager（无需SSH端口）登录，然后修复防火墙。

CPU或内存耗尽：实例负载过高导致sshd无响应。这时可以尝试停止实例（Stop）再启动（注意：停止后IP可能变化，除非有弹性IP），或者升级实例规格。

密钥对错误：确认你用的.pem文件是否正确，且权限为400（chmod 400 yourkey.pem）。

网络ACL限制：检查子网关联的Network ACL是否允许入站SSH。

自救工具：AWS控制台 > EC2 > 实例 > 右键“连接”有多种方式，包括Session Manager（不需要开放22端口，强烈推荐）。

场景二：实例磁盘满了，应用崩溃

症状：无法写入文件，数据库报错“No space left on device”，网站500错误。

快速修复：

先SSH进去，用df -h查看哪个分区满了，通常是/dev/xvda1（根分区）。

清理大文件：find / -type f -size +100M -exec ls -lh {} \; 找到大文件，判断是否可以删除（如日志、临时文件、旧备份）。

清理系统日志：sudo journalctl --vacuum-size=100M（systemd系统）或清空/var/log/下的旧日志。

如果根卷本身太小，可以扩展EBS卷：在控制台选择实例的根卷，点击“修改卷大小”，增大容量（比如从20GB扩到40GB），然后登录系统执行resize2fs或xfs_growfs来识别新空间（具体命令看文件系统类型）。

长期预防：

设置logrotate自动轮转日志。

监控磁盘使用率（CloudWatch自定义指标或第三方监控），设置告警阈值85%。

将应用日志和数据分离到独立的大容量卷（如挂载额外的EBS）。

场景三：账单暴涨——怀疑被挖矿或DDoS

症状：收到预算告警，发现当天费用远高于平时，实例数量异常增加。

紧急处理流程：

立刻登录控制台，查看EC2实例列表，看是否有多余的未知实例。如果发现大量陌生实例（尤其是GPU实例），说明账号可能泄露。

立即停止（Stop）这些实例，不要删除（保留证据便于后续调查）。如果停止不了，尝试强制终止（Terminate）。

更改根账号密码，并使所有访问密钥失效（删除或禁用）。

检查IAM用户，看是否有新创建的用户或未知的访问密钥。删除所有可疑用户。

开启详细账单，通过Cost Explorer查看是哪个区域、哪个服务产生了高费用，定位攻击源头。

联系AWS Support（或你的代理商） ，申请豁免（如果确实是安全事件，AWS有时会酌情减免部分费用）。

预防措施：

启用GuardDuty（有30天试用），它自动检测挖矿、异常API调用等威胁。

遵循第三篇的三道防线，尤其是MFA和最小权限。

限制IAM角色只能从特定IP调用（通过条件策略）。

场景四：忘记MFA设备，无法登录根账号

症状：换了新手机，Google Authenticator没备份，MFA码丢失，登录不了。

自救方案：

如果你在开启MFA时记录了恢复码（Recovery Codes） ，用恢复码登录或禁用MFA。

如果没记录，联系AWS Support进行身份验证：需要提供注册时的信用卡信息、电话号码、公司证件等，过程繁琐但可行。

避免办法：开启MFA时一定要下载恢复码并保存在安全的地方（比如密码管理器或打印出来）。另外，可以考虑使用硬件MFA（YubiKey） 配合备份，或者多台设备同时绑定（AWS支持多个MFA设备）。

场景五：服务器被DDoS攻击，流量费用飙升

症状：网站无法访问，CloudWatch显示网络流入/流出异常高，同时AWS账单上“数据传输”费用猛增。

防御策略：

如果你的应用在AWS上，启用AWS Shield Standard（免费，提供基础DDoS防护）。

对于重要业务，购买AWS Shield Advanced（约$3000/月），提供更强大的DDoS防护和费用保护（攻击导致的流量费可申请减免）。

在应用前端部署AWS WAF，配置速率限制规则（比如单个IP每秒最多100个请求），过滤恶意流量。

使用CloudFront或Global Accelerator做CDN加速，隐藏后端EC2的真实IP，减少直接攻击。

设置自动扩缩容，但要注意攻击时自动扩容可能带来巨额账单——建议结合WAF和Shield。

常见故障速查表

运维哲学：监控 > 修复

上面的“自救”都是事后补救，更高明的做法是事前监控。建议每个AWS用户都做好以下几项：

CloudWatch详细监控：启用EC2详细监控（1分钟粒度，而非默认5分钟），虽然多一点点费用，但能更早发现异常。

自定义指标：监控磁盘使用率、内存使用率（需要安装CloudWatch Agent），因为AWS默认不监控内存和磁盘。

日志集中管理：使用CloudWatch Logs将系统日志和应用日志集中存储，搜索和排障效率大增。

定期演练：每季度做一次故障演练，比如故意关掉一台实例，看自动恢复是否生效，团队响应是否及时。

人性化结尾：运维是技术，更是心态

我见过最淡定的运维，遇到故障先深呼吸，再按既定流程排查，半小时恢复。也见过最慌的，一看到告警就乱删文件，结果把系统搞得更糟。

运维的第一原则是“先保数据，再保服务” ——如果实例异常，先别急着重启，先做快照备份（如果可以的话），然后再尝试修复。因为数据丢了就真没了，服务宕机一小时还能追回来。

另外，不要害怕求助——如果你有代理商，他们的技术团队往往经验丰富，可能五分钟就能解决你折腾两小时的问题。我们公司自己就提供应急响应服务，客户凌晨三点打电话也能找到人。

最后一句：云上运维就像开飞机，仪表盘（监控）比操纵杆（操作）更重要。把监控做好，把预案做足，你就能安稳睡好每一个晚上。

如果需要更深入咨询了解可以联系全球代理上TG:jinniuge  他们在云平台领域有更专业的知识和建议，他们有国际阿里云，国际腾讯云，国际华为云，aws亚马逊，谷歌云一级代理的渠道，客服1V1服务，支持免实名、免备案、免绑卡。开通即享专属VIP优惠、充值秒到账、官网下单享双重售后支持。不懂找他们就对了。