Operational Knowledge Graph¶
Stand: 2026-09-01
Zweck und Betriebsstatus¶
Der Operational Knowledge Graph (OPKG) ist die read-only Kontextschicht fuer nicht-triviale operative Plaene. Er verbindet bestaetigte Abhaengigkeiten, Access Paths, Workflows, Runbooks und Source-of-Truth-Verweise, ersetzt aber weder Customer-Ops noch die autoritativen Zielsysteme.
V1 ist produktiv in Betrieb. Der Pilotbestand umfasst 158 Nodes, 163 Beziehungen und 24 Quellen. Die sieben produktiven Akzeptanzfragen wurden ueber den festen Provider erfolgreich beantwortet.
| Feld | Wert |
|---|---|
| Proxmox-Typ | VM |
| VMID | 136 |
| Name | opkg |
| Betriebssystem | Debian 13 |
| Ressourcen | 4 vCPU, 8 GiB RAM, 80 GiB Disk |
| Netz | VLAN 40 ueber vmbr0 |
| Verifizierte IP | 10.222.40.40/24 |
| Gateway | 10.222.40.1 |
| Laufzeit | Neo4j Community 2026.07.1 mit APOC 2026.07.1 |
| Datenpfad | /srv/lanstyle-operational-knowledge |
| Betriebsdateien | /opt/lanstyle-operational-knowledge |
opkg.ad.lanstyle.de ist nur der geplante DNS-Name. Solange A- und PTR-Record
nicht tatsaechlich verifiziert sind, darf dieser Name nicht als autoritativ
behandelt werden. Der bestaetigte technische Zugriffspunkt bleibt
10.222.40.40.
Zugriff¶
Der normale Agentenzugriff erfolgt read-only ueber MCPHub:
Codex
-> https://mcphub.lanstyle.de/lanstyle-mcp
-> lanstyle:knowledge:read plus Kundenscope
-> Neo4j auf 10.222.40.40:7687
MCPHub stellt sieben kundengebundene OPKG-Werkzeuge bereit. Vor einer Abfrage
werden Kundenscope und lanstyle:knowledge:read geprueft. Bolt ist nicht aus
dem Internet erreichbar und wird nur aus den vorgesehenen Management- und
MCPHub-Quellen zugelassen. Der Neo4j-HTTP- und Adminzugriff bleibt auf
Managementquellen begrenzt.
Credentials liegen ausschliesslich in Vaultwarden. Die operative Referenz ist
lanstyle-operational-knowledge-neo4j; Secretwerte gehoeren weder in dieses
Wiki noch in Git, Logs oder Receipts.
Daily-Ops-Verhalten¶
Vor einem nicht-trivialen operativen Plan fragt Codex den kundengebundenen Graphen best effort nach folgenden Informationen:
- Abhaengigkeiten und bevorzugter Access Path
- bestaetigter Workflow und CredentialRef
- Provider beziehungsweise Capability
- Runbook- und Wiki-Verweise
- Source of Truth und Datenstand
Der Graph ist keine harte Laufzeitabhaengigkeit. Bei Ausfall, Mehrdeutigkeit oder veraltetem Datenstand wird ohne Blockade auf Customer-Ops und die autoritativen Zielsysteme zurueckgefallen. Unbestaetigte Annahmen und Secrets werden nicht in den Graphen geschrieben.
Backup und Restore¶
Die Neo4j-Datenbanken neo4j und system werden als Offline-Dump gesichert.
Dump und Manifest werden per SHA-256 geprueft. Ein isolierter Restore-Test wurde
erfolgreich durchgefuehrt; die Produktivinstanz blieb danach gesund.
Retention-Vorgabe:
- lokale Offline-Dumps: 14 Generationen, produktiv aktiv
- PBS-Sicherung fuer VM 136: Ziel 7 daily, 4 weekly und 6 monthly
Ein echter VM-136-Snapshot wurde erfolgreich erstellt und durch PBS
verifiziert. Die VM-spezifische PBS-Retention ist noch nicht aktiv: Das
vorhandene PBS-Token darf sichern, besitzt aber keine Prune-Berechtigung;
serverseitiges Prune kann ohne separaten Namespace nicht nur auf vm/136
begrenzt werden. Der bestehende All-VM-Job bleibt deshalb unveraendert bei
keep-all=1. Eine isolierte Namespace-/Credential-Entscheidung oder eine
bewusst zentrale Datastore-Retention ist separat erforderlich. Andere VMs
wurden nicht veraendert.
Pflege¶
- Customer-Ops und autoritative Systeme bleiben fuehrend.
- Nur bestaetigtes, dauerhaft relevantes Betriebswissen importieren.
- Nach Aenderungen Import, feste Akzeptanzfragen und Kundenscope pruefen.
- Das menschlich relevante Betriebswissen in diesem Wiki pflegen; dynamische Inventardaten nicht duplizieren.
- DNS erst nach tatsaechlichem A/PTR-Read-after-write als bestaetigt aufnehmen.