Tasks, Ereignisse und Audit

Tasks, Ereignisse und Audit beantworten unterschiedliche Verwaltungsfragen. Ein Task sagt dem Operator, ob lang laufende Arbeit abgeschlossen wurde. Ein Ereignis hilft Oberfläche und Automatisierung, auf eine Zustandsänderung zu reagieren. Ein Audit-Datensatz sagt einem Sicherheitsprüfer, wer oder was eine folgenreiche Aktion versucht hat. Keines davon beweist allein das Ergebnis für den Kunden.

Der Ressourcenverantwortliche entscheidet, ob wiederholt oder zurückgesetzt wird, der Operator gleicht den Task-Zustand mit der zuständigen Laufzeit ab, und der Sicherheitsverantwortliche legt Aufbewahrung und Export des Audits fest. Halten Sie diese Datensätze über stabile Ressourcen-, Request-, Task- und Operations-IDs miteinander verbunden.

Tasks stehen für dauerhafte, lang laufende Arbeit wie Builds, Deployments, Migrationen, Importe, Bereitstellung und Updates. Verfolgen Sie Status, Fortschritt, Logs, Fehlercode und die Verfügbarkeit von Wiederholen/Abbrechen. Starten Sie keine Duplikate, nur weil die Verbindung eines Browsers abgebrochen ist.

Ereignisse aktualisieren den Live-Zustand der Oberfläche und lösen unterstützte betriebliche Abläufe aus. Verbraucher müssen die Autorisierung erneut prüfen und Grenzen bei erneutem Verbindungsaufbau oder Wiederholung tolerieren.

Audit-Datensätze ordnen sicherheits- und konfigurationsrelevante Aktionen Benutzern oder Systemakteuren zu. Das Sperren oder Löschen eines Benutzers entfernt die historische Zuordnung nicht. Exportieren Sie an ein SIEM, wenn unabhängige Aufbewahrung oder Korrelation erforderlich ist.

Audit-Details sollten Aktion und Ressource identifizieren, ohne Secrets, rohe Zugangsdaten, private Schlüssel, Prompts oder Modellausgaben zu speichern.

Lebenszyklus eines Tasks

Typische Task-Zustände unterscheiden eingereihte, laufende, wartende, erfolgreiche, fehlgeschlagene, abgebrochene und unterbrochene Arbeit. Die verfügbaren Zustände und Aktionen hängen von der Operation ab. Fortschritt ist ein Beleg des zuständigen Workers oder Daemons, keine Animation im Browser.

Halten Sie die Task-ID fest, bevor Sie eine lang laufende Operation verlassen. Das Neuladen der Seite muss sich wieder mit dem dauerhaften Zustand verbinden, statt eine zweite Operation zu erzeugen. Geht eine Befehlsantwort verloren, prüfen Sie sowohl den Task als auch den Eigentümer, bevor Sie es erneut versuchen.

Wiederholen, Abbrechen und Force Cancel

Wiederholen Sie nur, wenn der Task-Vertrag die Operation als wiederholbar kennzeichnet oder der Abgleich beweist, dass der vorherige Versuch einen Endzustand erreicht hat. Abbruchanfragen sind kooperativ, wenn der Eigentümer Abbrüche unterstützt. Force Cancel kann Opfield davon abhalten, auf eine verlassene Operation zu warten, rechtfertigt aber nicht die Annahme, dass die zugrunde liegende Laufzeitaktion nie stattgefunden hat.

Aktualisieren Sie nach einem Abbruch oder einer Unterbrechung die Ressource von ihrem Eigentümer und lösen Sie eine etwaige Operationsmarkierung auf, bevor Sie eine weitere Änderung starten.

Ereignisse und Echtzeitzustand

Echtzeitereignisse verringern die Latenz der Oberfläche, sind aber nicht die einzige Quelle der Wahrheit. Clients müssen Verbindungsabbrüche, Wiederholungen, doppelte Zustellung und ein Ereignis tolerieren, das vor einer aktualisierten Momentaufnahme eintrifft. Laden Sie nach dem erneuten Verbindungsaufbau die maßgebliche Momentaufnahme und führen Sie neuere Ereignisse über die stabile Ressourcenidentität zusammen.

Ereignisse, die Automatisierung auslösen, müssen aktuelle Autorisierung, Zuständigkeit, Leistungsumfang und Lebenszykluszustand erneut prüfen. Eine historische Berechtigung bei der Erzeugung des Ereignisses autorisiert keine spätere Änderung.

Interpretation des Audits

Audit-Datensätze identifizieren Akteur, Aktion, Ressource, Zeitstempel, Ergebnis und relevanten Anfragekontext. System- und Automatisierungsakteure müssen von menschlichen Sitzungen und Identitätswechseln unterscheidbar bleiben. Das Sperren oder Löschen eines Benutzers bewahrt die historische Zuordnung.

Das Audit ist kein Debug-Log. Verwenden Sie betriebliche Logs und Tasks für Implementierungsdetails und das Audit für die Rechenschaft über Sicherheit und Konfiguration. Exportieren Sie in unabhängig kontrollierten SIEM-Speicher, wenn Aufbewahrung oder Korrelation einen Vorfall von Opfield überstehen müssen.

„Unveränderliche Zuordnung“ bedeutet, dass Änderungen im Lebenszyklus eines Kontos den historischen Akteur eines Audit-Datensatzes nicht umschreiben. Es bedeutet nicht, dass die lokale Audit-Datenbank ein WORM-Speicher oder kryptografisch manipulationssicher gegenüber einer Person ist, die den Opfield-Host, PostgreSQL, Backups oder Verschlüsselungsschlüssel kontrolliert. Diese Administratoren bleiben innerhalb der Vertrauensgrenze.

Verlangt eine Richtlinie Belege, die eine Kompromittierung der Control Plane überstehen, exportieren Sie Audit-Datensätze fortlaufend an ein unabhängig administriertes SIEM oder ein WORM-fähiges Ziel, schränken Sie das Löschen dort ein, synchronisieren Sie die Zeit und überwachen Sie Lücken im Export. Halten Sie die externe Aufbewahrungsrichtlinie und die Zugriffsprüfung getrennt von der Administration von Opfield.

Checkliste für Untersuchungen

1. Identifizieren Sie die Ressource und die für Kunden sichtbare Auswirkung.
2. Finden Sie den auslösenden Audit-Datensatz und die Request-ID.
3. Finden Sie den dauerhaften Task oder die Operation.
4. Vergleichen Sie den Sollzustand mit dem aktuellen Zustand des Eigentümers.
5. Prüfen Sie zeitlich eingegrenzte betriebliche Logs.
6. Halten Sie Wiederholung, Abbruch, Rollback und abschließende Prüfung fest.

Erfolg und Fehler interpretieren

Ein erfolgreicher Task bedeutet, dass der zuständige Ablauf seinen dokumentierten Endzustand erreicht hat. Er beweist nicht unbedingt DNS-Verbreitung, Zugriff externer Clients, Korrektheit auf Anwendungsebene, zugestellte E-Mails, verarbeitete Webhook-Daten oder wiederhergestellte Geschäftsdaten. Ergänzen Sie eine unabhängige Prüfung, die zur Ressource passt.

Ein fehlgeschlagener oder unterbrochener Task beweist nicht, dass keine Nebenwirkung eingetreten ist. Der Eigentümer kann einen Container erstellt, eine Datei geschrieben, einen Anbieter geändert oder eine Laufzeitaktion abgeschlossen haben, bevor die Bestätigung verloren ging. Lesen Sie den aktuellen Zustand des Eigentümers und den Operationsverlauf, bevor Sie bereinigen oder wiederholen.

Wartende Zustände sollten die Abhängigkeit oder die benötigte Eingabe nennen. Bleibt ein Task ohne klaren Eigentümer im Wartezustand, bewahren Sie seine IDs und eskalieren Sie, statt Force Cancel als routinemäßige Bereinigung zu verwenden.

Bereinigung und Aufbewahrung

Die Bereinigung entfernt Daten, die Opfield nicht mehr benötigt, standardmäßig täglich um 02:00 Uhr. Konfigurieren Sie sie unter Settings > Features > Housekeeping: housekeeping:view zeigt Konfiguration, Statistiken und Laufverlauf, housekeeping:run startet einen Lauf, und housekeeping:configure ändert Kategorien und Zeitplan. Jede Kategorie kann ausgeschaltet werden. Die Kategorie Audit Log bewahrt standardmäßig 90 Tage auf; exportieren Sie Audit-Datensätze an ein SIEM, wenn eine Richtlinie eine längere Aufbewahrung verlangt.

Zwei in 2.11 hinzugekommene Kategorien sind standardmäßig eingeschaltet:

Kategorie	Was sie entfernt
Operation History	Abgeschlossene Tasks von Docker-Containern nach einem Tag. Nach der Aufbewahrungsfrist, standardmäßig 90 Tage: abgeschlossene Builds mit ihren Logs, leere Build-Batches, abgeschlossene Compose-, Workload-Availability- und Hosting-Operationen sowie Webhook-Zustellungen von Git-Quellen. Jede Ressource behält ihre 10 neuesten Läufe, und Datensätze, die noch etwas verwendet – ein Build-Artefakt, eine Availability-Platzierung, ein Snapshot oder der Ursprung eines gehosteten Nodes –, bleiben erhalten
Expired OAuth Grants	Abgelaufene OAuth-Autorisierungscodes sowie Access- und Refresh-Tokens und OAuth-Clients, die seit 90 Tagen keine Berechtigung hatten. Ein Refresh-Token wird bis zu seinem Ablauf aufbewahrt, damit seine Wiederverwendung weiterhin erkannt wird

Weitere Kategorien umfassen nginx-Logs, verworfene Alarme, Zustellungen von Benachrichtigungen, strukturierte Logs, ClickHouse-Systemtabellen, verwaiste KI-Artefakte, die interne Registry, verwaiste Volumes, ausgemusterte Schlüssel der System-PKI, ACME-Challenge-Dateien und alte Opfield-Images.

Aufbewahrung und externe Belege

Audit-Zeilen gehen nicht verloren, wenn Opfield stoppt. Beim Herunterfahren schreibt Opfield die noch in Bearbeitung befindlichen Zeilen, bevor es die Datenbankverbindung schließt. Ist die Datenbank bereits weg, etwa beim Herunterfahren eines Hosts, bei dem alle Container gleichzeitig stoppen, wird eine Zeile, die nicht geschrieben werden kann, an eine Spool-Datei auf dem Daten-Volume der Anwendung (/var/lib/opfield/audit-spool) angehängt und beim nächsten Start mit ihrer ursprünglichen ID gespeichert, sodass eine auf halbem Weg abgebrochene Wiedergabe nie eine Zeile doppelt hinzufügt; der SIEM-Export übernimmt die gespeicherten Zeilen. Neue Installationen stoppen PostgreSQL außerdem mit einem Smart Shutdown, der bis zu 75 Sekunden wartet, bis Opfield seine Verbindungen schließt; bestehende Installationen erhalten dies, wenn ihr PostgreSQL-Container das nächste Mal neu erstellt wird.

Bewahren Sie Audit-Datensätze gemäß Sicherheits- und Compliance-Richtlinie auf und exportieren Sie in unabhängig kontrollierten SIEM-Speicher, wenn die Belege einen Ausfall von Opfield oder die Kompromittierung eines Administrators überstehen müssen. Betriebliche Task-Logs können eine andere Aufbewahrung und Sensibilität haben. Erweitern Sie Audit-Payloads nicht um Secrets oder rohe Request-Bodys, nur um die Fehlersuche zu erleichtern.

Wenn Sie Belege an den Support oder ein anderes Team weitergeben, fügen Sie Zeitstempel, stabile IDs, Endzustand, bereinigte Fehlerdetails und das Ergebnis der unabhängigen Prüfung bei. Entfernen Sie Zugangsdaten, interne Topologie, Kundendaten, Prompts, Modellausgaben und unbeschränkte Logs.