Das Diagramm, das alle zeichnen, ist das für den Idealfall: Nutzer trifft App, App trifft Datenbank, fertig. Fürs Whiteboard reicht das, für den Betrieb eines Systems ist es nutzlos. Produktion hat eine andere Form, weil Produktion Traffic-Spitzen, Node-Ausfälle, Deploys und den gelegentlichen schlechten Nachmittag überstehen muss. Diese Realität zu visualisieren, nicht die aufgeräumte Skizze, macht aus einem Diagramm ein operatives Werkzeug.
Der Trick ist, nicht mehr „wer redet mit wem“ zu zeichnen, sondern drei sich überlagernde Ansichten: den Traffic-Pfad, die Fehlerdomänen und die Skalierungsgrenzen. Die meisten Produktionsdiagramme sind wirr, weil sie alle drei gleichzeitig und ohne Absicht zeigen wollen. Zeichne sie bewusst, und das Bild wird zu etwas, womit du um 3 Uhr nachts wirklich argumentieren kannst.
Ansicht eins: der Traffic-Pfad
Verfolge eine einzelne Anfrage von außen bis zu den Daten und zurück, und zeichne jeden Hop, den sie wirklich nimmt. In Produktion ist das länger, als die Skizze zugibt:
- Ein CDN oder Edge davor, das Cache-Treffer ausliefert, bevor dein Origin sie überhaupt sieht.
- Ein Load Balancer, der den Traffic auf Instanzen verteilt.
- Eine Schicht zustandsloser App-Server, nicht ein einzelner Kasten.
- Ein Cache, den die meisten Lesezugriffe vor der Datenbank treffen.
- Eine Primary-Datenbank für Schreibzugriffe und Read Replicas für den Rest.
- Ein asynchroner Pfad: eine Queue und Worker für die Arbeit, die nicht inline passieren sollte.
Ansicht zwei: die Fehlerdomänen
Zeichne jetzt die Linien, die Dinge danach gruppieren, „was gemeinsam ausfällt“. Availability Zones sind die offensichtlichen: zwei oder drei Spalten, auf die deine App- und Datenschicht verteilt sind, damit dich ein Zonenausfall nicht lahmlegt. Fehlerdomänen sind aber mehr als Zonen. Ein gemeinsamer Cache ist eine Domäne. Eine einzelne Primary-Datenbank ist eine Domäne. Die Queue ist eine Domäne. Wenn du diese Grenzen zeichnest, sind deine Single Points of Failure nicht mehr zu übersehen, denn sie erscheinen als der Kasten, von dem alles abhängt und neben dem kein Partner steht.
Ein Produktionsdiagramm zahlt sich in dem Moment aus, in dem es dir den Kasten zeigt, den du dir nicht leisten kannst zu verlieren.
Ansicht drei: die Skalierungsgrenzen
Markiere, was skaliert und wie. Die App-Schicht skaliert horizontal, also zeichne sie als wachsende Gruppe, nicht als festes Paar. Die Datenbank skaliert anders: nach oben für Schreibzugriffe, mit Replicas in die Breite für Lesezugriffe, und diese Asymmetrie zu zeigen lohnt sich, weil Produktionssysteme genau dort an eine Wand stoßen. Autoscaling-Gruppen, Worker-Pools, die mit der Queue-Tiefe wachsen, und jede Komponente mit fester Kapazität verdienen einen sichtbaren Hinweis. Die Skalierungsgeschichte ist die Hälfte der Kapazitätsplanung, und sie lebt in dieser Ansicht.
Vergiss nicht die Bausteine, die es nur in Produktion gibt
Das Design-Dokument lässt sie weg; Produktion kann das nicht. Observability (Metriken, Logs, Traces) zapft fast jede Komponente an. Secrets und Konfiguration kommen von irgendwoher. Es gibt einen Bastion-Host oder einen privaten Zugangsweg für Menschen. Backups laufen gegen die Datenschicht. Du musst nicht alles in ein Diagramm packen, und das solltest du auch nicht, aber ein Produktionsbild, das jedes davon weglässt, ist Fiktion. Gib den wichtigen einen Kasten.
Halte es aktuell, sonst lügt es
Ein Produktionsdiagramm ist nur nützlich, wenn es der Produktion entspricht, und Produktion ändert sich ständig. Genau deshalb solltest du es aus deinem Terraform oder deinen Manifesten ableiten und regelmäßig neu erzeugen, statt liebevoll eine Zeichnung von Hand zu pflegen, die abdriftet. Kombiniere das generierte Gerüst mit deinen Annotationen, bette es ins Runbook ein und aktualisiere es, wenn sich die Infrastruktur bewegt. Ein aktuelles Produktionsdiagramm ist eines der wirkungsvollsten Dokumente, die ein Team besitzen kann.
Zeichne den Traffic-Pfad, markiere die Fehlerdomänen, zeige die Skalierungsgrenzen und erzeuge die Basis aus echter Infrastruktur, damit sie ehrlich bleibt. Das ist das Diagramm, das du während eines Incidents wirklich offen haben willst.