Refresh, Gateway und Credential-Verantwortung
Refresh-SLO, Credential-Owner und Gateway sind Kontrollpunkte — kein Laptop-Gateway und kein geteiltes Passwort als System of Record.
Begriffe vor dem Lesen
- Publish — Freigabe und Bereitstellung eines BI-Produkts für Nutzung.
- Workspace / Stage — Arbeits- oder Veröffentlichungsbereich für Entwicklung, Test und produktive Nutzung.
- Refresh — Aktualisierung von Datenmodell, Kennzahlenmodell oder Reportdaten.
- Berechtigung — Berechtigung, welche Person welche Daten oder Flächen nutzen darf.
- RLS / OLS — Row-Level- und Object-Level-Security; Zugriff auf Zeilen oder Objekte im BI-Modell.
Ein zertifiziert-Report auf gestrigen Zahlen ist kein Operating. Refresh braucht ein SLO (wie frisch die Zahl sein muss), ein A für Credentials und ein On-Premises Gateway als Betrieb — nicht den Laptop des Builders.
In der Praxis zeigt sich das so: Der zertifiziert Power-BI-Report zeigt 12,4 Mio. Nettoumsatz von gestern, weil das Gateway auf dem Laptop des Builders hing.
Dieser Teil hängt den Datenpfad an den Publish-Vertrag aus Teil 1 und 2.
Vorher: Workspace, Stage und Promotion-Gates. Weiter: BI erzwingt die Berechtigungsmatrix.
Entscheidung
Binden Sie drei Felder an jedes Prod-Artefakt, das steuert:
- Refresh-SLO — Kadenz, erlaubte Verspätung, was bei Bruch gilt (Board pausiert / letzte gültige Periode / Incident). Ohne SLO ist „täglich“ ein Wunsch.
- Credential-Owner — benannte Identität (Dienstkonto), Rotation, kein Chat-Secret. Der Builder ist nicht das Konto.
- Gateway-Betrieb — Cluster oder Plattform-Gateway mit Custodian-A; persönliches Gateway nur für Dev, nie für Board. High availability ist Betrieb, kein Nice-to-have, sobald Steuerung hängt.
- Fail-sichtbar — stale oder fehlgeschlagen muss im Consumer-Kontext erkennbar sein, nicht nur im Admin-Portal.
- Hüte — Custodian betreibt Gateway und Konto; Steward triagiert Refresh-Incidents; Data Owner entscheidet, ob das Board bei Bruch pausiert.
Qlik Reloads, Tableau Extracts/Bridge und Fabric/Power-BI-Refresh sind Adapter. Dasselbe A, dieselbe Stop-Regel.
Refresh-Workflow
1. SLO am Artefakt festhalten
Steward schreibt Kadenz und Bruchregel in den Publish-Vertrag. „Irgendwann nachts“ ist kein SLO.
2. Konto vom Menschen trennen
Custodian führt das Dienstkonto. Rotation und Vault gehören zum Betrieb. Ein persönliches OAuth-Token als Prod-Refresh ist ein Incident.
3. Gateway aus der Bau-Zone holen
Persönliches Gateway darf Dev speisen. Prod braucht betriebenes Gateway oder Plattform-Refresh ohne Laptop. Urlaub des Builders darf den Close nicht stoppen.
4. Bruch als Incident
Fehlschlag oder Überschreiten des SLO öffnet ein Ticket an Steward plus Consumer-Hinweis. Stille Wiederholung „bis es wieder geht“ züchtet Board auf Gestern.
5. Evidence
Letzter erfolgreicher Lauf, Konto, Gateway-Knoten, Owner. Ein Screenshot ohne Zeitstempel ist keine Evidence.
Handoffs
| Von | An | Artefakt |
|---|---|---|
| Steward | Custodian | Refresh-SLO am Prod-Artefakt |
| Custodian | Steward | Dienstkonto + Gateway-Nachweis |
| Custodian | Steward | Incident: SLO gerissen oder Gateway down |
| Steward | Data Owner | Entscheidung: Board pausieren oder letzte gültige Periode |
| Data Owner | Consumer | Hinweis: Zahl gilt / gilt nicht |
Anti-Patterns
- Laptop-Gateway als Produktions-führendes System
- Passwort im Team-Chat oder in der Kennzahl-Datei
- Zertifizierungslabel bei gerissenem Refresh
- Builder als einziges Credential-A
- Gateway-Ausfall erst am Close-Morgen entdecken, ohne Nutzer-Hinweis
Umsetzung im Alltag
Dieser Einstieg ist kein Kalenderzwang und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.
- Für das Board-Semantic Refresh-SLO und Credential-Owner in einem Satz schreiben.
- Persönliche Gateways an Prod-Artefakten inventarisieren und umziehen oder als Incident markieren.
- Einen fehlgeschlagenen Lauf als Incident inkl. Consumer-Hinweis üben.
- Chat-Secrets durch ein Dienstkonto ersetzen.
BI publish deep dive
Part 3 of 5
View series