Kontinuierliche Verbesserung der Entwicklerproduktivität bei Snowflake

Ich werde oft gefragt: „Warum bist du zu Snowflake gestoßen und warum hast du dich dazu entschieden, an der Entwicklerproduktivität zu arbeiten?“ Ich bin zu Snowflake gestoßen, um von erstklassigen Ingenieuren zu lernen und Teil der hochgradig kollaborativen Kultur zu werden. Sie waren die geheime Zutat für das raketenartige Wachstum von Snowflake. Snowflake begann eine bemerkenswerte Transformation der Entwicklerproduktivität, und ich musste auf das Raketenschiff aufspringen, als es abhob!

Fangen wir von vorne an. 2012 gründeten Benoit Dageville und Thierry Cruanes Snowflake. Sie waren erfahrene Engineers im Datenbankbereich und haben einen Großteil des Codes geschrieben, der Snowflake bis heute unterstützt. Unsere Gründer glauben, dass jeder Ingenieur Code schreiben sollte, unabhängig vom Dienstalter. Unsere Senior Architects und CTOs können sich vor Ort ein Bild von der Produktivität der Entwickler:innen machen und die täglichen Probleme, die Machbarkeit von Zeitplänen und Lösungskonflikten genauer verstehen.

Snowflake erlebte ein schnelles Wachstum und stellte Top-Talente ein, was zu einer schnell wachsenden Codebase führte. Als Einproduktunternehmen wurde das Produkt von Snowflake mit der Zeit unweigerlich immer komplexer und funktionsreicher. Im Laufe der Jahre wuchs unser Testmaterial unkontrolliert, die Entwicklungsumgebung wurde immer komplexer und die Entwicklungs- und Testzeiten verlangsamten sich erheblich, was die Produktivität der Entwickler:innen beeinträchtigte. Darüber hinaus war die Infrastruktur, die unsere Systeme unterstützte, unter starker Last unzuverlässig, was manuelle Wiederholungen erforderte und Entwickler:innen durch Produktivitätseinbußen frustrierte. Trotz anfänglicher Bemühungen war die Zentralisierung und Skalierung unseres Tools nicht erfolgreich.

Anfang 2023 hatten wir Initiativen zur Verbesserung der kontinuierlichen Integration (CI) und der Entwicklungsumgebungen gestartet, die jedoch nur langsam vorankamen. Ende 2023 musste die Strategie überdacht werden, um sie in Gang zu bringen.

Wir haben vier wichtige Zutaten für den Neustart ermittelt: Führungspriorität, Messung, Kundenverbindung und Verantwortlichkeit.

Führungspriorität

Unsere Führungsebene definiert Entwicklerproduktivität als hohe Priorität für das gesamte Unternehmen, mit monatlichen Überprüfungen des CEO und der Führungsebene. Snowflakes CTO S Muralidhar ist stark an der Definition unternehmensweiter Ziele und der Führung unternehmensübergreifender Teams beteiligt. Die Produktivität der Entwickler:innen stieg um ein Vielfaches. In der Zwischenzeit traten Freiwillige im gesamten Unternehmen hinzu, um den Code zu refaktorisieren und die Testeinrichtung sowie die Laufzeiten zu verbessern, um die Neuauflage unseres Entwicklungssystems und unserer Entwicklungsumgebungen zu beschleunigen. 

Messung

Messungen sind entscheidend, um zu verstehen, ob wir Fortschritte machen. Es ist entscheidend, den Erfolg aus Kundensicht zu messen, und nicht unsere Fähigkeit, interne Meilensteine zu erreichen. Hierzu erfassen wir eine Kombination aus qualitativen und quantitativen Kennzahlen:

• Produktbetriebsmetriken: Systemverfügbarkeit erstellen; Gesamtzahl der Systembefehle pro Tag erstellen

• Benutzerseitige Produktmetriken: Latenzzeit beim Erstellen und Testen; Prozentsatz der gesunden Workspaces; Einführung neuer Systeme 

• Metriken für den User-Journey-Output: durchschnittliche PR-Anzahl pro Entwickler:in pro Woche; Latenz des PR-Lebenszyklus durch jede Phase von der PR-Einreichung, der ersten Bewertung und der letzten Bewertung bis zur Zusammenführung

• Entwicklerstimmung: quartalsweise CSAT (umfragebasiert); Top-Kampfgebiete

Wir legen uns ehrgeizige Quartalsziele auf der Grundlage von Kennzahlen fest und beobachten diese genau. In unserem wöchentlichen Betriebsrückblick gehen wir tief auf Metrikabweichungen ein und arbeiten an der Lösung. Wenn Kennzahlen nicht ausreichend mit der Entwicklererfahrung verbunden sind, überarbeiten wir sie und sammeln aktualisiertes Benutzerfeedback, um Konsistenz mit der Erfahrung der Benutzer:innen zu gewährleisten.

Kundenverbindung

Unsere Kunden sind anspruchsvolle Snowflake Engineers. Um sich ihr Vertrauen zu verdienen und den Kreislauf aus Feedback und Iteration aufzubauen, müssen wir nachweisen, dass wir 1) ihre Erfahrungen verstehen, 2) stetige Fortschritte machen und 3) anhand ihres Feedbacks neue Prioritäten setzen und iterieren.

Wenn wir Veränderungen vorantreiben, fallen unsere Kunden in drei Kategorien: Early Adopter, Follower und Laggards (Nachzügler). Early Adopters sind entscheidend, um kritisches Feedback für die Iteration zu geben, und sie fördern Innovationen in ihren Teams als vertrauenswürdige Insider, um die Akzeptanz zu fördern. Wir haben Early Adopters in jedem Team als Champions identifiziert und regelmäßig Interviews geführt, um über Fortschritt und Stimmung auf dem Laufenden zu bleiben. 

In Quartalsumfragen haben wir Nutzerfeedback als wichtiges Werkzeug analysiert, um die Quartalsplanung zu priorisieren. Wir haben häufig Nutzerinterviews über Produktgruppen hinweg durchgeführt und dabei nach Dienstalter, primären Programmiersprachen und geografischen Standorten analysiert. Dieses Feedback haben wir zur Optimierung der Prioritäten in monatlichen Sprints genutzt. Da sich jeder geografische Standort in seinem Teamrhythmus und seiner bevorzugten Kommunikationsart unterscheidet, haben wir uns an jedes Feature-Area-Team gewandt, um das beste Forum für die Interaktion mit den lokalen Entwickler:innen zu finden. Und wir haben stets den Kreis mit den Kunden geschlossen, um ihnen den Fortschritt ihrer wichtigsten Pain Points mitzuteilen und ihr Feedback zur Roadmap einzuholen.

Verantwortlichkeit

Wir haben Entwicklertools wie ein kundenorientiertes Produkt mit veröffentlichten Service Level Agreements behandelt. Wir demonstrierten die Verantwortlichkeit in wöchentlichen E-Mails und zweiwöchentlichen Updates in Product All-Hands. Transparenz fördert das Vertrauen der Kundschaft und sorgt dafür, dass Feedback fließt. 

Wir konnten den Fortschritt durch Messung liefern, Verbesserungen durch Kundenverbindung validieren und die Verantwortlichkeit durch Updates für unsere Kunden demonstrieren. Der Fokus beschleunigte die Entwicklung und Einführung von vier Innovationen: Bazel (Entwicklungssystem), Cloud-Workspace (Entwicklungsumgebung), SnowCI (kontinuierliche Integration) und Snowfort (Regressionstest-Framework). Mit jedem der vier Innovationsbereiche konnten wir technische und organisatorische Herausforderungen bewältigen.

Bazel

Unsere veralteten Build-Systeme Maven und CMake führten zu einer Fülle von Build-Skripten und inkonsistenten Tools, was die Lernkurve für Entwickler:innen, die mit verschiedenen Komponenten arbeiten, verschärfte. Lokale Builds waren unzuverlässig und erforderten häufige Wiederholungen und „saubere Builds“, was zu großer Frustration unter den Entwickler:innen führte. Durch den Einsatz von Bazel konnten wir konsistente, zuverlässige und schnelle Builds erzielen. Darüber hinaus konnten wir mit der Remote-Backend-Ausführung auf Buildbarn Erstellung und Test enorm parallelisieren und so die Latenz drastisch verringern.

Cloud-Workspace

Die alte Entwicklerumgebung auf MacBook-VMs hatte Probleme, die wachsende Nachfrage nach Entwicklung und Test des Produkts zu erfüllen. Benutzer:innen waren auf jeweils eine aktive VM beschränkt, und das Zurücksetzen einer defekten VM konnte 30 Minuten und manchmal deutlich länger dauern. Um dieses Problem anzugehen, haben wir flüchtige Cloud-Workspaces eingeführt, die auf Kubernetes ausgeführt werden und vorinstalliert sind mit dem neuesten Checkpoint-Code, Cache-Builds, IDE, Testtools und allem anderen, was Benutzer:innen für sofortige Produktivität benötigen. Ein:e Benutzer:in kann einen Workspace in zwei Minuten einrichten und mehrere Workspaces parallel verwalten, mit schneller Intra-Datacenter-Verbindung direkt mit dem Bazel Buildbarn-Cache. 

Die Migration von Entwicklungsumgebungen ist die grundlegendste Veränderung von Entwicklungsworkflows. Um die Trägheit zu überwinden, brauchte es mehr als nur ein großartiges Produkt. Wir haben die Early Adopters als Insider-Champions eingesetzt, unterhaltsame und kreative Kontaktarten genutzt, um die Nachzügler zu motivieren, sind Team für Team gegangen, um die Vorteile aufzuzeigen und haben den Kreis Runde für Runde mit Feedback geschlossen.

SnowCI

In der Vergangenheit beruhte unser CI-System auf ausgedehnten, unzusammenhängenden Jenkins-Skripten, die über die Jahre gewachsen waren. Diese zu beheben und zu optimieren, war eine echte Herausforderung. Grund hierfür waren schlechte Testmöglichkeiten und ein begrenztes Verständnis der gesamten Systemkonfiguration durch das Team. Durch den Aufbau eines internen Clean-Slate-YAML-basierten Systems namens SnowCI für unsere CI-Workflows haben wir eine Bereinigung dieser Skripte erzwungen und sind zu einem viel verständlicheren, konventionelleren und modernen CI-System übergegangen. So konnten wir konsequent die Phasen der KI messen, große Teile benutzerdefinierter, unzuverlässiger Workflows löschen und uns auf Geschwindigkeit und Zuverlässigkeit als unsere Kernprinzipien konzentrieren.

Snowfort

Unser altes Testframework wurde vor über einem Jahrzehnt entwickelt – ohne Isolation, damit Tests in einem sauberen Zustand beginnen und enden können, ohne Guardrails, um Inkonsistenzen zu verhindern, und ohne Abstraktion, um doppelten Boilerplate Setup-Code zu verhindern. Deshalb haben wir Snowfort entwickelt – das Regressionstest-Framework von Snowflake – um diese Defizite zu beheben. Außerdem konnten wir große Testmaterialien in kleine Batches unterteilen, was eine schnelle Wiederholung mit Testfehlern ermöglichte. Mit Buildbarn konnten wir die Testausführung parallelisieren und so die CI-Latenz verringern. Durch die Testisolierung konnten wir die Testunzuverlässigkeit drastisch reduzieren und so die CI-Zuverlässigkeit verbessern.

Fortschritt

Zwischen Februar und Dezember 2024 hat die Einführung der vier neuen Systeme von 10-20 % auf 90-95 % zugenommen. Build ist jetzt viel zuverlässiger und stabiler bei einer Latenzzeit von acht Minuten. CI-Latenz und Zuverlässigkeit in verschiedenen Phasen der Pipeline haben sich um das Drei- bis Sechsfache verbessert. Die vorübergehenden Entwicklerumgebungen sind mit vollständig zwischengespeicherten Builds und Tools in zwei Minuten aufgebaut, wobei die Einstellungen zwischen den Sitzungen vollständig beibehalten werden. Mit dem Snowfort-Regressionstest-Framework können Sie ganz einfach zuverlässige Tests mit richtiger Isolation schreiben. Dadurch hat sich die Stimmung der Entwickler:innen deutlich verbessert. Innerhalb von neun Monaten ist der Anteil unzufriedener Kunden von 58,9 % auf 21,4 % gesunken und der Anteil zufriedener Kunden hat von 17,8 % auf 42,3 % zugenommen.

Unsere Arbeit ist nicht getan. Vor uns liegt viel Arbeit, um die inneren Schleifen von Entwickler:innen reibungslos und noch angenehmer zu gestalten. Wir investieren in Bazel und die IDE-Strategie, um für jede Programmiersprache bei Snowflake lokale Builds und fließende Authoring- und Debugging-Erfahrungen in nur wenigen Minuten bereitzustellen. Wir investieren in SnowCI, um PR von der Autorenarbeit bis zur Zusammenführung in weniger als zwanzig Minuten abzuschließen. Mit den vier oben genannten wichtigen Zutaten sind wir in einer guten Position, um unsere Kunden weiterhin zu bedienen.