Erstellt am 05.06.2019

Aus dem Entwickler-Nähkästchen: Chronologie eines Bugfixes

Sie erwischen einen fast immer im falschen Moment und können echt fordernd sein: Bugs. Insbesondere im Umgang mit neuen Technologien sind sie manchmal fast vorprogrammiert. Simon Vogt, Software Engineer bei PostFinance, hat Erfahrung damit – wie sein Beispiel zeigt.

Der Bug platzt ins Meeting

Es ist Donnerstag, kurz vor Mittag. Während eines Meetings an unserem Standort an der Mingerstrasse in Bern, wo sich ein Teil unserer IT befindet, erreicht mich ein E-Mail von Jan. Er ist der Product Owner, mit dem ich als Software Engineer in einem Innovationsvorhaben eng zusammenarbeite. In der Betreffzeile des Mails steht: «WG: Keine Daten». Der Inhalt des Mails ist ebenso knapp: Nach dem Apollo-13-Zitat «Houston, we have a problem!» folgt ein Link zu einer Auswertung. Keine Daten vorhanden. Die Auswertung ist leer, was sie nicht sein sollte und bis anhin auch noch nie war. Und das in der (internen) Produktiv-Version namens «brikks». Kaum ist der erste Schreck vorbei, öffnet sich im Chatfenster die Meldung: «Simon, hast du soeben auf die Produktionsumgebung deployed?». Nein, habe ich natürlich nicht.

War ich für einen Moment geistesabwesend?

Mein Puls steigt, die Gedanken in meinem Kopf rasen. Oder habe ich das doch gemacht? Nur, wie hätte das passieren können? Etwa in einem geistesabwesenden Augenblick? Das Ganze erscheint mir seltsam. Schliesslich ist die Produktiv-Version bereits vor einem Monat live gegangen und funktionierte bisher ohne nennenswerte Deployment-Issues. Und klar, die aktuelle Codebasis beinhaltet heikle Datenbankmigrationen, die obsolete Daten aus der Datenbank entfernen. Ging hier allenfalls etwas schief? Das wäre sehr peinlich.

Das kann nicht sein

Ich schreibe Jan im Chat, dass ich gleich zurückrufe, klinke mich vorzeitig aus dem Meeting aus, setze mich aufs Fahrrad und radle in Richtung Engehalde, wo sich mein regulärer Arbeitsort befindet. Währenddessen bin ich bereits mit Jan am Telefon verbunden. Er fragt noch einmal, ob ich heute Morgen auf die Produktion deployed habe. Der aktuellste Stand des Master-Branches sei live. Ich bin mir mittlerweile sicher, dass ich keine Änderungen vorgenommen habe, und antworte: «Nein, ich weiss von nichts! Schau doch bitte schnell im Deployment-Log nach, wer deployed hat.» Jan hat das bereits gemacht: «Im Log steht, dass das letzte Deployment Richtung Produktion vor zwei Wochen gemacht wurde.»

Die erste Ahnung

Beide überlegen kurz. Jan teilt mir mit, dass er heute Morgen eine Fehlermeldung der Orchestrierungsplattform Kubernetes erhalten hat und fragt, ob das eventuell damit zu tun haben könnte. Oh je, ich ahne etwas und erkläre Jan, dass wir in unserem Kubernetes-Setup immer noch auf den :latest Tag unseres Docker Image verweisen. Jan ergänzt: «Und du meinst, dass sich Kubernetes nach den Fehlermeldungen heute Morgen automatisch das neuste Docker Image geholt hat?» Wir ahnen beide: Genau, das könnte es sein!

«It’s not a bug, it’s a feature» ... ;-)

So ist es auch. Kurz darauf – zurück am Arbeitsplatz – gehen wir zuerst das Problem mit der leeren Auswertung an. Zu unserem Erstaunen können wir diese glücklicherweise direkt im User Interface beheben, da sie gar keinen direkten Zusammenhang mit dem Deployment hat. Danach schalten wir vorerst einen Warnhinweis für unsere User auf und verweisen darauf, dass eine neue Version von brikks deployed wurde. Frei nach dem Motto «It’s not a bug, it’s a feature» ... ;-)

Hintergründe zum Bug und dem Bugfixing

Bei PostFinance arbeiten wir mit neuen Technologien. Dazu gehört auch Kubernetes. Da wir die ersten Erfahrungen mit der Orchestrierungsplattform nicht unnötig verkomplizieren wollten, hatten wir unser Deployment-Setup damals bewusst so einfach wie möglich gehalten. Auch, weil wir so schnell wie möglich produktiv gehen wollten, um rasch Kundeninteraktionen und -feedback zu sammeln. Beim Einrichten des Deployment-Setups haben wir folgende offizielle Warnung bewusst in Kauf genommen: «Note: You should avoid using the :latest tag when deploying containers in production as it is harder to track which version of the image is running and more difficult to roll back properly.»

Im Backlog haben wir ein Improvement erfasst, aber nicht hoch priorisiert – mit der Folge, dass uns anstelle des geplanten Improvements im Backlog ein kritischer Bug beschäftigte. Wer sich nun denkt: «Was ist denn mit PSP, dem Potentially Shippable Product?» Richtig, wir haben im Prinzip bei jeder Änderung auf dem Master-Branch ein PSP, das deployed werden kann. Dennoch wäre uns in diesem Fall ein kontrolliertes Einführen der Änderungen lieber gewesen, da wir auch diverse Änderungen im User Interface vorgenommen hatten, über die wir die User gerne vorinformiert hätten.

Das haben wir aus dem Bug gelernt

Mittlerweile taggen wir unsere Docker Images und konnten uns folglich auch vom :latest Tag in der Deployment-Konfiguration lösen. Die Ursache für den Neustart der Kubernetes-Pods haben wir nicht abschliessend geklärt. Gut möglich, dass der Chaos-Monkey sein Unwesen trieb. Hier lag effektiv eine suboptimale Konfiguration vor, die wir ursprünglich bewusst in Kauf genommen hatten. Gut, dass wir den Umstand noch früh beheben konnten.

Als Entwicklerin oder Entwickler bei PostFinance arbeitest du mit viel Eigenverantwortung in einem agilen Umfeld und in einem Team, das die offene Fehlerkultur pflegt. Interessiert? Wir freuen uns auf deine Spontanbewerbung.

Spontanbewerbung

Navigieren in Postfinance

Suchbegriff Eingabe

Live-Resultate Suche

Unsere Bereiche

Sprachauswahl