# Alles war grün. Nur die Kontrolle fehlte > Warum ein erfolgreiches Deployment noch keinen beherrschbaren Betrieb beweist. **Quelle:** https://pilot.isp.validatus.com/de/docs/everything-was-green-control-was-missing **Sprache:** de **Veröffentlicht:** 2026-10-08 **Aktualisiert:** 2026-10-13 **Kategorie:** Infrastruktur **Tags:** IT Operations, Observability, Network Policies, GitOps, SRE *Warum ein erfolgreiches Deployment noch keinen beherrschbaren Betrieb beweist.* Kurz vor der Freigabe einer neuen Bestellanwendung steht ein letzter Sicherheitstest an. Die Anwendung soll mit dem ERP kommunizieren und Dokumente im DMS ablegen. Andere interne Systeme benötigt sie nicht. Das IT-Team prüft deshalb zwei Verbindungen: eine erlaubte zum ERP und eine, die zur internen Personaldatenbank blockiert sein müsste. Beide Verbindungen funktionieren. Dabei sieht zunächst alles richtig aus. Die Deployment-Pipeline meldet Erfolg. Die Konfiguration ist versioniert. Das Monitoring zeigt keine Auffälligkeiten. Auch eine entsprechende Netzwerkregel liegt im Repository. **Erst der Test einer Verbindung, die nicht funktionieren dürfte, macht das Problem sichtbar.** Das Beispiel ist hypothetisch. Die technische Schwachstelle dahinter ist real. ## Die Regel war da. Der Schutz nicht. In Kubernetes lassen sich Verbindungen zwischen Anwendungen mit sogenannten NetworkPolicies begrenzen. Doch eine solche Regel schützt nicht allein dadurch, dass sie existiert. Sie benötigt eine Netzwerkkomponente, die ihre Vorgaben tatsächlich durchsetzt. Fehlt diese Unterstützung, bleibt die Policy wirkungslos. Auch falsch gewählte Selektoren können dazu führen, dass eine Regel nicht die vorgesehenen Workloads erfasst. Eine korrekt ausgerollte Konfiguration kann somit Sicherheit suggerieren, die der tatsächliche Netzwerkverkehr nicht bestätigt. **Zwischen einer definierten Regel und wirksamer Kontrolle liegt der Nachweis.** Das betrifft auch GitOps. GitOps-Systeme vergleichen den tatsächlichen Zustand fortlaufend mit einer versionierten Sollkonfiguration. Sie erkennen Abweichungen und können den gewünschten Zustand wiederherstellen. Aber sie entscheiden nicht, ob dieser Zustand überhaupt richtig ist. Eine ungeeignete Konfiguration lässt sich genauso zuverlässig reproduzieren wie eine gute. ## Ein Dashboard entscheidet nicht. Nehmen wir an, das Team korrigiert die Zugriffskontrolle und bestätigt ihre Wirkung durch einen erneuten Test. Einige Tage später wird die Bestellanwendung langsamer. Anfragen dauern länger. Das Monitoring erkennt steigende Latenzen. Jetzt stellt sich eine andere Frage: Was ist die Ursache? Liegt es an der letzten Änderung? Am ERP? An einer externen Abhängigkeit? Verteilte Traces, beispielsweise mit OpenTelemetry, helfen dabei, Anfragen über Systemgrenzen hinweg nachzuvollziehen. Aber Messwerte erklären nicht automatisch, warum eine Veränderung eingetreten ist. Und sie entscheiden nicht, ob ein Rollback die richtige Reaktion wäre. Ein vorschneller Rollback könnte eine funktionierende Änderung zurücknehmen, während das eigentliche Problem bestehen bleibt. Außerdem ist die Rückkehr zu einer älteren Anwendungsversion noch keine vollständige Wiederherstellung von Daten und Geschäftsprozessen. **Monitoring macht Veränderungen sichtbar. Kontrolle entsteht erst, wenn daraus verantwortbare Entscheidungen werden.** ## Kontrolle entsteht zwischen den Systemen. Genau hier beginnt die eigentliche Architekturarbeit. Identitäten bestimmen, wer handeln darf. Netzwerkregeln begrenzen Verbindungen. Deployment-Systeme verwalten Konfigurationen. Monitoring liefert Signale. Wiederherstellungsverfahren schaffen einen möglichen Rückweg. Jeder Baustein erfüllt seine Aufgabe. Aber erst ihr Zusammenspiel macht den Betrieb beherrschbar. Drei Fragen sind deshalb entscheidend: 1. **Berechtigung:** Wer darf eine Änderung auslösen? 2. **Wirkung:** Wie weisen wir nach, dass Regeln und Konfigurationen tatsächlich greifen? 3. **Reaktion:** Wer entscheidet bei Abweichungen – und wie stellen wir den Betrieb wieder her? Dafür benötigen wir nicht zwangsläufig mehr Werkzeuge. Oft beginnt gute Architektur damit, vorhandene Systeme, ihre Abhängigkeiten und ihre Verantwortlichkeiten so miteinander zu verbinden, dass ihre tatsächliche Wirkung überprüfbar wird. ## Nicht alles, was funktioniert, ist unter Kontrolle. Eine erfolgreiche Pipeline bestätigt ein Deployment. Ein Dashboard zeigt gemessene Zustände. Eine Policy beschreibt eine beabsichtigte Regel. Keine dieser Aussagen allein beweist, dass der Betrieb beherrscht wird. **Gute Architektur sorgt nicht nur dafür, dass Systeme funktionieren. Sondern dafür, dass wir ihre Wirkung verstehen, Abweichungen erkennen und wissen, wie wir darauf reagieren.** --- ## Quellen und Vertiefung - [Kubernetes – Network Policies](https://kubernetes.io/docs/concepts/services-networking/network-policies/) - [OpenGitOps – Principles](https://opengitops.dev/) - [OpenTelemetry – Observability Primer](https://opentelemetry.io/docs/concepts/observability-primer/) - [Google SRE – Service Level Objectives](https://sre.google/sre-book/service-level-objectives/) - [NIST – Zero Trust Architecture](https://csrc.nist.gov/pubs/sp/800/207/final) *Das Einstiegsszenario ist hypothetisch. Die technischen Aussagen beruhen auf dokumentierten Mechanismen und daraus abgeleiteten Architekturprinzipien.*