生产服务器治理与内网 Gitea 远程办公
把一台阿里云 ECS 从「能用」做成「可接手」:脚本化的账号体系与安全基线、一条命令带自动回滚的发布,以及零公网端口的内网 Gitea 远程访问
- 角色
- 服务器与账号体系管理员(单人)
- 量级
- 1 台 ECS · 7 个管理脚本 · 10 篇运维手册
- 时间
- 2026年10月 — 至今
做了什么
- 账号体系:入职开号与离职回收全走脚本 —— 建号、装带加固前缀的公钥、随机 sudo 口令、建库账号、写台账,手工 useradd 视为违规
- 安全基线:SSH 关密码登录、只允许 sysops 组、root 仅密钥;MySQL / Redis 只绑回环,端口暴露每日自检,安全组不放行 3306 / 6379
- 发布与回滚:deploy-backend 备份 → 替换 → 重启 → 探活 → 失败自动回滚;前端 tar 备份后解包校验,回滚同样一条命令
- 远程办公:内网 Gitea 经 Tailscale tailnet 访问,零公网端口;再自建 Headscale 去掉官方账号与 3 人上限,用 subnet router 直连内网网段
- 可交接:管理员手册 + 9 篇同事手册(申请账号 → 自检 → 部署 → 改库 → 报错速查),新人按文档即可上手,不必等管理员在线
问题:服务器能用,但接手不了
接手时的状态很常见:几个人有 root、账号是口头加的、发版靠一句「你重启一下」、出了事去翻群聊。 这类系统不是不能用,而是不可交接——所有关键知识都挂在具体的人身上,一旦换人,风险立刻显性化。
所以目标不是「再装几个服务」,而是把三件事写成制度:谁能进、能做什么、出事怎么救。
账号体系:把开通与回收变成脚本
账号是权限的源头,也是最容易被手工操作绕过的地方。这里的原则是:只有脚本能开号,手工 useradd 一律视为事故。
| 阶段 | 动作 | 产物 |
|---|---|---|
| 开通 | 收公钥 → 建系统账号并入 sysops → 装带加固前缀的公钥 → 生成随机 sudo 口令 → 建库账号 → 写台账 |
一条可交付的开号结果 + 台账一行 |
| 使用 | 家目录 700/700/600;公钥带 no-agent-forwarding 等前缀;sudo 需密码 |
权限最小、可追溯 |
| 回收 | 撤公钥、锁账号、删库账号、查孤儿文件与配置引用、核对云侧 RAM 与操作审计 | 回收清单,逐项确认 |
台账(accounts.tsv,640 root:sysops)只记账号与公钥指纹,不记任何密码——密码走密码管理器或一次性链接,不在 IM 里明文发。
「谁在什么时候、用什么身份、执行了什么」,由 sudo 审计日志回答,而不是靠回忆。
安全基线:默认不暴露
安全不是一个开关,而是一组默认值。这台机器上的默认值是「关掉一切不必要的入口」:
- SSH:禁密码登录、禁键盘交互、最多 3 次尝试、只允许
sysops组与 root,root 仅密钥。 - 数据库:MySQL 只绑
127.0.0.1,root 走 socket;Redis 只绑回环。安全组不放行 3306 / 33060 / 6379。 - 自检:
db-exposure-check每日校验端口暴露与绑定地址,user-audit每周输出账号 / 公钥 / 口令年龄 / sshd 生效配置快照。 - 云侧:RAM 子账号只给只读与会话管理,不给
RunCommand、快照与重置密码;ActionTrail 保留审计。
基线快照(sshd 配置、sudoers、账号与公钥指纹、监听端口)在改动前先备份,出问题可以整体回退——改之前先想好怎么退。
发布与回滚:一条命令,失败自己退回去
发布是最容易出事的环节,所以它被压成一条命令,并且自带退路:
deploy-backend <jar> 备份 → 替换 → 重启 → 探活 → 失败自动回滚
deploy-frontend <dist> tar 备份 → 清空解包 → 校验 index.html
配套的规则同样明确:低峰发布;含 SQL 变更先备份再发;发布后检查服务状态、近两分钟日志无 ERROR、关键页面抽查;磁盘留出余量(备份只留最近两三份)。
回滚不需要现场想命令——上一个版本就在 *.bak-* 里,用同一条脚本回滚即可。
远程办公:内网 Gitea,零公网端口
内网 Gitea 原本只能在公司网段访问,同事在家就没法推代码。传统解法是开公网端口或架 VPN,但这两种都在扩大攻击面。
第一版 · Tailscale:把 Gitea 服务器与同事的电脑放进同一个加密 tailnet,用虚拟 IP 访问。
不开公网端口、不做端口映射、不装 VPN 设备;访问权限按设备授权,tailscale ping 能直接定位是直连还是走中继。
第二版 · 自建 Headscale:官方 Tailscale 依赖第三方账号,且有 3 用户上限,对团队是硬约束。 于是自建 Headscale 作为控制服务器——它只负责协调(注册、下发地址、交换公钥、下发 ACL),业务流量仍是节点间点对点直连,打不通才走 DERP 中继。 Gitea 服务器作为 subnet router 宣告内网网段,同事在家可以直接用原来的内网地址访问,客户端配置几乎不用改。
取舍写在前面:自建换来可控与不限人数,代价是要自己维护控制服务器、证书与升级。
文档即交付
这套东西真正的交付物不是一台配好的机器,而是十篇能照着做的文档:
- 《管理员手册》:账号基线、开通与回收、数据库管理、发布与回滚、审计巡检、应急处置、云侧管控、已知坑。
- 《同事手册》9 篇:申请账号 → 自检与配置 → 信息速查 → 服务器规则 → 常用命令 → 部署代码 → 数据库操作 → 报错速查 → 找管理员。
写法上刻意「去个人化」:命令按「在哪台机器执行」标注,值一律用占位符,每步写清「预期看到什么」。 文档里的每条结论都来自实测——比如「普通同事账号读不到 root 服务的 journal,真实日志在应用目录」,就是排障时撞出来的。
结果
- 新同事从「等管理员在线」变成「照文档自助」:申请、自检、部署、连库、排错都有路径。
- 发布从「凭记忆操作」变成「一条命令 + 自动回滚」,失败不再需要现场决策。
- 远程办公从「开端口 / 架 VPN」变成「设备进 tailnet 才能访问」,公网暴露面为零。
- 账号从「谁都能加」变成「只有脚本能加」,离职回收有清单、有审计、可核对。