星图导航
首页 文章 排行榜 申请收录 友链申请 关于
首页 / 文章资讯 / 网站运营 / 一个人管十个站:多站点统一运维怎么做

一个人管十个站:多站点统一运维怎么做

星图导航配图

手上同时管着五个、十个站,很多人第一反应是“忙不过来”。真正拖垮人的不是站点数量,是每个站都有一套自己的操作方式:这个站用宝塔、那个站纯命令行,这个站备份放本地、那个站从来没备过。把重复动作标准化,十个站的日常工作量能压到一个站的两倍以内。下面这套做法我在自己几个站上跑了两年,能直接照搬。

先把所有站的信息收进一张表

新建一张表格,字段固定死:站点名、域名、服务器 IP、面板地址和账号、程序类型和版本、数据库名和账号、备份路径、CDN 是否开启、SSL 到期日、备案号、负责人。这张表放在本地加密文档里,密码部分单独存到密码管理器,表格里只写“见密码库第几项”。

为什么强调这张表?因为多站运维出的问题,八成不是技术问题,是“想不起来”。想不起来这个站的数据库密码是什么,想不起来 SSL 什么时候到期,想不起来上次改配置改的是哪台机器。表格建好,这些全都变成查一下的事。

统一面板,别一个站一个玩法

能用同一款面板就统一用同一款。宝塔、1Panel、aaPanel 都行,选一个用得顺的,所有服务器装同一个版本。好处很直接:备份路径一致、日志位置一致、定时任务入口一致、防火墙规则写法一致。换一台机器操作,肌肉记忆直接能用。

面板版本也别乱升。生产环境跑着稳定的版本,没有安全更新就不动它。要升级先在测试机上跑一遍,确认网站、数据库、PHP 扩展都正常,再批量推。多站环境下,一次翻车就是十个站一起翻。

运维脚本化,别靠手工点

日常最高频的动作就那几个:备份数据库、备份站点文件、清理日志、检查磁盘、检查证书。这五件事必须全部脚本化,写成 shell 或者 Python,扔进 cron。

备份脚本的核心参数:数据库用 mysqldump 加 gzip,站点文件用 tar 排除 cache 和 logs 目录,备份文件按“站点名_日期”命名,保留最近七天,超期的自动删。脚本跑完要有输出,成功写一行日志,失败发一封邮件或者推到企业微信。没有告警的定时任务等于没有。

磁盘检查更简单:df -h 拿到使用率,超过百分之八十五就告警。很多人是网站打不开了才发现磁盘满,那时候数据库可能已经写坏了。

批量操作要先分组

十个站不要当成十个独立对象,按业务分组。比如内容站一组、工具站一组、测试站一组。批量改配置的时候按组来,一组改完验证一组,出问题只影响一组,回滚也只回一组。

改之前先做快照。面板有快照功能就用快照,没有就手动打包配置目录。nginx 和 php 的配置文件、站点目录、数据库,三样都要。改完发现不对,十分钟能回到改之前,比现场排查两小时强。

监控入口集中到一个地方

十个站不可能每天逐个打开看。做一个统一的监控页,或者用现成的探针(Uptime Kuma、哪吒监控都行),把所有域名加进去,每分钟探测一次,挂了立刻通知。监控项至少三项:HTTP 状态码、响应时间、证书有效性。

响应时间这一项很多人忽略。状态码两百但响应五秒,用户早就走了。设个阈值,比如超过两秒就标记为慢,连着三次超标就告警。慢往往是磁盘满、数据库慢查询、内存不够的前兆,早发现能省一次事故。

故障处理要有固定顺序

十个站里某一个挂了,先别急着登服务器。按顺序走:第一步,从外部访问确认是不是真挂,有时候是自己网络的问题;第二步,看监控和日志,定位是应用层还是系统层;第三步,看最近有没有改动,九成的故障由最近的改动引起;第四步,能回滚先回滚,别在现场debug;第五步,回滚后复盘,写清楚原因和下次怎么避免。

这个顺序的价值在于,慌乱的时候人容易跳步。跳过“确认是不是真挂”,直接重启服务,重启完发现问题还在,又怀疑是别的原因,来回折腾半小时。

成本和隔离也要一起算

十个站如果每台都配独立服务器,一个月开销很容易上千。省法有两种:一是把流量小的几个站合并到一台性能好点的机器,用不同目录加 nginx 多站点跑;二是静态资源全走 CDN,源站只留程序和数据库,带宽能压到原来的三分之一。合并的时候必须做资源隔离,一个站的 PHP 进程内存爆了不能把整台机器拖垮,用 PHP-FPM 的进程池限制或者 cgroup 卡住上限。

还有个特别容易忽略的点是时区。几台机器分布在不同机房,有的默认 UTC,有的默认北京时间,日志时间对不上,排查故障的时候先怀疑人生。统一设成 Asia/Shanghai:timedatectl set-timezone Asia/Shanghai,顺手把 NTP 时间同步打开。机器时间漂了几分钟,定时任务就会在错误的时间点触发,备份跑到高峰时段,站点直接卡死。

把重复决策提前做掉

多站运维真正省时间的地方,不是操作快,是决策少。提前定好规则:什么情况必须回滚、什么情况可以热修、备份保留几天、证书提前多少天续、什么时候允许上生产改代码。规则定好写进文档,遇到情况直接套,不用每次重新权衡。

我自己的规则是:影响前台访问的问题一律先回滚;数据库结构变更只在凌晨做且必须提前备份;证书剩十五天自动续;任何改动先在自己流量最小的站上跑一天。这几条执行下来,一年没出过一次全站事故。

管十个站累不累,取决于你有没有把它们当成一套系统来管。当成十个独立的小摊子,永远忙;当成一套有标准流程的系统,日常就是看告警、跑脚本、偶尔修一次。