Multi-Source: Identität und Betrieb
Environments, stabile FQNs, Soft-delete, Drift, Monitoring und Scorecards für Connector-Gesundheit über mehrere Services hinweg.
Herausforderung
Mit mehreren Services entstehen typische Betriebsfehler: Prod und Dev im selben Namespace, gelöschte Tabellen die kuratierte Felder mitreißen, unbemerkter Drift und niemand, der Stale-Ingestion eskaliert. Einzelne Connectoren „laufen“ — das Estate als Produkt fehlt.
Ansatz
Multi-Source-Betrieb als Produkt führen: stabile FQNs und Environments, explizite Delete-/Soft-delete-Regeln, Drift-Monitoring und eine Connector-Scorecard (Freshness, Coverage, Fehlerquote, Verantwortung).
Services × Environments
→ stabile Identity
→ Soft-delete / Quarantäne
→ Scorecard + Eskalation
Betriebsregeln
| Thema | Regel | Tipp |
|---|---|---|
| Environments | Getrennte Services oder klare Namespace-Prefixe — nie still mischen | UI-Filter und Naming prüfen |
| FQN/Identity | Anzeigenamen ändern sich; stabile IDs behalten | Rename ≠ neue Identity ohne Migration |
| Delete | Soft-delete nach bestätigten Misses; kuratierte Felder schützen | Policy pro Service-Typ testen |
| Drift | Schema-Änderungen als Change-Events behandeln | Nicht nur „Ingestion grün“ |
| Scorecard | Freshness, Success-Rate, Asset-Coverage, Owner-Coverage | Consumer-Outcome getrennt halten |
Best Practices
Estate-Inventory als eine Seite
Jeder aktive Connector: Owner, SLO, Secret-Pfad, Delete-Policy, Environment. Neuer Connector ohne Zeile = kein Go-Live. Ohne Inventory sind Alerts und Reviews Rätselraten über „was läuft überhaupt“.
Stale und Failure getrennt alerten
Exit ≠ 0 und „letzter Erfolg zu alt“ sind verschiedene Incidents (Getting Started Teil 7). Ein Alert-Kanal für beides erzeugt Müdigkeit oder blinde Flecken. Kritische Flows priorisieren; wöchentlich nur rote SLOs, monatlich das Estate.
Scorecard mit Trends, nicht nur Snapshots
Freshness, Success-Rate, Owner-Coverage der kritischen Assets — monatlich im Platform-/Governance-Review. Adoption (Glossary %) bewusst getrennt: sonst wird Connector-Health schöngerechnet. Ampel sparsam (siehe Scorecard-Beispiel unten).
Neue Systeme nur mit Decision Record (Teil 1)
„Schnell noch Connector X“ umgeht Scope, Delete und Owner — und vergiftet das Estate. Jede Erweiterung = Record + Inventory-Zeile + Alert-Ziel.
Quarantäne vor Hard-Delete
Miss-Threshold kalibrieren (zu aggressiv → False Deletes; zu lasch → Geister). Soft-delete/Quarantäne schützen Descriptions, Glossary-Links und Owner. Auf Staging testen, bevor Prod auto-löscht.
Stolperfallen
Copy-Config Dev → Prod ohne Environment-Diff — Prod-Assets unter Dev-Namen oder umgekehrt.
Auto-Delete ohne Staging-Test. Stewardship-Verlust in einem Run.
Eine Ampel für Health und Adoption. Unklare Maßnahmen; bitte trennen.
Ein On-Call ohne Connector-Owner. Betriebsvorfälle vs. Source-Rechte vermischen sich.
Drift ignorieren, weil exit 0 — Schema-Change ist trotzdem ein Change-Event.
Vorgehen
- Inventory aller aktiven Connectoren mit Owner und SLO.
- Environment-Matrix prüfen (keine Prod-Assets unter Dev-Service).
- Delete-Policy pro Service-Typ dokumentieren und auf Staging testen.
- Alerts bei Stale-Ingestion und wiederholten Failures.
- Monatliche Scorecard; Ausreißer mit Decision-Record-Update schließen.
Troubleshooting
- Plötzliche Asset-Flut: neuer Umfang oder Filter-Regression — Run-Diff prüfen.
- Massive Deletes: Miss-Threshold und Source-Outage; Soft-delete/Quarantäne.
- FQN-Brüche nach Rename: Identity-Strategie und ggf. Migration/Alias.
- Alert-Müdigkeit: Thresholds und Dedup; kritische Flows priorisieren.
Scorecard-Beispiel (Monat)
| Signal | Grün | Rot |
|---|---|---|
| Freshness | ≥ 95 % Connectoren innerhalb SLO | Unter 90 % oder kritischer Flow stale |
| Success-Rate | ≥ 98 % Runs ok | Wiederholte Failures ohne Owner-Response |
| Owner-Coverage | Kritische Assets ≥ 90 % | Pilotprojekt-Flow unter 70 % |
| Delete-Incidents | 0 ungeplante Hard-Deletes | Kuratierte Felder verloren |
Consumer-Adoption (Glossary, Domains) bewusst nicht in dieselbe Ampel — sonst wird Connector-Health schöngerechnet.
Hilfe beim Umsetzen
Estate-Inventory-Tabelle anlegen (Connector, Env, Owner, SLO, Secret, Delete-Policy). Monatliche Scorecard nur Health-Signale; Adoption getrennt. Neue Connectoren nur mit Teil-1-Record + Inventory-Zeile. Standard-Configs über OpenMetadata-Ingestions-Generator vereinheitlichen.
Checkliste
- Hat jeder Connector einen Owner und Freshness-SLO?
- Sind Environments in Identity und UI unterscheidbar?
- Ist Soft-delete getestet — ohne Verlust kuratierter Felder?
- Gibt es eine Scorecard, die Nutzer-Outcome nicht mit Connector-Health vermischt?
- Ist das Estate-Inventory aktuell?
Artefakt
Connector Estate Scorecard + Runbook für Stale/Failure/Delete + aktualisiertes Inventory.
Tools
- OpenMetadata-Ingestions-Generator — standardisierte Job-Configs über das Estate.
- OpenMetadata Connectors — Connector-Betrieb und Ingestion-Übersicht.
- Observability/Alerting + Change-System (intern) — Stale/Failure und Scorecard.
Ressourcen
- Getting Started Teil 7 — Backup, Upgrade, Betrieb
- Governance Teil 8 — Adoption und Scorecards
Weiterlesen
OpenMetadata: Connecting Source Systems
Part 8 of 8
View series