Der Sommer ist normalerweise eine ruhige Zeit für Unternehmen: Viele Menschen sind im Urlaub, Kundenprojekte entwickeln sich langsamer und nur wenige neue Projekte werden gestartet. Es gibt aber auch Probleme, die typisch für diese Jahreszeit sind: Etwas geht kaputt, die Verantwortlichen sind im Urlaub und es zeigt sich, wie anfällig manche Prozesse sind, die normalerweise reibungslos funktionieren.
Das ist uns letzte Woche passiert.
Ein Backend-Entwickler hat kurz vor seiner Abreise noch eine Änderung vorgenommen. Die CI/CD-Pipeline lief durch, unsere internen Entwicklungssysteme wurden erfolgreich aktualisiert, und der Entwickler fuhr in den Urlaub. Aber: Als das Frontend-Team am nächsten Tag mit der Arbeit begann, schlug die Erstellung von CDEs (Cloud Development Environments) fehl. Das Backend steckte in einem Crash-Loop fest.
Leider besteht unser Backend-Team nur aus zwei Entwicklern, und beide sind gerade im Urlaub. Also hat das Frontend-Team (zwei Entwicklerinnen 🙂 versucht, das Problem selbst zu beheben.
Ich wurde im Standup um 11 Uhr auf das Problem aufmerksam. Zu diesem Zeitpunkt hatten die beiden Frontend-Entwicklerinnen den Vormittag damit verbracht, die CDE-Erstellung (erfolglos) zu debuggen. Wir verbrachten zu dritt eine Stunde mit dem Debugging und kamen dann zu dem Schluss, dass sie einfach „blind und langsam“ am Code arbeiten müssten, ohne einen lokalen Build durchführen zu können.
Sie können ihre Änderungen zwar immer noch in der Entwicklungsinstanz überprüfen, aber die CI/CD-Pipeline braucht etwa 15 Minuten bis zur Fertigstellung, was für Frontend-Entwickler_innen viel zu lange ist. Zumindest für unser Team, das sich an sofortige Hot-Reloads gewöhnt hat.
Früher haben alle Entwickler_innen Cloudomation lokal ausgeführt und betrieben, aber seit wir CDEs verwenden, ist dieses Wissen verstaubt, neue Entwickler_innen hatten es noch nie versucht, und wir kamen zu dem Schluss, dass der Versuch, ein lokales Deployment zum Laufen zu bringen, wahrscheinlich länger dauern würde, als auf die Rückkehr der Backend-Entwickler aus dem Urlaub zu warten.
Mit einigen Hinweisen von einem Backend-Entwickler, die er mir großzügigerweise über Slack während seines Urlaubs gab, konnte ich am Nachmittag einen Workaround zusammenhacken. Die CDE-Erstellung funktionierte um 16 Uhr wieder. Wir haben also fast einen ganzen Tag für zwei Frontend-Entwicklerinnen und einen halben Tag meiner eigenen Zeit verloren.
Insgesamt hielt sich der Schaden in Grenzen. Dennoch hat mir dieser Vorfall einige Dinge verdeutlicht:
- Wir sind sehr schnell sehr abhängig von CDEs geworden. Das zeigt, wie nützlich sie sind, aber macht unsere CDE-Deployment-Automatisierungen zu einem Single-Point-of-Failure.
Wir haben einige Grundregeln die generell gut funktionieren, aber diesmal problematisch wurden: - Fortschritt machen / Vorwärts bewegen: Wenn notwendig, setzen wir Kundensysteme zurück. Wir machen das aber nicht mit unseren internen Systemen und vermeiden es, auf alte Versionen / Commit-Hashes zurückzugehen oder problematische Änderungen zurückzusetzen. Stattdessen beheben wir lieber gleich die Grundursache. Deshalb haben wir (noch) keinen automatischen Vorgang, um auf eine alte Version einiger unserer Komponenten in unseren CDEs zurückzugehen.
- Es ist ok, interne Entwicklungsumgebungen zu breaken. Dafür sind sie da. Sie sind dafür gemacht, als sichere Umgebungen zu dienen, die nicht irgendwelche Prozesse von Production ausführen, es wird nicht erwartet, dass sie immer verfügbar sind und jeder kann sie kaputt machen, ohne die Arbeit von anderen Personen zu blockieren. Mit diesem Vorfall lernte ich aber, dass das nur für Veränderungen wahr ist, die während des Arbeitstages durchgeführt werden. Alles, was am Ende des Tages commited wird, wird während dem Nightly-Build in die CDE-Teamplate-Snapshots eingebettet und auf alle am Morgen erstellten CDEs übertragen. Während des Tages können die Entwickler_innen einfach beschließen, keine Änderungen aus den Repositories anderer Teams zu ziehen und können in ihren isolierten CDEs weiterarbeiten, wenn irgendetwas nicht mehr funktionieren sollte. Wenn aber das Template defekt ist, betrifft dies alle Entwickler_innen.
- Nicht jede_r hat zu wissen, wie ein Deployment funktioniert. Das ist einer der Hauptgründe, warum CDEs eingesetzt werden sollten: Für die Reduktion der Deployment-Komplexität, damit sich Developer nicht mehr darum kümmern müssen. Es ist großartig, dass wir intern schon hier angekommen sind, aber das erfordert natürlich, dass unsere CDE-Deployment-Automatiserung funktioniert.
- Wir haben keine Self-Service-Workarounds, mit denen Entwickler_innen ihre Blocker aus dem Weg schaffen können, ohne dass sie Probleme beheben müssen, die von anderen Teams verursacht wurden. So wäre es zum Beispiel ein Leichtes gewesen, das CDE-Template vom Vortag zu verwenden – aber wir verwerfen das alte Template, wenn wir ein neues Template erstellen. Diese sollten sowieso nur kurzlebig sein und wir können sie jederzeit von Grund auf neu erstellen – aber das gilt nur, wenn keine wichtige Komponente defekt ist und Personen, die sie reparieren können, alle im Urlaub sind.
- Es ist äußerst wertvoll, Allrounder (oder Hacker) im Team zu haben, die einspringen und Fehler beheben (d. h. Schnelle Workarounds erstellen), um Blocker aufzulösen. Meiner Erfahrung nach sind solche Leute oft nicht die besten Software-Ingenieure_innen (deshalb bin ich ja auch CEO :P), aber in einer Krise können sie von unschätzbarem Wert sein.
Wir verwenden CDEs jetzt seit etwas mehr als sechs Monaten. Das ist lange genug, um eine Menge Wissen darüber verloren zu haben, wie man ohne sie arbeiten kann, aber nicht lange genug, um alle Probleme, die mit ihrer Verwendung einhergehen, auszubügeln. So gesehen ist es überraschend, dass wir zum ersten Mal in einer Situation waren, in der zwei Entwicklerinnen fast einen ganzen Tag lang blockiert waren, weil die CDE nicht verfügbar war.
Letztendlich kam ich zu dem Schluss, dass es gut ist, dass das Backend-Team im Urlaub war. Wären sie hier gewesen, hätten sie das Problem schnell behoben und ich hätte wahrscheinlich nicht einmal davon erfahren. Jetzt weiß ich davon und werde dafür sorgen, dass wir diese Abhängigkeit vom Backend-Team beseitigen, indem wir „Easy-Fixes“ anbieten, die jede_r Entwickler_in selbst anwenden kann.
