那个深夜里，我们都在找宕机日志
2026年6月17日凌晨2点47分，我盯着屏幕上那行“Connection refused”发呆。这不是第一次了。作为一个跑了近十年服务器的运维，我太熟悉这种凌晨被电话叫醒的感觉。这次出问题的是阿里云的一台ECS，跑着公司核心的SVN服务器。客户那边几百号开发等着提交代码，而我连日志在哪都差点没找到。
你会发现，真正让运维崩溃的往往不是故障本身，而是找日志、改密码、调权限这些日常操作在高压下突然卡壳。这篇文章就聊聊这些让你在凌晨三点骂娘的破事，以及我踩过坑后的真实解法。
服务器宕机日志在哪里？别等崩了再找
Linux系统的常规藏身处
绝大多数服务器（包括阿里云ECS）跑的是Linux。宕机日志最可能躺在以下几个地方：
- /var/log/messages：系统通用日志，很多异常会先写到这里。
- /var/log/syslog：Ubuntu/Debian系统的主日志文件。
- /var/log/kern.log：内核日志，内核崩了或者驱动出问题，这里记录得最详细。
- /var/log/dmesg：内核环缓冲区日志，启动时的硬件检测信息，也能看到宕机前的痕迹。
但实操中你会发现：有时候服务器是直接物理宕机，比如阿里云宿主机故障导致实例被重启，这时候系统日志可能根本没来得及写入。你需要在阿里云控制台的“运维与监控”->“系统日志”里找“硬件故障记录”，或者用journalctl -k -b -1看上一次启动的内核日志。
云平台的隐藏菜单
2025年以后，阿里云、腾讯云、AWS都提供了更高级的日志服务。以阿里云为例，你可以在“日志服务”里配置“操作审计”，记录所有API调用和实例状态变更。如果服务器被黑客攻击后宕机，这些日志比系统日志更关键。我习惯把关键服务器的日志实时同步到OSS，再做一次异地备份——吃过大亏的人才懂这有多重要。
阿里云服务器密码怎么修改？三种场景三种坑
场景一：你还能登录SSH
最简单的就是passwd命令。但很多人忽略的是：阿里云默认的初始密码强度很高（大小写字母+数字+符号），你手动改了个简单密码，转头就被暴力破解。我的建议是：用openssl rand -base64 32生成随机密码，记在密码管理器里。2024年我们被黑客撞库，就是因为有人把密码改成了“Admin123!”——你猜怎么着？撞库成功率100%。
场景二：你连SSH都进不去了
这时候有两个路线：一是去阿里云控制台的“实例详情”->“重置实例密码”，重启后生效。注意这个操作会强制重启，如果你没做好业务降级，生产环境会直接炸锅。另一个是挂载系统盘救援——我之前写过一篇《阿里云ECS系统盘卸载挂载实战》，过程不复杂，但你要确保有另一台同区域的ECS当救援机。
场景三：MySQL、Redis等应用的密码
很多人以为改服务器密码就等于改了数据库密码，醒醒。2025年12月，一个朋友的公司被拖库，就是因为改了SSH密码没改MySQL密码，黑客通过之前植入的后门以root无密码登录了数据库。所以务必单独修改：MySQL用ALTER USER 'root'@'localhost' IDENTIFIED BY '新密码';，Redis去配置文件里改requirepass。
服务器如何设置777权限？先想清楚三件事
我知道你一定在网上看过“chmod 777 -R /”这个命令。听着，2026年的今天，任何专业的运维都不会教你用777。非要给某个目录最高权限，你至少得问自己三个问题：
- 这个目录需要写入权限吗？ 如果不需要，755就够了。
- 谁需要执行权限？ 普通文件644，可执行文件755，目录755。
- 这是临时操作吗？ 如果是，设置完记得改回来。我曾经在部署WordPress时给wp-content设了777，结果黑客上传了一个webshell，整个站被挂马。事后分析，那行
chmod -R 777 wp-content就是罪魁祸首。
如果你真的遇到顽固的权限问题（比如PHP-FPM写入失败），用setfacl -m u:www-data:rwx /目标目录做细粒度控制，比777安全得多。
服务器被黑客攻击后，第一件事不是拔网线
2025年8月，我处理过一起典型的挖矿病毒入侵。攻击者通过Jenkins未授权访问拿到了shell，然后下载门罗币矿工。很多新手的第一反应是拔网线、关机，但这样会丢失入侵痕迹。正确的做法是：
- 立即创建快照：云平台控制台点一下，保留当前磁盘状态作为取证依据。
- 收集攻击日志：用
lastb看登录失败记录，history看执行了哪些命令，netstat -anp看异常连接。注意：很多黑客会清理.bash_history，所以最好有auditd审计日志。 - 切断网络但保留实例：在云平台安全组里把所有入方向流量全部拒绝，而不是直接关机。
- 查找后门文件：重点检查
/tmp、/dev/shm、/var/tmp以及crontab里是否有异常任务。
那次攻击最终追查到攻击者通过SVN服务器端口（默认3690）的弱口令进入了内网。这恰好引出下一个问题。
SVN服务器端口：默认3690，但你可以做得更好
很多团队装了SVN后，直接裸跑默认端口。2026年的网络环境里，这等于跟全世界说“快来干我”。攻击者用nmap扫一下就能发现SVN服务，然后尝试暴力破解账号。
我的做法：
- 改端口：把
/conf/svnserve.conf里的port = 3690改成高位端口，比如9898。然后记得在阿里云安全组放行新端口。 - 绑定IP：如果SVN只给内网用，就用
listen-host = 内网IP限制监听地址。 - 配合SSH隧道：安全需求高的场景，干脆关掉svnserve，走
svn+ssh://协议，利用SSH的加密和认证。配置方法不复杂：确保服务器上有svnserve和sshd，客户端用svn checkout svn+ssh://用户名@IP/仓库路径就行。
另外，别忘了定期回滚版本库——2025年我们遭遇勒索病毒，攻击者加密了整个SVN仓库，还好我们有每两小时的增量备份，只丢了最后两小时的内容。
写在最后
运维这行当，说白了就是用经验换安稳。从宕机日志的排查思路到密码修改的细节，从权限设置的陷阱到黑客攻击的应急流程，再到SVN端口的安全加固——没有哪个技巧是能一招鲜吃遍天的。但只要你明白这些操作背后的“为什么”，遇到问题时不慌，一步一步查日志、改配置、做备份，大多数故障都能解决。
下次凌晨三点再被叫醒，至少你知道该先看哪行日志了。