Ein Endpoint, der früher 80 Millisekunden gebraucht hat, braucht in der Produktion jetzt vier Sekunden. Wie würdest du die Ursache finden?

Miss, bevor du rätst. Klär, ob es für alle langsam ist oder für ein Konto, und lies dann einen Trace, um zu sehen, wo die Zeit tatsächlich sitzt: Anwendungscode, Datenbank oder ein ausgehender Aufruf. Meistens ist es die Datenbank, hol also das Slow-Query-Log und führ EXPLAIN ANALYZE auf der verdächtigen Query aus. Parallel prüfst du, was sich geändert hat, denn ein Deploy, eine Datenmengenschwelle oder ein Cache, der nicht mehr trifft, erklärt die meisten Regressionen.

Zuerst will ich die Form des Problems. Ist es jeder Request oder das neunundneunzigste Perzentil, ein Mandant oder alle, und wann genau hat es angefangen. Dieser Zeitstempel löst meist schon den halben Fall, weil er sich mit einem Deploy, einer Migration oder einer Config-Änderung deckt. Dann hole ich einen Trace für einen langsamen Request und schaue mir den Wasserfall an, denn zu raten, welche Schicht langsam ist, kostet die meiste Zeit. Ist es die Datenbank, prüfe ich das Slow-Query-Log und führe EXPLAIN ANALYZE aus, und die häufigen Antworten sind ein Plan-Umschwung nach Tabellenwachstum, ein fehlender Index auf einer neu gefilterten Spalte oder ein N-plus-eins, das erst wehtut, seit Konten mehr Zeilen haben. Ist es ein ausgehender Aufruf, prüfe ich, ob diese Abhängigkeit degradiert ist und ob wir überhaupt ein Timeout haben, denn ein fehlendes Timeout macht ihren schlechten Tag zu unserem. Wenn Nutzer währenddessen leiden, mitigiere ich zuerst: zurückrollen, einen kurzen Cache setzen oder den teuren Pfad abwerfen, und schließe die Diagnose dann ohne Druck ab.