这篇文章很枯燥，但我要讲。

不同于小作坊Home Lab的一套系统版本用到死，拼八字上千天不重启，在一个合规的企业（或Home Lab）中，维持安全稳定的系统基线同样是生产环境安全的重要组成部分。

我尝试了基于OpenClaw构建一套低维护成本的系统基线维护方案。是的，OpenClaw——总有一些事情，Codex 它们做不好。

0x01 从合规性讲起

企业与家庭式作坊Home Lab最大的区别是什么？是集群数量？是硬件规格？自然不是。

我认为最大的区别是，企业雇佣了专门的团队构建了一条条可以被广泛使用的基线，制定了基线相关的KCI，以促使整个企业跟随基线发布进度进行演进；而家庭用户，大部分则没有构建统一的部署模版，进行安全调优，并维持固定的频率对安装的系统和产品进行升级。

以我知道的某个合规优先的大型企业来说说，在企业中对系统版本基线如何定义。

首先，企业为了维护需要以及成本控制，在同一类系统中，一般只会选择一种带支持服务的系统发行版。例如：Linux系列一般只会选择一款带企业服务的发行版，如RedHat。Windows Server系列则比较特殊，由于生命周期支持较长，以及每个大版本之间的差别没有Linux那么大，实际上可能维持一条比较长的生命周期支持产品线，如Win2k12 到 Win2k22有可能都会同时出现在生产环境。但Win2k12 如果一旦宣布End of Support，企业则会通过受控的方式将大部分服务器同机升级到更新的版本。如果因为特殊原因无法升级，则会产生费用，由项目组进行换机升级。

这里我们主要说Linux。由于Linux基线滚动更新，通常会有一个统一的团队（如Chief Technology Office）对每个月的补丁包收集并发布为当月的baseline（基线）。以RHEL yum源为例，当月基线发布后，会整合为一个以当前基线为路径的yum源。简单地说，系统只要进行yum源路径切换并执行yum update，则会同步到新基线上，完成一次补丁（Patching）。

实际上的情况会比理想环境复杂得多。由于承载业务的复杂性，如数据库、中间件、第三方产品等都可能对新的基线中部分软件包出现兼容性问题，通常CTO团队需要进行大量测试，确保没有引入bug才会发布基线。实际系统管理员在进行Patching操作时也很难一帆风顺，极有可能因为系统的复杂性（如DMZ、集群、复杂数据库等）导致补丁操作失败、需要回退。

从网络安全的角度，由于有统一固定的基线，网络安全团队可以很快知道当前的服务器是否合规。例如，网络安全团队可以向所有分支机构制定KCI —— 只有保持在最新三条基线的服务器视为合规。那么一旦有服务器落到四个月前的基线而没有进行补丁操作，影响了KCI数据，则可以很容易进行追责。

0x02 Home Lab怎么做

对于高要求的Home Lab环境我决定部分采用企业的管理思路，并在不影响业务的情况下尝试以更高的安全标准进行Patching。

0x001 统一Linux版本

在开始的时候我当时维护着两套Linux版本基线：CentOS 7 与 Debian 12. 当我的Home Lab刚刚建立的时候，所有的服务器均为CentOS 7. 而后面因为CentOS 7 生命周期结束，对于新构建的VM我使用Debian 11/12进行承载 —— 这也是时间演化的结果，算是我的技术债了。

如果统一Linux版本，对我而言有如下好处：

1. 不需要维护两套内网Linux源，当时需要同步CentOS源和Debian11/12源，额外占有NAS空间。
2. 更统一的交互逻辑，例如对网络配置的修改则更为统一，不需要区分操作系统发行版本。
3. 更易于维护Ansible脚本，当时我使用一些自定义的Ansible脚本，通过Jenkins进行CI/CD。由于多发行版的存在，我需要额外制定很多分支情况。
4. Debian的大版本升级相对于CentOS更容易。

作为决策：我决定批复预算（¥0，主要是时间成本），将所有CentOS机器换机升级到Debian；同时统一Debian大版本为13.

0x002 基线治理

对于CentOS的历史主机，经过重装业务应用等方式我全部迁移到了Debian。这不是本文的治理重点，暂且不表。对于现网的Debian11/12机器，我通过GPT构建了一套in-place upgrade脚本来将基线同步到Debian13，这套脚本做了这些事情：

1. 进行pre-check，采集OS基本信息并判断是否可以健康地运行升级
2. 建立vCenter VM与实际FQDN的映射关系并进行vCenter VM Snapshot
3. 配置apt源与禁用三方源
4. 执行升级
5. 执行post-check

这套脚本有dry-run模式，用于真实升级前的演练。而通过GPT或其它AI调用的方式来进行执行，通常会有更为全面的post-check，会发现脚本没有覆盖的问题。例如：Zabbix Agent在Debian升级13后不工作，GPT可以自主分析问题并进行修复。

在这里，我没有使用OpenClaw的方式进行调用。在Codex中进行调用有助于回朔会话，使AI在同一上下文下进行操作。而OpenClaw的优势我认为在于定时触发与移动端触发支持，并不适用于这个场景。

在完成基线治理后，我的Home Lab环境中只会存在Debian 13一种Linux服务器基线。不可避免地，虚拟化环境中会有第三方系统基线无法完全迁移到Debian，如运行Mikrotik的VM、如运行HAOS的VM，这些不受基线管理，但应作为风险接受项由另外的方式保证基线和补丁更新。

0x003 日度基线

不同于企业按月发布的基线，由于服务器数量不多，且承载业务可控，我完全可以采用跟随主流发布源的周期进行日度补丁更新，并在发生内核更新的情况下进行重启。

主要问题和挑战在于：

1. 如何保证业务恢复：这要求所有的业务能在重启后自动拉起，且必须有重试机制。对于跨机器依赖服务尤其具有挑战（如应用服务器和数据库服务器）。
2. 如何进行健康检查：这要求应用可以反馈正确的healthy结果，尤其是容器和数据库。
3. 如何进行失败告警：当补丁失败/重启失败/业务启动失败等情况发生时，我如何被通知到。
4. 如何决定补丁顺序：对于各个VM我如何确定补丁顺序，大原则一般是先数据库，再中间件，再网络设备，最后是外网设备。
5. 如何处理反亲和项目：这通常会发生在集群服务中，需要保证集群中有最低限度的active节点。在我的案例中主要是DNS集群和代理集群。
6. 如何确保日志可审计：触发Patching时，Agent不是说干就干，而是在批准的框架下，以最小权限来干。

而GPT可以轻易处理上述绝大部分挑战：

1. 通过Agent执行维护脚本，可以通过自然语义要求对业务进行检查，并修复failed的service
2. GPT可以轻易地改造目前现网容器，加入health check探针
3. 失败通知我集成了短信通知接口，一旦有补丁失败会触发短信告警，同时也通过Zabbix、Uptime-Kuma等进行监控

4. 补丁顺序、反亲和等均可在受控环境下执行数轮维护脚本，确定最优顺序

5. 通过结合ITSM系统，避免脚本误触发，并自动进行留痕

作为决策：我决定让GPT写个脚本作为daily maintenance，以每日更新的方式进行补丁基线更新，并使用OpenClaw进行调度，在ITSM的框架下运行。

通过套了OpenClaw来运行脚本给我带来了意想不到的惊喜。根据提示词，它甚至会在脚本因为简单原因的失败后主动进行重试。而我完全也可以要求它在遇到问题时进行更多的排错和处理，完全取决于提示词。

这个daily maintenance脚本逻辑并不复杂：

1. 对现网进入维护的主机走ITSM流程，起Change Order
2. CO获批后，ITSM将daily maintenance持有的密钥对分发到各个服务器
3. daily maintenance脚本进行precheck/patching/postcheck
4. daily maintenance脚本根据执行情况关闭CO并标注执行情况
5. ITSM吊销植入到主机的密钥对

在以往，我们可以通过cron进行周期性调度，而有了AI的加持，我们可以在OpenClaw进行调度：

这里的提示词非常简单，但我们完全可以通过完善提示词，让维护脚本在没有进入正确分支时，由AI进行自动修复。

0x03 我们获得了什么

至此，我完成了Linux版本的统一与日度基线维护。当前架构下仅维护Debian13一套系统模版作为基础架构，并通过OpenClaw日度维护任务进行基线同步，从而一定程度上增强了安全性和后续的可维护性。

对比企业方案这仍然只是冰山一角，安全基线是方方面面的，除了补丁，还有配置项目基线、漏洞追踪、主动扫描、登录审计等许多要求。这些构成了企业的零信任安全环境，而我们也可以取其有明显收益的部分，让我们的Home Lab环境稍微安全一丢丢。