我们自己的一台服务器上跑着五十来个网站。这么做省钱，但也意味着任何一个站出问题，其他四十九个都可能受影响。
这篇讲清楚这种架构的风险在哪、必须划哪些边界。对你的实际意义是：你的网站很可能也在这样一台机器上——共享主机就是这个模式——知道风险在哪，你才知道该问服务商什么。
共享带来的三类风险
一、资源被抢。
CPU、内存、数据库连接是共用的。一个站被搜索引擎密集抓取、或者程序写得差每次访问都跑重查询、或者干脆被攻击了，它会把资源吃掉，剩下的站一起变慢。
这类问题的表现很讨厌：你的网站间歇性变慢，而你自己什么都没改。查日志也查不出所以然，因为问题不在你这。
二、一个站被入侵，可能影响全部。
这是最严重的一类。如果所有网站的文件在同一个用户下、目录权限又宽松，那么攻破一个站就能读写其他站的文件。
实际的攻击路径通常是：某个站用了一个多年没更新的插件，被扫到漏洞传了个后门文件，然后横向去改其他站——最常见的是往页面里插隐藏链接，或者把访客跳到别处。
三、配置是共用的。
如果多个站共用同一份服务器配置文件，那么为某一个站做的改动会影响所有站。改错了不是一个站坏，是全部坏。
我们自己动这类共享配置的时候有条硬规矩：改之前先复制一份带时间戳的备份。看起来老土，但当你要改的文件被五十个域名共用时，它是唯一让你敢动手的东西。
必须划的边界
文件权限隔离。每个站的文件应该属于不同的系统用户，互相不能读写。这是最基础也最有效的一条——它把”一个站被攻破”限制成一个站的事。
很多便宜的共享主机不做这一层，所有站跑在同一个用户下。这是这类主机最大的风险，而且从外面完全看不出来。
数据库分离。每个站一个独立数据库、独立账号，账号只能访问自己那个库。这样即使程序被注入，也拿不到别的站的数据。
资源上限。给每个站设 CPU 和内存的上限，一个站失控时它自己先慢，而不是拖垮整台机器。
日志分开。每个站的访问日志和错误日志独立。混在一起的话，出问题时根本查不出是哪个站引起的。
更彻底的做法：让访客根本碰不到服务器
上面那些是”怎么把共享做安全”。还有另一个方向：把网站的公开访问部分从服务器上移走。
如果一个网站的页面在两次更新之间是不变的——绝大多数企业网站都是——那它可以提前生成成静态文件，部署到 CDN 网络上。访客拿到的是文件，服务器只在改内容的时候用到。
这样做之后，服务器的负载和攻击面同时大幅下降：没有公开流量打到它，也就没有针对它的公开攻击面。
我们自己的站现在就是这样。服务器还在，但它只是一个内容管理的地方，访客完全接触不到。顺带的好处是快——页面从 CDN 直接发，不需要回源。
这个做法不适合所有网站（有登录、有交易的还是需要动态），但对纯展示型的企业站，它同时解决了性能、安全和资源竞争三个问题。
怎么判断你现在是什么情况
如果你不知道自己的网站在什么样的主机上，这几个方法可以判断：
看价格。每月十几到几十纽币的”无限流量、无限网站”套餐，基本都是共享主机，而且很可能是隔离做得比较松的那种。
问服务商三个问题。每个站是不是独立的系统用户？数据库是不是独立账号？有没有资源上限？答不上来的话，通常答案是没有。
观察规律性变慢。如果你的网站在某些时段固定变慢，而流量并没有增加，那多半是邻居的问题。
共享不是问题，没人管才是
要说清楚的是：共享服务器本身没有错。五十个小网站各自开一台服务器，成本高得离谱，而且大部分资源闲置。
真正决定风险的是有没有人在管：系统更新有没有跟上、插件有没有定期升级、有没有人在看日志、出事的时候多久有人处理。
一台有人维护的共享服务器，比一台没人管的独立服务器安全得多。选主机的时候，”谁来管”这个问题比”是不是独享”重要。
我们自己维护的这台机器，五十个站里出过问题的都是同一类原因——用了很久没更新的东西。所以流程上最重要的一件事不是隔离，是定期更新，以及有人真的在看。
我们托管的项目是分用户隔离、独立数据库、日志分开的，静态化的站根本不在服务器上跑。这些不是加价项，是共享架构下的基本要求——因为出事的时候，损失是所有客户一起承担的。