Von Andrew Tan
Das Postmortem-Paradoxon
Jedes große Technologieunternehmen veröffentlicht sie jetzt. Stripe hat eine Statusseite voller davon. Netflix schreibt detaillierte technische Analysen. Uber, LinkedIn, GitHub, Cloudflare — sie alle haben den Vorhang geöffnet, um zu zeigen, was schiefgelaufen ist und warum.
Hier ist das Paradoxon: Die gleichen Fehler passieren immer wieder. Nicht bei den gleichen Unternehmen, nicht in den gleichen Systemen, aber die gleichen Muster. Ein Team bei DoorDash verliert Zahlungsdaten auf die gleiche Weise, wie ein Team bei Netflix vor drei Jahren Ansichtsmetriken verlor. Eine Uber-Datenpipeline bricht 2024 aufgrund von Schema-Drift zusammen, genauso wie eine LinkedIn-Pipeline 2021.
Ich habe die letzten Wochen damit verbracht, 50 öffentliche Postmortems und Zwischenfallberichte von Unternehmen zu lesen, die zusammen Billionen von Ereignissen verarbeitet haben. Das Ziel war nicht, jeden möglichen Fehlermodus zu katalogisieren. Es ging darum, die Cluster zu finden — die Hauptursachen, die oft genug auftauchen, dass sie nicht als einmaliges Pech abgetan werden können.
Vier Muster dominieren. Und was mich überraschte: Die meisten davon sind im Designstadium vermeidbar, nicht im Betriebsstadium.
Wie die 50 ausgewählt wurden
Bevor wir in die Muster eintauchen, ein kurzer Hinweis zur Methodik. Ich habe mich auf öffentliche Postmortems von Unternehmen konzentriert, die groß angelegte Dateninfrastrukturen betreiben: Uber, Netflix, Stripe, LinkedIn, GitHub, Cloudflare, DoorDash, Airbnb, Spotify und AWS. Ich habe Sicherheitsverletzungen und reine Infrastrukturausfälle (wie DNS-Ausfälle) übersprungen, es sei denn, sie betrafen direkt Datenpipelines.
Die Auswahl war nicht zufällig. Ich habe Postmortems priorisiert, die Folgendes beinhalteten:
- Ursachenanalyse mit technischer Tiefe
- Zeitachse des Fehlers und der Wiederherstellung
- Explizite Erwähnung von Datenqualität oder Pipeline-Auswirkungen
- Gelernte Lektionen oder Prozessänderungen
Einige Unternehmen veröffentlichen häufig (Cloudflare, GitHub). Andere selten (Netflix). Die 50 repräsentieren einen Querschnitt aus Batch-ETL, Streaming und hybriden Architekturen.
Muster 1: Schema-Drift (38% der Vorfälle)
Die häufigste Ursache war täuschend einfach: Das Upstream-System änderte sein Datenformat, und die Pipeline wusste es nicht.
In einem gut dokumentierten Vorfall entdeckte ein Datenteam, dass ein Downstream-Warehouse elf Tage lang beschädigte Datensätze geladen hatte. Die Quell-API hatte ein neues Feld hinzugefügt. Der JSON-Parser der Pipeline behandelte es als unerwarteten Schlüssel und ließ die gesamte Datensatzcharge stillschweigend fallen. Es wurden keine Warnungen ausgelöst, da die Pipeline nicht abstürzte — sie produzierte einfach weniger Zeilen als erwartet, und der Unterschied lag im normalen Schwankungsbereich, bis er es nicht mehr war.
Dies ist kein Randfall. Es ist das Standardverhalten vieler Datenintegrationswerkzeuge.
Die Postmortems zeigen drei Varianten dieses Musters:
Additive Drift
Ein neues Feld, eine neue Spalte oder ein neuer Ereignistyp erscheint. Die Pipeline ignoriert es oder schlägt fehl, je nachdem, wie streng ihre Schema-Validierung ist. Die meisten Postmortems stellten fest, dass ihre Pipelines so konfiguriert waren, dass sie "permissiv" sind, weil strenge Validierung in der Vergangenheit Fehlalarme verursacht hatte.
Typ-Drift
Ein bestehendes Feld ändert seinen Typ. Ein String wird zu einer Zahl. Ein Zeitstempel verliert seine Zeitzone. Diese sind am schwersten zu erkennen, da die Daten immer noch gültig aussehen. Ein Postmortem beschrieb eine Umsatzmetrik, die sich stillschweigend verdoppelte, weil ein Währungsfeld von ISO-Format zu einem numerischen Enum wechselte und die Pipeline den Enum-Wert als Multiplikator interpretierte.
Semantische Drift
Das Format bleibt gleich, aber die Bedeutung ändert sich. Ein "user_id"-Feld beginnt, Geräte-IDs anstelle von Konto-IDs zu enthalten. Ein "status"-Feld erhält einen neuen Zustand, den die Downstream-Logik als Fehler behandelt. Die Daten bestehen alle Validierungsprüfungen und sind dennoch falsch.
Bemerkenswert ist, wie selten diese Vorfälle von Schema-Registern oder Datenverträgen erfasst wurden. In den meisten Fällen hatten die Teams ein Register. Es wurde einfach nicht an der Pipeline-Grenze durchgesetzt. Das Schema war irgendwo dokumentiert, aber die Pipeline war nicht verpflichtet, es zu validieren.
Muster 2: Rückstau und Lastspitzen (24% der Vorfälle)
Der zweite Cluster betrifft Pipelines, die bei normaler Last perfekt funktionieren und unter unerwartetem Volumen zusammenbrechen. Der Auslöser variiert — eine Marketingkampagne, ein virales Ereignis, ein vierteljährlicher Berichtszyklus, ein falsch konfigurierter Upstream-Job, der plötzlich das 10-fache seiner üblichen Rate ausgibt.
Der Fehlermodus ist fast immer derselbe: Die Pipeline kann die Last nicht abwerfen, also lässt sie sie fallen.
Ein Postmortem von einer Streaming-Plattform beschrieb einen Kafka-Consumer, der während eines Produktstarts sechs Stunden hinterherhinkte. Die Consumer-Gruppe skalierte automatisch, aber die neuen Instanzen stießen auf ein Datenbankverbindungspool-Limit, das bei dieser Skalierung nie getestet worden war. Die Pipeline stürzte nicht ab. Sie hörte einfach auf, neue Ereignisse zu verarbeiten, während alte aus der Retention herausfielen. Als das Team es bemerkte, waren die Daten weg.
Ein weiteres beschrieb einen Batch-ETL-Job, der zwei Jahre lang gut lief, bis zum Black Friday, als das Quellsystem Dateien 40-mal größer als gewöhnlich ausgab. Der Job lief 18 Stunden, erschöpfte den temporären Speicher und schlug fehl, ohne seine partiellen Ausgaben zu bereinigen. Der nächste geplante Lauf begann auf den beschädigten Daten.
Der gemeinsame Faden: Diese Pipelines waren für den stationären Betrieb ausgelegt, nicht für Grenzbedingungen. Sie hatten Überwachungen dafür, ob sie liefen, aber nicht dafür, wie nah an ihren Grenzen sie arbeiteten.
Mehrere Postmortems stellten fest, dass Lasttests zugunsten von "wir skalieren einfach automatisch" zurückgestellt wurden. Auto-Skalierung funktioniert für Rechenleistung. Sie funktioniert nicht für Verbindungspools, Speichergrenzen, Festplatten-I/O oder Downstream-API-Ratenlimits — die Engpässe, die Pipelines tatsächlich brechen.
Muster 3: Stiller Datenverlust (19% der Vorfälle)
Dies ist das Muster, das Ingenieure nachts wach hält. Die Pipeline meldet Erfolg. Die Dashboards zeigen grün. Das SLA wird eingehalten. Aber die Daten sind unvollständig, dupliziert oder beschädigt — und niemand weiß es, bis ein Geschäftsanwender fragt, warum die Zahlen falsch aussehen.
Stiller Verlust zeigt sich in mehreren Formen in den Postmortems:
Der Filter, der zu aggressiv war
Eine Datenqualitätsregel ließ Datensätze fallen, die einem fehlerhaften Muster entsprachen. Die Regel war dazu gedacht, beschädigte Upstream-Daten zu erfassen, aber sie erfasste auch legitime Datensätze mit ungewöhnlichen, aber gültigen Werten. Über drei Wochen wurden 12% der legitimen Transaktionen herausgefiltert.
Das genau-einmal, das es nicht war
Eine Pipeline behauptete, genau-einmal-Semantik zu haben, verwendete jedoch ein nicht-idempotentes Ziel. Als ein vorübergehender Netzwerkfehler einen erneuten Versuch auslöste, wurden einige Datensätze zweimal geschrieben. Die Deduplizierungslogik existierte theoretisch, aber nicht im tatsächlichen Codepfad.
Die Retentionslücke
Eine Streaming-Pipeline schrieb in eine Nachrichtenwarteschlange mit einem 24-Stunden-Retentionsfenster. Als die Downstream-Verarbeitung aufgrund eines separaten Vorfalls ins Hintertreffen geriet, liefen die unverarbeiteten Daten ab, bevor die Wiederherstellung abgeschlossen war. Die Pipeline-Protokolle zeigten erfolgreiche Schreibvorgänge. Die Daten waren einfach nicht da, als jemand versuchte, sie zu lesen.
Was stillen Verlust so gefährlich macht, ist, dass er für traditionelle Überwachung unsichtbar ist. Pipeline-Gesundheitsmetriken — Laufzeit, Durchsatz, Fehlerrate — erfassen ihn nicht. Man benötigt Datenqualitätsmetriken: Zeilenanzahl, Kardinalitätsprüfungen, referenzielle Integrität, Verteilungstests. Die meisten Postmortems gaben zu, dass diese Prüfungen nach dem Vorfall hinzugefügt wurden, nicht davor.
Muster 4: Kaskadierende Ausfälle durch gemeinsamen Zustand (14% der Vorfälle)
Der kleinste Cluster, aber oft der katastrophalste. Dies sind Vorfälle, bei denen ein Ausfall in einer Pipeline andere durch gemeinsame Infrastruktur beschädigt oder deaktiviert.
Ein denkwürdiges Postmortem beschrieb ein "Giftpillen"-Ereignis — ein einzelner fehlerhafter Datensatz, der einen Parser in eine Endlosschleife versetzte. Der Consumer-Thread hing, die Partition wurde neu ausbalanciert, und der neue Consumer-Thread hing ebenfalls. Innerhalb von Minuten war eine ganze Consumer-Gruppe offline. Da die Pipeline einen Kafka-Cluster mit anderen Diensten teilte, war die Protokollkomprimierung des Brokers betroffen, und nicht verwandte Pipelines begannen, erhöhte Latenzen zu sehen.
Ein weiteres beschrieb einen Metadaten-Speicher, der von mehreren Batch-Jobs verwendet wurde. Eine Schema-Migration für einen Job sperrte die Metadaten-Tabelle für 90 Sekunden. Jeder andere Job, der dieselbe Tabelle berührte, schlug fehl oder lief in einen Timeout. Was ein Einzelteam-Problem hätte sein sollen, wurde zu einem unternehmensweiten Vorfall.
Die Lehre aus diesen Postmortems ist nicht nur "isolieren Sie Ihre Ausfälle". Es ist, dass gemeinsamer Zustand oft unsichtbar ist. Teams merken nicht, dass sie Infrastruktur teilen, bis sie ausfällt. Der Kafka-Cluster, die Metadaten-Tabelle, das gemeinsame NFS-Mount — diese werden nicht als Teil des Pipeline-Designs betrachtet, aber sie sind Teil seiner Fehlerdomäne.
Wie die verbleibenden 5% aussahen
Der Rest der Postmortems waren wirklich einmalige Ereignisse: ein kosmischer Strahl, der ein Bit umdreht, ein Anbieter-API, das ohne Vorwarnung das Verhalten ändert, ein Zertifikat, das an einem Feiertagswochenende abläuft. Dies sind die Ausfälle, die man nicht wegdesignen kann. Die oben genannten 95% kann man.
Die Design-Checkliste
Nach dem Lesen dieser 50 Postmortems sah ich immer wieder die gleiche Lücke. Die Ausfälle passierten nicht, weil den Teams Talent, Werkzeuge oder Bewusstsein fehlten. Sie passierten, weil spezifische Designfragen nicht früh genug gestellt wurden.
Hier sind sechs Fragen, die, wenn sie ehrlich während der Designüberprüfung beantwortet werden, die Mehrheit der von mir analysierten Vorfälle verhindert hätten:
1. Was passiert, wenn sich das Schema ohne Vorwarnung ändert?
Nicht "haben wir ein Schema-Register?" — das ist eine Werkzeugfrage. Die Designfrage ist: schlägt die Pipeline fehl, wenn das Schema von den Erwartungen abweicht, oder passt sie sich stillschweigend an? Adaptives Verhalten fühlt sich sicherer an, bis es falsche Daten produziert. Standardmäßig auf Fehler setzen. Machen Sie Schema-Abweichungen laut.
2. Was ist die maximale Last, bei der diese Pipeline getestet wurde, und was bricht zuerst, wenn wir sie überschreiten?
Die meisten Teams testen auf Korrektheit. Weit weniger testen auf Grenzen. Kennen Sie Ihren ersten Engpass — Speicher, Verbindungen, Festplatte, Downstream-Ratenlimits — und haben Sie einen Plan für eine sanfte Degradation, wenn Sie ihn erreichen.
3. Wie würden wir wissen, wenn wir 10% unserer Daten stillschweigend verlieren würden?
Dies ist die wichtigste Frage. Wenn Ihre einzige Validierung "der Job ist fertig" ist, fliegen Sie blind. Sie benötigen unabhängige Datenqualitätsprüfungen, die das Ausgabevolumen, die Verteilung und die Schlüsselmetriken mit historischen Baselines vergleichen.
4. Sind unsere Wiederholungen sicher?
Jede Wiederholungslogik ist ein potenzieller Duplikationsmechanismus, es sei denn, das Ziel ist streng idempotent. Überprüfen Sie jeden API-Aufruf, jeden Datenbankschreibvorgang, jede Dateianfügung. Wenn Sie keine Idempotenz garantieren können, garantieren Sie zumindest einmal und akzeptieren Sie den gelegentlichen Verlust über die garantierte Duplikation.
5. Welche anderen Systeme fallen aus, wenn dieses ausfällt?
Kartieren Sie Ihre Fehlerdomäne. Wenn Ihre Pipeline hängt, blockiert sie eine gemeinsame Warteschlange? Erschöpft sie einen Verbindungspool? Füllt sie eine Festplatte, die andere Jobs benötigen? Entwerfen Sie für die Begrenzung des Explosionsradius, nicht nur für die Wiederherstellung.
6. Kann jemand, der diese Pipeline noch nie gesehen hat, sie um 3 Uhr morgens debuggen?
Die Postmortems mit den schnellsten Wiederherstellungszeiten hatten alle eines gemeinsam: Beobachtbarkeit, die kein institutionelles Wissen erforderte. Protokolle, die Entscheidungen erklären, nicht nur Zustandsänderungen. Metriken, die die Datenintegrität zeigen, nicht nur die Systemgesundheit. Warnungen, die auf die Ursache hinweisen, nicht nur auf Symptome.
Die unbequeme Wahrheit
Das Lesen von 50 Postmortems macht Sie nicht immun gegen Ausfälle. Aber es macht die Muster offensichtlich. Und die Muster sind größtenteils langweilig. Schema-Drift. Lastgrenzen. Fehlende Validierung. Gemeinsamer Zustand. Dies sind keine exotischen verteilten Systemprobleme. Sie sind Designhygiene.
Die Teams, die diese Postmortems veröffentlicht haben, gehören zu den besten der Welt im Aufbau von Dateninfrastrukturen. Wenn sie immer noch auf diese Muster stoßen, tun es alle anderen auch. Der Unterschied ist, ob Sie sie in der Designüberprüfung oder um 3 Uhr morgens erwischen.
Wenn Sie Datenpipelines entwerfen und eine Plattform möchten, die Schema-Verträge durchsetzt, Rückstau elegant handhabt und Ihnen visuelles Debugging bietet, wenn etwas schiefgeht — sei es Batch oder Streaming — sehen Sie sich layline.io an. Die Community Edition ist kostenlos zu erkunden.
Probieren Sie die Community Edition aus →
Andrew Tan ist ein Serienunternehmer und Gründer von layline.io, das Unternehmensdatenverarbeitungsinfrastrukturen aufbaut, die sowohl Batch- als auch Echtzeit-Workloads in großem Maßstab bewältigen.