应用环境搭建到底要做哪些事？一台新 Linux 服务器的标准动作

不少老板都经历过这样的场景：新服务器到货，找个人装装系统、装个软件，当天业务就跑起来了。看起来省事，往后一两年里却接连冒出怪事——某天重启之后服务起不来，谁也说不清这台机器上到底装过什么；数据库公网能连上，弱口令撑了半年没出事纯属运气；证书过期了没人发现，客户打开页面一片红叉。

这些都不是"软件没装好"，是环境没搭好。

环境搭建这件事，做得糙的版本和做得细的版本，交付时看上去几乎一样——业务都跑着。差别要在出事那天、续证那天、换人接手那天才显现出来。这篇把我们摩杰斯在日常交付里反复验证过的一套标准动作按顺序过一遍，把一台新服务器从裸机带到"能扛事"，既是给想自己动手的厂里技术当清单，也是给老板一个验收别人干活的尺子。

一、先想清楚这台机器要跑什么

拿到服务器别急着装系统，先在纸上把"这台机器上跑什么"列清楚。

一台典型的业务服务器，通常是三类东西的组合：应用本身（一个 Web 应用、一套进销存、一个官网）；它依赖的运行环境（某种语言运行时、一个数据库、一个 Web 服务入口）；围绕它们的辅助件（定时任务、日志、备份任务）。

列清单这个动作有两个用处。一是决定装什么、不装什么——环境搭建最重要的原则是"少装"：机器上每一个多余的软件，都是一个未来的漏洞来源和排障干扰项。二是决定安全边界：只跑一个内部应用、不对公网开放的机器，和挂着官网加数据库的机器，防火墙和暴露面完全是两套打法。

清单别停在脑子里，落成一张表更管用。一台业务服务器的规划表，五列就够：

列	填什么	后面谁会用
跑什么	应用名称与用途	服务清单、开机自启
依赖什么	运行时、数据库、缓存之类	版本清单、补丁跟踪
占哪个端口	端口号、对外还是仅内网	防火墙清单、反向代理配置
数据放哪	数据目录、日志目录	磁盘分区、备份范围
怎么起	手工命令、系统服务还是容器编排	开机自启、重启演练

这张表在装系统之前是计划，做完之后就是交付文档的骨架——端口列直接变成防火墙清单，数据目录列直接决定磁盘怎么分，起法列决定开机自启怎么配。一份表贯穿到底，比事后回忆"当时怎么弄的"可靠得多。

清单列完，最好再回答一个问题：这台机器坏了，业务停得起多久？这个数决定了后面要配到什么程度——如果是官网停一天无所谓，标准流程就够；如果是生产系统，环境从第一天起就该配上备份和恢复预案，这属于环境搭建的一部分，不是"以后再说"的事。

二、系统层：装完系统先做这几件事

操作系统选型这里不展开，只重复一句结论：别用已经停止维护的老版本系统。新装机型的选择上，我们偏向简洁的发行版：RHEL 系的 Rocky Linux、AlmaLinux，Debian 系的 Ubuntu LTS Server 版，都是成熟稳妥的选择；有条件的团队，我们甚至用 Arch Linux——滚动更新、默认装出来就是最小系统，天然贴合"按需安装"的路数。

安装方式上，我们的原则从来只有一条：最小化安装。 装出来的系统越简化越好——只保留让系统跑起来的必需件，其余一律不装，业务需要什么再按需补什么。图省事勾"全量安装"，等于给机器预装了一堆这辈子用不上的软件包，这些多余的东西每一个都是双重的负担：平时占磁盘占内存，出事时多一片攻击面，打补丁时多一批要跟的更新。系统简化还有一个常被低估的好处：机器上东西少，排障就快。服务列表一屏能看完，哪个进程该在、哪个不该在一眼分明；塞满杂物的机器，光是分清"哪些是自己装的"就要半天。

按需安装不等于随手安装。每装一样东西，记两笔：为什么装（对应哪个业务）、装的什么版本。这两笔就是后面"环境即文档"的原料。

磁盘分区要在装系统那一步就分对。 这一步比很多人以为的重要，因为装完再改要停机、要搬迁数据，成本高得多。几条硬经验：

- 系统盘和数据盘分开。 有条件就挂两块盘：系统、运行时、程序放系统盘，数据库与业务数据放数据盘。将来重装系统、换机器、扩容，数据盘摘下来就还在；混在一块，重装系统就等于连数据一起赌命。 - /var 单独成区。 日志、数据库默认目录、容器镜像都在 /var 底下。它独立成区，日志写爆了顶多这一区满，不会把根分区拖死——根分区满了，机器连正常登录都困难。 - 按三年后算余量，不是按现在。 长得最快的三样是图片附件、日志、数据库备份文件。按"现在够用"分区，一年后就得动刀。 - 能用 LVM 就用。 逻辑卷的价值是后期加盘扩容不停机，虚拟机、云主机上尤其省事。 - swap 按内存配。 十六 G 内存配四到八 G 的 swap，属于"平时用不上、急时能救命"的保险。完全不配，内存打满时进程是被直接杀掉的，不是被换出去的，表现就是服务莫名消失。

分区这一步做对，后面"数据在哪、备份备什么、扩容怎么扩"全都有了明确答案；做错，这三件事每件都要临时找答案。

系统装完，第一波标准动作按顺序做：

时区与时间同步。 把时区改成东八区，开 NTP 时间同步。这一步三十秒的事，但不做的话，日后日志时间对不上、证书校验莫名失败、定时任务在奇怪的小时触发，都是它埋的雷。数据库主从、分布式应用对时间的要求更苛刻。

更新源与系统补丁。 装完先更新一遍。国内机器把源换成近的镜像站，速度差十倍。之后保持"安全更新及时打、大版本升级看清楚再动"的节奏。

普通用户加 sudo。 建一个日常用的普通账号，需要管理员权限时用 sudo 提权，别拿 root 当日常账号。这不是姿势问题：root 直接操作，一条手误就是不可挽回的，sudo 至少留了一层"要确认"的缓冲，而且每条提权命令都留了痕。

口令策略：机器生成的随机密码，不用人编的。 这台机器上的每一个口令——root、sudo 账号、数据库、应用后台、后续各类服务——统一用随机密码生成器生成，长度十二位起步，大写字母、小写字母、数字、特殊字符四类至少各含一种。人编的密码再自以为冷门，套路都在爆破字典里；机器生成的才真正无规律。生成之后立即归位：进密码管理器或打印进密码信封，绝不出现在聊天记录、表格和便签里。多台机器各用各的，不图省事复用——一台泄露，不能连坐全部。这套口令纪律是我们摩杰斯每接手一台机器都要重申的底线，看着繁琐，出事时就是它把损失锁在了一台机器上。

主机名与说明。 给机器起个能认出来的主机名，顺手在说明文件里写一句这台机器是干嘛的。机器多了以后，"这是哪台、跑的什么"靠猜是灾难。

装完做一次减法自查。 最小化安装之后，仍然会有一批用不上的服务默认在跑（打印、蓝牙、本地邮件传输代理之类）。装完顺手列一遍当前跑着的服务，把与业务无关的停掉、禁用开机自启。判断标准就一句话：这个服务停了，业务会受影响吗？ 不会，就关。十分钟的活，换回来的是更短的服务清单和更小的攻击面——而且清单越短，下次出事时排查越快。

几条基础参数顺手确认。 文件句柄上限这类默认值"够用但不理想"：业务并发一上来，服务就报"打开的文件太多"，重启能好一会儿，然后复发。环境阶段把它在系统层和运行用户层都确认一遍，比出事时再翻配置省事。至于内核网络参数、内存回收策略这些，业务量不大时不必深调，动着容易，调回去难。

还有一条要单独讲：服务器上不装图形界面。 桌面环境动辄多装几百个包，吃内存、常驻进程、漏洞面扩大，而服务器管理真正需要的东西——命令行、文件传输、远程执行——SSH 一条通道全覆盖。装机时选最小编不带任何桌面，管理全程走终端。极个别场合业务确实要求图形服务（某些特定软件只给图形配置界面），也只装 XFCE4 这类轻量桌面应应付付，绝不上完整的 GNOME 或 KDE——那属于把办公电脑的配置错误地搬到了服务器上。

三、安全基线：环境搭建里不能省的部分

系统层收拾干净，接下来是安全基线。详细的安全加固在《Linux 服务器安全加固与入侵应急》里专门展开过，这里只说环境搭建阶段就必须做的四件：

SSH 收口。 真正的门禁是两条：禁用 root 密码登录、改用密钥，再装上防爆破工具（fail2ban 这类）连续输错自动拉黑。公网上的机器，SSH 端口每天被扫的次数超乎想象，弱口令加密码登录等于把门钥匙放在门口垫子下面。至于"把端口从默认的 22 挪开"，基本没有作用——我们做应急处理时见过端口早就改掉的机器照样被扫出来——现在的端口扫描工具几秒钟就能把全部 65535 个端口跑完，藏端口藏不住；它顶多让日志里的扫描噪音少一点，别把安全指望放在这上面。

防火墙从"全关"起步，再按需开。 这是硬规矩：新机器的防火墙默认状态是全部端口关闭，一个口都不开，然后业务要哪个端口，再开哪个——而不是反过来"默认全开再逐个堵"。方向反了，堵漏永远追不上暴露面。每开一个口，都在端口清单上记三笔：开的什么口、给哪个服务用、能不能限源。开放端口执行最小化原则：能不开的坚决不开；只对本机用的服务绝不对外开；只对内网用的服务就只对内网网段开，能限定来源 IP 的就不全网放行。特别强调一条：数据库端口绝不对公网开放。数据库被拖库的案例里，相当一部分根本不是被"黑"进去的，是数据库端口直接裸在公网上、密码还弱。

日志能留、能查。 确认系统日志和服务日志都在正常落盘，配上轮转（logrotate），别让一个日志文件把磁盘写满。日志是出事后唯一能还原现场的东西。

账号分账，别用一个账号打通关。 环境里至少有三层账号：系统层（普通用户加 sudo）、数据库层（业务专用账号、权限最小）、应用层（管理员与操作员分开）。用一个万能账号贯穿三层最省事，也最经不起事故——操作员被钓鱼骗走密码，等于把应用、数据库、系统一起交了出去。分账的代价是多记几个口令，而这件事正好被上一条解决：口令交给生成器，人不负责记。顺带一句：账号该禁用就禁用，别留"方便以后用"的僵尸账号，离职、换人、临时外包留下的账号，是审计里最先被点名的东西。

留下能查的痕迹。 环境搭建阶段不要求上完整审计体系，但两样东西必须有：命令历史带时间戳（否则事后翻历史只有命令、没有时间，等于没有），sudo 操作有日志。真出事时，"谁在什么时候动过什么"是唯一能重建过程的东西。

装完就加固，不是"跑起来再说"。 很多环境是"先用起来，安全以后补"，这个"以后"通常永远不会来。加固不必一次做满，但上面这几条是底线，属于环境搭建当日的工作量。

四、运行环境：按清单装，别顺手装

到了装应用运行环境的环节，核心纪律还是清单化：需要 PHP 就装 PHP，需要数据库就装数据库，每装一样都在清单上记一笔版本号。将来排查"装了个新版本跑不起来"的问题，这份版本清单能省一半时间。

几条实践上的要点：

先定目录约定，再往里装东西。 建议统一成一套固定结构：应用放在 /opt 下一个独立目录，里面分几样固定的东西——编排文件、环境变量文件、数据目录、备份目录、运维脚本目录。整齐只是附带的好处，真正值钱的是三件事：备份脚本知道该备哪几个目录，迁移时知道该拷什么，半年后接手的人打开目录就知道东西在哪。反过来，压缩包解压在哪算哪、文件随手扔在家目录、备份和数据混在一起，是后面所有混乱的源头。

Web 服务统一入口。 用 Nginx 之类做统一入口，把不同应用挂在不同端口或路径后面，证书也集中在这里配。所有服务各自裸奔在不同端口上的做法，早晚会乱。

数据库装完第一件事是收口。 改掉默认或空口令；只监听本机或内网地址，不监听公网；业务账号按最小权限给——查询的账号不给删表权限。这几步做完，数据库层面的基本盘就稳了。

运行环境，我们非常推荐用 Docker 打包，特别是 Docker Compose。 这件事的收益比太高：一份 compose 文件把应用、依赖、端口、数据卷、环境变量全部写清楚，起服务一条命令；换机器迁移，本质上是"拷走 compose 文件和数据卷、在新机器上重新拉起来"；升级、回退、重建环境，都是分钟级、可重复的动作。更妙的是，"环境即文档"这件事在 compose 里是自动实现的——文件本身就是这台机器跑着什么的完整答案，不用另写。几条使用纪律：镜像版本写死具体 tag、别用 latest（否则半年后重建出来的环境已经不是当初那个）；数据一律落在宿主机卷或目录上，容器随时可扔、数据不能陪葬；compose 文件和普通配置一样进备份、进交付文档。唯一的提醒是别混用：一旦决定用容器，就不要在宿主机上再散装另一套服务，两种体系混在一台机器上，最后谁也说不清谁管什么。

环境即文档。 把安装步骤写成脚本或至少写成笔记。第二次照着搭一台一样的机器时（迁移、灾备、扩容都用得上），你会感谢这份文档。手上的动作留不下来，环境就永远只存在这一台机器上，它坏了就是真的坏了。

端口和访问路径一起规划。 一台机器上装到第三个应用，端口几乎必然撞车。装之前把端口分配写进开头那张规划表：谁占哪个口、对外还是仅内网、经不经反向代理。推荐的结构是对外只暴露 80 和 443，其余全部收在内网或本机——证书只在一处配，防护只在一处做，加一个应用只是加一段转发规则，不用再开一个新端口。反过来，每个应用各开一个公网端口的做法，端口清单会越来越长，防火墙规则会越来越难讲清楚。

一套典型应用的落地顺序。 以"一个 Web 应用配一个数据库"为例，按依赖顺序装，比想到哪做到哪省事得多：系统与网络（时区、源、主机名）→ 数据盘挂载与目录建好 → 数据库（建库、建专用账号、确认只监听本机）→ 应用运行环境（版本写死）→ 应用本身（先手工跑通）→ 反向代理与证书（对外这一步最后做）→ 开机自启与重启验证。顺序背后是一条简单的逻辑：被依赖的先装，对外的最后开。照着这个顺序走，任何一步出问题，排查范围永远在刚动过的那一层；顺序乱了，问题出在哪一层都说不清。

五、域名、证书与上线前检查

对有 Web 业务的机器，域名和证书是环境的一部分，也要按规矩来：

证书免费付费按需选择，关键是自动续期加结果通知。 HTTPS 证书可以用 acme 系列工具（如 certbot）申请免费证书，也可以买商业证书——免费还是付费，按业务需要选就行，这不是重点。重点是别用手动申请然后"到期再说"：部署时直接把自动更新脚本配好，并让脚本把每次执行的结果邮件发送到指定邮箱——续没续成、什么时候续的，邮件见分晓。这一步邮件通知的价值在于消灭静默失败：续期脚本悄悄坏了三个月，没有邮件通知就没人知道，直到证书过期业务打不开；有了结果邮件，第一次失败当天就有人看见。配完之后手动触发一次，验证流程和邮件都真能跑通。证书过期导致业务打不开，是运维事故里最冤的一种，纯属流程问题。

上线前的检查单过一遍。 环境搭完不等于能上线，用外部视角验一遍：从公网扫描一下开放的端口，和清单对得上吗？所有服务配了开机自启吗？日志在正常滚动吗？定时任务列出来看过一遍吗？最有分量的一项：把机器重启一次。 重启能起来的环境才是真正的环境——不少"运行了两年"的机器，重启之后一堆服务起不来，因为某次手改的配置没落盘、某个服务从来不是自启的。重启演练放在上线前，代价最小。

这条检查单源自我们摩杰斯环境搭建项目的交付验收单，建议打印出来逐项打勾，别凭印象过：

检查项	通过标准
端口暴露	公网扫描结果与端口清单完全一致，没有一个多余端口
开机自启	业务服务全部设为自启，重启后自动恢复
完整重启	整机重启一次，业务可用、日志正常、无报错刷屏
数据落盘	数据库与业务数据在数据盘，重启后数据完好
时间同步	系统时间准确，同步服务在正常运行
证书	自动续期配好，手动触发验证过，结果邮件能收到
备份	备份任务至少成功跑过一次，恢复步骤验证过
告警	磁盘水位、关键进程有最低限度告警，且真能送到人
文档	一页环境说明写完，端口清单与口令存放位置齐全

这张表的价值，是把"我觉得搭好了"换成"逐条验过了"。自己搭的环境最缺的恰恰是这个外部视角——因为搭的人知道每一步的意图，所以会下意识地跳过那些"显然没问题"的项，而事故往往就藏在显然里。

最低限度的监控与告警。 不要求上监控平台，但磁盘水位、内存占用、关键进程存活这三样得有最低限度的看护——哪怕先是一条定时脚本，磁盘超过八成、关键进程不在了，能发条通知到人。磁盘写满拖垮数据库、进程静默挂掉没人发现，是事后回看最"不值得"的两类事故：发现它们的门槛很低，前提是有人被叫到了。

备份计划跟环境一起搭。 这一步经常被归为"以后优化"，其实它属于环境搭建的收尾：环境搭好那天，备份任务、备份去向、恢复步骤就该一并就位。备份体系怎么做，之前那篇《服务器备份到底该怎么做？从"备了"到"能恢复"差多远》专门展开过，照着配就行。

六、交付与交接：让机器"可以被接手"

环境搭建的最后一步，经常被跳过，但它决定这套环境是真资产还是黑盒：交付一份一页纸的环境说明。

内容不复杂：这台机器跑着哪些服务、各自什么版本、配置文件在哪；root、数据库、应用后台这些口令是机器生成的十二位以上随机密码，统一放在哪里（密码信封或密码管理器，不是聊天记录）；服务怎么重启、常见问题找哪个日志；防火墙开了哪些端口、各自给什么服务用、为什么。半夜出事的时候，接手的人靠这一页纸就能干活，而不是从"先搞清楚这台机器上有什么"开始。

顺带说个判断标准：一台说不清"上面有什么"的服务器，无论跑着多重要的业务，都是风险敞口。 环境说明不是给外人看的文档，是给自己留的退路——半年后连当初搭环境的人自己都忘了细节，这页纸就是唯一可靠的记忆。

我们交接一台机器时，要交的是四样东西，不是一句"装好了"。 一是那页环境说明；二是口令的存放位置（信封在哪、密码管理器谁有权限），注意是位置而不是口令本身；三是编排文件或安装脚本这类能重建环境的东西；四是端口清单和变更记录。这四样在手上，换谁来接手都能干活；只有一句"装好了"，接手的人第一件事就是从零摸底。

再补一条容易被忽略的：留一份变更记录。 不用复杂，一个文本文件就够——哪天、改了什么、为什么改、改之前是什么样。环境出问题，九成和最近某次改动有关；有这份记录，排查从"翻遍所有配置文件"变成"先看最后一次动的是哪"。同理，改任何配置前把原件复制一份带日期的备份，是最低成本的后悔药。

七、三种常见场景，重点完全不一样

同一套标准动作，落到不同机器上，侧重其实不同。按厂里最常见的三类说：

场景	典型配置	搭建重点	可以省的地方
内网小工具	一台机器、一个应用、一个数据库，只对内网开放	数据落盘、备份、重启验证	证书可以缓一步（内网先走 HTTP），对外防护可简化
官网或内容站	一台机器，Web 入口加数据库，对公网开放	证书自动续期、端口最小化、防爆破、静态资源缓存	数据库只监听本机即可，不必对外
内网生产系统	一台或两台，业务停不得	备份与恢复演练、监控告警、快速重建预案	花哨的性能优化一样都不要

三条线的判断依据还是那个问题：这台机器停一天，损失有多大？ 内网小工具停一天，大家骂两句就过去了；生产系统停一天，可能是一批货交不出去、一个客户丢掉了。搭建深度不一样，钱也就不该花在同一个地方——给内网小工具配双机热备是浪费，给生产线上的系统只留一句"出问题找我"则是赌博。

八、装完头一个月常冒出来的几个毛病

下面这几件事不是理论推演，是我们接手的机器里环境搭完头一个月最常遇到的。提前知道，能省掉不少半夜翻日志的时间：

重启之后服务没起来。 八成是两种情况：服务压根没设开机自启（当初是手工敲命令跑起来的）；或者配置文件改完没生效，重启时加载的还是旧的。所以交付前必须真重启一次——"我看它跑得好好的"永远替代不了重启。

磁盘莫名其妙满了。 来源通常是三处：日志没配轮转、数据库备份文件堆在同一块盘、容器镜像和旧层没清理。先按目录大小排一遍看谁在长，别急着删文件——删之前先确认这个文件是干什么用的，删错一次比磁盘满更麻烦。

时间不对。 表现是日志时间错乱、证书校验失败、定时任务在古怪的时刻触发。多数是时区没设或时间同步服务没起来，两分钟能修好；但发现得晚，日志的因果顺序就乱了，出事时连"先发生什么"都排不出来。

端口冲突，新服务起不来。 一台机器装到第三个应用时几乎必然遇到。规划表里记过端口就不会撞；真撞了先查是谁占着，别顺手把新服务的端口一改了事——改完可能和反向代理里那段转发规则对不上，表现出来就是"服务在跑但页面打不开"。

证书续期悄悄失败。 续期脚本天天在跑，但失败了没人知道，直到某天页面报证书过期。这正是要求"续期结果发邮件"的全部理由：把"到底续上没有"变成每天能看见的一行字，而不是等到过期那天才被客户告知。

九、几个常见的搭建误区

按踩坑频率排一下：

误区一：root 直接跑业务。 手误没有缓冲，进程被入侵即拿到最高权限。建普通用户、最小权限，十分钟的事。

误区二：数据库端口对公网开放。 前面说过，不再重复，这是致命项。

误区三：证书手动申请、装完不管。 续期必须自动化，且验证过一次。

误区四：所有东西挤一台机器还不做隔离。 公司小、预算紧，一台机器跑几个应用可以理解，但至少把 Web 入口、应用、数据库的权限边界划开，一个应用被攻破不等于全家沦陷。

误区五：装完不记录版本和步骤。 环境只存在于那台机器和那个人的脑子里，机器一坏、人一走，全部重来。

误区六：环境搭完才想备份，或者根本不想。 备份是环境的组成部分，不是增值服务。

误区七：一次改太多。 调整环境一次动一样，改前记下现状，坏了能退回去。"同时改了五处，不知道哪处弄坏的"是排障界最贵的悬案。

误区八：装个桌面图省事。 以为有图形界面更好管，实际是把办公电脑的包袱搬到服务器上：多几百个包、多一片漏洞面、多一批要跟的更新，而管理效率并没有提高——服务器上的活，命令行始终更快更准。保持无桌面的精简系统，才是真正省事的路线。

误区九：数据和系统混在一处。 单盘不分区最省事，代价是系统出问题要重装时，数据也跟着赌一把。至少把 /var 分出来、有条件再加一块数据盘，成本几乎为零，救的却可能是全部业务数据。

误区十：直接改线上配置，不留退路。 改之前复制一份带日期的原件，改完不对能立刻换回去——三十秒的动作，能省掉一整晚"该回滚到哪一版"的纠结。线上直接编辑又没备份，等于把每一次调整都做成不可逆的。

十、从裸机到交付的完整顺序（清单版）

把前面各节的动作按顺序串一遍，这就是一张可以直接照着执行的装机清单：

1. 规划：列清这台机器要跑的应用、依赖与辅助件，落成五列规划表（跑什么、依赖什么、占哪个端口、数据放哪、怎么起）；明确"停得起多久"，决定备份与恢复配置的深度。 2. 系统：选简洁的发行版（RHEL 系 Rocky/Alma、Debian 系 Ubuntu Server，有条件可 Arch），最小化安装，不带桌面；磁盘按数据盘与 /var 分区、留足余量；装完改时区、开时间同步、换近源、更新一遍、做一次减法自查。 3. 账号：建普通用户加 sudo；全部口令用生成器出十二位以上四类字符随机密码，归入密码信封，各机器不复用；系统、数据库、应用三层账号分开，不留僵尸账号。 4. 安全基线：SSH 密钥登录禁 root 密码、装防爆破（改端口仅降噪不指望防身）；防火墙从全关起步，按需开、最小化开、记录每个口；日志确认落盘并配轮转；命令历史带时间戳、sudo 留痕。 5. 运行环境：定好目录约定（编排文件、环境变量、数据、备份、脚本各归其位）；用 Docker Compose 打包（版本写死、数据落宿主机卷、compose 入备份）；数据库收口；Web 统一入口、对外只留 80 与 443。 6. 对外服务：域名解析、HTTPS 证书（免费或付费按需选）、自动续期脚本配好执行结果邮件通知、手动触发验证一遍。 7. 上线检查：公网端口扫描对清单、开机自启全配、定时任务过目、磁盘内存进程有最低限度告警、完整重启一次验证。 8. 备份就位：备份任务、去向、恢复步骤随环境当天交付，不留"以后再说"。 9. 交付：一页环境说明落笔——服务清单、版本、配置位置、密码存放、端口清单、重启方法。

九个步骤走完，这台机器才算从"能跑"变成了"能扛"。中途每一步多花的十分钟，都是将来某个深夜少熬的一小时。

十一、交给专业的人，也有一页验收纸

环境搭建是可以自己动手的活，照着这篇的顺序做，一台普通业务服务器一两天能收拾利索。但如果机器上跑的是停不得的生产系统，或者厂里实在没人肯碰命令行，找专业的人一次性把环境搭好、把文档留下，是笔划算的买卖——环境搭建是典型的一次性短期项目：今天搭好、文档交付、当场验收，之后的日子机器怎么维护是您自己的事。

什么时候该找外面的人，判断起来其实就三条：机器停了有实际的钱在损失；厂里只有一个人会弄、而这个人还要休假；历史环境已经乱到说不清上面有什么，重建比整改更省。三条里中一条就值得考虑，中两条基本不用犹豫。

我们摩杰斯做 Linux 服务，环境搭建类项目的交付物通常包括：按清单装好的运行环境、收口后的安全基线、能自动续期的证书、随环境就位的备份任务，以及最重要的一页环境说明。验收也简单：当场重启一次、当场演练一次备份恢复、当场照着文档核一遍清单——三样都过，这个环境才算真的交付了。

机器终归是拿来跑业务的，但业务跑得稳不稳，一半的底子是在环境搭建那两天打下的。新服务器到手，别只装个软件就完事——把该做的标准动作做全，往后每一次半夜的警报，概率都会小很多。

把一台裸机变成一个"能扛事"的环境，拢共九步：想清楚要跑什么、系统最小化收好底、账号口令交给生成器、安全基线从全关起步、运行环境照清单、证书管续期、上线前重启演练、备份随环境就位、交付留下一页纸。每一步都不难，难的是件件都做、事事留痕。

服务器不会因为业务跑起来了就自动变安全，环境也不会随着时间自动变规矩。系统装得越简、口令越是机器出的、端口开得越少，将来的深夜警报就越少——第一次就按标准来，是成本最低的时刻。

想补齐周边的知识拼图：为什么生产系统值得建在 Linux 上，看《系统为什么从第一天就跑在 Linux 上》；半夜宕机怎么分钟级拉起，看《产线系统半夜宕机怎么分钟级拉起》；环境之上的安全层怎么加固，看《Linux 服务器安全加固与入侵应急》；环境的保险怎么配，看《服务器备份到底该怎么做？从"备了"到"能恢复"差多远》。应用环境搭建这类一次性短期项目的服务范围，见摩杰斯 Linux 服务器服务介绍。

>