Montag, 7:30h: Die Chefin, Frau Blümel, stürmt zu mir ins Büro, weil in unserer Online-Anwendung CatTube ein schwerwiegender Fehler aufgetaucht ist. Sie bittet mich, rasch zu handeln. Jeder Fehler führe schließlich zu hohen Ausfallkosten. Im vorliegenden Fall würde CatTube keine Tickets für die Kunden mehr erstellen, sodass die Nutzer umsonst auf alle Dienste zugreifen könnten.
Montag, 11:30h: Ich habe mit meinem Team mehrere Fehler in der Codebasis gefunden, allesamt verursacht durch fehlerhafte Code-Erweiterungen. Da haben einige Teammitglieder wohl Bockmist gebaut. Die betreffenden Entwickler bitte ich um schnelle Erledigung.
Montag, 13:30h: Alex, der Chefarchitekt unseres Teams meldet, alle Fehler seien inzwischen behoben. Es habe sich um minimale Flüchtigkeitsfehler gehandelt, die erst nach dem Einchecken ins Quellcodeverwaltungssystem aufgetaucht seien. Die manuellen Unittests habe CatTube erfolgreich überstanden.
Montag, 16:30h: Eine verschlimmbesserte Version der Anwendung zeigt Zeichen der Instabilität. Das Testteam meldet mir trotzdem, dass alle Tests grünes Licht zeigen. Jetzt bemerke ich ein schlechtes Gefühl im Bauch. Leider beträgt die Testabdeckung für CatTube höchstens 50 Prozent. Das ist ein hoher Faktor, weil wir die Tests erst vor Monaten nachträglich hinzufügten. Immerhin sind wir dadurch von DEFCON 5 zu DEVCON 3 fortgeschritten – ich habe diese Metapher nur für mich eingeführt. Die anderen wissen nichts davon. Jedenfalls stochern wir bei der Fehlersuche noch häufig im Nebel beziehungsweise agieren größtenteils im Blindflug.
Montag, 19:30h: Das Team hat mühsam weitere Fehler aufgespürt. Die Anwendung scheint jetzt auf der Entwicklungsplattform stabil und fehlerfrei zu laufen. Glücksgefühle überkommen mich. Ich rufe die Testabteilung an und bitte um kurzfristige Überprüfung.
Montag, 22:00h: Die Müdigkeit überwältigt mich. Außerdem sitzt mir Frau Blümel ständig im Nacken. Wann können wir endlich produktiv gehen, ist ihre Lieblingsfrage. Ich berichte ihr, dass das Testteam erst jetzt positive Rückmeldung gegeben hat, und muss sie leider auf morgen vertrösten. Heute geht nichts mehr. Schließlich ist um diese Zeit kein Administrator mehr im Büro. Sichtlich verärgert verlässt sie den Raum.
Dienstag, 9:00h: Erst jetzt kam der erste Kollege von der Administration ins Büro. Als ich ihn anrufe und um Einspielen der verbesserten Version bitte, erwidert er, dass dies bis zum Nachmittag warten müsse. Vorher müsste sein Team noch andere Aufgaben abarbeiten. Dass ich ihn auf die Dringlichkeit des Falles aufmerksam mache, quittiert er nur mit einem: „Das mag ja sein, aber wir müssen vorher noch ein paar Wartungsarbeiten erledigen. Wie Du weißt, haben wir nur begrenzte Ressourcen.“
Dienstag, 20:00h: Das Operations-Team meldet erfolgreichen Vorzug. Die neue Version ist jetzt online. Erleichtert fahre ich nach Hause.
Mittwoch, 9:45h: Frau Blümel stürmt zu mir ins Büro, weil in unserer Online-Anwendung CatTube ein schwerwiegender Fehler aufgetaucht ist. Sie bittet mich, rasch zu handeln. Jeder Fehler führe schließlich zu hohen Ausfallkosten. Das System würde jetzt sehr viele Aussetzer beim Streaming zeigen.
Mittwoch, 12:00h: Ich habe eine Task Force ins Leben gerufen, um das neue Problem kurzfristig zu lösen. Die Entwickler berichten mir, dass die neue Version zu Unverträglichkeiten mit den Erweiterungen führt, die das Wartungsteam gestern in die Code-Basis eingefügt habe. Dadurch würden die Streaming-Dienste ausgebremst.
Donnerstag, 8:00h: Jetzt haben wir in mühevoller Kleinstarbeit den ganzen Code gereviewt. Dass unsere Dokumentation unvollständig und zum größten Teil veraltet ist, hat sich dabei als Bremsklotz erwiesen. Ich koordiniere jetzt alle Teams, um endlich das Problem ein für alle Mal zu lösen.
Freitag, 18:30h: Heute habe ich ohne schlechtes Gewissen eine Großpackung Gummibären vertilgt. Die hoffentlich fehlerfreie neue Version wurde vom Operations-Team jetzt in den Produktivbetrieb eingestellt. Ich bete inbrünstig, dass der Albtraum endlich ein Ende haben möge, und verlasse das Büro, um ins wohlverdiente Wochenende zu starten.
Montag, 7:30h: Die Chefin, Frau Blümel, stürmt zu mir ins Büro, weil in unserer Online-Anwendung CatTube ein schwerwiegender Fehler aufgetaucht ist. Sie bittet mich, rasch zu handeln. Jeder Fehler führe schließlich zu hohen Ausfallkosten. Im vorliegenden Fall würde CatTube keine Tickets für die Kunden mehr erstellen, sodass die Nutzer umsonst auf alle Dienste zugreifen könnten. Ein Déjà-vu-Gefühl übermannt mich. Die neueste Ausgabe von JavaSPEKTRUM liegt auf meinem Schreibtisch. Dort geht es um den Schwerpunkt „Die Kunst des Automatisierens – DevOps, DevSecOps, MLOps, DataOps“. Eine innere Kraft drängt mich dazu, diese Ausgabe genau zu studieren.
››Täglich grüßt das Murmeltier‹‹
Das vorliegende, zugegeben übertriebene Beispiel verdeutlicht, warum DevOps & Co. eine unabdingbare Kultur in IT-Unternehmen darstellen sollte, die schon vor der Softwareentwicklung beginnt. Erst durch funktionsübergreifende Teams, einen entsprechenden Prozess, essenzielle Praktiken und Automatisierungswerkzeuge lassen sich Ineffizienzen zwischen den notwendigen Rollen vermeiden. Der DevOps-Lebenszyklus sorgt für schnelle und nahtlose Kommunikation von Teams und noch dazu für höhere Qualität, weil Entwicklung, Testen und Operations nahtlos ineinandergreifen. Zudem beschleunigt sich der Prozess von der Softwareentwicklung bis zum Produktivbetrieb neuer Versionen rasant. Technologien wie Docker und Microservices verhelfen nicht nur zu einer modularen Architektur, sondern auch zu einer besseren Aufteilung von Mitarbeitern in funktionsübergreifende Teams.
