Audit-Vorlage
performance
Finde, wo das System langsam ist, wo es unter Last umkippt und wo es Ressourcen verschwendet.
Mappt auf: SRESite Reliability Engineering — Systeme mit Engineering betreiben, über SLOs und Error-Budgets. · DORADevOps Research and Assessment — die vier zentralen Kennzahlen der Software-Delivery-Performance. · SLOsService Level Objective — ein Zielwert für eine Zuverlässigkeitsmetrik, etwa 99,9 % Verfügbarkeit.
Spezialisten, parallel
Jeder Befund ist belegbasiert und übersteht ≥2-von-3 adversarielle Skeptiker.
Wie dieses Audit arbeitet
Elf Spezialisten laufen parallel über serverseitige Latenz, Throughput und Skalierungsverhalten: algorithmische Hot Paths, Query-Effizienz und N+1Eine N+1-Abfrage: eine Extra-Query pro Zeile statt einer für die ganze Menge — eine häufige Performance-Falle.-Muster, Caching, Concurrency, Leaks, Netzwerk-I/O, Resilienz und Kosten. Jeder Befund nennt ein konkretes Artefakt — eine Hot-Path-file:line, einen Query-Plan, eine gemessene Latenz, einen Profiler-Frame —, kennzeichnet sich als measured oder reasoned und übersteht die adversarielle Verifikation, bevor er landet. Jeder bestätigte Fix kommt mit geschätzter Metrik-Verbesserung und dem Lastniveau, ab dem der Pfad heute bricht.
Wann du es einsetzt
Ein Endpoint wurde nach einem Release langsam
Ein Request-Pfad, der früher schnell war, hängt jetzt, und der Trace zeigt auf die Datenbank. Das Audit jagt N+1Eine N+1-Abfrage: eine Extra-Query pro Zeile statt einer für die ganze Menge — eine häufige Performance-Falle.-Muster pro Endpoint, liest den Query-Plan auf Full Scans und fehlende Indizes und quantifiziert jeden: Queries pro Request, p95 vorher gegen nachher und den Index oder die gebündelte Query, die es behebt.
Dimensionierung für 10x mehr Traffic
Vor einem Launch oder einer Kampagne musst du wissen, ob das System hält. Das Audit denkt jeden kritischen Pfad bei 2x und 10x aktueller Last durch, benennt den ersten Bottleneck, der saturiert — eine Hot Row, ein globaler Lock, ein zu kleiner Connection-Pool —, und nennt das Lastniveau, ab dem es bricht, plus die realistische Decke nach der Behebung.
Eine langsame Dependency löste eine Kaskade aus
Ein langsamer Downstream-Call staute Threads und riss den Service mit. Das Audit prüft Timeout-Disziplin bei jedem externen Call, jagt Retries ohne BackoffDas zunehmend längere Warten zwischen Retries, damit sich eine angeschlagene Dependency erholen kann. und JitterEine zufällige Schwankung im Retry-Timing, damit nicht viele Clients gleichzeitig erneut versuchen. und markiert fehlende Circuit BreakerEin Schutzmechanismus, der Aufrufe an eine ausfallende Dependency vorübergehend stoppt, damit sich Fehler nicht stauen., BackpressureEin Signal, das einen schnellen Produzenten bremst, damit ein langsamerer Konsument nicht überlastet wird. und Load SheddingDas bewusste Verwerfen oder Ablehnen einiger Requests unter Überlast, damit der Rest stabil bleibt. — und zeigt den Failure Mode, wenn eine Dependency langsam ist, nicht nur tot.
Was du bekommst
Eine pro Dimension benotete Scorecard plus ein nach Priorität sortierter Backlog aus GitHub-Issues, jedes mit Beleg, quantifizierten Kosten und einem Vorher/Nachher-Fix samt geschätzter Metrik-Verbesserung.