- Jede neue Datenquelle ist ein kleines Projekt, weil die Plattform keinen Self-Service-Pfad dafür hat.
- Die Plattform funktioniert, aber zwei Personen wissen, wie, und keine davon ist in Ihrem Team.
- Zugriffsrechte, Logs und Dashboards widersprechen sich, deshalb traut niemand einer Abfrage.
- Ein Trino-, NiFi- oder Kafka-Bestand ist gewachsen und die Abhängigkeiten sind inzwischen Vermutung.
Leistung
Daten- und integrationslastige Systeme
Ich mache interne Datenplattformen betreibbar: ein Pfad für eine neue Quelle, eine Stelle für die Logs und eine Verantwortlichkeit, die die nächste Umorganisation übersteht.
Wann Teams anrufen
Die Situation, zu der das passt
Diese Plattformen scheitern selten laut. Sie werden langsamer in der Veränderung.
Vorgehen
Drei Phasen, überlappend
Nichts davon beginnt mit einer Zielarchitektur. Es beginnt damit, was die Plattform heute tatsächlich tut.
-
01
Flüsse aufnehmen
Ich verfolge Daten von der Quelle bis zum Dashboard und notiere jede Stelle, an der sie transformiert, zwischengespeichert oder kopiert werden. Ergebnis ist ein Bild davon, was von was abhängt.
-
02
Den Eingang festlegen
Was ein Datenteam anfragt und was es ohne Nachfrage bekommt: Provisioning, Credentials, Registry-Einträge, Query-Routing, Zugriffsregeln. Das ist der Vertrag, der die Ticket-Warteschlange ersetzt.
-
03
Einen Schnitt umsetzen
Eine Quelle, vollständig über den neuen Pfad provisioniert, während das Team zusieht. Self-Service, der nie benutzt wurde, ist ein Diagramm und keine Fähigkeit.
Ergebnis
Was am Ende vorliegt
Dokumentation, die zum System passt, und ein Pfad, der den manuellen Schritt entfernt.
- Ein Bild der Plattform: Quellen, Jobs, Speicher, Query-Schicht und Verantwortlichkeit.
- Ein Self-Service-Pfad für die häufigste Anfrage, mit den Operatoren oder der Automatisierung dahinter.
- Query-Routing und Zugriffsregeln, die zur Organisation passen, inklusive Impersonation, wo das erwartet wird.
- Logs und Alerts an einer Stelle, mit einer Retention-Entscheidung statt drei überlappender Werkzeuge.
- Betriebsdokumentation für die Menschen, die nachts angerufen werden, nicht für das Wiki.
- Eine Liste dessen, was abgeschaltet werden sollte — meist kürzer und nützlicher als die Liste des Neuen.
Formate
Drei Arten der Zusammenarbeit
Von zwei Wochen Lesen bis zum Plattformaufbau neben Ihrem Team.
Kurzanalyse
Zwei bis drei Wochen. Ein schriftliches Bild der Plattform, ihrer Verantwortlichkeiten und der drei Änderungen, die am meisten Handarbeit entfernen.
Plattformaufbau
Drei bis sechs Monate, Teilzeit. Operatoren, Self-Service-Pfade und die Query-Schicht, gemeinsam mit dem Plattformteam statt als Übergabe.
Stabilisierung
Einige Wochen konzentrierte Arbeit an einer Plattform, die unter Last scheitert, Daten verliert oder sich nicht ohne Ausfall aktualisieren lässt.
Fragen
Vor dem ersten Gespräch
Die drei Fragen, die zuerst kommen.
Ersetzen Sie unsere Plattform oder arbeiten Sie damit?
Damit. Diese Plattformen sind teuer im Neubau und meist nah an funktionierend; die Lücke ist üblicherweise der Self-Service-Pfad, die Verantwortlichkeit oder eine Komponente, die niemand anzufassen wagt.
Arbeiten Sie mit bestimmten Werkzeugen?
Apache NiFi, Trino und Starburst, Kafka, PostgreSQL, ClickHouse, BigQuery, Dagster und Kubernetes kommen am häufigsten vor. Das Muster ist wichtiger als der Anbieter, und ich sage es, wenn ein Werkzeug nicht passt.
Geht das im laufenden Betrieb?
Es muss. Alles hier passiert auf einem laufenden System, deshalb gehören Rollback und Bereitschaftsnotizen zu den Ergebnissen und nicht nur der Zielzustand.
Kontakt
Beschreiben Sie die Plattform und wo es weh tut
Eine kurze Nachricht mit Stack, Rahmenbedingungen und Zeitplan reicht, um einzuschätzen, ob das Mandat passt.