IT in Unternehmen: Wie sich Softwareverrottung verhindern lässt
Dieser Artikel ist eine Übersetzung. Das Original des Softwareentwicklers und Bloggers Rajiv Prabhakar ist hier(öffnet im neuen Fenster) zu finden. Es wurde am 25. April 2020 veröffentlicht.
Vor kurzem bin ich bei Twitter auf einige Tweets gestoßen(öffnet im neuen Fenster), die eine Geschichte erzählten, die ebenso amüsant wie schockierend ist:
"Einer meiner Kunden ist für mehrere der 100 größten Pensionsfonds der Welt verantwortlich. Er hatte einen nächtlichen Batch-Job laufen, der abstürzte. Zuerst wusste niemand, was los war. Dieser Batch-Job war noch nie abgestürzt, zumindest nicht, soweit sich jemand erinnern konnte oder Logs dafür hatte.
Die Person, die das Programm geschrieben hatte, war vor 15 Jahren oder mehr verstorben und seit Jahrzehnten nicht mehr in der Firma beschäftigt gewesen. Das Programm war nicht sehr groß, aber ziemlich undurchdringlich – und es war in einem Stil geschrieben, der die Effizienz der Berechnung der Lesbarkeit für Menschen vorzog. Und natürlich gab es keine Tests.
Wie der Zufall es wollte, war am Vortag eine Änderung in der Orchestrierung der Skripte gepusht worden, die in dieser Umgebung liefen. Man vermutete, dass das die Ursache war. Die Entwickler setzten alles auf die vorherige Version zurück. Leider wurde es dadurch schlimmer.
(...)
Ein anderes Programm, der Leistungsverteiler, sollte eine Warnung ausgeben, wenn die Beiträge für die aktuellen Projektionen nicht ausreichten. Da es keine Ausgabe des ersten Programms gab (es war ja abgestürzt), nahm es folgenden Fall an: "Alle Beiträge sind 0". Das sollte natürlich nicht so sein. Aber niemand wusste, dass sich dieses Programm so verhielt, denn das erste Programm war ja noch nie abgestürzt.
(...)
Ich bekam eine überraschende Nachricht vom CIO. 'Tut mir leid, dass ich dich störe, wir haben ein großes Problem. s1X. Könntest du heute Nachmittag herfliegen?' S1X bedeutet: 'schlimmer als Schweregrad 1, weil das Problem Auswirkungen auf andere, unabhängige Teile des Geschäfts hat'."
Glücklicherweise sind die Pensionsfonds sicher und die Geschichte ging gut aus. Aber: Es ist beunruhigend, dass so etwas Essenzielles wie unsere Finanzsysteme mit veralteter Software arbeiten, die buchstäblich niemand versteht.
(Noch eine Geschichte mit einem weniger glücklichen Ende: 16.000 Coronavirus-Fälle wurden in England nicht gemeldet, weil eine Behörde ein überholtes, 30 Jahre altes Dateiformat verwendet hatte(öffnet im neuen Fenster).)
Geschäftsmodelle für erodierende Systeme
Das oben genannte Beispiel ist kein Einzelfall. Als ich 2012 Intel verließ, um zu Sun zu wechseln, wurde mir klar, wie schlecht es um deren Sparc-Produktlinie bestellt war. Einst die goldene Gans der Dot-Com-Server-Ära, war sie unglaublich weit hinter Intels Xeon-Produktlinie zurückgefallen.
Tatsächlich wurde mir von meinem eigenen Vorgesetzten gesagt, ich solle unsere Simulationen auf den Xeon-Servern laufen lassen – und nicht auf der Sparc-Serverfarm, denn diese sei "sehr langsam". Schlimmer noch: Intels CPUs waren nicht nur leistungsfähiger, sondern durch die Produktionsvorteile auch deutlich billiger in der Herstellung.
Die nächste naheliegende Frage, die ich hatte: Warum in aller Welt kauften die Leute überhaupt unsere Sparc-Chips, wenn sie so weit hinter der Konkurrenz lagen? Die Antwort, die ich von einem Senior-Architekten erhielt, machte mich sprachlos: Unsere Kunden hätten Softwaresysteme, die so veraltet seien, dass sie nur noch auf Sparc/Solaris-Systemen betrieben werden könnten.
Eine Migration auf x86/Linux wäre für sie nicht zu bewältigen gewesen. In vielen Fällen war sogar der Quellcode verloren gegangen, was verhinderte, dass sie ihre Anwendungen überhaupt neu hätten kompilieren können. Das Beste, was sie tun konnten, war ein Upgrade auf die neueste Generation der gleichen Sparc-Prozessoren – egal, wie langsam oder teuer sie waren.
Es ist wirklich so: Das Geschäftsmodell unserer gesamten Abteilung drehte sich um die erodierenden Softwaresysteme der US-amerikanischen Unternehmen.
Die Kosten, den Betrieb am Laufen zu halten
Als ich bei Amazon anfing, arbeitete ich mit dem Archetyp eines Legacy-Systems. Es enthielt riesige Mengen technischer Schulden und war von einem anderen Team entwickelt worden, das sich längst aufgelöst hatte. Die Verantwortung für das Projekt wurde auf unser Team übertragen – und es erwies sich als so unbeliebt, dass die Entwickler in Scharen abwanderten. Von den rund zehn Teammitgliedern, die es gab, als ich kam, war ein Jahr später kein einziges mehr da.
Oberflächlich betrachtet hatte das System viele Vorteile. Es war in einer modernen Sprache und einem modernen Tech-Stack (Java 8) geschrieben. Ein ganzes Team von Entwicklern mit sechsstelligen Einkommen war täglich daran zugange. Es wurde ständig aktualisiert, um Bugs zu beheben und/oder neue Funktionen hinzuzufügen.
Trotzdem war es offensichtlich, dass die Fluktuation das System niederdrückte. Infolge des Verantwortungs- und Teamwechsels ging eine enorme Menge an institutionellem Wissen verloren. Wissen um das allgemeine Code-Design, um die End-to-End-Funktionalität, um Best Practices und Debugging-Techniken. Wir arbeiteten hart, um es am Laufen zu halten. Und doch hatten wir das Gefühl, in einem Sumpf zu versinken, ständig jede Änderung in Frage stellen zu müssen und von allen Seiten von einer Art Kriegsnebel umgeben zu sein.
Können Sie sich vorstellen, wie viel schlimmer alles noch hätte sein können, wäre das Projekt auf Java 1 gelaufen – mit gar keiner aktiven Entwicklung und ohne Entwickler, die sich gekümmert hätten?
Es gibt Wege, katastrophale Programmausfälle zu vermeiden
Als Softwareentwickler streben wir danach, robuste, fehlerfreie Systeme zu entwickeln, die man jahrelang einfach laufen lassen kann, ohne manuell einzugreifen. Nach diesem Maßstab ist das Pensionsfonds-Skript sicher ein voller Erfolg.
Die harte Realität ist aber, dass alles eines Tages kaputtgeht. Alles wird irgendwann aktualisiert werden müssen. Zum Beispiel:
- weil Ihr System Hardware braucht, die nicht mehr produziert wird,
- weil Ihr System über Abhängigkeiten verfügt, die nicht mehr gültig sind,
- weil Ihr System über Abhängigkeiten mit schwerwiegenden Sicherheitslücken verfügt – und die einzigen Patches sich auf rückwärts-inkompatiblen Versionen befinden,
- weil die Anwendung auf Grundlage bestimmter Annahmen entwickelt wurde, die nicht mehr zutreffen(öffnet im neuen Fenster),
- oder einfach: weil die Welt sich verändert hat und die Anwendung sich mit ihr verändern muss.
Egal, was der Grund ist: Veränderung ist unvermeidlich. Die Frage ist nur, wie schmerzhaft sie sein wird, wenn sie schließlich nötig wird.
Wenn Sie ein System haben, an dem aktiv gearbeitet wird, muss eine Veränderung nicht allzu schmerzhaft sein. Wenn Sie jedoch ein System haben, das über mehrere Jahre oder sogar Jahrzehnte völlig ignoriert wurde, gibt es viele Dinge, die katastrophal schiefgehen können.
- Die Menschen, die das System programmiert haben, sind möglicherweise nicht mehr im Unternehmen,
- der Quellcode ist verlorengegangen,
- die neuen Entwickler wissen nicht, wie man den Quellcode richtig kompiliert, um die ausführbare Datei zu erzeugen, oder
- wie man die neue ausführbare Datei verteilt, oder
- wie die ausführbare Datei korrekt gestartet wird, mit allen, korrekt konfigurierten Flags, oder
- wie die Architektur und Implementierung des Codes zu verstehen ist, oder
- wie die Invarianten und impliziten Annahmen zu verstehen sind, die der Code braucht, um zu funktionieren, oder
- wie automatisierte Tests auszuführen sind, oder
- wie das Debugging bei Testfehlern funktioniert, oder
- wie man Fehler im Produktionsbetrieb behebt, oder
- wie man Zugriff auf Logs und Metriken erhält.
Wenn Sie versuchen, alle oben genannten Punkte zu dokumentieren, wird das helfen. Ihre Dokumentation wird aber große Lücken enthalten. Umfassende Dokumentation ist kein Ersatz dafür, sich die Hände schmutzig zu machen.
Ein müßiger Geist
Einen engagierten Entwickler zu haben, der für diese Dinge verantwortlich ist, ist ein guter erster Schritt. Aber das reicht nicht.
Dokumente werden die Menschen nur so lange lesen, bis sie sich langweilen. Sie werden außerdem nicht die gleichen Erkenntnisse daraus ziehen wie aus eigener Erfahrung – und durch das Lösen echter Probleme.
Wenn Menschen gebeten werden, etwas zu prüfen, ist die Wahrscheinlichkeit groß, dass sie es einfach schnell absegnen, um sich dann auf andere, neuere und schönere Projekte zu konzentrieren – oder dass sie es einfach nur aussitzen. Ohne echte Herausforderungen und wenn keine Ergebnisse gefordert werden, werden viele den Weg des geringsten Widerstands gehen.
Wenn Sie wirklich vermeiden wollen, dass Ihre Software vor sich hin rottet, ist der einzige Weg, ständig in Bewegung zu bleiben. Auch wenn es unnötig oder riskant erscheint. Denn der beste Weg, Ihr institutionelles Wissen und Ihre Fähigkeiten aufzubauen, zu erhalten und zu verifizieren, besteht darin, ständig Änderungen vorzunehmen und Ihre Fähigkeit zu testen, diese Änderungen erfolgreich umzusetzen. Der Tag, an dem Sie aufhören, sich zu bewegen, ist der Tag, an dem Ihr institutionelles Wissen anfängt zu verfallen.
Selbst sich im Kreis zu bewegen ist, so lächerlich es auch klingt, besser als komplette Untätigkeit. Realistisch betrachtet gibt es aber ohnehin immer etwas, das Systembetreuer tun können, um vorwärts zu kommen – selbst wenn es nur in winzigen Schritten ist.
Sie könnten Ihre Umgebung aktualisieren, um die neuesten Versionen aller Abhängigkeiten zu verwenden:
- zum Beispiel die Migration von JDK 8 auf 11 oder
- Sie aktualisieren Ihre JVM, um den G1-Garbage-Collector anstelle von CMS zu verwenden, oder
- Sie aktualisieren den GCC-Compiler von Version 5 auf 7 oder
- Sie upgraden Ihre Datenbank von Postgres 9.5 auf Postgres 11 oder
- Sie aktualisieren Ihr AWS SDK von Version 1.10 auf 1.11 oder
- Sie installieren die neueste Linux-Distribution auf Ihren Rechnern.
In schwerwiegenden Fällen, in denen Ihre Abhängigkeiten hoffnungslos veraltet sind, können Sie prüfen, ob Sie auf einen neueren Stack migrieren können:
- zum Beispiel von Sparc zu x86 oder
- von Solaris zu Linux.
Sie können Ihre Entwickler fordern, indem Sie auch die Anwendung aktualisieren:
- zum Beispiel, indem noch vorhandene Bugs und Sonderfälle angegangen werden,
- die automatisierte Testsuite gestärkt wird,
- technische Schulden bereinigt werden,
- Leistungsoptimierungen vorgenommen werden,
- neue Funktionen implementiert werden oder
- der Code schrittweise überarbeitet wird, um ihn lesbarer zu machen.
All das ist zwangsläufig mit vorübergehenden Risiken und scheinbar unnötigen Kosten verbunden. Zwangsläufig werden Ihre Entwickler dabei Fehler machen und Bugs einbauen. Deswegen scheint es sehr verlockend, einfach gar nichts zu tun. Nach dem Motto: "Wenn es nicht kaputt ist, muss es auch nicht repariert werden."
Wenn das betreffende System nur eine minimale Funktion für das Geschäft hat, mag das sogar die rationalste Lösung sein. Aber bei jedem unternehmenskritischen System wird diese Vernachlässigung von einem kleineren, vorübergehenden Risiko zu einem dauerhaften, katastrophalen Risiko. Nämlich dem Risiko, dass Ihr System eines Tages dringend debuggt oder aktualisiert werden muss, aber niemand dazu in der Lage ist.
Für jedes unternehmenskritische System ist es unerlässlich, institutionelles Wissen und Fähigkeiten zu erhalten. Der einzige Weg, das zu tun, ist kontinuierliches Training. Ihr (Unternehmens-)Gehirn ist ein Muskel. Benutzen Sie ihn oder verlieren Sie ihn.
Auch zu diesem Thema:
.jpg)
- Anzeige Hier geht es zum Handbuch für Softwareentwickler bei Amazon Wenn Sie auf diesen Link klicken und darüber einkaufen, erhält Golem eine kleine Provision. Dies ändert nichts am Preis der Artikel.