企业官网建设流程全解析

第一章 场景：谁来巡检一个9节点集群

先交代被巡检对象：一套 Rocky9 + Kolla-Ansible 20.6.0（Epoxy 版）的生产级高可用 OpenStack 集群，9 节点三组角色——3 台控制节点（ostk-ctl1/2/3，10.10.10.81~83）跑 keystone/nova/neutron/glance/cinder/horizon 等全量控制面服务，3 台计算节点（.91~93）跑 nova_compute 与 libvirt，3 台 Ceph 节点（.101~103）提供外部块存储后端；控制面服务统一走 VIP 10.10.10.84（keepalived + haproxy）。

这种规模的日常巡检清单，人工做一遍大约是：9 台逐台登录，控制面 12 个关键容器逐个看状态，7 个服务注册是否齐全，compute service 有没有 down，VIP 探活，Ceph 集群健康加 mon 仲裁加 OSD 全量在线。全部做完二十分钟起步，且做十次错两次——人都会漏。

这篇实录记录两件事：怎么把这套集群交给 AI Agent（一次性配置），以及之后巡检实际发生了什么（对话式巡检 + 值守自动巡检 + 四组真实故障演练）。所有时间线均为真实记录，非设计稿。

第二章 交接：AI 怎么认识这套集群

2.1 纳管与角色识别

把 9 台主机加入 Agent 的主机清单后，第一件事不是巡检，是让 AI 自己搞清楚每台机器是什么角色。用 scan_roles 工具发起探测（commit=false 先预览），AI 登录每台机器查特征指纹：docker 里有 keystone 容器判定为控制节点、有 nova_compute 判定为计算节点、有 cephadm 判定为 Ceph 节点。9 台全部命中，零误报（对照组的 yum 源服务器没有误命中）。确认无误后 commit=true 写回，值守监测立即按角色挂上对应探针。

2.2 探针分层：不是所有节点看一样的东西

巡检的核心设计是按角色分层——控制节点关心容器健康，计算节点关心 nova_compute 活着，Ceph 节点关心集群健康而不是单机负载：

一个实现细节：OpenStack CLI 认证不走 source admin-openrc.sh（kolla_toolbox 以非 root 用户运行读不了 0600 权限文件），而是每次动态从 passwords.yml 读 admin 密码、以环境变量内联方式注入 docker exec。密码不落日志、不进配置文件。

docker exec -e OS_USERNAME=admin -e OS_PASSWORD=<动态读取> \

-e OS_AUTH_URL=http://10.10.10.84:5000 ... \

kolla_toolbox openstack service list

第三章 实录：一次完整的对话式巡检

配置完成后，日常巡检就是一句话的事。以下是一次真实巡检的交互记录（回显做了节选）：

【向 AI 提问】「OpenStack 集群现在的状态怎么样？全面查一下。」

【AI 执行过程】它先 SSH 到 ctl1，依次执行了这些命令（每一步都实时可见）：

>>> docker ps --format "{{.Names}} {{.Status}}" # 容器健康

keystone Up 3 days (healthy)

nova_api Up 3 days (healthy)

...（12个关键容器全部 healthy）

>>> openstack service list # 经 kolla_toolbox，控制面服务

keystone / neutron / nova / glance / heat / heat-cfn / placement

>>> openstack compute service list

3台compute全部 enabled 且 up

>>> curl -s -o /dev/null -w "%{http_code}" http://10.10.10.84:5000/v3/

200 # VIP 探活正常

>>> cephadm shell -- ceph -s # 登录 ceph1

HEALTH_OK, 3 mon 仲裁正常, 24 OSD 全部 up

【AI 结论】「集群整体健康：控制面 12 容器全部 healthy；7 项服务注册完整；3 计算节点在线；VIP 认证入口 200；Ceph HEALTH_OK 无降级。无异常项。」

整个过程不到两分钟。人工巡检容易漏的三类问题——compute service 显示 down 但进程还在、某个容器 unhealthy 但服务还能响应、Ceph 集群 HEALTH_WARN 但存储还能用——都在 AI 的检查路径里，因为它执行的是清单不是感觉。

3.1 巡检对话和普通聊天的区别

值得强调的是安全边界：这套巡检全程只有只读命令，但 AI 毕竟持有可变更的权限。项目的分级管控在巡检场景下的表现是：查询类命令直接放行，假如巡检结论之后用户顺口说「那把 heat 服务重建一下」，这类变更命令会触发人工确认而不是直接执行。巡检归巡检，变更归变更，边界不因对话连续而模糊。

第四章 故障演练：四组真实时间线

巡检能力是不是真的，演练是唯一标准。对集群做了四组端到端故障注入，每组完整记录从注入到告警到恢复的全时间线。

4.1 演练一：控制面容器故障

这次演练先失败了一次：第一次用 docker stop 注入，值守毫无反应。排查发现不是探针 bug——kolla 容器带 restart 策略，被 dockerd 几秒内自动拉起，探针采到的就是正常状态。教训是演练方法论的：对容器化服务注入故障必须用 docker pause（dockerd 不会自动恢复，且探针的异常正则覆盖 Paused 状态），stop 只能骗到自己。这条经验同样适用于 K8s/Harbor 等一切带 restart 策略的容器演练。

4.2 演练二：VIP/HAProxy 宕

同时 pause 全部 3 台控制节点的 haproxy，VIP 10.10.10.84 断连。113 秒后告警「VIP/HAProxy 探活失败：HTTP 000」；恢复后约 48 秒收到探活正常。注意这里如果逐台 stop，keepalived 会让 VIP 漂移到存活节点，探活根本不会断——要打断 VIP 必须三台同时处理，这也是 HA 设计的验证点。

4.3 演练三：控制面服务注册缺失

注入方式更刁钻：openstack service delete 删掉 heat 的服务注册（服务还在跑，但 keystone 里不注册了）。41 秒后告警「控制面服务缺失 1: heat」。这个演练还顺带验证了联动告警的正确性：VIP 宕期间 CLI 连不上认证端会误报「7 个服务全缺失」，VIP 恢复自动回正——告警系统对「自己探活不了」和「服务真没了」做出了正确区分。

4.4 演练四：Ceph 降级与一个真实缺陷

注入：停止 ceph3 的一块 OSD（systemctl stop ceph-fsid@osd.2），预期 Ceph 进入 HEALTH_WARN 并告警。结果：不告警。

排查发现这是一个真实的探针缺陷：判定函数检查的异常键是 bad/down/missing，而 Ceph 采集数据用的键是 ok/health——ok=False 时永远走不到异常分支，「永不告警」。修复方式是新增布尔判定加去抖（commit 920c53f，补 3 项单测），重启后重新演练：46 秒告警「Ceph 集群不健康：HEALTH_WARN(osd down)」，恢复后约 150 秒收到 HEALTH_OK。

这段的价值在于展示了演练的另一半意义：演练不仅验证「告警能不能响」，还会暴露「判定逻辑写错了但从来没被触发过」的暗病。没有这次演练，这个永不告警的缺陷会一直安静地躺着。

第五章 两种巡检形态与最终形态

5.1 问答式 vs 值守式

对话式巡检（第三章）适合变更前后、上班第一眼的主动检查；值守式巡检（第四章背后的机制）则是后台常驻：每 30 秒一轮全节点轮询，异常经双去抖确认后告警，恢复后自动闭环 recovered。两者的检查项完全一致，只是触发方式不同。

值守的告警链路是三路的：Web 界面弹横幅（带未恢复告警面板）、三连急音、可选邮件。去抖参数取的是经验值：连续 2 轮异常才告警（滤掉偶发超时），连续 3 轮正常才报恢复（滤掉抖动）。

5.2 一次真实教训：告警延迟的真相

K8s 集群演练时曾遇到「故障 15 分钟不告警，疑似线程卡死」的现象，排查后真相完全不同：主机清单里还有 9 台已下线的旧虚拟机，值守每轮仍对它们做完整 SSH 存活探测，每台超时十几秒，把单轮巡检拖到 5~8 分钟，告警自然就慢了。把离线主机移出清单后，告警提速到 27 秒。教训：监控系统的「慢」先查轮询路径的最坏情况，不要先怀疑线程模型；下线主机的处置（移除或排除）是值守的卫生学。

5.3 实录结论

这套「AI + 角色探针 + 故障演练」的巡检体系，交付验证时真机 21 项全过、单测 136 项全过，四组演练全部 alert 到 recovered 闭环。对个人运维者来说，它把「二十分钟起步且会漏」的人工巡检，变成了「两分钟问答 + 后台 30 秒一轮自动值守」；对企业来说，它的价值更进一步：巡检路径是代码化的、可回归的，演练抓出的每一个暗病都会变成测试用例沉淀下来。

最后给想复现的人一句建议：先做第二章的角色识别与探针配置，再做第三章的问答式巡检建立信任，最后才上值守——顺序反了，你会在没有信任基础的情况下被告警噪音淹没。