机房十年：从机柜到云

十年前的夏天，我头一次进机房。两个机柜，四十二台服务器，一台交换机，空调是挂壁式的，坏了要打电话找人来修。那时候我二十四岁，觉得机房是个很神圣的地方，进去要换鞋，说话不敢大声。

今年三月，同一套业务，机房只剩一排柜子，十六台机器，大部分跑的是代理和专线设备。真正的计算在云上，我在办公室点几下鼠标就能开十台。听起来是进步，但中间有几年，我们走得很难看。

这篇按分镜写，四个时间点，每段都标出画面、旁白和当时的判断。不写技术教程，只写十年里那些决定是怎么做出来的，以及哪些决定后来被证明是弯路。

一、2015：两个机柜就够了

1.1 画面

一间三十平米的房间，地面刷了防静电漆，两台五匹空调对着吹，噪音大到要贴着耳朵说话。两个机柜并排，里面塞了四十二台服务器，标签是手写的，有几张已经卷边。

门后挂着一本纸质登记簿，进去要写名字和时间。旁边放着一双塑料拖鞋，尺码只有四十二。

1.2 旁白

那时候业务量小，一天两万次请求，两台应用服务器加一台数据库就能撑住。第二个机柜基本是空的，放了一些备份设备和一台老交换机，我们叫它“杂物柜”。

规划的时候按三年做的：每年增十台服务器，机柜留了一半空间，电力按满配申请。这个规划在头两年成立，到第三年就不成立了，因为业务涨得比预想快，一台机器上跑了六七个应用。

1.3 当时的判断

判断是：自建机房比租用便宜，而且数据在自己手里踏实。这个判断在当时是对的，机柜一年的电费和带宽费用，确实比同等配置的托管便宜不少。

代价是我们没算人力。机房要有人管温湿度、管布线、管备件、管消防，这些事没有一个人专职做，都是运维顺手干。顺手干的意思就是，出问题才想起来。

二、2018：搬进模块化机房

2.1 画面

新机房在另一栋楼的二层，两百平米，二十个机柜排成两排，冷通道封闭，地板下面是走线槽。进门刷卡，人脸识别，登记改成系统里点一下。

搬迁那天来了十二个人，两台货车跑了六趟。每台服务器拔线之前先拍照，编号贴在机箱上，到了新机房按老位置复原。搬完首台开机是下午三点，业务恢复是第二天凌晨一点。

2.2 旁白

搬家的原因不是业务涨了，是那间屋子的电力到顶了。空调、服务器、照明全加起来，超过配电柜的额定容量，夏天一热就要跳闸。有一次跳闸发生在晚上八点，正是订单高峰。

新机房是租的，按机柜付费，电力、空调、消防、门禁都由对方管。我们只需要管机柜里面的东西。签合同的时候，我特意问了三个问题：单柜供电多少、网络怎么进、出问题多久到场。

问这三个问题是因为吃过亏。旧机房的配电是按十年前的标准做的，服务器功率涨了三倍，配电没动。新机房我们按每柜六千瓦签的，实际用了不到一半，但留了余量，后面加机器不用再谈。

2.3 当时的判断

判断是：把基础设施的活交出去，自己只管服务器以上。这次判断带来的变化比想象中大，运维组从“什么都要管”变成“只管系统和应用”，头半年反而更忙，因为要把过去靠人盯的事变成监控项。

搬到模块化机房之后，我们经历了一次连续三个月的稳定期，没有因为环境问题出过故障。那三个月我们把备份和演练补上了，这两件事在旧机房里一直没空做。

三、2021：一半搬到云上

3.1 画面

屏幕上是两张表，左边是机房里的机器清单，右边是云上的实例清单。中间画了一条线，写着“同步中”。清单上有一半的条目被标成绿色，表示已经迁完。

办公桌上摆着两台笔记本，一台开着云控制台，一台连着跳板机。那段时间我一天要在两个界面之间切几十次，切到自己都烦。

3.2 旁白

上云的直接原因是扩容速度。机房扩容要采购、要上架、要布线，快则三周；业务方要求三天内加二十台机器应对活动，我们做不到。头一次因为扩容慢丢了一次活动，损失不算大，但很难解释。

迁移的顺序是先无状态的，再有状态的。前端、图片处理、定时任务先走，数据库留到后面。数据库迁移花了四个月，方案改了三版，核心是双写加比对，不是一键搬迁。

3.3 当时的判断

判断是：混合形态会长期存在，不必追求全部上云。这个判断顶住了不少压力，当时有一种声音是“要么全搬，要么不搬”，我们没听。

留在机房的是核心数据库和专线设备，理由是数据量太大、迁移窗口太长、且业务对延迟敏感。这个决定在两年后被重新评估过一次，结论是仍然成立。

四、2024：机房只剩一排

4.1 画面

机房还是那间两百平米的屋子，二十个机柜空了十六个，柜门开着，里面只剩理线架。剩下四个机柜里，一台核心交换机、两台专线接入设备、一排存储。

墙上的温湿度计还在，指针停在二十六度。登记系统里，上个月的进出记录只有七条。

4.2 旁白

末了一批业务迁走是在二三年底，做完之后我们没退租，留了一年观察。留下来的原因是两个：专线要落地，历史数据要留一份离线副本。

这一年里，机房的使用率不到两成，费用照付。到了续租的时候，算了一笔账：保留四个机柜的钱，和把专线改走别的线路、把冷数据归档的钱，差不太多。所以决定保留，但缩到两个机柜。

4.3 当时的判断

判断是：基础设施的选择不是一次性的，是随业务形态反复调整的。十年前自建是对的，八年前租机柜是对的，五年前上云是对的，现在留一排也是对的。

这四个“对”互相矛盾，但在各自的时点都成立。我后来总结，基础设施决策的寿命大概是三年，超过三年就要重新算一次，不能因为当年算对了就一直沿用。

五、十年里没变的东西

5.1 备份和演练

地方换了四次，备份策略改过七版，唯一没变的是每月一次恢复演练。演练的要求很土：从备份里恢复一个库，恢复到一台临时机器上，跑一遍核心查询，记录耗时。

这件事在机房里做，在云上也做。云上的备份看起来更可靠，实际上更需要演练，因为快照、跨区复制、版本保留这些概念的细节很多，不演练就不知道恢复到底要多久。

有一回演练发现，某个库的备份文件比实际数据小了三分之一。原因是备份脚本漏了一张后来新增的大表，脚本没改，备份一直“成功”。这要是没演练，等到真出事才发现，损失就不止一晚上的数据。

5.2 清单和标签

另一个没变的是清单。十年前是手写标签加一本登记簿，现在是资产表加自动发现，本质是一件事：知道自己有什么，放在哪，谁负责。

资产不准的时候，什么都会出问题：扩容算错容量，故障找不到机器，下线漏掉一台还在跑任务的机器。这十年我们吃过四次亏，每次都和清单不准有关。

现在清单是自动发现的，每天对一次。对不上的条目会进一张待确认表，负责人在三天内认领或者删除。这条规则执行了一年，待确认表稳定在十几条，说明自动发现能兜住八成，剩下两成还得靠人。

常见问题

问：现在还有必要自建机房吗？

答：看业务对延迟和数据的约束。有专线对接、有离线归档、有特殊硬件，自建或租机柜仍然合理。纯 Web 业务、弹性需求大的，云上更省心，前提是把成本和退出方案算清楚。

问：混合形态怎么管，会不会两边都管不好？

答：关键是统一入口。资产、监控、发布、告警四件事，不管资源在哪，都要在同一个界面里看到。我们把两边的机器都注册进同一张资产表，标签一致，报表才能合起来看。

问：上云之后运维的工作变少了吗？

答：事务性工作少了，判断性工作多了。不用再管空调和布线，但要管成本、管权限、管容量规划。人数没减，工作内容换了。

问：机房搬迁要注意什么？

答：先做依赖梳理，再做停机窗口，然后才是搬。每一台机器拔线前拍照、贴编号，到新位置按图复原。搬迁当天不要改配置，任何变更都留到业务恢复之后，否则出问题分不清是搬坏的还是改坏的。