Die Hälfte deiner Services läuft gleichzeitig in Timeouts, und es wurde nichts deployed. Wie führst du diesen Incident?

Ruf den Incident aus, benenn einen Incident Commander und trenn Untersuchung von Kommunikation. Dann jag die gemeinsame Dependency: Authentifizierung, DNS, eine Datenbank, ein Zertifikat, die Control Plane des Service Mesh oder eine Cloud-Zone. Prüf, was sich außerhalb von Deploys geändert hat, also Config-Pushes, Feature Flags, DNS-Einträge, ablaufende Zertifikate und den Provider-Status. Mitigier vor der Diagnose, indem du Last abwirfst, umschaltest oder das verdächtige Flag deaktivierst, und verifizier dann mit nutzerseitigen SLIs.

Breit und gleichzeitig ohne Deploy heißt fast nie zehn unabhängige Bugs, sondern eine Sache darunter. Ich stelle also sofort die Incident-Struktur auf, Commander und jemand für die Kommunikation, und arbeite dann die Liste der gemeinsamen Schichten ab: Auth-Service, DNS, die primäre Datenbank, die Mesh Control Plane, Zertifikate und den Gesundheitsstatus des Cloud-Providers. Parallel frage ich, was sich geändert hat, das kein Code ist, denn Config-Pushes und Feature Flags sind Änderungen, die Leute nicht mitzählen. Wir hatten genau dieses Muster einmal, und es war die Erneuerung einer internen Certificate Authority, bei der ein Intermediate leise abgelaufen war, sodass jeder mTLS-Handshake in derselben Minute zu scheitern begann. Der Hinweis war, dass die Fehler auf Verbindungsebene lagen und nicht auf Anwendungsebene. Während diese Untersuchung läuft, will ich einen Mitigationshebel bereit haben, meist nicht essenziellen Traffic abwerfen oder auf die Sekundärregion umschalten, denn ich bin lieber degradiert und stabil als komplett kaputt, während wir nachdenken. Danach verifiziere mit echten User-Metriken, nicht nur mit grünen Pods.