Prototyping-Pipelines killen Produktion diese Fehler kosten Sie Nachtbetrieb

Industrie-Prototyping scheitert selten an der Demo, sondern am ersten Montag nach der Demo. Meine Position: Ein MVP, das Sensor-, Maschinen- oder Anlagenzustände verarbeitet, ist ab dem ersten externen Test ein Produktionssystem. Wer es anders behandelt, spart scheinbar zwei Wochen Entwicklung und kauft sich dafür Monate an Bereitschaftsdienst, Datenkorrekturen und politischen Erklärungen ein.

Der erste Fehler ist der Glaube, ein MVP dürfe ohne Betriebsvertrag leben

Viele Teams verwechseln „Minimum Viable Product“ mit „Minimum Observable Product“. Das ist für DevOps teuer, weil die fehlenden Nicht-Funktionsanforderungen erst auffallen, wenn ein Anlagenbediener, ein Field Engineer oder ein Kunde bereits vom System abhängt. Der Ansatz Industrie Prototyping mit Software von Idee zum MVP unterschätzt aus meiner Sicht genau diese Schwelle, weil ein MVP in industriellen Umgebungen nicht nur validiert, sondern sofort Erwartungen an Verfügbarkeit erzeugt.

Der konkrete Fehler: Teams definieren User Stories, aber keine SLOs. Sie sagen „Daten sollen nahezu live ankommen“, aber niemand schreibt auf, ob damit p95 unter 500 ms, p99 unter 2 s oder nur „irgendwann vor Schichtende“ gemeint ist. Als intern gesetzte Zielgröße ist p95 unter 750 ms für Statusänderungen oft ein sinnvoller Start, weil Bedienoberflächen sonst als träge wahrgenommen werden; als gemessener Wert in einem Vorserien-Lasttest mit 120 simulierten Geräten kann p99 bei 4,8 s dagegen schon ein Warnsignal sein, weil Retry-Kaskaden dann meist nicht mehr sichtbar vom eigentlichen Nutzwert getrennt werden.

Was kostet der Fehler? Zuerst kostet er Vertrauen. Danach kostet er Zeit: Ohne SLO kann niemand entscheiden, ob ein Incident wirklich ein Incident ist. Der Bereitschaftsdienst verbringt dann zwei Stunden mit Bauchgefühl-Debugging, weil Prometheus 2.50, Grafana 10.4 und OpenTelemetry Collector 0.96 zwar vorhanden sind, aber keine Service-Level-Objektive, keine Burn-Rate-Alerts und keine Traces mit brauchbaren Attributen wie machine_id, firmware_version oder workcell existieren.

Ich würde nicht mit einer Demo beginnen, deren Erfolg nur im Frontend sichtbar ist, weil genau diese Demos später als implizite Betriebszusage zitiert werden. Ich würde zuerst drei harte Betriebsfragen beantworten: Wie viele Minuten Datenverlust sind akzeptabel? Wer darf ein fehlerhaftes Deployment zurückrollen? Welche Metrik beendet die Diskussion? Das klingt unsexy, aber es schützt DevOps vor dem Klassiker: „Gestern ging es doch noch im Meeting.“

• Fehlende SLOs kosten Entscheidungszeit: Ohne Error Budget wird jeder kleine Aussetzer politisch, weil kein gemeinsamer Grenzwert existiert.
• Fehlende Traces kosten Ursachenzeit: Ohne OpenTelemetry-Konventionen verschwimmen API, Queue und Geräteadapter, weil Logs allein keine Kausalität liefern.
• Fehlende Runbooks kosten Schlaf: Ohne klare Kommandos für Neustart, Replay und Quarantäne wird Bereitschaft zur Improvisationsübung.

Die Demo-Architektur wird teuer, sobald sie echte Daten behalten soll

Der zweite Fehler ist die romantische Idee, dass man Demo-Code später „nur sauberziehen“ müsse. Das ist meistens falsch, weil Datenmodelle, Authentifizierung und Zustandsübergänge nicht wie CSS refaktoriert werden können. Wenn ein Team drei Wochen lang Events ohne Schema-Version speichert, zahlt DevOps danach mit Migrationen, Sonderfällen und manueller Datenbereinigung.

Ein typisches Beispiel ist die Wahl von SQLite für lokale Geschwindigkeit. SQLite 3.45 ist hervorragend für einen isolierten Prototypen, weil Setup und Deployment fast nichts kosten. PostgreSQL 16 mit TimescaleDB 2.14 gewinnt dagegen, sobald mehrere Schreibquellen, Retention, Backups, Rollenrechte und Abfragen über Zeitfenster nötig sind, weil industrielle Zustände fast immer historisch erklärt werden müssen. SQLite kostet später eine Migration mit Sperrlogik und Datenvalidierung; PostgreSQL kostet früher mehr Schema-Disziplin, Monitoring und Betriebs-Know-how.

Die explizite Abwägung ist simpel: SQLite 3.45 gewinnt bei einem Wegwerf-Prototypen auf einem Laptop, weil die Time-to-Demo minimal ist; es kostet aber Replikation, zentrale Backups und paralleles Schreiben. PostgreSQL 16 plus TimescaleDB 2.14 gewinnt bei jedem MVP, der in eine Pilotanlage geht, weil WAL, Rollen, Indizes, hypertables und Point-in-Time-Recovery bereits Betriebsbegriffe sind; es kostet dafür lokale Einfachheit und verlangt frühere Entscheidungen über Partitionierung, Retention und Migrationen mit Flyway 10 oder Liquibase 4.

Die Kosten sieht man erst, wenn der Prototyp Erfolg hat. Ein gemessener Import von 18 Millionen Rohwerten kann auf einem schlecht indizierten Tabellenentwurf mehrere Stunden dauern, weil jede nachträgliche Normalisierung CPU, I/O und Sperren frisst. Eine Retention von 14 Tagen als bewusst zu justierender Startwert kann dagegen reichen, wenn Rohdaten in S3-kompatiblen Object Storage ausgelagert und nur verdichtete Zustände dauerhaft in PostgreSQL gehalten werden. Dieser Wert ist kein Naturgesetz, sondern ein Betriebshebel.

Ein kleines, lauffähiges Minimum ist besser als eine unsichtbare Datenbank auf einem Entwicklernotebook. Diese Compose-Datei startet PostgreSQL 16 mit Healthcheck und zwingt das Team, Verbindungsdaten, Persistenz und Startzustand ausdrücklich zu behandeln:

services:
  db:
    image: postgres:16
    environment:
      POSTGRES_USER: prototype
      POSTGRES_PASSWORD: prototype
      POSTGRES_DB: mvp
    ports:
      - "5432:5432"
    volumes:
      - pgdata:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U prototype -d mvp"]
      interval: 10s
      retries: 5
volumes:
  pgdata:

Der Punkt ist nicht, dass Docker Compose produktionsreif wäre. Der Punkt ist, dass sogar ein lokales MVP reproduzierbar starten muss, weil jede unsichtbare Entwicklerannahme später im Kubernetes-Cluster, in GitLab CI oder in GitHub Actions als gebrochener Build wieder auftaucht.

Teams unterschätzen Queues, weil sie Nachrichten mit Wahrheit verwechseln

Der dritte Fehler ist semantisch: Eine empfangene Nachricht ist noch keine gültige Wahrheit. In industriellem Prototyping mit Softwareentwicklung entstehen Daten oft aus Gateways, Edge-Adaptern, OPC UA nach IEC 62541, MQTT 5.0, REST, gRPC oder proprietären Exporten. DevOps zahlt den Preis, wenn das Team keine klare Grenze zwischen Transport, Validierung, Persistenz und fachlichem Zustand zieht.

Apache Kafka 3.7 und NATS JetStream 2.10 sind hier ein guter Vergleich. Kafka gewinnt, wenn lange Retention, Replay über viele Consumer Groups und hohe Schreiblast zentral sind, weil Log-Segmentierung, Partitionierung und Consumer-Offsets genau dafür gebaut sind; es kostet aber Betriebskomplexität, Speicherplanung und Know-how bei ISR, Rebalancing und min.insync.replicas. NATS JetStream gewinnt, wenn geringe Latenz, einfache Topologien und Edge-nahe Deployments wichtiger sind, weil Streams und Consumers leichter zu betreiben sind; es kostet dafür weniger Ökosystemtiefe bei schweren Analytics-Workloads und verlangt Disziplin bei Stream-Limits.

Viele Teams wählen Kafka, weil es erwachsen klingt, nicht weil ihr Prototyp es braucht. Das ist teuer, weil ein Drei-Broker-Cluster laut gängiger Kafka-Betriebspraxis zwar einen Broker-Ausfall tolerieren kann, aber nur dann sauber bleibt, wenn Replikationsfaktor, ISR und Producer-Acks zusammenpassen. Eine sinnvolle, zu überprüfende Konfiguration wäre replication.factor=3, min.insync.replicas=2 und acks=all, weil sonst ein MVP scheinbar stabil läuft und beim ersten Broker-Problem Daten bestätigt, die nicht robust repliziert sind.

Noch schlimmer ist der Fehler, Nachrichten ohne idempotente Schlüssel zu verarbeiten. Wenn ein Gateway nach Verbindungsabbruch zehn Minuten Daten nachliefert, entstehen Dubletten, wenn der Consumer nur „insert“ kennt. Das kostet Datenkorrektur und Incident-Zeit. Ein eindeutiger Schlüssel aus source_id, sequence_number und event_time kostet am Anfang ein paar Diskussionen, spart aber später Stunden, weil Replay dann kein Risiko, sondern ein Werkzeug ist.

Den Beitrag Industrie-Prototyping mit Softwareentwicklung in der IT würde ich im Betrieb härter lesen, weil IT-Entwicklung hier nicht bei sauberem Code endet, sondern bei der Fähigkeit, Ereignisse nach einem Fehler gezielt erneut zu verarbeiten.

Der finanzielle und operative Preis dieses Fehlers ist nicht abstrakt. Wenn 0,5 Prozent der Events doppelt geschrieben werden, klingt das klein; bei 2 Millionen Events pro Tag sind das 10.000 falsche Zustände täglich, und jeder nachgelagerte Report wird verdächtig. Diese Rechnung ist eine einfache Hochrechnung, keine Messung, aber sie reicht, um zu zeigen, warum Idempotenz keine Architekturkosmetik ist.

Sicherheit wird zu spät eingebaut, weil der Prototyp angeblich isoliert ist

Der vierte Fehler ist der Satz: „Das läuft nur im Pilotnetz.“ Dieser Satz ist gefährlich, weil Pilotnetze in der Praxis Ausnahmen erzeugen: temporäre VPNs, geteilte Passwörter, offene Dashboards und Firewall-Regeln, die niemand zurückbaut. DevOps trägt danach die Verantwortung für etwas, das nie als Plattform gedacht war, aber plötzlich Plattformrechte hat.

IEC 62443 ist kein Papiermonster, wenn man sie als Checkliste für Zonen, Kommunikationspfade und Rollen benutzt. OAuth 2.1, OpenID Connect, mTLS mit SPIFFE/SPIRE, Vault 1.15, cert-manager 1.14 und Kubernetes NetworkPolicy sind keine „Enterprise-Verzierung“, weil sie verhindern, dass Demo-Zugangsdaten in Produktionspfade wandern. Kubernetes 1.29 macht NetworkPolicies nicht automatisch wirksam, weil dafür ein CNI wie Cilium 1.15 oder Calico 3.27 die Regeln durchsetzen muss; diese Einschränkung gehört in jedes Architekturgespräch.

Ein häufiger Kostenpunkt ist Secret-Handling. Ein Token in einer Helm-Values-Datei kostet später Rotation, Audit und Misstrauen, weil niemand beweisen kann, wo es gelandet ist. Sealed Secrets, External Secrets Operator oder Vault Agent Injection kosten anfangs mehr YAML und Rechteklärung, aber sie reduzieren den Schadenradius. Laut Herstellerdokumentation begrenzt GitHub Actions ein einzelnes Secret auf 48 KB; diese veröffentlichte Grenze ist selten das Problem, aber sie erinnert daran, dass Secrets kein Konfigurationsarchiv sind.

Ich würde nicht erlauben, dass ein MVP mit Admin-Accounts gegen echte Anlagen- oder Betriebsdaten läuft, weil erfolgreiche Prototypen fast nie sauber weggeworfen werden. Stattdessen würde ich von Tag eins an Rollen trennen: Read-only für Dashboards, Write für Ingestion, Admin nur für automatisierte Deployments. Das kostet vielleicht einen halben Tag im Identity Provider, verhindert aber später den unangenehmen Satz: „Wir wissen nicht, welcher Dienst das geändert hat.“

Auch Container-Sicherheit wird zu spät ernst genommen. Trivy 0.49, Syft 1.0, Grype 0.74, Cosign 2.2 und SLSA-Provenance sind für ein MVP nicht übertrieben, wenn es in ein echtes Netzwerk darf, weil verwundbare Images und nicht signierte Artefakte keine Prototyp-Probleme bleiben. Eine kritisch bewertete CVE im Base Image kostet nicht nur Patch-Zeit, sondern oft ein Change-Fenster, einen neuen Abnahmetest und eine Erklärung an Security.

Der Betrieb verliert, wenn Deployments schneller sind als Rollbacks

Der fünfte Fehler betrifft Delivery. Teams feiern, dass sie zehnmal am Tag deployen können, aber sie üben nicht, wie sie in drei Minuten zurückgehen. Schnelle Deployments ohne schnelle Rollbacks sind für DevOps kein Fortschritt, weil die mittlere Wiederherstellungszeit wichtiger ist als die Anzahl der Releases.

Argo CD 2.10, Helm 3.14, Kustomize 5, Terraform 1.7 und Kubernetes 1.29 funktionieren gut zusammen, wenn Zuständigkeiten sauber bleiben. Terraform sollte Infrastruktur wie Cluster, Netz, IAM und Datenbankinstanzen verwalten, weil Drift dort teuer ist. Helm oder Kustomize sollten Applikationsmanifeste verwalten, weil Release-Historie, Values und Umgebungsunterschiede dort näher am Team liegen. Wer alles in ein einziges Terraform-Monorepo legt, bezahlt später mit langsamen Reviews und Angst vor kleinen Änderungen, weil jede Applikationskorrektur wie ein Infrastrukturereignis wirkt.

Ein starkes Muster ist Progressive Delivery mit Argo Rollouts oder Flagger. Ein vorsichtig gewählter Canary-Anteil von 10 Prozent ist ein zu justierender Startpunkt, weil man damit echte Last sieht, ohne alle Nutzer zu treffen. Der Wert ist nicht heilig: Bei sehr wenigen Geräten kann 10 Prozent statistisch wertlos sein, während bei hoher Last schon 1 Prozent reicht. Disputierbar ist, ob Canary für jedes MVP nötig ist; ich halte ihn für nötig, sobald externe Nutzer betroffen sind, weil Rollback ohne Teilfreigabe nur Schadensbegrenzung nach Vollschaden ist.

Die Kosten falscher Delivery zeigen sich in Bereitschaftsmetriken. MTTR, Change Failure Rate, Deployment Frequency und Lead Time aus DORA sind keine Managementposter, wenn DevOps die Zahlen ernst nimmt. Eine Change Failure Rate von 25 Prozent als beobachteter Quartalswert bedeutet nicht automatisch schlechte Entwickler, aber sie bedeutet fehlende Schutzgeländer, weil jeder vierte Change operative Nacharbeit erzeugt. Eine MTTR von 45 Minuten kann akzeptabel sein, wenn Daten gepuffert werden; sie ist katastrophal, wenn Bediener in dieser Zeit Blindflug haben.

Viele Prototypen haben keine synthetischen Checks. Das ist absurd, weil ein einzelner Blackbox-Exporter-Check gegen Login, Ingestion-Endpunkt und Dashboard mehr schützt als zehn hübsche Architekturfolien. Ein MVP braucht mindestens Health, Readiness, Metriken und einen synthetischen Datenpunkt, der Ende-zu-Ende sichtbar ist. Sonst merkt DevOps zwar, dass Pods laufen, aber nicht, dass der Nutzen tot ist.

Beginnen Sie nicht mit dem nächsten Feature. Legen Sie morgen ein einziges Produktionskriterium fest: ein SLO für den wichtigsten Datenfluss, inklusive Messpunkt, Alert und Runbook. Danach prüfen Sie, ob Daten replaybar, Secrets rotierbar und Rollbacks geübt sind. Wenn eine dieser Antworten fehlt, ist der Prototyp nicht fast fertig, sondern nur erfolgreich vorgeführt.