Die p99-Latenz deiner Haupt-API verdreifacht sich zwanzig Minuten nach einem Deploy. Erklär mir, was du tust.

Stabilisier, bevor du untersuchst: Wenn das Timing mit dem Deploy korreliert, roll erst zurück oder stopp das Rollout. Vergleich dann alte und neue Version auf denselben Dashboards, prüf Fehlerrate und Saturation neben der Latenz und stell fest, ob der Ausschlag gleichmäßig ist oder auf einen Endpoint, einen Shard oder eine Zone beschränkt. Traces zeigen, welcher Hop gewachsen ist. Die Ursachenanalyse kommt, wenn die User in Sicherheit sind.

Als Erstes stoppe ich die Blutung. Wenn vor zwanzig Minuten ein Deploy rausging und sich die Latenz verdreifacht hat, ist das ein Rollback, bis das Gegenteil bewiesen ist, und ich liege gerne falsch über die Kausalität, solange es den Usern gut geht. Parallel rufe ich einen Incident aus, damit jemand die Kommunikation besitzt, denn die schlimmsten Incidents, in denen ich war, waren die, in denen dieselben drei Leute in fünf Kanälen gleichzeitig debuggt und Fragen beantwortet haben. Dann prüfe ich, ob es gleichmäßig ist. Ist es jeder Endpoint oder einer? Alle Pods oder nur das neue ReplicaSet? Eine Availability Zone? Das schrumpft den Suchraum meist sofort. Von dort ziehe ich einen Exemplar-Trace für einen langsamen Request und schaue, wo die Zeit tatsächlich hingegangen ist. Wir hatten so einen Fall, bei dem der neue Build einen harmlos wirkenden Logging-Aufruf in eine Schleife gesetzt hat, der pro Iteration ein DNS-Lookup machte, der Span-Baum hat das in Sekunden offensichtlich gemacht. Nach dem Rollback bestätige ich, dass p99 wieder unter dem SLO liegt, bevor ich irgendetwas schließe.