Aufbewahrungsgrenzen festlegen

Die Aufbewahrungsrichtlinie bestimmt, wie lange Tale einzelne Datenkategorien behält. Betreiber legen die zulässigen Grenzen fest; Organisationsadmins aktivieren Kategorien und wählen eine Dauer innerhalb dieser Grenzen. Eine kürzere Dauer kann vorhandene Historie löschen. Prüfe deshalb die Folgen vor der Übernahme.

Grenzen und Richtlinie unterscheiden

Zwei Dateien unter TALE_CONFIG_DIR/<orgSlug>/governance/ erfüllen unterschiedliche Aufgaben:

Jede Organisation erhält bei ihrer Erstellung eigene Dateien. Eine Änderung an einer Organisation ändert nicht die Richtlinie einer anderen. Fehlt ihre Grenzdatei, greift Tale nicht auf eine Organisation namens default zurück.

Jede Kategorie enthält min, max, default und unit. Ein höheres min verlangt eine längere Aufbewahrung; ein niedrigeres max begrenzt die zulässige Dauer. Keiner der beiden Werte aktiviert allein die Bereinigung. Dafür ist die angewendete Richtlinie maßgeblich.

Grenzen einer Organisation ändern

Gehe von der vorhandenen vollständigen Datei aus und behalte unveränderte Kategorien bei. Dieser Ausschnitt zeigt eine einzelne Kategorie; er ersetzt nicht die gesamte Datei:

chatHistory:
  min: 30
  max: 730
  default: 90
  unit: days

Die meisten Kategorien verwenden Tage; userTempHours und agentTempHours verwenden Stunden. Die Kategorie für den Tokenverbrauch heißt usageLedger. Verwende die Bezeichner aus der vorhandenen Datei, damit die Validierung Fehler erkennen kann.

Umgebungsvariablen werden ausdrücklich in _metadata.envNames an der Dateiwurzel zugeordnet, optional mit _metadata.envPrefix. Die mitgelieferte Datei ordnet beispielsweise TALE_RETENTION_AUDIT_MIN dem Feld auditLog.min zu. Eine Mindestgrenze darf über die Umgebung nur steigen, eine Höchstgrenze nur sinken. Starte die Backend-Prozesse nach Änderungen ihrer Umgebung neu.

Ein Release kann eine Kategorie hinzufügen, nachdem die Datei einer Organisation angelegt wurde; automationVersions ist eine davon. Solange die Datei der Organisation sie nicht aufführt, übernimmt Tale die Grenzen dieser Kategorie und ihre Umgebungsvariablen aus der mitgelieferten Datei. Die mitgelieferte Datei ordnet ihr TALE_RETENTION_VERSIONS_MIN, TALE_RETENTION_VERSIONS_MAX und TALE_RETENTION_VERSIONS_DEFAULT zu. Trage die Kategorie in die eigene Datei der Organisation ein, um ihr eigene Grenzen zu geben; sobald die Datei die Kategorie enthält, gilt die Datei. Wie bei jeder Änderung der Grenzen sieht der Admin der Organisation den Vorschlag unter Richtlinien & Limits und übernimmt ihn, bevor die Bereinigung die Kategorie durchsetzt.

Zwei Untergrenzen sind fest vorgegeben: auditLog.min darf nicht unter 180 Tagen liegen und loginAttempt.min nicht unter 90 Tagen. Eine Datei, die eine davon unterschreitet, lädt Tale nicht. Bis du sie korrigierst, zeigt die Aufbewahrungsrichtlinie der Organisation keine zulässigen Bereiche an und lässt sich nicht speichern; das Backend-Protokoll nennt beide Untergrenzen. Die geplante Bereinigung arbeitet weiter mit den zuletzt übernommenen Grenzen.

Mit der mitgelieferten Datei kann eine Organisation Audit-Logs 180 bis 3650 Tage aufbewahren. Ein Upgrade von Tale überschreibt die Datei einer Organisation nicht. Eine Organisation aus einem früheren Release kann deshalb noch auditLog.min: 365 enthalten. Senke diesen Wert, um eine kürzere Aufbewahrung der Audit-Logs zu erlauben, oder erhöhe ihn, wenn eine Vorschrift oder ein Vertrag eine längere Audit-Historie verlangt.

Änderung prüfen und übernehmen

Bitte nach der Änderung den Organisationsadmin, den Vorschlag unter Richtlinien und Grenzen zu prüfen. Die Bereinigung verwendet den übernommenen Stand der Grenzen. Eine Dateiänderung des Betreibers aktiviert neue Grenzen nicht stillschweigend.

Prüfe aktivierte Kategorien, bisherige und neue Fristen sowie eine mögliche Schonfrist. auditLogRetentionDays: 730 ist eine gewählte Dauer; auditLog.min: 180 ist eine Mindestgrenze. Unterscheide diese Bedeutungen beim Prüfen eines Diffs.

Ergebnis der Bereinigung verstehen

Der Backend-Worker bereinigt Daten nach Zeitplan und getrennt je Organisation. Threads, Dokumente, Kontakte und externe Konversationen durchlaufen einen Lebenszyklus. Kategorien mit einzelnen Datensätzen können nach Aufbewahrungs- und Schonfrist direkt gelöscht werden. Nicht jeder gelöschte Datensatz erscheint im Papierkorb.

Jeder Lauf löscht je Kategorie und Organisation nur eine begrenzte Zahl von Datensätzen: bis zu 50.000 Chat-Filter-Ereignisse und bei allen anderen Kategorien Stapel von höchstens 1.000 Datensätzen. Ein größerer Rückstand, etwa eine lange Historie beim ersten Aktivieren einer Kategorie, wird über mehrere tägliche Läufe abgebaut.

automationVersions entfernt gespeicherte Versionen von Automatisierungen, die älter als der gewählte Zeitraum sind. Die Kategorie ist aus, bis ein Admin sie einschaltet, und die mitgelieferten Grenzen erlauben 90 bis 3650 Tage. Unabhängig vom Zeitraum behält die Bereinigung, was das Produkt noch liest: die Live-Version, die Versionen der letzten zehn Live-Schaltungen, jede Version, die ein Lauf verwendet hat, die neuesten zwanzig Versionen, die Versionen, aus denen diese wiederhergestellt wurden oder auf denen sie basieren, und Versionen, die eine Person unter Aufbewahrungssperre gespeichert hat. Eine Versionsnummer wird nie erneut vergeben. Für jede Automatisierung, die Versionen verloren hat, schreibt die Bereinigung ein Audit-Ereignis, das sie benennt.

Auch Audit-Einträge werden je Organisation aufbewahrt. Die Bereinigung entfernt den ältesten zulässigen zusammenhängenden Anfang ihrer Audit-Kette und stoppt an einem Eintrag, den eine Aufbewahrungssperre schützt. Eine kürzere Frist eines Mandanten verkürzt nicht die Historie eines anderen.

Jeder Bereinigungslauf wird im Audit-Log der Organisation als Systemereignisse der Kategorie Daten festgehalten. Er beginnt mit Aufbewahrungs-Run gestartet, erfasst für jede Kategorie, in der er Datensätze gelöscht hat, ein einziges Ereignis mit deren Anzahl statt eines Ereignisses pro Datensatz, und endet mit Aufbewahrungs-Run abgeschlossen. Stoppt ein Lauf an einem Fehler oder behält er fällige Datensätze, weil ihre Löschung fehlgeschlagen ist, endet er stattdessen mit Aufbewahrungs-Run fehlgeschlagen; der nächste geplante Lauf versucht diese Datensätze erneut. Alle Ereignisse eines Laufs nennen denselben Aufbewahrungs-Run als Ziel, und auch ein Lauf, der nichts zu löschen findet, hält Beginn und Ende fest.

TALE_RETENTION_DISABLED=true pausiert die geplante Aufbewahrungsbereinigung für ein Wartungsfenster. Die Variable stellt keine Daten wieder her und verhindert keine anderen Löschwege. Halte ihre Aktivierung fest und entferne sie nach der Wartung.

Gesperrte Daten bewahren

Aufbewahrungssperren haben für ihren unterstützten Geltungsbereich Vorrang vor der Richtlinie. Eine organisationsweite Sperre schützt die Organisation; engere Sperren schützen die zugeordneten Objekte oder Personen. Lies den Ablauf für Aufbewahrungssperren, bevor du eine betroffene Richtlinie änderst.

Eine Sperre ersetzt kein Backup. Sind Daten außerhalb einer Sperre bereits gelöscht, bringt eine längere Frist sie nicht zurück. Dafür brauchst du ein erhaltenes Backup und den dazu passenden Bereitstellungsstand.