Wenn die Anwendung in Produktion geht: DevOps, Integrationen und eine sichere Cloud

ArcCloud / Engineering-Werkstatt / 01

Um 9:02 hat der Kunde bezahlt. Um 9:03 behauptet die Anwendung das Gegenteil.

Der Zahlungsanbieter hat die Zahlung angenommen, doch die Antwort kam nicht rechtzeitig zurück. Der Nutzer aktualisiert die Seite. Die Anwendung wiederholt die Anfrage. Kurz darauf treffen zwei Benachrichtigungen zur selben Transaktion ein. In den Logs sieht alles nach mehreren unabhängigen Ereignissen aus. Für den Kunden ist es einfach eine Bestellung, deren Status niemand erklären kann.

Solche Probleme passen selten in eine einzelne Methode. Sie ziehen sich durch Code, Netzwerk, Datenbank, Warteschlange und Deployment. Dein Controller kann sauber geschrieben sein und trotzdem zwei Belege ausstellen. Die Pipeline kann grün sein, und nach der Veröffentlichung rufen Mitarbeiter an, weil sie sich nicht anmelden können. Deine Anwendung kann in der Cloud laufen, ohne dass du ihre Daten wiederherstellen kannst.

In diesem Leitfaden entwickeln wir einen Blick auf das gesamte System. Jede wichtige Entscheidung verbinden wir mit einem Symptom, einer Ursache, einer Lösung und einem Test, der den Fehler tatsächlich aufdecken kann. Dieser Test bleibt dir länger erhalten als der Name des nächsten Cloud-Dienstes.

Lies der Reihe nach oder kehre zu einem bestimmten Problem zurück

Der Weg in den Produktivbetrieb

01 / Bevor Services entstehen

Kläre zuerst, was das System einem Menschen verspricht

In Pracownia bestellen Unternehmen Bauteile. Das System hat eine Angular-Oberfläche, eine .NET-API, eine relationale Datenbank und einen Hintergrundprozess. Es ist mit einem Zahlungsanbieter und dem Lager verbunden. Nach Bestätigung der Bestellung verschickt es eine Nachricht und erstellt einen Beleg. Das reicht für anspruchsvolle Probleme. Dreißig Microservices brauchen wir dafür nicht.

Wir beginnen mit einem Gespräch mit der Person, die Bestellungen bearbeitet. Bedeutet „angenommen“ gespeichert, bezahlt oder im Lager reserviert? Darf die Menge nach Beginn der Zahlung noch geändert werden? Was tun wir, wenn die Zahlung erfolgreich war, die Ware aber nicht mehr verfügbar ist? Ohne diese Antworten modelliert ein Entwickler keinen Prozess. Er schreibt eigene Vermutungen in if.

Trenne Zustände, die sich unabhängig verändern

Ein einziges Feld Status mit den Werten „neu“, „bezahlt“, „versandt“, „Fehler“ erzählt bald nicht mehr die Wahrheit. Eine Bestellung kann bezahlt sein und gleichzeitig auf die Warenreservierung warten. Eine Zahlung kann Klärung benötigen, obwohl der Beleg bereits existiert. Deshalb modellieren wir Bestell-, Zahlungs- und Erfüllungsstatus getrennt. Die Kundenansicht setzt diese Fakten verständlich zusammen: „Zahlung bestätigt. Wir warten auf die Bestätigung des Lagers.“

Order:       Draft → Submitted → Cancelled
Payment:     Pending → Confirmed | Failed | NeedsReview
Fulfilment:  NotRequested → Reserving → Reserved | Rejected

Regel: Ein Verkaufsbeleg entsteht höchstens einmal
       für eine bestimmte bestätigte Transaktion.
Regel: Ein Nutzer von Firma A liest keine Bestellungen von Firma B.
Regel: Ein Timeout ändert Pending nicht automatisch in Failed.

Übergänge brauchen ausdrückliche Bedingungen. Eine Zahlungsbestätigung darf die Bestellung nicht auf einen früheren Stand zurücksetzen. Eine verspätete Nachricht „ausstehend“ darf eine bereits bekannte Bestätigung nicht überschreiben. Wenn zwei Personen denselben Datensatz ändern, hilft Nebenläufigkeitskontrolle: Aktualisieren mit erwarteter Version und einem verständlichen Konflikt statt unbemerktem Überschreiben fremder Arbeit.

Wähle eine Einfachheit, die du dauerhaft beherrschst

Für den Anfang genügen klar getrennte Module: Bestellungen, Zahlungen, Abwicklung. Die API verarbeitet Interaktionen, ein Worker übernimmt Hintergrundaufgaben. Die Module haben eigene Regeln und ändern ihre Daten nicht gegenseitig über zufällige Abkürzungen. Unabhängige Services lohnen sich bei einem konkreten Grund: einem eigenen Team, deutlich anderer Skalierung, erforderlicher Isolation oder einem unabhängigen Veröffentlichungsrhythmus.

Jede Aufteilung in Services bringt Netzwerkkommunikation, Vertragsversionierung und eine weitere Fehlerquelle mit sich. Halte eine kurze Architekturentscheidung fest: Problem, erwogene Optionen, Entscheidung und Anlass zur Neubewertung. „Wir trennen die Berichtserstellung ab, wenn sie der API trotz Limits Ressourcen entzieht“ hilft mehr als ein Diagramm, in dem sofort alles ein Microservice ist.

02 / Das Modell an Systemgrenzen

Eine Integration beginnt mit einer Vereinbarung, nicht mit einem HTTP-Client

Das externe Lager nennt ein Produkt „Artikel“, liefert Mengen als Text und beschreibt Reservierungsfehler mit Codes, die der Nutzer nicht kennt. Verteile dieses Format nicht in deiner Domäne. Ein Integrationsadapter übersetzt den fremden Vertrag in Begriffe der Anwendung: Reservierung bestätigt, Ware nicht verfügbar, Daten abgelehnt oder Ergebnis vorerst unbekannt.

Unterscheide einen Befehl von einem Ereignis. ReserveStock ist die Aufforderung, eine Arbeit auszuführen; sie kann abgelehnt werden. StockReserved beschreibt eine Tatsache, die bereits eingetreten ist. Präzise Namen machen klarer, wer über eine Entscheidung verfügt und ob eine Nachricht wiederholt werden darf.

Eine Beispielnachricht braucht weniger Felder als ein umfangreiches ORM-Objekt, aber mehr als nur die Bestell-ID:

{
  "eventId": "evt-demo-0001",
  "type": "OrderSubmitted",
  "schemaVersion": 1,
  "occurredAt": "2026-10-13T09:00:00Z",
  "orderId": "ord-demo-0001",
  "tenantId": "tenant-demo-a",
  "correlationId": "corr-demo-0001"
}

eventId identifiziert ein konkretes Ereignis, orderId das Geschäftsobjekt, und correlationId hilft, die Spuren eines Ablaufs zu verbinden. Sie sind nicht austauschbar. Das Feld tenantId verleiht keine Berechtigungen: Der Empfänger muss dem Produzenten vertrauen und den zulässigen Kontext prüfen. In einer öffentlichen API stammt die Firmen-ID aus einer autorisierten Beziehung des Nutzers, nicht aus ungeprüft übernommenem JSON.

Auch eine Schemaänderung ist ein Deployment

Ergänze zunächst optionale Felder und lasse Empfänger unbekannte Felder ignorieren. Eine geänderte Bedeutung eines bestehenden Feldes bricht den Vertrag, auch wenn sich das JSON weiterhin parsen lässt. Ein Empfänger darf eine unbekannte Währung nicht durch den Standard PLN ersetzen. Pflege Beispielnachrichten, Vertragsprüfungen für Produzent und Konsument sowie eine Phase, in der Versionen nebeneinander bestehen. Speichere Geldbeträge mit ausdrücklicher Währung und vereinbarter Darstellung, ohne unbeabsichtigte Gleitkommaarithmetik.

Nicht jede Antwort muss sofort eintreffen. Eine längere Aufgabe kann 202 Accepted und eine Vorgangs-ID zurückgeben, deren Status der Client später abfragt. „Zur Ausführung angenommen“ muss etwas Dauerhaftes bedeuten. Existiert die Aufgabe nur im Prozessspeicher und verschwindet beim Neustart, versprich dem Nutzer keine garantierte Ausführung.

Pracownia-Szenario / ein lokal unsichtbarer Fehler

„Ich habe Retry ergänzt. Jetzt entstehen manchmal zwei Rechnungen.“

In den Tests antwortete der Partner immer. In unserem Beispiel speicherte er die Daten, aber die Verbindung brach vor der Antwort ab. Unser Code wiederholte den Befehl. Der erste Versuch war nicht fehlgeschlagen – sein Ergebnis war unbekannt. Dieser Unterschied verändert die gesamte Reparaturstrategie.

03 / Ungewissheit gehört zum Protokoll

Retry hilft erst, wenn die Bedeutung einer Wiederholung feststeht

Idempotenz bedeutet hier, dass die mehrfache Ausführung desselben logischen Vorgangs keine weiteren geschäftlichen Auswirkungen erzeugt. Beim Anlegen einer Bestellung verwendet der Client bei Wiederholungen denselben Schlüssel. Der Server verknüpft ihn mit dem Nutzer oder Unternehmen, dem Vorgangstyp und einem Fingerabdruck der relevanten Daten. Eine geänderte Menge mit demselben Schlüssel darf nicht unbemerkt das Ergebnis der alten Bestellung liefern – sie muss einen eindeutigen Konflikt auslösen.

Prüfe Authentifizierung und Autorisierung auch, bevor du ein gespeichertes Ergebnis zurückgibst. Ein alter Schlüssel darf entzogene Rechte nicht umgehen. Die Datenbank braucht eine Eindeutigkeitsbedingung und eine Transaktion. „Prüfen, ob vorhanden; andernfalls hinzufügen“ verliert ohne diesen Schutz gegen zwei parallele Anfragen. Lege außerdem fest, wie laufende Vorgänge behandelt, Antworten gespeichert und Schlüssel befristet werden. Nach Ablauf kann der Wiederholungsschutz entfallen. Eine zusätzliche Geschäftsregel, etwa eine eindeutige Transaktions-ID des Zahlungsanbieters, bleibt wichtig.

BEGIN
  claim (TenantId, Operation, IdempotencyKey)  -- UNIQUE
  Übereinstimmung des Anfrage-Fingerabdrucks prüfen
  Order speichern
  OutboxEvent mit dauerhafter EventId speichern
  das mit dem Schlüssel verknüpfte Operationsergebnis speichern
COMMIT

Worker: Outbox lesen → veröffentlichen → Versand markieren
Consumer: BEGIN → claim (Consumer, EventId) UNIQUE
          → fachliche Änderung → COMMIT → ACK

Die Outbox schließt eine Lücke. Nicht alle.

Ohne Outbox kann die Bestellung erfolgreich gespeichert werden, während das Senden an die Queue scheitert. Wird das Ereignis in derselben Transaktion wie die Bestellung gespeichert, kann ein Worker es später erneut aufgreifen. Ein anderes Fehlerfenster bleibt: Der Broker hat die Nachricht angenommen, aber der Worker fällt aus, bevor er sie als gesendet markiert. Nach dem Neustart veröffentlicht er sie erneut. Deshalb speichert der Empfänger die IDs verarbeiteter Ereignisse und bestätigt Deduplizierung und eigene Datenänderung gemeinsam.

Ein Duplikat eines bereits bestätigten Ereignisses beendest du ohne neue Auswirkung und bestätigst den Empfang. Ein Konflikt mit einem noch laufenden Vorgang braucht eine gesonderte, vereinbarte Behandlung. Besteht die Auswirkung im Aufruf eines weiteren externen Dienstes, umfasst die lokale Transaktion dessen Server nicht. Du brauchst auch beim Partner Idempotenz, einen eigenen Abgleichprozess oder eine ausdrückliche Kompensation. Eine Rückzahlung dreht die Zeit nicht zurück; sie ist ein neuer Vorgang, der ebenfalls scheitern kann. Versprich dem Team kein „exactly once“, ohne den genauen Geltungsbereich der Garantie zu nennen.

Lege das Retry-Budget fest, bevor du die Anzahl der Versuche einstellst

Beim Lesen von Partnerdaten kommen begrenzte Wiederholungen vorübergehender Fehler, wachsende Wartezeiten mit zufälliger Streuung und die Beachtung von Retry-Afterinfrage. Eine Antwort 400 wegen einer falschen Produktnummer repariert sich nicht nach einer Sekunde. Ein Schreib-Timeout erfordert einen anderen Umgang als der Timeout eines sicheren Lesevorgangs. Jeder Versuch verbraucht Zeit, Verbindungen und das Kontingent des Partners.

Angenommen, der Nutzer darf höchstens acht Sekunden warten. Drei Versuche zu je fünf Sekunden plus Pausen passen nicht zu diesem Versprechen. Du brauchst eine Deadline für den gesamten Vorgang und musst Abbruchsignale an Abhängigkeiten weiterreichen. Ergänze Retry nicht unabhängig in drei Schichten: Vier Versuche auf jeder von drei Ebenen können bis zu 64 Aufrufe des tiefsten Dienstes erzeugen. Ein Circuit Breaker trennt eine fehlerhafte Abhängigkeit vorübergehend ab; er ersetzt weder Idempotenz noch ein Limit gleichzeitiger Anfragen.

Dokumentation: AWS: sichere Wiederholungen und das Transactional-Outbox-Muster.

04 / Öffentlicher Eingang, begrenztes Vertrauen

Ein Webhook ist eine Nachricht vom Partner. Prüfe zuerst, ob sie wirklich von ihm stammt

Bestätige eine Zahlung nicht deshalb, weil der Browser zur Adresse /successzurückgekehrt ist. Auch JSON mit einem Feld paid: truereicht nicht. Den tatsächlichen Status leitest du aus einer verifizierten Nachricht des Zahlungsanbieters oder einer autorisierten Abfrage seiner API ab, zugeordnet zur richtigen Bestellung sowie zum erwarteten Betrag und zur Währung.

Bei HMAC-Signaturen benötigt die Prüfung normalerweise die exakten Bytes des Request-Bodys. JSON zu parsen und neu zu serialisieren kann Leerzeichen oder die Feldreihenfolge verändern – und damit die Grundlage der Signatur. Nutze die offizielle Bibliothek und Spezifikation des jeweiligen Anbieters: Verknüpfung von Zeitstempel und Inhalt, Kodierung und Secret-Rotation sind nicht universell.

Das Zeitfenster gegen Replay muss berücksichtigen, wie der konkrete Partner erneute Zustellungen signiert. Alle Nachrichten über fünf Minuten starr abzulehnen, ohne das Protokoll zu kennen, kann gültige verspätete Ereignisse ausschließen. Zeitsynchronisierung, Deduplizierung und ein Verfahren zum manuellen Abgleich gehören zur Lösung.

Teste gültige und ungültige Signaturen, fehlende Signaturen, übergroße Bodys, zwei parallele Kopien eines Ereignisses und eine umgekehrte Zustellreihenfolge. Prüfe außerdem den Ausfall des Workers nach Speicherung der Auswirkung, aber vor Bestätigung der Nachricht. Dieser Test ist oft wichtiger als ein weiteres perfektes JSON-Beispiel.

Beispiel eines konkreten Protokolls: GitHub: Webhook-Signaturen validieren. Prüfe die Parameter deines Anbieters immer in dessen Dokumentation.

05 / Architektur mit Vertrauensgrenzen

Was darf öffentlich sein, und was sollte außerhalb des Internets bleiben?

„Privat“ bedeutet, den Netzwerkzugang einzuschränken. „Geschützt“ umfasst zusätzlich Identitäts-, Berechtigungs- und Datenkontrollen. Die Begriffe ersetzen einander nicht. Eine öffentliche API kann gut geschützt sein; ein interner Dienst, auf den zu viele Konten zugreifen dürfen, kann unsicher sein.

Eine signierte URL ist ein vertrauliches Token: Wer sie besitzt, kann sie bis zum Ablauf nutzen oder weitergeben. Begrenze ihren Umfang und ihre Lebensdauer und schreibe sie nicht in öffentliche Logs. Öffentlicher Frontend-Code ist definitionsgemäß herunterladbar. Darin lässt sich ein API-Schlüssel weder durch Minifizierung noch durch eine beim Build eingebundene Umgebungsvariable verstecken. Eine öffentliche Anwendungs-ID oder API-Adresse darf sichtbar sein; Zugangsdaten für privilegierte Vorgänge müssen auf dem Server bleiben oder durch geeignete delegierte Berechtigungen ersetzt werden.

In Azure schaltet das Erstellen eines Private Endpoint den vorhandenen öffentlichen Dienstzugang nicht zwingend ab. Prüfe die Einstellung public network access, Firewallregeln und DNS. Prüfe in AWS ebenso Routen, Security Groups sowie Ressourcen- und Endpoint-Policies. Ein Test innerhalb des Netzwerks bestätigt nicht, dass Verbindungen aus dem Internet gesperrt sind.

Dokumentation: Azure Private Endpoint und AWS-IAM-Praktiken.

06 / Schutz, der auch außerhalb der Oberfläche wirkt

Ein versteckter Button ist keine Berechtigungskontrolle

Ein Kunde von Firma A ist angemeldet und darf eigene Bestellungen ansehen. Er ersetzt die ID in der URL durch eine Bestellung von Firma B. Prüft der Server nur die Gültigkeit des Tokens, hat er gerade fremde Daten freigegeben. Jeder Objektvorgang erfordert eine Prüfung der Beziehung Nutzer–Unternehmen–Ressource–Aktion. „Nicht gefunden“ kann die Existenz eines Objekts verbergen; entscheidend ist jedoch, den Zugriff vor der Datenausgabe abzulehnen.

tenant = authorizedMembership.For(currentUser)
order = Orders.SingleOrDefault(
    id == requestedId AND tenantId == tenant.Id)

if order is null: return NotFound
if !policy.CanCancel(currentUser, order): return Forbidden
order.Cancel(serverTime)

Ein Token ist nicht echt, nur weil sich sein JSON lesen lässt. Nutze bewährte Middleware und prüfe Signatur, Aussteller, Empfänger und Gültigkeitszeitraum. Privilegierte Rollen brauchen eine eigene Policy und MFA. Lege fest, wie Berechtigungsänderungen und Sitzungsbeendigungen wirken, insbesondere bei länger gültigen Tokens.

Fünf Stellen, an denen Schutzmaßnahmen oft auseinanderlaufen

• Browsersitzung. Wähle Cookies und Tokens passend zur Architektur. Setze bei Cookie-Sitzungen unter anderem Secure und HttpOnly; wähle SameSite und CSRF-Schutz bewusst. HttpOnly begrenzt das Auslesen eines Cookies durch Skripte, löst allein jedoch weder XSS noch CSRF.
• CORS. Steuert, wie Browser Antworten zwischen Origins lesen dürfen. Es ersetzt keine Authentifizierung und hält beliebige HTTP-Clients nicht auf.
• Benutzereingaben. Parametrisiere SQL-Abfragen, kodiere Daten passend zum Ausgabekontext und vermeide das Einfügen nicht vertrauenswürdigen HTMLs. Prüfe Länge, Bereich und erlaubte Werte auf dem Server.
• Anhänge. Prüfe Größe und tatsächlichen Typ, vergib eigene Namen und trenne Dateien vom Anwendungscode. Archive können beim Entpacken riesig werden. Scannen und Quarantäne dürfen keinen direkten Weg ins öffentliche Verzeichnis öffnen.
• Abruf fremder URLs. Eine Import- oder Auditfunktion kann für SSRF missbraucht werden. Begrenze Protokolle und Ziele, blockiere interne und Metadata-Adressen und prüfe auch Weiterleitungen sowie DNS-Auflösung. Ergänze ausgehende Netzwerkkontrollen.

Request-Limits müssen die Kosten berücksichtigen. Hundert einfache Lesevorgänge belasten anders als hundert erzeugte Berichte. Begrenze aufwendige Vorgänge nach authentifizierter Identität und Unternehmen; öffentliche Eingänge zusätzlich anhand von Netzwerksignalen. Melde eine Limitüberschreitung verständlich, ohne Infrastrukturdetails preiszugeben.

WAF, Dependency-Scanner und Penetrationstests sind nützlich, übertragen die Verantwortung für Zugriffsregeln aber nicht von der Anwendung auf ein Werkzeug. Plane Tests mit einem Konto aus einem anderen Unternehmen, einem Konto ohne Rolle, einer abgelaufenen Sitzung und einer Anfrage außerhalb der Oberfläche ein. Ein System, das „jedem Einbruch standhält“, kann niemand ehrlich versprechen. Angriffsflächen lassen sich jedoch konsequent verkleinern, Missbrauch erkennen und der Entzug von Zugriffen üben.

Für die Test-Checkliste: OWASP: Autorisierung auf Objektebene und Schutz vor SSRF.

07 / Ein wiederholbarer Prozess statt eines Heldenskripts

Gutes DevOps beginnt damit, ein Deployment reproduzieren zu können

Im Team gibt es jemanden, der „weiß, wie man das hochlädt“. Auf seinem Rechner liegt die Konfiguration, auf dem Server wurden einige Dinge von Hand geändert. Solange diese Person verfügbar ist, wirkt alles effizient. Die Probleme beginnen im Urlaub, bei einem Vorfall oder mit der zweiten Umgebung. Betriebswissen darf nicht ausschließlich in einem Kopf und einer Terminal-History existieren.

Das Repository sollte Code, Build-Definition, Infrastruktur und nicht geheime Konfiguration beschreiben. Secrets gehören in einen geeigneten Speicher; die Dokumentation nennt ihre Namen, Verantwortlichen und das Rotationsverfahren. Test- und Produktionsumgebungen haben getrennte Identitäten und Zugriffsbereiche. „Andere Datenbank mit demselben Administratorkonto“ bietet keine ausreichende Isolation.

Einmal bauen, dasselbe Ergebnis weiterreichen

Bauen Staging und Produktion die Anwendung separat, hast du ein ähnliches, aber nicht zwingend dasselbe Produkt getestet. Fixiere die Auflösung der Abhängigkeiten mit einem Lockfile, dokumentiere die Toolchain-Version und übertrage dasselbe, per Digest identifizierte Image zwischen den Umgebungen. Der Tag latest reicht nicht aus, um festzustellen, welcher Code am Dienstag um 14:10 lief.

Nützliche Nachweise sind Commit, Pipeline-Run-ID, Artefakt-Prüfsumme, Testergebnis, Abhängigkeitsverzeichnis und Freigabeinformation. Eine SBOM hilft festzustellen, ob eine entdeckte Schwachstelle dein Image betrifft. Signaturen und Herkunftsnachweise helfen zu prüfen, woher das Image kommt. Keines dieser Dokumente allein bedeutet, dass der Code sicher ist.

CI/CD sollte keinen dauerhaften Administratorschlüssel speichern

OIDC-Föderation tauscht die Identität eines Jobs gegen kurzlebige Cloud-Berechtigungen. Der Schutz hängt jedoch von den Vertrauensbedingungen ab: richtiger Aussteller, Token-Empfänger, Repository, Branch oder geschützte Umgebung. Der Eintrag id-token: write in GitHub Actions erlaubt, ein OIDC-Token anzufordern – keinen unbeschränkten Zugriff auf AWS oder Azure.

Prüfe das tatsächliche Format des Claims sub für Repository und Anbieter. GitHub verändert die Identifizierung neuer Repositories; eine aus einem alten Beitrag kopierte Beispiel-Policy kann deshalb nicht passen. Die Cloud-Rolle soll das Bereitstellen konkreter Ressourcen erlauben, nicht die Verwaltung des gesamten Kontos. Ein Job, der einen fremden Pull Request testet, darf keine Produktionszugangsdaten erhalten.

Eine grüne Pipeline muss etwas beweisen

Ein Unit-Test prüft eine Regel; ein Integrationstest sollte die echte Datenbank-Engine starten und Transaktionen sowie Constraints nachweisen. Ein Vertragstest schützt die Grenze zum Partner. Ein E2E-Test prüft den wichtigsten Nutzerweg. Ergänze absichtliche Fehler: Zugriffsverweigerung, Timeout, Duplikat und inkompatibles Schema. Hundert Tests mit einem idealen Mock belegen keine korrekte Transaktionsisolation.

Lege gesondert fest, was eine Veröffentlichung stoppt. Fehler in Autorisierung oder Migrationstests sollten das Deployment blockieren. Schwachstellenscans brauchen Regeln zur Relevanzbewertung, Behebungsfristen und Ausnahmebehandlung. Ein Team, das einen dauerhaft roten Scanner ignoriert, hat nur Dekoration in seiner Pipeline.

Dokumentation: GitHub Actions und OIDC und Workflows sicher verwenden.

08 / Alte und neue Version leben nebeneinander

Ein Anwendungs-Rollback macht Datenänderungen nicht automatisch rückgängig

Die neue Version schreibt eine andere Bedeutung in ein Feld, die Migration entfernt die alte Spalte, und wenige Minuten später steigen die Fehlerzahlen. Du stellst das vorige Image wieder her. Es erwartet weiterhin die alte Struktur. Der „Rollback“-Button funktioniert technisch, die Anwendung fachlich aber nicht. Eine sichere Rückkehr planst du vor der Veröffentlichung.

Erweitern, übertragen, erst dann entfernen

Bei Expand–Contract ergänzt das erste Deployment eine neue Struktur, die mit der alten Version kompatibel ist. Im nächsten Schritt werden Daten portionsweise übertragen und Schreibvorgänge konsistent gehalten. Danach nutzt die Anwendung das neue Modell. Erst wenn alte Prozesse und Empfänger die bisherige Struktur nicht mehr benötigen, entfernt eine separate Änderung das veraltete Element.

1. Neue Felder hinzufügen; die alte Version liest weiterhin die bisherigen.
2. Kompatibles Schreiben des alten und neuen Formats bereitstellen.
3. Historische Daten in kleinen, wiederaufnehmbaren Batches ergänzen.
4. Vollständigkeit vergleichen; Lesen über ein Feature Flag umstellen.
5. Beobachten und die Rückkehr zum bisherigen Lesen ermöglichen.
6. Das alte Format in einem separaten, späteren Deployment entfernen.

Prüfe vor dem Umschalten alle aktiven Schreibpfade, einschließlich alter Instanzen und Worker. Sie dürfen nicht unbemerkt ausschließlich das alte Format pflegen. Ein Backfill sollte die Datensatzversion oder eine geeignete Update-Bedingung prüfen, damit er keine neuere Änderung überschreibt. Auch doppeltes Schreiben muss korrekt sein. Liegen beide Felder in derselben Datenbank, nutze eine Transaktion. Liegen sie in zwei Diensten, brauchst du einen Synchronisations- und Abgleichprozess. Ein Backfill muss sicher wiederholbar sein; lange Tabellensperren während der Arbeitszeit können mehr schaden als die Schemaänderung selbst.

Ein schrittweises Deployment hat vorher festgelegte Abbruchbedingungen

Die neue Version kann zunächst einen kleinen Teil des Verkehrs erhalten. Beobachte Fehler, Latenz und Geschäftsergebnis, nicht nur, ob der Prozess noch läuft. Lege Schwelle, Messfenster und Entscheidungsverantwortung fest. Ein Feature Flag kann einen neuen Pfad abschalten, macht aber keine bereits ausgeführte Finanzoperation rückgängig und ersetzt keine Datenkompatibilität.

Führe nach dem Deployment kurze Tests aus: Anmeldung eines Testkontos, autorisierter Lesezugriff, kontrollierter Vorgang und Verarbeitung einer Nachricht durch den Worker. Umgebung und Testdaten müssen erkennbar sein, damit das Monitoring sie nicht für Kundenverkehr hält. Ein automatischer Produktionstest darf nicht versehentlich eine echte Karte belasten oder Nachrichten an zufällige Empfänger senden.

Warum Kompatibilität zum Rollback gehört: AWS Builders’ Library.

Pracownia-Szenario / Bereitschaftsdienst um 14:17

„Wir haben RAM ergänzt. Eine Stunde später war das Problem wieder da.“

Der Importer liest die gesamte Datei, erstellt eine Liste aller Datensätze und startet für jeden eine Aufgabe. Die größere Maschine hat den Ausfall nur verschoben. Wir müssen wissen, wie viel Arbeit gleichzeitig laufen darf, wie groß ein Element ist und was geschieht, wenn der Produzent schneller als der Konsument ist.

09 / Ressourcen gehören zum Vertrag

Speicher begrenzen wir auf mehreren Ebenen, nicht mit einer einzigen Variablen

Miss zuerst. Relevant sind der Speicher des gesamten Prozesses oder Containers, der vom GC verwaltete Heap, Allokationsrate, GC-Pausen und die Zahl laufender Vorgänge. Ein Heap, der nach mehreren vollständigen Collections weiter wächst, deutet auf etwas anderes hin als ein stabiler Heap bei wachsendem nativem Speicher. Eine einmalige Spitze beim Erzeugen einer großen Datei braucht eine andere Korrektur als ein unbegrenzt wachsender Cache.

Typische Ursachen sind unspektakulär: ToListAsync() über eine ganze Tabelle, riesiges JSON im Speicher, ein Dictionary ohne Ablauf, nicht freigegebene Streams, zu viele parallele Tasks oder das Loggen ganzer Dokumente. Lege maximale Seiten-, Datei-, Request- und Ergebnisgrößen fest. Verarbeite Daten als Stream, soweit das Format es zulässt; lies kleine Chargen und halte keine unnötigen Kopien vor.

Eine begrenzte Queue ist eine bewusste Antwort auf Überlastung

Wenn 200 Aufgaben pro Sekunde eintreffen, du aber 50 ausführst, wächst der Rückstand jede Sekunde um etwa 150. Ohne Limit speichert der Arbeitsspeicher nur das Problem. Du kannst auf freien Platz warten, Arbeit mit einer Überlastungsmeldung ablehnen oder sie dauerhaft an einen Broker übergeben. Die Wahl hängt von der Zusage an den Nutzer ab. Eine Aufgabe still zu verwerfen, nachdem „angenommen“ angezeigt wurde, ist keine korrekte Strategie.

var queue = Channel.CreateBounded<Job>(
    new BoundedChannelOptions(100)
    {
        FullMode = BoundedChannelFullMode.Wait,
        SingleReader = true,
        SingleWriter = false
    });

// Wartet auf freien Platz; berücksichtigt den Abbruch.
await queue.Writer.WriteAsync(job, cancellationToken);

// Alternative: ohne Wartezeit ablehnen, wenn der Channel voll ist.
bool accepted = queue.Writer.TryWrite(job);

Eine unbegrenzte Zahl von Produzenten, die in WriteAsync warten, hält weiterhin Tasks und Puffer im Speicher. Begrenze auch gleichzeitige Anfragen beziehungsweise Produzenten und die Wartezeit. Die letzten beiden Zeilen zeigen alternative Wege zum Einstellen von Arbeit – führe nicht beide für dieselbe Aufgabe aus. Der Channel liegt im Prozessspeicher und ist kein dauerhafter Broker. Eine Kapazität von 100 begrenzt die Elementzahl, nicht deren Gesamtgröße. Hundert Objekte mit je einer 20-MB-Datei benötigen weiterhin sehr viel Speicher. Übergib besser die ID einer Datei im privaten Storage und lies sie über einen kontrollierten Stream.

Ein Kubernetes-Request ist keine Obergrenze

requests.memory dient unter anderem dazu, die Platzierung des Pods auf einem Node zu planen. limits.memory setzt eine durch Systemmechanismen durchgesetzte Containergrenze. Ein Prozess kann wegen Speichermangels beendet werden; die Anwendung erhält nicht immer Gelegenheit, eine Ausnahme sauber zu behandeln. Ein CPU-Limit kann die verfügbare Rechenzeit drosseln. Zu enge Werte können daher Latenzen und Timeouts erhöhen.

resources:
  requests:
    cpu: "250m"
    memory: "256Mi"
  limits:
    cpu: "1000m"
    memory: "512Mi"

Dieser Ausschnitt beschreibt kein vollständiges Deployment. Er umfasst einen einzelnen Container. Bei mehreren Replikaten, Sidecars und Node-Ressourcen ist der Gesamtverbrauch anders. Wähle Werte anhand von Lasttests, Startzeit und GC-Profil; lasse Reserven und beobachte anschließend, ob das System sie braucht.

.NET-Falle: „60“ bedeutet nicht immer sechzig

Ein GC-Heap-Limit ist kein Limit für den gesamten Prozessspeicher. Thread-Stacks, Teile der Runtime-Strukturen und native Allokationen liegen unter anderem außerhalb davon. Ein Heap-Limit in Höhe des gesamten Containerlimits kann zu wenig Platz für den Rest lassen. Prüfe zuerst das Verhalten der Runtime im Container; Standardmechanismen berücksichtigen Umgebungsgrenzen, und manuelle Einstellungen sollten aus Messungen folgen.

# Umgebungsvariable: hexadezimale Schreibweise
DOTNET_GCHeapHardLimitPercent=0x3C

// Ausschnitt aus runtimeconfig.json: Dezimalzahl
"System.GC.HeapHardLimitPercent": 60

In der Umgebungsvariablen wird der Wert 60 als hexadezimales 0x60interpretiert, also dezimal 96. Prüfe außerdem die Priorität der Einstellungen: Ein ausdrückliches Byte-Limit kann verhindern, dass der Prozentwert verwendet wird. Setze nicht vorsorglich alle Varianten gleichzeitig.

Details: GC-Konfiguration in .NET, Requests und Limits in Kubernetes und System.Threading.Channels.

10 / Ein Dienst bringt Kosten und Verantwortung mit

AWS und Azure: Wähle benötigte Fähigkeiten statt des größten Diagramms

Für ein kleines Team kann eine verwaltete Anwendungsplattform der sinnvollere Start sein als ein eigener Kubernetes-Cluster. Ein Cluster bietet Kontrolle, bringt aber Updates, Netzwerk, Policies, Kapazitätsplanung und Bereitschaftsdienst mit. Wähle ihn, wenn das Team diese Möglichkeiten braucht und betreiben kann. Nur weil eine Anwendung in einem Container läuft, benötigt sie nicht sofort den Orchestrator mit den meisten Optionen.

Die folgende Übersicht zeigt beispielhafte Dienste mit verwandten Aufgaben. Sie sind nicht eins zu eins austauschbar. Semantik, Limits, Abrechnung, Regionen und Verantwortungsumfang unterscheiden sich:

Domänengrenzen und Integrationsverträge sind portabler als Dienstnamen. Ein Adapter kann Brokerdetails verbergen, sollte aber keine Garantien versprechen, die eine Implementierung nicht erfüllt. Ist die Nachrichtenreihenfolge eine Geschäftsanforderung, definiere ihren Geltungsbereich und prüfe ihn für die gewählte Konfiguration.

Ein Budgetalarm stoppt den Zähler nicht

Budgets helfen, Kostenanstiege zu erkennen, doch Abrechnungsdaten kommen verzögert an. Behandle einen Alarm bei 100 PLN nicht als Garantie, dass die Rechnung diesen Betrag niemals überschreitet. Auch automatische Aktionen wirken verzögert und nur in begrenztem Umfang. Eine Datenbank anzuhalten kann den Geschäftsbetrieb unterbrechen, während ein Teil der Kosten weiterläuft.

Kosten begrenzt du vorher: maximale Replikazahl, parallele Aufgaben, Upload-Größe, Aufgabendauer, Request-Limits und Aufbewahrungsrichtlinien. Weise Ressourcen Verantwortliche und Kosten-Tags zu. Prüfe vergessene Testumgebungen, alte Snapshots, regionsübergreifenden Transfer, NAT und doppelte Logs. Autoskalierung ohne festgelegtes Maximum kann einen Codefehler in ein finanzielles Problem verwandeln.

Lege außerdem fest, was beim Erreichen des Limits passiert: neue Aufgaben ablehnen, eine Queue mit geschätzter Wartezeit oder ausgewählte Funktionen einschränken. Schütze ein Cloud-Konto niemals allein mit einem Zähler im Browser. Die letztliche Kontrolle liegt bei Server und Plattform.

Grenzen der Budgetmechanismen: Azure Cost Management und AWS Budgets.

11 / Miss den Dienst aus Sicht des Menschen

Der Server antwortet mit 200. Warum hat der Kunde noch keinen Bericht?

Die API kann korrekt laufen, während der Worker seit einer Stunde keine Aufgaben mehr abholt. Neben HTTP-Fehlerzahlen brauchst du daher das Alter der ältesten Nachricht, die Zahl ausstehender Vorgänge und deren Abschlusszeit. Die durchschnittliche Queuelänge sagt nicht, ob ein Kunde dauerhaft feststeckt.

Für Pracownia nehmen wir ein Übungsziel: 99 % der korrekt angenommenen Bestellungen sollen innerhalb von zwei Minuten eine Lagerbestätigung erhalten. Das ist ein SLO für eine konkrete Funktion, kein pauschales Versprechen für die gesamte Anwendung. Definiere Anfang und Ende der Messung, Ausnahmen und die Behandlung von Partnerausfällen. Die Messung soll das Kundenerlebnis abbilden, auch wenn die unmittelbare Ursache außerhalb deines Servers liegt.

Übertrage den Trace-Kontext durch HTTP und Nachrichten mit Standardmechanismen, etwa OpenTelemetry. Ergänze Ereignis- und Vorgangs-IDs in den Logs. Speichere keine Tokens, Secrets, vollständigen Dokumente oder unnötigen personenbezogenen Daten. Für Telemetrie gelten definierte Aufbewahrungsfristen und Zugriffsrechte. Verwende orderId nicht als Label jeder Metrik: Sehr viele eindeutige Werte können Kosten erhöhen und das Monitoringsystem belasten.

Drei Probes, drei unterschiedliche Fragen

• Startup: Hatte die Anwendung genug Zeit zum Starten? Diese Probe lässt langsam startenden Prozessen Zeit.
• Readiness: Kann diese Instanz jetzt Traffic annehmen? Ein Fehlschlag entfernt sie aus den bereiten Empfängern, statt sie automatisch neu zu starten.
• Liveness: Steckt der Prozess so fest, dass ein Neustart helfen kann? Fehler oberhalb einer festgelegten Schwelle können den Container neu starten.

Hängt Liveness bedingungslos von der Datenbank ab, kann ein kurzer Datenbankausfall eine Neustartlawine aller Anwendungen auslösen. Auch Readiness braucht bewusste Planung: Hängen alle Instanzen vom selben Partner ab, kann ihre gemeinsame Abschaltung die Lage verschlechtern. Manchmal ist es besser, nur eine Funktion abzuschalten und die übrigen verfügbar zu halten.

Ein guter Alarm sagt, wer reagieren muss, welche Auswirkungen bestehen und wo zuerst nachzusehen ist. „CPU 85 %“ ohne Kontext muss niemanden zwingend wecken. „Seit fünf Minuten wurde keine gültige Aufgabe abgeschlossen, die älteste wartet zwölf Minuten“ weist auf eine konkrete Diagnose hin. Ergänze ein kurzes Runbook: Dashboard, erste drei Prüfungen, sichere Maßnahme und Eskalationsweg.

Dokumentation: Bedeutung der Kubernetes-Probes und OpenTelemetry in .NET.

12 / Ruhe entsteht vor dem Alarm

Der Notfallplan muss auch funktionieren, wenn der Systemautor schläft

Zurück zur Zahlung am Artikelanfang. Wir sehen „ausstehend“, der Kunde sagt, er habe bezahlt. Die schlechteste erste Reaktion ist eine manuelle erneute Belastung. Stoppe zunächst das automatische Erzeugen weiterer Auswirkungen, ermittle Transaktions-IDs und vergleiche den Anbieterstatus mit unseren Daten. Erst danach setzt du die Verarbeitung fort, markierst den Fall zur Klärung oder startest eine vereinbarte Kompensation.

Eine DLQ ist kein Papierkorb, den niemand öffnet

Eine Dead-Letter Queue enthält Nachrichten, die nicht nach den vereinbarten Regeln verarbeitet werden konnten. Jede sollte eine erkennbare Ursache, eine Versuchszahl und einen Verantwortlichen haben. Sende nach einer Korrektur nicht gedankenlos die ganze Queue mit Höchstgeschwindigkeit erneut: Du könntest den Ausfall wiederholen oder den Partner überlasten. Beginne mit einer kleinen Stichprobe, beobachte das Ergebnis und erhöhe erst danach das Tempo.

Ein Backup ist der Anfang des Nachweises, nicht sein Ende

Definiere RPO, den zeitlich ausgedrückten akzeptablen Datenverlust, und RTO, die angestrebte Wiederherstellungszeit. Ein Übungs-RPO von 15 Minuten und ein RTO von zwei Stunden sind zu prüfende Anforderungen, keine Eigenschaften einer gekauften Maschine. Ein tägliches Backup erfüllt das erste Ziel ohne zusätzliche Mechanismen nicht.

Stelle das Backup in einer isolierten Umgebung wieder her. Prüfe Verschlüsselungsschlüssel, Rechte, vollständige Dateien und kompatible Anwendungsversionen. Kontrolliere Geschäftsregeln, Datensatzanzahl und Lesbarkeit der Dokumente. Deaktiviere E-Mail-Versand und echte Zahlungen in der Wiederherstellungsumgebung, damit der Test keine Kundenaktionen wiederholt.

Nach dem Zurücksetzen der Datenbank kann ihr Stand älter sein als bereits an Partner gesendete Ereignisse. Nach dem Restore ist ein Datenabgleich nötig. Löschschutz für Sicherungen und getrennte Backup-Rechte reduzieren das Risiko, dass ein kompromittierter Zugang sowohl Produktion als auch die letzte Rückkehrmöglichkeit zerstört.

Dokumentiere nach dem Vorfall Zeitleiste, Auswirkungen, Ursache und konkrete Aufgaben mit Verantwortlichen. „Nächstes Mal aufpassen“ ist keine Systemverbesserung. Ein Duplikattest, ein geändertes Limit, ein zusätzliches Signal oder ein einfacheres Rollback sind es. Eine gute Analyse hilft der nächsten Person und sucht keinen Schuldigen.

Backups überprüfen: AWS Well-Architected: regelmäßige Wiederherstellungstests.

13 / Gelesen? Jetzt selbst ausprobieren

.NET-Labor: Brich den Ablauf, bevor das Netzwerk es tut

Lade ein kleines Konsolenprojekt mit Quellcode und polnischer Anleitung herunter. Es läuft lokal, ohne Cloud-Konto, Schlüssel oder externe NuGet-Pakete. Es umfasst acht selbstprüfende Szenarien: Wiederholung, Payload-Konflikt, Rennen von 32 Anfragen, firmenspezifischer Schlüsselbereich, fehlgeschlagener Commit, Publikationsausfall, Konsumenten-Deduplizierung und volle Queue.

dotnet run --project ArcCloud.ProductionPatterns.Lab.csproj --configuration Release

Erwartet werden acht Meldungen PASS und Exit-Code 0. Das Projekt zielt für die Laborkompatibilität auf net8.0 und benötigt die passenden SDK-Referenzpakete. Die README erklärt den Start mit einer neueren Runtime. Prüfe für ein neues Produkt die aktuell unterstützte Version .NET 10 LTS; das Ziel dieses kleinen Labors ist keine Versionsempfehlung für ein neues System.

Drei Runden, mit denen du den Mechanismus verstehst

1. Ergebnis vorhersagen. Notiere vor dem Start des Szenarios DispatcherCrash , wie viele Bestellungen, Zustellungen und Auswirkungen entstehen. Lies erst danach das Ergebnis.
2. Baue in einer Kopie einen kontrollierten Fehler ein. Überspringe die Inbox-Prüfung. Der Duplikattest sollte eine zusätzliche Auswirkung erkennen. Besteht er weiterhin, prüfe, ob du die richtige Stelle geändert hast und ob der Test das Richtige misst.
3. Übertrage die Regel auf deine Anwendung. Finde einen Vorgang, der sich wiederholen kann. Notiere Schlüssel, Geltungsbereich, Aufbewahrungsdauer, Transaktionsgrenze und Verfahren zum Ergebnisabgleich.

Das Paket enthält außerdem Arbeitsblätter für Integrationsvertrag, Deployment-Plan und Incident-Runbook. Fülle sie mit echten Namen, Verantwortlichen und Schwellenwerten. Ersetze „Monitoring: vorhanden“ durch die Adresse eines konkreten Dashboards und die Bedingung, unter der jemand handelt.

14 / „Fertig“ braucht einen Nachweis

Wie nimmst du eine Anwendung ab, ohne eine Aufgabenliste mit Qualität zu verwechseln?

Organisiere die Abnahme nach Szenarien statt nach der Zahl erledigter Tickets. Jedes Versprechen braucht eine Ausgangsbedingung, ein erwartetes Ergebnis und einen Ort, an dem dieses dokumentiert wird. So kann ein neues Teammitglied die Prüfung wiederholen, statt darauf zu vertrauen, dass jemand „schon alles durchgeklickt hat“.

Beziehe die Nutzersicht in die Abnahme ein: Erklärt die Meldung eine Verzögerung, lässt sich der Vorgang nach Aktualisieren wiederfinden, und sieht der Support den Status? Sonst kann ein technisch korrektes „202“ für den Kunden eine leere Seite bedeuten. Genau hier treffen Leistung, Verfügbarkeit und Nutzbarkeit zusammen.

Wie dieses Wissen länger bleibt

Du musst nicht den ganzen Text auswendig lernen. Merke dir die Fragen, die in jedem Projekt wiederkehren: „Was, wenn die Antwort nicht ankommt?“, „Wer darf diesen Datensatz ändern?“, „Was begrenzt die Arbeitsmenge?“, „Wie stellen wir Daten wieder her?“ und „Welcher Test könnte zeigen, dass wir falschliegen?“

Ein Artikel ersetzt weder Praxis noch Code-Reviews oder die Verantwortung für einen laufenden Dienst. Er kann dir aber eine wiederholbare Arbeitsweise geben: Annahme, Implementierung, Ausfallversuch, Messung und Korrektur. Dieser Prozess bleibt nützlich, auch wenn sich Bibliotheksnamen ändern.

15 / Acht Entscheidungen, die du begründen können solltest

Kurzer Test: Was tust du im Bereitschaftsdienst?

Wähle für jede Frage eine Antwort. Du erfährst sofort ihre Konsequenz und kannst sie korrigieren. Das ist eine Lernübung, kein Zertifikat. Das Ergebnis wird weder an den Server gesendet noch nach dem Neuladen gespeichert.

Wähle die Antworten. Das Ergebnis bleibt in diesem Browser-Tab.

Nächste Schritte / Vom Wissen zur konkreten Änderung

Dein System braucht keine weitere allgemeine Liste guter Praktiken.

Es braucht Antworten darauf, wo es Daten verlieren, Vorgänge verdoppeln, fremde Datensätze offenlegen oder die Infrastruktur überlasten könnte. Danach braucht es eine Reihenfolge für Korrekturen und Tests, die ihre Wirksamkeit belegen.

Bei ArcCloud prüfen wir Anwendungen, Integrationen und Cloud-Umgebungen. Wir unterstützen vom Erkennen eines Problems bis zur Behebung: Umfang festlegen, Risiken anhand konkreter Szenarien zeigen und die Prüfung nach dem Deployment planen. Die passende Auditart hängt davon ab, was tatsächlich untersucht werden muss – eine öffentliche Website zeigt nicht die gesamte Logik eines privaten Systems.

Du möchtest weitere Workshops dieser Art? Entdecke ArcCloud Engineering Brief. Unten findest du das aktuelle Abonnementangebot. Dieser Leitfaden, das Quiz und das Labor bleiben ohne Kauf zugänglich.

16 / Wenn Details zählen, lies die Quelle

Dokumentation, zu der sich die Rückkehr lohnt

Die Kapitel verlinken die Dokumentation der Technologieanbieter und OWASP. Die folgende Liste ordnet die weiterführende Lektüre. Prüfe vor einer Konfiguration Runtime-Version, Ressourcentyp und Region. Dienstlimits und Möglichkeiten ändern sich schneller als grundlegende Entwurfsprinzipien.

• Microsoft: Retry Pattern — wann Wiederholungen helfen und wann sie ein Problem verschärfen.
• AWS: Idempotent APIs — Identität eines Vorgangs und sichere Wiederholungen.
• AWS: Transactional Outbox — Daten und Publikationsabsicht speichern.
• GitHub: Webhook-Signaturen — exakter Inhalt, Signatur und Secret.
• OWASP API Security: BOLA — Zugriff auf ein konkretes Objekt.
• OWASP: SSRF Prevention — Grenzen beim Abruf externer Adressen.
• GitHub Actions: OIDC — Vertrauen und kurzlebige Pipeline-Identität.
• Microsoft: GC-Konfiguration — Format und Geltungsbereich der Heap-Limits.
• Kubernetes: Containerressourcen — Requests, Limits und Verhalten bei Überlastung.
• Kubernetes: Probes — Bereitschaft, Start und Lebensfähigkeit eines Prozesses.
• Microsoft: Azure für AWS-Anwender — Dienstrollen vergleichen, ohne vollständige Austauschbarkeit anzunehmen.
• .NET-Supportrichtlinie — eine unterstützte Version für ein echtes Produkt wählen.

Lernmaterial von ArcCloud Studio · geprüft am 13.10.2026 · konzeptionelle Illustration, fiktives System Pracownia. Vertiefung der Codegrundlagen: Sauberer Code in C# und Clean Architecture.