Roadmap: AI-native GitOps control plane and self-growing operation modules

[YangYuS8]

背景

Astralith 当前已经具备轻量级自动化运维平台的核心闭环：主机管理、主机组、内置运维模块、任务创建、Ansible Runner 执行、Celery 异步调度、SQLite 结果保存、APScheduler 定时任务与前端日志展示。

原计划是在此基础上引入 AI-assisted self-growing operation modules：让 Agent 根据任务失败日志、Ansible 执行结果、历史巡检记录和用户描述，辅助生成新的运维模块提案、Runbook、Ansible Playbook 草案、风险评估与测试用例，使平台具备“从故障经验中沉淀可复用运维能力”的成长性。

但如果只是“接入大模型 API，然后生成一段日志分析或 Playbook 草案”，竞争力仍然不足。后续路线应升级为：

Astralith 不做简单的 AI 聊天运维助手，而是做一个面向个人服务器与小团队的 AI-native GitOps 运维控制平面。

也就是说，Git 仓库负责描述服务器与服务的期望状态，Astralith 负责同步、解析、对账、校验、生成变更计划、执行受控操作与记录审计；AI 负责基于证据包分析故障、生成可审核的 GitOps 变更提案、Runbook 与受控运维模块草案。

新定位

Astralith
= GitOps Reconciler
+ Ansible Executor
+ Docker Compose Stack Manager
+ Evidence-based AI Incident Analyzer
+ Policy-gated Operation Module Factory

面向场景：

• PVE / Homelab 多 VM / CT 管理。
• 多台服务器上的 Docker Compose Stack 管理。
• 小团队轻量级自动化运维。
• Ansible 任务执行与结果审计。
• 故障经验沉淀为 Runbook / Operation Module。
• Git 作为基础设施期望状态来源。

核心目标

不是让 Agent 直接接管服务器，也不是让 Agent 自动生成代码后立即上线，而是构建一个受控闭环：

Git 仓库声明期望状态
  ↓
Astralith 同步并解析 hosts / stacks / modules / policies
  ↓
对比 Desired State 与 Actual State
  ↓
生成 Diff 与 Apply Plan
  ↓
Policy-as-Code 校验与风险评级
  ↓
人工审核 approve / reject
  ↓
通过 Ansible Runner / Docker Compose 执行
  ↓
保存执行结果、审计记录与回滚信息

AI 参与的闭环：

任务失败 / 巡检异常 / 用户描述问题
  ↓
构建 Evidence Pack
  ↓
AI 基于证据包生成诊断报告
  ↓
判断现有模块是否已覆盖该场景
  ↓
生成 Runbook / Operation Module Proposal / GitOps Change Proposal
  ↓
Schema 校验、Policy 校验、syntax-check、dry-run / check mode
  ↓
人工审核 approve / reject
  ↓
通过后沉淀为受控模块、文档或 GitOps PR 草案

设计原则

1. Git 是期望状态来源。 服务器、服务、模块、策略等资源应尽可能声明化、版本化。
2. AI 只生成提案，不直接执行变更。 AI 不拥有服务器执行权，不直接修改生产环境。
3. 执行能力仍通过 Ansible Runner、Docker Compose 与内置 operation modules。
4. 不允许用户上传 Python 插件，不执行任意上传代码。
5. 高风险操作必须人工确认。 涉及删除数据、修改防火墙、修改 SSH、删除 volume、数据库操作等必须阻断或强制审核。
6. 所有变更必须可追溯、可审计、可回滚。 保存 commit SHA、diff、plan、审批人、执行日志与结果。
7. 安全判断不能只依赖 LLM。 LLM 可以解释风险，但必须有确定性的 schema validation、allowlist、policy rules 和 dry-run。
8. 第一阶段优先生成数据库中的 proposal，不直接改写仓库代码。 后续可以导出 patch 或 PR 草案。
9. 面向 Docker Compose 与 Ansible 优先。 暂不扩展为 Kubernetes 管理平台。

核心概念

1. Desired State Repository

用于描述 Astralith 管理对象的 Git 仓库。

示例结构：

astralith-infra/
├── hosts/
│   ├── proxy-01.yaml
│   ├── monitoring-01.yaml
│   └── dev-01.yaml
├── stacks/
│   ├── uptime-kuma/
│   │   ├── stack.yaml
│   │   ├── compose.yaml
│   │   └── .env.example
│   ├── nginx-proxy-manager/
│   │   ├── stack.yaml
│   │   ├── compose.yaml
│   │   └── .env.example
│   └── zabbix/
│       ├── stack.yaml
│       ├── compose.yaml
│       └── .env.example
├── modules/
│   ├── system_inspection/
│   │   ├── module.yaml
│   │   ├── playbook.yaml
│   │   └── runbook.md
│   └── docker_compose_restart/
│       ├── module.yaml
│       ├── playbook.yaml
│       └── runbook.md
├── policies/
│   ├── compose-security.yaml
│   ├── ansible-risk-rules.yaml
│   └── operation-risk.yaml
└── README.md

2. Desired / Actual Diff

Astralith 需要区分：

Desired State：Git 仓库中声明的目标状态
Actual State：当前数据库、主机扫描、Docker 状态、任务结果中反映的实际状态
Diff：二者差异
Apply Plan：为消除差异而生成的执行计划

示例：

Git 中声明 uptime-kuma 应该部署到 monitoring-01
实际状态中 monitoring-01 没有 uptime-kuma stack

Diff:
  + create stack uptime-kuma on monitoring-01

Plan:
  1. create /opt/stacks/uptime-kuma
  2. sync compose.yaml
  3. run docker compose config
  4. run docker compose pull
  5. run docker compose up -d
  6. verify container health

3. Evidence Pack

AI 不应直接基于零散日志自由发挥，而应基于结构化证据包分析。

Evidence Pack 示例：

{
  "task_id": 42,
  "host": "proxy-01",
  "stack": "nginx-proxy-manager",
  "time_range": "2026-06-27T19:00:00+09:00/2026-06-27T19:10:00+09:00",
  "signals": {
    "ansible_events": [],
    "stdout": "...",
    "stderr": "...",
    "docker_ps": [],
    "docker_logs": [],
    "systemd_status": [],
    "journalctl": [],
    "ports": [],
    "disk_usage": [],
    "recent_git_commits": [],
    "previous_incidents": []
  }
}

AI 输出必须尽量引用证据来源，例如：

• 哪一段 stderr 支持该判断。
• 哪个容器状态异常。
• 哪个端口探测失败。
• 最近一次 GitOps 变更是否可能相关。

4. Policy-as-Code

对 GitOps 变更、Compose 文件、Ansible Playbook 与 AI 生成提案进行确定性校验。

初期可内置轻量规则引擎，后续再考虑接入 OPA / Conftest 一类工具。

Compose 规则示例：

• 禁止 privileged: true，除非显式豁免。
• 禁止直接挂载 /、/etc、/var/run/docker.sock，除非显式标记高风险。
• 禁止使用 latest 镜像，除非标记为实验环境。
• 暴露公网端口必须声明 risk_level。
• 数据库类服务必须声明持久化 volume。
• 禁止提交真实 .env、私钥、token。

Ansible 规则示例：

• 禁止危险 shell 命令，如 rm -rf /、格式化磁盘、批量删除关键目录。
• 限制 shell / command 模块使用场景。
• 修改 SSH、防火墙、OpenWrt、数据库、volume 的任务必须强制人工审核。
• Playbook 必须支持 check mode 或提供 dry-run 说明。

5. AI Proposal

AI 输出不应是纯文本建议，而应转化为可审核对象。

Proposal 类型：

Incident Report
Runbook Proposal
Operation Module Proposal
GitOps Change Proposal
Policy Explanation
Rollback Plan Proposal

GitOps Change Proposal 示例：

变更目标：修复 nginx-proxy-manager 502
影响对象：proxy-01 / nginx-proxy-manager stack
证据链：容器日志、端口探测、上次部署记录、健康检查失败
变更内容：修改 compose.yaml，增加 healthcheck，固定镜像版本，补充 restart policy
风险等级：medium
回滚方案：恢复上一 commit 后重新 docker compose up -d
验证步骤：HTTP 200、容器 healthy、无 502 日志
建议生成 PR：yes

6. Controlled Operation Module DSL

AI 不直接生成可执行 Python 插件，而是生成受控 DSL 或 metadata，由 Astralith 映射到已有安全执行能力。

示例：

module_key: docker_compose_restart
title: Restart Docker Compose Stack
risk_level: medium
target_type: stack
parameters_schema:
  type: object
  required:
    - host_id
    - stack_name
  properties:
    host_id:
      type: string
    stack_name:
      type: string
    pull_before_restart:
      type: boolean
      default: false
allowed_actions:
  - docker_compose_ps
  - docker_compose_pull
  - docker_compose_up
  - docker_compose_logs
rollback:
  strategy: rerun_previous_compose_commit
evidence_required:
  - docker_ps
  - compose_file
  - recent_logs

推荐架构

                 Git Repository
        hosts / stacks / modules / policies
                         │
                         ▼
              GitOps Sync Service
                         │
                         ▼
             Desired State Database
                         │
                         ▼
                Diff / Plan Engine
                         │
        ┌────────────────┴────────────────┐
        ▼                                 ▼
Policy Validator                  Evidence Pack Builder
        │                                 │
        ▼                                 ▼
Risk Report                  AI Analysis / Proposal
        │                                 │
        └────────────────┬────────────────┘
                         ▼
                 Human Review Center
                         │
                         ▼
              Ansible Runner Executor
                         │
                         ▼
             Result / Audit / Rollback Log

关键工作流

Workflow A：Docker Compose GitOps 部署

用户向 Git 仓库提交 stacks/uptime-kuma/stack.yaml 与 compose.yaml
  ↓
Astralith 手动或定时同步仓库
  ↓
解析 Desired Resources
  ↓
扫描 Actual State
  ↓
生成 Diff：新增 uptime-kuma stack
  ↓
生成 Apply Plan
  ↓
执行 compose config 与 policy validation
  ↓
管理员审核
  ↓
通过 Ansible Runner 在目标主机创建 /opt/stacks/uptime-kuma
  ↓
同步 compose.yaml
  ↓
执行 docker compose pull / up -d
  ↓
保存 commit SHA、执行日志、部署结果与验证结果

Workflow B：故障到模块沉淀

某次 Ansible / Docker Compose 任务失败
  ↓
Astralith 构建 Evidence Pack
  ↓
AI 生成 Incident Report
  ↓
AI 判断现有模块是否覆盖
  ↓
未覆盖则生成 Runbook Proposal 与 Operation Module Proposal
  ↓
系统进行 schema validation、policy validation、syntax-check、dry-run / check mode
  ↓
管理员审核
  ↓
通过后导出为模块草案、文档、测试用例或 GitOps PR 草案

版本规划

v0.5.0 — Evidence Pack + AI Incident Analysis MVP

目标：让平台可以基于结构化证据包生成中文故障分析报告。

范围：

• 新增 AI analysis service boundary。
• 新增 Evidence Pack 数据结构。
• 支持从 task stdout / stderr / raw events 构建基础证据包。
• 补充 host facts、systemd 状态、Docker 状态、磁盘状态、端口探测等可选证据。
• 输出问题摘要、关键证据、可能原因、建议排查步骤和风险提示。
• 将 AI 分析结果保存到 SQLite。
• 前端任务详情页展示 AI 分析结果。
• 不进行自动修复，不生成可执行模块。

验收：

• 选择一次失败任务，点击 AI 分析，可以得到结构化中文诊断报告。
• 报告包含证据引用和人工复核提示。
• AI 输出不能绕过证据包直接要求执行危险命令。

v0.6.0 — GitOps Repository Sync MVP

目标：引入 Git 仓库作为期望状态来源。

范围：

• 新增 gitops_repositories 表。
• 新增 gitops_sync_runs 表。
• 支持配置仓库 URL、分支、本地路径、启用状态。
• 支持手动 sync。
• 支持保存最近 commit SHA。
• 解析 hosts/*.yaml。
• 解析 stacks/*/stack.yaml。
• 解析 modules/*/module.yaml。
• 解析 policies/*.yaml。
• 前端展示 Desired Resources。

验收：

• 用户配置一个 Git 仓库后，Astralith 可以拉取并解析资源。
• 前端可以看到 Git 中声明的 hosts / stacks / modules / policies。
• 同步失败时保存错误日志。

v0.7.0 — Desired / Actual Diff + Policy Validation

目标：让平台可以对比期望状态与实际状态，并生成受控执行计划。

范围：

• 新增 desired_resources 表。
• 新增 resource_diffs 表。
• 新增 apply_plans 表。
• 新增 policy_results 表。
• 实现 Desired / Actual diff。
• 支持新增 / 更新 / 删除资源的 diff 类型。
• 生成 Apply Plan。
• 对 compose.yaml 执行基础格式校验。
• 对 Ansible Playbook 执行 syntax-check。
• 对高风险字段执行 policy validation。
• 前端新增 Diff Center 与 Apply Plan 页面。

验收：

• Git 中新增一个 stack，平台能识别 diff 并生成部署计划。
• 含危险配置的 compose / playbook 会被标记为高风险或阻断。
• 未通过 policy validation 的计划不能直接执行。

v0.8.0 — Docker Compose GitOps Apply

目标：让 Astralith 能够受控部署 Docker Compose Stack。

范围：

• 通过 Ansible Runner 在目标主机创建 /opt/stacks/<stack_name>。
• 同步 compose.yaml 与必要元数据。
• 执行 docker compose config。
• 执行 docker compose pull。
• 执行 docker compose up -d。
• 支持部署后验证：容器状态、healthcheck、端口探测。
• 保存 commit SHA、执行日志、stack 状态。
• 支持回滚到上一 commit 对应 compose 文件。

验收：

• 在 Git 仓库添加 uptime-kuma stack 后，Astralith 能检测到新增资源。
• 审核通过后，平台能将其部署到指定主机。
• 前端可以查看部署计划、执行日志、验证结果与回滚信息。

v0.9.0 — AI GitOps Change Proposal

目标：让 AI 从故障证据中生成可审核的 GitOps 变更提案。

范围：

• 新增 ai_proposals 表。
• Proposal 支持类型：incident_report / runbook / operation_module / gitops_change / rollback_plan。
• AI 可根据 Evidence Pack 生成 compose 修改建议、模块修改建议、runbook 修改建议。
• 支持导出 patch 草案。
• 可选：生成 GitHub PR 草案，而不是直接写入主分支。
• 前端新增 Proposal Review 页面。

验收：

• 对一次容器异常，AI 可以生成带证据链的 GitOps Change Proposal。
• Proposal 包含影响范围、风险等级、变更内容、验证步骤和回滚方案。
• Proposal 需要人工审核，不得自动执行。

v1.0.0 — Self-growing Operation Module Factory

目标：将故障经验沉淀为可审核、可验证、可复用的受控运维模块。

范围：

• 完善 operation_module_proposals 表。
• Proposal 包含 title、problem_summary、module_key、task_key、risk_level、parameters_schema、runbook、generated_playbook、test_plan、status。
• 支持从 task result / evidence pack / incident report 生成 module proposal。
• 支持 proposal 状态：draft / reviewing / approved / rejected / implemented。
• 增加安全校验器：危险命令检测、Ansible module allowlist、参数校验、风险等级提示。
• 对 generated_playbook 执行 ansible syntax-check。
• 支持 dry-run / check mode 验证记录。
• 管理员可以 approve / reject proposal 并填写审核意见。
• 支持将已审核 proposal 导出为内置模块草案。
• 支持生成模块文档、测试用例、示例参数与回滚说明。

验收：

• 对一次服务异常或巡检失败任务，系统可以生成模块提案。
• 提案包含 Runbook、Playbook 草案、参数说明、风险等级和测试计划。
• 含危险命令或缺少参数校验的提案会被标记为高风险或校验失败。
• 审核通过的 proposal 可以被导出为可评审的模块草案。

数据库扩展草案

gitops_repositories
- id
- name
- repo_url
- branch
- local_path
- auth_type
- enabled
- last_sync_at

gitops_sync_runs
- id
- repository_id
- commit_sha
- status
- stdout
- stderr
- started_at
- finished_at

desired_resources
- id
- repository_id
- commit_sha
- resource_type
- resource_key
- file_path
- content_json
- content_hash

actual_resources
- id
- resource_type
- resource_key
- source
- content_json
- content_hash
- scanned_at

resource_diffs
- id
- sync_run_id
- resource_type
- resource_key
- diff_type
- before_json
- after_json
- risk_level

apply_plans
- id
- diff_id
- plan_json
- status
- policy_status
- ai_summary
- approved_by
- approved_at

policy_results
- id
- plan_id
- rule_key
- severity
- passed
- message

evidence_packs
- id
- task_result_id
- host_id
- content_json
- created_at

ai_analysis_results
- id
- evidence_pack_id
- summary
- content_json
- model_name
- created_at

ai_proposals
- id
- evidence_pack_id
- proposal_type
- title
- content_json
- status
- risk_level

operation_module_proposals
- id
- source_proposal_id
- module_key
- title
- problem_summary
- parameters_schema
- runbook
- generated_playbook
- test_plan
- status
- risk_level

前端页面规划

1. GitOps Repositories
   - 仓库 URL、分支、最近 commit、同步状态、同步日志

2. Desired Resources
   - Git 中声明的 hosts / stacks / modules / policies

3. Diff Center
   - Desired State 与 Actual State 的差异

4. Apply Plan
   - 将要执行什么、影响哪些主机、风险等级、验证步骤、回滚方式

5. Policy Results
   - 哪些规则通过，哪些规则阻断，哪些需要人工确认

6. Evidence Pack
   - AI 分析基于哪些证据

7. AI Analysis
   - 结构化故障分析报告

8. Proposal Review
   - 审核 AI 生成的 Runbook / Module / GitOps Change Proposal

9. Audit Log
   - Git commit、审批记录、执行记录、回滚记录

非目标

• 不做完全自动化自我修改系统。
• 不让 Agent 直接执行任意 shell。
• 不引入用户上传插件市场。
• 不在第一阶段做 Kubernetes 管理平台。
• 不将 Astralith 扩展为企业级 CMDB、堡垒机或完整 CI/CD 平台。
• 不做复杂多租户权限系统。
• 不做商业级 AIOps 大数据平台。
• 不追求全自动自愈，优先做半自动、可审核、可回滚。

面向毕业设计与求职的价值

该方向可以作为 Astralith 的核心创新点：

在基础自动化运维平台上，引入面向 Docker Compose 与 Ansible 的轻量 GitOps 闭环，并通过 Evidence Pack、Policy-as-Code 与 AI Proposal Review 机制，将一次性故障处理经验沉淀为可审核、可验证、可版本化、可复用的受控运维能力。

相比普通 CRUD + 大模型 API，本路线体现了更完整的工程能力：

• GitOps：基础设施期望状态版本化。
• DevOps：变更计划、执行、验证、回滚闭环。
• AIOps：基于证据包的故障分析，而非自由聊天。
• 安全工程：策略校验、风险评级、人工审核、审计日志。
• 平台工程：把运维经验沉淀为标准化模块。

这既服务毕业设计，也能支撑 AI Agent / DevOps / SRE / 平台工具方向的实习投递。