企业官网建设流程全解析

简介：这份文档资料面向缺乏服务器技术背景的中小企业管理者与运维入门人员，围绕「公司内部服务器搭建」与「企业服务器搭建方案」两大主题，解答服务器类型繁多时如何选型、小公司是否需要自购服务器等常见困惑。内容结合小型Web/APP应用、企业官网、海量图片视频流媒体等典型场景，给出云服务器、GPU云服务器、FPGA云服务器及黑石物理服务器CPM的适用建议，并延伸至深度学习训练平台搭建、图片视频编解码渲染、直播弹幕、MMORPG游戏与政企高安全场景的选型思路。资源包共1个docx文件，约801KB，正文共6页，结构紧凑、便于通读。目前已有1864人学习下载，适合希望快速建立服务器选型认知、对照自身业务场景做决策的读者参考。

1. 公司内部服务器搭建：从一台裸机到能扛住业务的内网底座

很多团队第一次搭公司内部服务器，都是被现实逼出来的：测试环境要连外网、代码仓库托管在第三方、文件共享靠微信传来传去、数据库被开发随手装在自己电脑上。等到某天断网、某个人离职、某块硬盘挂了，才发现整套业务居然悬在几台个人电脑上。所谓公司内部服务器搭建，本质就是把散落在个人设备上的关键服务，收敛到一台（或一组）可控、可备份、可远程访问的机器上，让它成为团队的内网底座。

这件事听起来像运维的活，但真正落地时，往往是团队里最懂技术的那个人先顶上。它适合 5 到 50 人的中小团队，也适合大公司里需要独立隔离环境的小组。企业服务器搭建方案的核心不是买多贵的硬件，而是想清楚三件事：这台机器要跑哪些服务、这些服务之间怎么隔离、出问题时怎么在半小时内恢复。把这三件事想明白，一台普通塔式服务器甚至一台高配工作站，就能撑起整个团队的日常研发。下面按选型、系统、服务、安全、避坑的顺序，把整套方案拆开讲。

2. 企业服务器搭建方案：硬件选型与系统安装的取舍

2.1 先定服务清单，再反推硬件配置

企业服务器搭建方案最容易翻车的地方，是先买机器再想用途。我一般会先列一张服务清单，把未来一年内可能跑的东西写全，再按资源类型归类。CPU 密集型（编译、CI、数据库）和内存密集型（虚拟机、容器、缓存）对硬件的要求完全不同，混在一起买容易花冤枉钱。

这张表不是让你一次买齐，而是帮你判断瓶颈在哪。中小团队最常见的错误是磁盘用机械盘跑数据库，结果查询慢到怀疑人生。如果预算有限，优先把钱花在 SSD 和内存上，CPU 反而可以妥协。另外，服务器虚拟化技术现在很成熟，一台物理机跑 Proxmox 或 KVM，把不同服务拆进独立虚拟机，既隔离了故障，又方便快照回滚，比全部塞在宿主机上稳得多。

2.2 系统安装：分区、时区与网络三件套

系统选型上，企业内部服务器主流是 Ubuntu Server LTS 和 CentOS 系（现在更多转向 Rocky Linux 或 AlmaLinux）。如果团队没有强绑定某个发行版，我建议用 Ubuntu Server LTS，软件源新、文档多、社区活跃。安装时有三件事必须一次做对，否则后期改起来很痛苦。

第一是分区。不要用默认的 LVM 全盘方案，手动划分出/、/var、/home和 swap。/var单独分区是因为日志和数据库默认写在这里，一旦爆盘不会拖垮根分区。第二是时区，服务器时区统一设为Asia/Shanghai，否则日志时间对不上，排查问题时全是玄学。第三是网络，生产服务器必须配静态 IP，不要依赖 DHCP，否则重启后 IP 变了，所有指向它的服务全部失联。

# 查看当前时区与时间同步状态 timedatectl status # 设置时区为上海 sudo timedatectl set-timezone Asia/Shanghai # 启用 NTP 时间同步，保证集群内时间一致 sudo timedatectl set-ntp true # 查看网卡名称与当前 IP ip addr show # 编辑网络配置（Ubuntu Server 使用 netplan） sudo vim /etc/netplan/00-installer-config.yaml

netplan 配置里把dhcp4改为no，手动填写addresses、gateway4和nameservers。改完执行sudo netplan apply，然后用ip addr确认 IP 已生效。这里有个细节：如果服务器同时有内网和外网需求，建议内网走静态 IP，外网访问通过网关或跳板机转发，不要把管理端口直接暴露出去。时间同步看起来不起眼，但集群里如果各节点时间差超过几分钟，证书校验、日志关联、分布式锁都会出问题，属于典型的后悔药没处买。

2.3 基础服务与内网 DNS 的落地

系统装好后，先别急着装业务软件，把基础服务补齐。内网 DNS 是很多人忽略的一环，但它决定了你以后是用git.internal还是192.168.1.37访问服务。用 dnsmasq 或 bind 都行，小团队用 dnsmasq 足够，配置简单，还能兼做 DHCP。

# 安装 dnsmasq sudo apt install dnsmasq -y # 编辑配置，添加内网域名解析 sudo vim /etc/dnsmasq.conf # 在文件末尾添加： # address=/git.internal/192.168.1.10 # address=/wiki.internal/192.168.1.10 # server=223.5.5.5 # 重启服务 sudo systemctl restart dnsmasq sudo systemctl enable dnsmasq

配置里的address行把内网域名指向服务器 IP，server行指定上游 DNS 用于解析外网域名。这样团队成员只要把 DNS 指向这台服务器，就能用域名访问内部服务，以后换 IP 只改一处。注意 dnsmasq 默认监听 53 端口，如果系统装了 systemd-resolved，会冲突，需要先停掉它或改端口。基础服务还包括内网软件源镜像，把常用包缓存到本地，能大幅减少外网依赖，断网时也不至于寸步难行。

3. 服务部署：从文件共享到代码仓库的最小可用组合

3.1 用 Docker 隔离服务，避免依赖打架

服务部署阶段，最大的敌人是依赖冲突。Git 需要某个版本的库，Wiki 需要另一个版本，直接装在宿主机上迟早打架。常见做法是用 Docker 把每个服务装进独立容器，宿主机只负责跑 Docker 引擎。这样升级、迁移、回滚都只动容器，不动系统。

# 安装 Docker 与 Compose 插件 sudo apt install docker.io docker-compose-plugin -y # 启动并设置开机自启 sudo systemctl enable --now docker # 把当前用户加入 docker 组，避免每次 sudo sudo usermod -aG docker $USER # 验证安装 docker version docker compose version

加入 docker 组后需要重新登录才生效。这里有个安全提醒：docker 组权限等同于 root，不要把不信任的用户加进去。容器网络建议用自定义 bridge 网络，让同一网络内的容器用服务名互相访问，而不是写死 IP。

# docker-compose.yml 示例：Git 服务与 Wiki 服务 version: "3.8" services: gitea: image: gitea/gitea:latest container_name: gitea restart: always ports: - "3000:3000" - "222:22" volumes: - ./gitea/data:/data networks: - internal wiki: image: requarks/wiki:2 container_name: wiki restart: always ports: - "3001:3000" environment: - DB_TYPE=sqlite volumes: - ./wiki/data:/wiki/data networks: - internal networks: internal: driver: bridge

这份 compose 文件把 Git 和 Wiki 拆成两个容器，各自挂载数据卷到宿主机目录，重启容器数据不丢。restart: always保证服务器重启后服务自动拉起。端口映射上，Git 的 SSH 用 222 避免和宿主机 22 冲突。数据卷路径建议放在独立分区，方便单独备份。参数上，Gitea 的app.ini里要配好ROOT_URL和 SSH 端口，否则克隆地址会错。

3.2 文件共享与内网访问：Samba 与反向代理

文件共享是内部服务器的高频需求。Linux 上给 Windows 和 Mac 混用环境提供共享，Samba 是最稳的选择。配置时注意权限模型，建议按部门或项目建组，用组权限控制访问，不要给每个人单独配。

# 安装 Samba sudo apt install samba -y # 创建共享目录并设置权限 sudo mkdir -p /srv/share/project sudo groupadd devteam sudo chown -R root:devteam /srv/share/project sudo chmod -R 2770 /srv/share/project # 添加 Samba 用户（需先有系统用户） sudo smbpasswd -a zhangsan # 编辑配置 sudo vim /etc/samba/smb.conf

smb.conf 里添加共享段，设置path、valid users、read only和create mask。2770权限里的2是 setgid，保证新建文件继承父目录的组，避免组权限失效。改完用testparm检查语法，再sudo systemctl restart smbd。如果 Windows 访问提示权限不足，先确认 Samba 用户已启用，再检查目录的 Linux 权限和 SELinux/AppArmor 是否拦截。

内网服务多了以后，端口记不住，可以用 Nginx 做反向代理，统一走 80 或 443，按域名分流。这样对外只暴露一个入口，证书也只配一处。反向代理配置里注意proxy_set_header要带上真实 IP 和协议头，否则后端服务日志里全是代理的 IP，排查问题时等于黑匣子。

4. 安全与备份：内部服务器也不能裸奔

4.1 最小权限、防火墙与 SSH 加固

内部服务器不等于安全区。很多公司内网被一台中招的电脑横向渗透，就是因为内部服务毫无防护。安全加固从 SSH 开始：禁用密码登录，改用密钥；禁止 root 直接登录；改默认端口能减少扫描噪音，但别把它当主要防线。

# 生成密钥对（在客户端执行） ssh-keygen -t ed25519 -C "zhangsan@company" # 上传公钥到服务器 ssh-copy-id -p 22 zhangsan@192.168.1.10 # 服务器端编辑 SSH 配置 sudo vim /etc/ssh/sshd_config # 修改以下项： # PermitRootLogin no # PasswordAuthentication no # PubkeyAuthentication yes # Port 22022 # 检查配置并重启 sudo sshd -t sudo systemctl restart sshd

改端口后记得防火墙放行新端口，否则重启 SSH 会把自己关在门外。防火墙用 ufw 或 firewalld，默认拒绝入站，只放行必要端口。数据库、缓存这类服务不要对全网开放，只允许应用服务器 IP 访问。签名验签服务器、域服务器这类涉及认证的服务，更要严格限制来源，并开启审计日志。

4.2 备份策略：3-2-1 原则与恢复演练

备份是内部服务器最容易被跳过的一环，因为平时看不出价值，出事时才知道有没有。我一般按 3-2-1 原则做：至少 3 份数据，2 种不同介质，1 份异地。对中小团队，落地版是：本地 SSD 一份、NAS 一份、对象存储或另一台机器一份。

# 用 rsync 做增量备份到 NAS rsync -avz --delete \ --exclude 'cache/' \ /srv/share/ backup@nas.internal:/backup/share/ # 数据库逻辑备份 docker exec gitea mysqldump -u root -p'密码' gitea > /backup/gitea_$(date +%F).sql # 用 cron 每天凌晨执行 # 0 3 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1

备份脚本要写日志，否则失败了你不知道。更重要的是定期做恢复演练：把备份数据恢复到一台测试机，确认能正常启动服务。只备份不恢复，等于没备份。数据库备份建议用逻辑备份加物理备份结合，逻辑备份方便跨版本恢复，物理备份恢复快。备份文件要加密，尤其是包含用户数据的，别把备份当成安全盲区。

5. 避坑与排查：内部服务器搭建最常见的 5 个翻车现场

5.1 磁盘满了才发现日志没轮转

现象：服务突然不可用，登录一看根分区 100%。原因：日志、Docker 镜像、数据库 binlog 默认无限增长，没有配置轮转和清理。解决：给/var/log配 logrotate，Docker 配log-opts限制单文件大小和数量，数据库开 binlog 过期清理。监控磁盘使用率，超过 80% 就告警。

5.2 容器重启后数据丢了

现象：docker compose down再up，数据全没了。原因：数据卷用了匿名卷或没挂载到宿主机目录，容器删除时卷被清理。解决：所有有状态服务必须用 bind mount 挂到宿主机明确路径，并在 compose 里写死。定期检查docker volume ls，确认没有游离的匿名卷。

5.3 内网域名解析时好时坏

现象：有时能访问git.internal，有时不行。原因：客户端 DNS 配置了多个服务器，内网 DNS 和外网 DNS 混用，查询顺序随机。解决：统一客户端 DNS 指向内网 dnsmasq，由它转发外网查询。检查/etc/resolv.conf是否被 NetworkManager 覆盖，必要时锁定配置。

5.4 SSH 改端口后连不上

现象：改完 SSH 端口重启服务，新连接被拒绝。原因：防火墙没放行新端口，或 SELinux 没允许新端口。解决：改端口前先在防火墙放行，SELinux 环境用semanage port -a添加端口。改完不要关掉当前会话，另开一个窗口测试成功后再退出。

5.5 时间不同步导致证书校验失败

现象：内部 HTTPS 服务浏览器报证书错误，但证书明明没过期。原因：服务器时间偏差太大，超出证书有效期容忍范围。解决：所有服务器启用 NTP 同步，内网可以自建时间服务器，客户端指向它。定期用chronyc sources或timedatectl检查同步状态。

6. 进阶技巧：用快照和监控把故障恢复压到十分钟内

内部服务器搭到能用只是第一步，真正体现水平的是出事后的恢复速度。我的习惯是给每台物理机或虚拟机配快照能力，Proxmox、KVM、甚至云主机都支持。升级前打快照，改配置前打快照，装新服务前打快照。快照不是备份，但它能把「改坏了回不去」变成「回滚五分钟」。配合监控，故障发现时间也能大幅缩短。

监控不用一上来就上 Prometheus 加 Grafana 那套，小团队用 Netdata 或 Uptime Kuma 就够。Netdata 装完即用，CPU、内存、磁盘、网络、容器状态一屏看完；Uptime Kuma 负责拨测，HTTP、TCP、Ping 都能监控，服务挂了发通知。关键是告警要发到团队真正会看的地方，否则监控等于摆设。

# 用 Docker 快速起一个 Uptime Kuma docker run -d --restart=always \ -p 3002:3001 \ -v uptime-kuma:/app/data \ --name uptime-kuma \ louislam/uptime-kuma:1 # 用 Docker 起 Netdata docker run -d --restart=always \ -p 19999:19999 \ -v netdataconfig:/etc/netdata \ -v netdatalib:/var/lib/netdata \ -v netdatacache:/var/cache/netdata \ -v /:/host/root:ro,rslave \ -v /etc/passwd:/host/etc/passwd:ro \ -v /etc/group:/host/etc/group:ro \ -v /proc:/host/proc:ro \ -v /sys:/host/sys:ro \ -v /etc/os-release:/host/etc/os-release:ro \ --name netdata \ netdata/netdata:stable

Uptime Kuma 起来后，在 Web 界面添加监控项，把内网关键服务的域名和端口填进去，通知渠道接企业微信或邮件。Netdata 挂载了宿主机根目录和 proc，能直接看到宿主机指标，不用在每台机器装 agent。参数上注意 Netdata 的-v /:/host/root:ro,rslave是只读挂载，避免容器写坏宿主机文件。

再进一步，可以把常用恢复操作脚本化。比如一个restore.sh，传入服务名，自动从最近备份恢复数据卷、重启容器、验证端口。脚本里加set -e，任何一步失败就停，避免半恢复状态。我自己的习惯是每季度做一次「假装服务器挂了」的演练：从快照恢复一台机器，跑一遍恢复脚本，记录耗时。第一次演练通常要一两个小时，练几次后能压到十分钟以内。这个时间差，就是团队面对故障时的底气。

希望帮到你。

本文还有配套的精品资源，点击获取