最近接了个内部系统的部署任务要从零开始为它搭一套跑在 Linux 上的运行环境。说实话这种活儿看着简单真正做起来全是细节磁盘怎么分、服务怎么拉、权限怎么控、出了问题怎么查每一步都能踩出坑来。这篇文章就把我这次从规划到落地的完整过程梳理一遍重点说说那些常规文档里不会写的东西希望能给正在做类似事情的你一点参考。这套环境跑的是一个面向内部团队使用的文档协作服务没有公网访问需求用户量不大但对稳定性、备份恢复和权限隔离有一定要求。整体思路是用一台物理服务器做基础承载虚拟化出两个独立实例一个跑应用一个跑数据库和其他辅助服务除此之外再单独留一台备份机做定时快照和异地归档。1. 内容整体设计与思路拆解1.1 需求分析这个环境到底要解决什么问题动手之前把需求捋清楚很重要。表面上看任务就是“装个系统、装个服务”但实际要满足的约束条件包括这几条服务要能长时间稳定运行不能动不动就挂。数据要可靠数据库和应用配置都要有可恢复的手段。权限要清晰不同职责的人不能互相干扰。要有基本的监控能力出了问题至少能快速定位。在内部环境里还有一个需求往往容易被忽略就是可维护性。以后接手的同事不一定了解当时怎么装的所以安装步骤、配置说明、备份策略这些都要有据可查。1.2 技术选型为什么这么选系统层面选了主流的 Linux 发行版理由也很简单生态成熟、资料多、遇到问题容易搜到答案而且它对硬件的兼容性很省心。另一个重要原因是它自带的包管理工具能直接装齐后续要用的软件不用到处找依赖。虚拟化方案用的是轻量级的容器方案而不是传统虚拟机。一个实例放 Nginx 和应用程序另一个实例放数据库和缓存服务。这样拆的好处是应用和数据隔离升级应用不影响数据库排查问题的时候边界也更清楚。目录结构上遵循了数据与程序分离的原则。程序装在系统盘数据挂在独立的数据盘这样以后系统盘出问题重装系统数据盘一挂回来就完事。1.3 整体架构规划一张图看懂各部件关系这套环境的逻辑结构是这样组织的物理服务器提供 CPU、内存、磁盘等基础资源。容器实例 A运行 Nginx 反向代理和应用程序本体。容器实例 B运行 PostgreSQL 数据库和 Redis 缓存。备份服务器接收定时备份任务存放数据快照和配置归档。网络层面所有实例都在同一个内部网段里只有 Nginx 监听了服务端口数据库和缓存服务只在内网监听不向外部暴露。2. 核心细节解析与实操要点2.1 磁盘分区给未来留好余量磁盘分区是最容易被忽略的环节但恰恰是后面最让人头疼的问题来源之一。我的做法是系统分区和数据分区独立数据分区单独挂载到一个专门的目录以后扩容也不用动系统盘。分区的时候要考虑到日志增长速度。很多服务默认会把日志写到系统盘时间长了系统盘容易满。我在规划时就留了一个独立的日志分区并且配置了日志轮转限制单个日志文件大小和保留份数避免日志把磁盘塞满。另外分区表格式选择上新机器建议直接用 GPT支持更大的容量也方便以后加盘。老机器如果还在用 MBR超过 2TB 的盘会识别不了这点要注意。2.2 用户与权限管理少用 root多用普通用户日常运维不要直接拿 root 操作这是我的一个执念。root 权限太大一个误操作可能把整个系统搞挂。我习惯的做法是创建一个具有 sudo 权限的普通用户日常登录和管理都用它。需要提权的时候单独执行 sudo 命令日志里还能记录操作痕迹。应用程序自身用独立的低权限账号运行不给它多余的权限。数据库这边也一样创建了专门的应用账号只授权了应用数据库的增删改查权限没有授予全局管理权限。这样就算应用被攻破影响面也是可控的。2.3 网络与防火墙配置能做多小就做多小网络配置这块的核心思想就是“默认拒绝”。防火墙默认丢弃所有入站流量然后按需放行。我这次实际开放的端口只有两个一个是 SSH 管理端口另一个是 Nginx 的服务端口。其他端口一律不开。这里有个容易踩的坑很多人改了防火墙规则之后不重启验证结果服务重启后连不上。我每次改完防火墙都会主动重载配置再用外部视角扫描一下端口确认实际生效。2.4 系统初始化与安全加固基础工作要扎实装完系统第一件事我通常会做几项基础加固更新系统补丁把已知安全漏洞堵上。修改 SSH 配置禁用 root 直接登录允许密钥认证登录。设置系统级的资源限制防止单个进程把内存或 CPU 耗尽。配置时间同步保证系统时间和真实时间一致。时间同步这一点特别容易被忽视。如果系统时间漂移严重日志的时间戳会对不上排查问题时会非常痛苦。3. 实操过程与核心环节实现3.1 系统安装与基础配置安装系统时我选了最小化安装不带图形界面。服务器上装图形界面纯属浪费资源而且增加被攻击的面。安装过程中的关键是手动规划分区这里把我的分区方案列出来供参考挂载点大小文件系统用途/boot1GBext4引导分区/50GBext4系统根分区/data剩余全部xfs数据分区swap8GBswap虚拟内存根分区给 50GB 看起来不小但系统更新、软件安装、临时文件都会往这里写留够了余量。装完系统之后我顺手做了这几件事配置了主机名按“服务名-角色名”的规则命名方便辨认。设置了固定 IP因为 DHCP 分配的地址重启后可能变对服务来说这是致命的。关闭了不需要的系统服务减少资源占用和攻击面。固定 IP 这块有个小技巧配置完之后一定要重启网络服务验证一下有些配置错误要到重启才暴露出来。3.2 容器实例创建与服务部署容器实例的创建过程比较流程化但有几个参数值得单独说明网络模式选择了桥接模式让容器可以直接使用物理网络的 IP 段方便其他设备直接访问。数据目录做了宿主机目录挂载容器可以随时重建但数据都留在宿主机上。容器设置了自动重启策略物理机重启之后容器能自己拉起来不用人工干预。应用部署这块分了三个层次第一层是 Nginx负责接收外部请求并转发给应用。我给它配置了 gzip 压缩静态文件直接由它处理动态请求才转给后端有效减轻应用的压力。第二层是应用本体用的是现成的部署包解压之后改配置就能跑。配置里指定了数据库连接地址、缓存地址、日志路径这些关键参数。第三层是 PostgreSQL 和 Redis数据库负责存结构化数据Redis 负责缓存热点数据。Redis 我特意开了持久化开关虽然性能会有一点点损耗但换来的是数据安全值。3.3 数据备份与恢复方案备份这件事做没做、做得对不对只有到灾难发生那天才知道。我的备份方案分三个维度备份类型频率保留策略存放位置数据库全量备份每天一次保留7天本地备份目录数据库增量备份每6小时一次保留48小时本地备份目录应用配置备份每次变更后保留最近10份备份服务器备份脚本是手写的脚本核心逻辑不复杂先导出数据库再打包配置目录然后传到备份服务器最后清理过期备份。脚本里设置了完整的日志记录每次备份成功或失败都能在日志里看到。这里我要强调一下恢复演练的重要性。备份不是“做了就行”还得定期验证备份数据能不能恢复。我这次特意做了一次全流程的恢复演练从一个干净环境开始用最近的备份把整个服务拉起来确认数据可用。这一步能发现很多平时注意不到的问题比如备份文件损坏、脚本执行权限不对、恢复步骤缺东少西。3.4 监控与日志配置监控系统不一定要用很重的东西有时候简单的方案反而更可靠。我先在系统层面配置了基础监控包括磁盘使用率超过 80% 时报警。内存使用率超过 90% 时报警。系统负载超过阈值时报警。关键服务进程掉线时报警。应用层面我给日志配置了按天切割和定期清理。应用本身产生的日志会写到独立目录Nginx 的访问日志和错误日志也分开存放排查问题的时候能直接定位到对应类型的日志。有一个细节值得提SSH 登录日志一定要保留足够长时间。如果服务器出了安全问题这些日志是追踪入侵痕迹最重要的线索。4. 常见问题与排查技巧实录4.1 网络连接问题排查部署过程中遇到最典型的一个问题应用已经启动了Nginx 也配置好了但从外面访问就是不通。这个时候我按顺序做了这些排查先看 Nginx 进程是否正常监听端口确认服务本身没挂再看防火墙规则确认端口确实放行了然后看安全策略和网络组策略是不是把流量拦住了最后检查路由和交换机的配置看链路是否通。最后定位到的问题挺有意思防火墙规则加了端口放行但规则顺序不对前面的拒绝规则把后面的放行规则盖住了。防火墙的规则是自上而下匹配的一条匹配就结束顺序不对等于白放行。这里分享一个经验放行规则一定要放在拒绝规则之前。4.2 磁盘空间告警处理运行了两周之后收到磁盘告警查了一下发现是日志文件增长太快。应用的一个调试开关没有关导致日志里刷了大量调试信息几天就把磁盘空间吃掉了。处理步骤是先关闭调试开关然后压缩并归档旧的日志文件释放出一部分空间再调整日志轮转策略把保留份数从 7 份减到 3 份同时限制每个日志文件的大小。这个问题引出一个教训新部署的系统前面两周要重点盯一下日志大小和磁盘使用率很多问题都是在这段时间暴露出来的。4.3 服务启动失败的排查有次重启系统之后数据库容器一直起不来。排查过程是这样的先看容器状态发现重启了好几次都失败再看容器日志报错是数据目录权限不对检查数据目录权限发现所有者不对文件属主和容器内运行的用户不一致。原因也简单我之前手动挂载数据目录时设了错误的属主。解决方法是把数据目录的属主改成容器内运行用户对应的 UID再重启容器就好了。这个案例想说明的是使用数据目录挂载时权限匹配是绕过不过去的坎。容器内用户的 UID 和宿主机目录的属主要保持一致否则就会报各种奇怪的权限错误。4.4 性能调优备忘应用跑起来之后发现高峰期响应偏慢。我用系统自带的监控工具抓了一下发现 CPU 没满、内存够用但磁盘 IO 等待很高。进一步排查发现问题出在 PostgreSQL 的配置上默认参数是按小机器调的连接数和缓存都偏小。调整思路是根据实际内存大小重新分配数据库缓存增加了连接数上限优化了查询的排序和哈希内存。调整之后响应速度明显改善。这里有个小心得很多数据库默认配置都不是为实际业务量调的部署完一定要根据机器配置和业务特点做一轮数据库配置调优不要直接拿默认参数上线。5. 一些补充的实操心得这条路上踩了挺多坑最后挑几个比较通用的经验分享出来。第一一个部署文档要随身记。不管项目多简单该记的东西一定要记装了什么、改了哪个配置、执行了什么命令、是为了解决什么问题。这个记录刚开始可能觉得麻烦等过两个月回头看会感谢当时的自己。第二变更操作留出回滚余地。每次改配置之前先备份原来的文件每次升级软件之前先确认回滚方案。宁可多花五分钟做备份也不要因为省事把自己逼到没有退路。第三自动化的脚本要小步快跑。手写脚本的时候先做最简单版本跑通了再叠加功能。一个大而全的脚本如果一开始就写得很复杂出了 bug 反而不好排查。第四安全问题真的不能只看运气。基础加固没做好的话运气好也可能跑一年没问题但运气来了可能就是一场灾难。该更新的补丁别拖该关的端口别留这些基础工作永远是值得的。最后再分享一个小技巧系统初始化的时候把时区、语言、时间同步、主机名这些基础项一次配好后面能省很多麻烦。人都是嫌麻烦的但麻烦一次和麻烦十次选哪个账谁都会算。