von Jacob Fahrenkrug und Johann Schmitt

Aus dem Leben des Softwareentwicklers Hannes

Es ist 7:56 Uhr. Das Büro ist noch ganz ruhig. Ich gehe in die Kaffeeküche, um die erste Kanne des Tages aufzusetzen. Mit einer großen Tasse heißen Kaffees komme ich zurück in unser Büro. Von weitem kann ich durch die Glaswand den Monitor erkennen, der die aktuellen Informationen zu unserem Softwaresystem anzeigt. Als die Anzeige umschlägt sehe ich:

Einen dicken, roten Streifen auf dem Monitor prangen. Dieser signalisiert mir: Wir haben einen Blocker.

Teamwall Screenshot

Sofort stürze ich in unser Büro und bemühe mich nur unzureichend den frischen Kaffee nicht zu verschütten. Mein bis eben noch leicht schläfriges Gehirn beginnt in Höchstgeschwindigkeit die Optionen durch zuspielen. Das System ist im Moment nicht betriebsfähig. Wir machen also aktuell kein Geschäft. Der Firma geht mit jeder Sekunde in der ich nichts tue, um das Problem zu lösen, Geld durch die Lappen. Das Problem könnte in der Infrastruktur liegen. Ich rufe bei den Kollegen vom Betrieb an. Allerdings ist es erst acht Uhr und außerdem Mittwoch. Da kommen die Kollegen erst gegen halb neun. Während ich die Mobil-Nummer vom Notfallmanager suche, fluche ich leise: Wie praktisch wäre es jetzt, wenn ich Zugriff auf die Infrastruktur hätte. Ich könnte selber prüfen, ob die Datenbank hochgefahren ist und alle unsere Dienste genügend Speicher haben. Endlich finde ich die Telefonnummer und erreiche unseren Notfallmanager. Dieser erklärt mir, dass er gerade in der U-Bahn sitzt und spätestens um halb neun da sein wird. Bereitwillig verspricht er sich sofort bei mir zu melden, sobald er im Büro eintrifft.

Ein Blick auf die Uhr verrät mir, dass ich noch zwanzig Minuten warten muss, bis ich Informationen über die Infrastruktur bekomme. Ich überlege kurze was als nächstes zu tun ist. Das Problem muss ja nicht in der Infrastruktur liegen. Ich könnte mir die Log-Dateien unseres Softwaresystems anschauen. Mit einem Klick öffne ich in einem Browserfenster unseren zentralen Log-Server. Schnell sind die Log-Dateien des produktiven Systems gefunden. Ein Blick auf die Zeitstempel zeigt die Uhrzeit der letzten Aktualisierung – 7:36 Uhr. Die Statuszeile des Log-Servers teilt mir schmucklos mit, dass die nächste Aktualisierung um 8:36 stattfinden wird. Panisch öffne ich unser Ticketsystem, um die traurige Gewissheit zu bekommen: Das Ticket wurde um 7: 58 Uhr erstellt und der Fehler wurde um 7:51 Uhr beobachtet. Mutlos blicke ich erneut zur Uhr über unserem Monitor. Sie zeigt 8:24 Uhr. Auf dem Monitor leuchtet gerade erneut der dicke, rote Balken auf als mein Telefon klingelt. Endlich – der Notfallmanager ist da. Voller Hoffnung nehme ich den Hörer ab, um mit dem ersten Satz die aufmunternde Nachricht zu bekommen: „Die Hardware funktioniert tadellos und alle Dienste sind erreichbar!“. Das bedeutet es ist ein Softwarefehler. Nur ich kann das Problem lösen! Jedoch bekomme ich die notwendigen Log-Dateien erst in zehn Minuten. Um den Fehler besser auf meinem eigenen Computer nachstellen zu können, brauche ich eine Datenbankkopie. Diese könnte ich jetzt machen lassen. Ich flitze zu den Kollegen vom Betrieb, um meiner Idee persönlich mehr Nachdruck zu verleihen. Unser Notfallmanager teilt mir mit, dass der Datenbankadministrator Mittwochs immer später kommt. Deshalb kann ich die lokale Datenbankkopie frühestens um halb elf bekommen. Enttäuscht schlendere ich zurück in unser Büro. Frustriert lese ich die inzwischen aktualisierten Log-Dateien auf unserem Log-Server. Eine ganze Reihe von Fehlermeldungen zeigt mir, dass wir ein Problem mit einer Datenbanktabelle haben. Die Lösung liegt nahe. Ich verfluche, die Tatsache, dass ich mir jetzt nicht schnell eine Datenbankkopie erstellen kann, um zu zeigen, dass meine Lösung, dass Problem wirklich behebt. Lustlos beschäftige ich mich mit dem Tagesgeschäft während ich ungeduldig auf meine Datenbankkopie warte. Endlich 10:20 Uhr bekomme ich den Anruf von unserem Datenbankadministrator. Meine Datenbankkopie ist erledigt und ich kann sie auf meinen eigenen Computer spielen. Vier Minuten später habe ich meine Lösung umgesetzt und sehe, dass ich die richtige Idee hatte. Das Problem ist gelöst. Ich rufe unseren Notfallmanager an und sage ihm, was wir mit der produktiven Datenbank machen müssen, damit unser Softwaresystem wieder betriebsfähig wird. Er schlägt vor, dass ich zu unserem Datenbankadministrator gehe und das wir das Problem gemeinsam in der produktiven Datenbank beheben. Um 10:42 Uhr verlasse ich erleichtert, das Büro des Datenbankadministrators. Die Firma verdient wieder Geld.

Dieser Erfahrungsbericht zeigt einen Softwareentwickler, der ein Problem lösen will, das im Betrieb aufgetreten ist. Da er nicht direkt auf die Infrastruktur und die Log-Dateien zugreifen kann, dauert es sehr lange bis das Problem gelöst ist. Die Folgen sind ein frustrierter Mitarbeiter und ein Gewinnausfall von zwei Stunden. Damit ein Softwareentwickler seinen Beruf richtig ausüben kann, braucht er direkten Zugriff auf produktive Infrastruktur und Log-Dateien. Getreu dem Motto: Füge zusammen, was zusammen gehört, sollte die künstliche Trennung zwischen dem Betrieb und der Entwicklung aufgehoben werden.

In solchen Momenten wünsche ich mir mehr Einblick in den Betrieb. Immer heißt es, dass aus Sicherheitsgründen niemand Zugriff haben darf. Dabei ist es wichtig für mich als Entwickler zu wissen, wie sich meine Anwendung im Betrieb verhält. Dann würde ich auch viel besser verstehen, wenn die Jungs vom Betrieb mal wieder von uns wollen, dass wir eine bestimmte Version eines Datenbanktreibers einsetzen sollen oder wir angeblich ein Speicherleck haben. Wie schön wäre es ein gemeinsames Verständnis zu haben und danach die Arbeit und Tools zu organisieren.

Ein Tag im Leben des Notfallmanagers Ronny

Es ist kurz nach acht Uhr und ich sitze mit gefühlt weiteren zweitausend Sardinen in der U2 auf dem Weg ins Büro. Da fängt das Blackberry unseres Notfallmanagements an zu vibrieren. Der Tag beginnt. Diese Woche habe ich Bereitschaft und die Nacht war ruhig. Am Telefon ist ein Entwickler, der mir etwas von „Unterbrechung“ und „kein Umsatz“ und Infrastrukturproblemen erzählt. So richtig kann ich ihn nicht verstehen, denn der Zug läuft gerade in den Bahnhof Schönhauser Allee ein und hunderte neue Sardinen versuchen sich in die Büchse zu quetschen. Also kann ich dem Kollegen nur sagen, dass ich sofort an die Analyse gehe, sobald ich im Büro bin. 

Im Bahnhof Alexanderstraße habe ich den Tablet soweit, dass ich die Seite unseres Monitorings sehen kann: Alle überwachten Server und Dienste scheinen fehlerfrei zu laufen. Das hatte ich auch stark vermutet, ich habe ja auch keine Alarm-Nachricht bekommen. Hätte der Entwickler, dass nicht aus den Logs oder dem Monitoring selber sehen können? Im Büro greife ich als erstes zum Telefon und übermittle die frohe Botschaft. Jetzt mache ich mich erst mal auf den Weg einen Kaffee zu holen. Der Weg wird mir aber von eben diesem Entwickler angeschnitten, der jetzt persönlich vorbeikommt, um seine Idee vorzubringen: Er braucht einen Datenbankabzug der Produktionsdatenbank, um den Fehler bearbeiten zu können. Kann er keine Testdaten auf einer der vielen Entwicklungsdatenbanken erstellen oder generieren? Wozu gleich einen Abzug der ganzen Datenbank. Nun gut, nicht meine Baustelle; das kann nur ein Datenbank-Administrator. Die kommen heute aber später, weil sie gestern – wie an so vielen Dienstagen – spät abends noch eine Wartungsmaßnahme im Rechenzentrum zu erledigen hatten.

Als der Datenbank-Admin angekommen und den Abzug erstellt hat, kann der Entwickler seine Fehlerbehebung testen und danach machen wir die Reparatur an der produktiven Datenbank gemeinsam.

In solchen Augenblicken wünsche ich mir mehr Einblick in die Entwicklung zu haben. Wenn es ein aktuelles Problem gibt, dann heißt es immer gleich: „Es wird kein Umsatz gemacht“. Wenn wir uns aber etwas von der Entwicklung wünsche, um den Betrieb stabiler zu machen, dann wird das Thema als unwichtig auf die lange Bank geschoben. Dann heißt es „Wenn jemand im Problemfall seinen Vorgang nicht bearbeiten kann, dann holt er es eben später nach“. Wie schön wäre es ein gemeinsames Verständnis zu haben und danach die Arbeit und Tools zu organisieren.