大家好，我是你们的服务器“老司机”小A。今天咱们聊一个看似简单但容易“翻车”的话题——转交服务器需要什么？

别看这问题简单，实际操作中，多少人因为漏掉一个小步骤，导致网站宕机、数据丢失，甚至被老板请去“喝茶”。所以，今天我就用轻松幽默的方式，带大家梳理一份“零翻车”转交清单，顺便分享几个血泪教训（别问我怎么知道的）。

一、转交前的“灵魂拷问”：你真的准备好了吗？

转交服务器就像把自家养的猫托付给朋友——你得确保对方知道猫粮在哪、铲屎频率、以及它半夜会跳你脸上（别问我为什么举例这么具体）。服务器同理，以下问题必须确认：

1. 为什么要转交？

- 公司架构调整？运维团队更换？还是你终于受不了老板的“再优化一下”准备跑路？（开玩笑的）

- 举例：某网友把服务器转交给新同事，结果对方误删了生产环境数据库……因为没说明这是“测试服”和“生产服”的区别。

2. 对方懂服务器吗？

- 如果接手的是个只会用Word的小白，建议先给他报个《Linux从删库到跑路》速成班（误）。

二、硬核清单：转交服务器的必备项

1. 权限与账号：别让接手人变成“无头苍蝇”

- Root/管理员密码：别笑！真有人写在便利贴上然后弄丢了。

- SSH密钥：如果是密钥登录，记得移交`.pem`或`.ppk`文件，并教他怎么用（否则他会疯狂问你“为啥连不上”）。

- 后台面板权限：比如宝塔面板、cPanel、AWS控制台等。

- 数据库账号密码：尤其是MySQL、MongoDB这些，别等到应用挂了才发现没给权限。

2. 文档与配置：没有文档的运维都是“玄学”

- 服务器用途说明：比如这是跑官网的、还是内部ERP的？优先级如何？

- 服务列表与端口：用`netstat -tuln`查一下，标清楚哪个端口对应哪个服务（比如Nginx用80，MySQL用3306）。

- 定时任务（Crontab）：曾经有人转了服务器才发现备份脚本没移交……然后硬盘炸了。

- 防火墙规则：iptables或firewalld配置，别让新运维一脸懵：“为啥外网访问不了？”

3. 数据与备份：丢了数据就准备“提桶跑路”吧

- 数据存放路径：比如网站代码在`/var/www`，日志在`/var/log`。

- 备份策略与位置：手动备份？自动备份？备份文件放本地还是OSS？

- *血泪案例*：某公司转交时没提备份盘快满了，结果一周后磁盘写爆，数据全丢。

- 数据库导出文件（SQL Dump）：以防万一，留个最新版的`.sql`文件。

4. 依赖与环境：“这服务跑不起来啊！”

- 运行环境版本：PHP是7.4还是8.0？Python用2.7还是3.9？差一个小版本可能就崩了。

- 依赖包列表：比如用`pip freeze > requirements.txt`（Python）或`composer.json`（PHP）。

- *真实事件*：某开发移交项目时没给Node.js的`package.json`，结果新团队装了依赖死活跑不起来……

5. 监控与告警：别等用户骂街才发现挂了！

- 监控工具配置（如Prometheus、Zabbix）。

- 告警通知渠道（邮件、Slack、钉钉等）。

- *反面教材*：某运维离职后告警邮件发到他个人邮箱……结果服务器宕机三天没人管。

三、骚操作环节：如何优雅地甩锅？（划掉）交接

1. 录制操作视频：

- 用OBS录个屏：“这是重启服务的姿势，这是查看日志的姿势……”比文字教程直观100倍。

2. 搞个交接沙盒环境

- 克隆一台测试服务器让接手人练手，总比直接拿生产环境“开刀”强。

3. 签个免责声明（严肃脸）

- “本人已移交所有资料，后续问题概不负责”——虽然法律上不一定有用，但能提醒对方认真对待。

四、终极防坑

1. 检查表：

```

[√] 权限给了吗？

[√] 文档写了吗？

[√] 备份有了吗？

[√] 环境说明了吗？

[√] 监控移交了吗？

2. 交接后观察期：

- 保持一周在线支援（除非你铁了心要拉黑前东家）。

****

转交服务器不是丢钥匙那么简单——它关乎数据安全、业务连续性和你的职业口碑（以及前同事会不会在朋友圈骂你）。按这份清单操作，保你交接稳如老狗！

如果还有疑问，欢迎在评论区提问~ （当然也可以吐槽你遇过的奇葩交接经历！）

TAG:转交服务器需要什么,转交服务器需要什么条件,转服务器多久可以转回来,服务器交换