Im Juli 2023 dauerte die Ausführung der Testsuite von Ramps Python-Monolithen 45 Minuten, und langsame Tests staute die Merge-Queue im gesamten Unternehmen auf – Ingenieure blockierten einen halben Tag nur dafür, um ausstehende Änderungen zu beaufsichtigen. Zwei Jahre zuvor hatte ein interner Beitrag bereits darauf hingewiesen, dass langsame Tests die Produktivität der Ingenieure beeinträchtigen, doch seitdem war nichts unternommen worden.
Statt sich auf eine große Neufassung festzulegen, maß das Team zunächst: Etwa 38 der 45 Minuten entfielen auf den pytest-Aufruf selbst. Die Profilerstellung zeigte, dass der Testlauf CPU-gebunden war, sodass die erste einzelne Maßnahme – schnellere CPUs – die Laufzeit für sich genommen um etwa 50 % reduzierte, der größte einzelne Gewinn des gesamten Projekts und derjenige, dessen Ermittlung am wenigsten Aufwand erforderte.
Von dort aus teilten sich die Ingenieure auf und führten günstige, parallele Experimente durch, die auf das beschränkt waren, wozu jeder bereits Kontext hatte: Docker-Layer-Caching auf selbst gehosteten Runnern sparte über eine Minute; ein neu geschriebener Algorithmus zur Arbeitsaufteilung in pytest-xdist sparte 2–3 Minuten; mehr Testdatenbanken und abgestimmte Postgres-Verbindungseinstellungen behoben Lock-Contention, sobald über 20 Worker auf dieselbe Datenbank zugriffen. Nicht jedes Experiment zahlte sich aus – das Einbinden von Testdaten in den RAM brachte keinen Gewinn und wurde verworfen –, aber jedes war günstig genug, um den Versuch wert zu sein.
Verfolge günstige Experimente mit hohem potenziellem Nutzen und höre in dem Moment auf, in dem die Gewinne abnehmen
Zuerst zu messen (38 von 45 Minuten waren der pytest-Aufruf selbst, CPU-gebunden) bedeutete, dass das Team den tatsächlichen Engpass behob, statt zu raten.
Die Maßnahme mit dem höchsten Hebel und dem geringsten Aufwand zuerst umzusetzen (schnellere CPUs, ~50 % Gewinn) schuf Schwung und gab Zeit frei, um riskantere Ideen zu erkunden.
Die Aufteilung in parallele, kostengünstige Experimente ermöglichte es dem Team, viele Hypothesen schnell zu testen, statt alles auf eine große Änderung zu setzen.
Das Auftragen der pro Änderung eingesparten Zeit machte die Kurve des abnehmenden Ertrags sichtbar und gab dem Team ein konkretes Signal, aufzuhören, statt für marginale Gewinne weiter zu feilen.
Messe, bevor du optimierst, behebe zuerst den Punkt mit dem höchsten Hebel und führe dann ein Portfolio günstiger Experimente parallel durch – und nutze die schrumpfende Größe jedes Gewinns als Signal zum Aufhören.
Nach einer Woche lief die Suite in unter 5 Minuten, eine Reduktion von grob über 70 % gegenüber den ursprünglichen 45. Neue Verbesserungen gegen Ende der Woche sparten nur noch Sekunden (unter 5 %) der Laufzeit ein, was das Team als Signal nutzte, aufzuhören und die verbleibenden Ideen in einen Long-Tail-Backlog zu verschieben, statt weiter zu optimieren.
DEN BELEGEN FOLGEN
Die Quellen
- Picking Low Hanging Fruit Ramp Engineering · builders.ramp.com ·