Nicht jedes Altsystem gehört modernisiert. Wenn die Produktlinie ausläuft, der Vertrag endet oder eine andere Plattform es in achtzehn Monaten ablöst, ist jede Modernisierung Geld in einem Auslaufmodell. Wann das der richtige Schluss ist, steht in einem eigenen Artikel.
Was danach kommt, steht dort nicht, und es ist der Teil, der in der Praxis schiefgeht. Denn „wir modernisieren nicht" wird regelmäßig als „wir tun nichts" umgesetzt, und das ist etwas ganz anderes.
Dieser Artikel beschreibt, was ein ordentlicher Wartungsmodus enthält: fünf Dinge, die weiterlaufen, drei, die aufhören, und die zwei Angaben, ohne die es kein Wartungsmodus ist, sondern Vernachlässigung mit besserem Namen.
Einfrieren ist eine Entscheidung, kein Zustand
Der Unterschied zwischen einem eingefrorenen und einem vernachlässigten System ist von außen unsichtbar. Beide bekommen keine neuen Funktionen, bei beiden passiert scheinbar nichts.
Der Unterschied liegt in zwei Angaben, die entweder existieren oder nicht.
Ein Enddatum. Wann wird das System abgeschaltet? Ohne diese Angabe ist jede Entscheidung über Aufwand unmöglich: Ob sich eine Maßnahme lohnt, hängt davon ab, wie lange sie noch trägt. Das Datum darf grob sein, es darf verschoben werden, und es muss existieren.
Ein Name. Wer ist bis dahin zuständig? Nicht ein Team, eine Person. Ein System ohne benannten Zuständigen ist genau das System, bei dem im Ernstfall drei Leute nacheinander sagen, dass sie sich das mal ansehen.
Beides gehört an eine Stelle, die jemandem gehört: ein Kalendereintrag, ein Eintrag im Systemverzeichnis, meinetwegen ein Zettel. Nicht in ein Dokument, das nach dem Schreiben niemand mehr öffnet.
Fünf Dinge, die weiterlaufen
Ein eingefrorenes System ist kein abgeschaltetes. Es steht im Netz, es verarbeitet Daten, und die folgenden fünf Dinge hören deshalb nicht auf.
Erstens: Sicherheitsaktualisierungen der Laufzeitumgebung. Betriebssystem, Webserver, Datenbank. Das ist der Teil, der am ehesten als „wir ändern ja nichts mehr" missverstanden wird, und er ist der wichtigste.
Zweitens: Sicherungen und ihre Wiederherstellung. Eine Sicherung, die niemand zurückgespielt hat, ist eine Vermutung. Im Wartungsmodus wird sie seltener gebraucht und ist genauso wichtig, weil niemand mehr täglich mit dem System arbeitet und deshalb ein Fehler länger unbemerkt bleibt. Ein Rückspieltest im Quartal ist eine vertretbare Frequenz.
Drittens: Überwachung, reduziert auf das Nötige. Läuft es, kommt es an die Datenbank, ist die Platte voll, laufen die Sicherungen. Vier Prüfungen reichen. Was nicht mehr nötig ist, sind Messwerte für Optimierungen, die niemand mehr vornimmt.
Viertens: Zertifikate und Ablaufdaten. Der häufigste Ausfall eines eingefrorenen Systems ist ein abgelaufenes Zertifikat. Automatische Erneuerung gehört eingerichtet, auch wenn sonst nichts mehr angefasst wird, weil dieser eine Vorgang sonst an einem Kalendereintrag hängt, der mit einer Person das Haus verlässt.
Fünftens: Fehlerkorrekturen, die den Betrieb betreffen. Was den Betrieb anhält, wird repariert. Was nur unschön ist, nicht. Die Trennlinie ist enger, als sie klingt, und sie hält nur, wenn jemand sie verteidigt.
Drei Dinge, die aufhören
Genauso wichtig ist die Gegenliste, und sie ist der Teil, der Durchsetzung braucht.
Neue Funktionen. Der Kern der Entscheidung und die Stelle, an der sie fast immer aufweicht. Der Wunsch nach „nur einer kleinen Änderung" hört nicht auf, nur weil das System ein Enddatum hat, und jede erfüllte Ausnahme macht die nächste leichter.
Aufräumen um seiner selbst willen. Refactoring, Aktualisierungen von Bibliotheken ohne Sicherheitsgrund, Verbesserungen der Struktur. All das zahlt sich über Jahre aus, und die gibt es hier nicht mehr.
Optimierung. Ein eingefrorenes System, das seit Jahren mit derselben Last läuft, wird nicht schneller gemacht. Wenn die Last steigt, ist das ein Anlass, die Entscheidung zu überprüfen, kein Anlass für einen Zwischenspeicher.
Isolieren: das System darf nichts mitreißen
Der technisch wichtigste Teil des Wartungsmodus ist die Isolation, und er wird am häufigsten ausgelassen, weil er Arbeit ist, ohne dass sich etwas sichtbar ändert.
Die Leitfrage lautet: Was passiert, wenn dieses System morgen ausfällt? Wenn die Antwort mehr enthält als dieses eine System, ist die Isolation nicht fertig.
Drei Richtungen gehören geprüft.
Wer hängt daran? Systeme, die dieses hier aufrufen und ohne es nicht arbeiten können. Jede solche Verbindung braucht entweder ein Verhalten für den Ausfall oder eine Entkopplung über eine Warteschlange. Das ist kein Umbau am Altsystem, sondern eine Maßnahme auf der anderen Seite, und deshalb erlaubt.
Woran hängt es? Dienste, die dieses System braucht. Jeder davon ist eine Ausfallquelle, die sein Ende überleben muss. Eine besondere Rolle spielen Fremddienste im Internet: Eine Schnittstelle, die abgeschaltet wird, bringt ein eingefrorenes System zum Stehen, und niemand liest mehr die Ankündigungen des Anbieters.
Wie viel Netz sieht es? Hier gilt die umgekehrte Reihenfolge zum Normalfall: Ein System ohne Pflege bekommt so wenig Zugang wie möglich. Kein Verwaltungszugang aus dem Internet, keine ausgehenden Verbindungen außer den zwingenden, und die Zugänge auf die Menschen beschränkt, die tatsächlich zuständig sind.
# Was spricht dieses System ueberhaupt an? Eine Woche mitschreiben,
# dann steht die Liste der zwingenden Verbindungen fest.
ss -tnp | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn
# Und wer spricht es an? Dieselbe Frage aus der anderen Richtung.
ss -tn state established | awk '{print $4}' | cut -d: -f1 | sort -uWas in diesem Zustand wegfallen kann, ist mehr als gedacht: Funktionen entfernen, die niemand mehr nutzt.
Abhängigkeiten festnageln
Ein eingefrorenes System soll sich nicht von selbst ändern. Das klingt selbstverständlich und ist es nicht: In vielen Projekten zieht irgendein Vorgang beim Ausrollen die neuesten Fassungen von Abhängigkeiten, und ein Neustart nach zwei Jahren installiert dann etwas anderes als das, was lief.
Drei Maßnahmen verhindern das, und alle drei sind einmalige Arbeit.
Versionen festschreiben, auch die des Grundbilds. Kein beweglicher Verweis auf eine Version, sondern ein fester. Das gilt für die Anwendungsabhängigkeiten genauso wie für das Betriebssystembild.
Das lauffähige Ergebnis aufbewahren, nicht nur den Bauplan. Ein Bauvorgang, der Pakete aus dem Internet holt, funktioniert in drei Jahren womöglich nicht mehr, weil ein Paketverzeichnis abgeschaltet wurde. Ein abgelegtes Abbild oder ein Archiv der Abhängigkeiten ist die Sicherung dagegen.
Einmal von null aufbauen, bevor der Wartungsmodus beginnt. Das ist die Prüfung für die beiden Punkte darüber, und es ist die einzige Art, sie zu belegen. Der Aufbau dauert einen Tag und beantwortet die Frage, ob das System nach einem Serverausfall überhaupt wieder entstehen könnte.
Die Regel für Änderungen, die es trotzdem gibt
Die Erfahrung sagt: Es wird Änderungen geben. Eine gesetzliche Anforderung, ein Steuersatz, ein Partner, der seine Schnittstelle ändert. Eine Regel, die das verbietet, wird gebrochen, und dann gibt es gar keine Regel mehr.
Was funktioniert, ist eine Regel mit einer Tür:
- Änderungen brauchen einen Anlass von außen. Gesetz, Vertrag, Sicherheit, Ausfall. Ein Wunsch aus dem Haus zählt nicht, egal wie klein er ist.
- Jede Änderung verlängert das Enddatum nicht. Das ist die wichtigste der vier Regeln. Sonst wird aus dem Wartungsmodus ein Dauerzustand mit anderem Namen.
- Jede Änderung wird auf derselben Grundlage gebaut wie das, was läuft. Keine neue Bibliotheksversion, keine neue Sprachversion, nur um diese eine Änderung zu machen.
- Eine Person entscheidet. Die aus dem ersten Abschnitt. Keine Runde, keine Abstimmung, sonst dauert die Entscheidung länger als die Änderung.
Ob sich der Ausstieg rechnet, ist eine eigene Rechnung: Der Business Case für eine Modernisierung.
Der Ausstieg: Datum und Auslöser
Ein Wartungsmodus endet auf eine von zwei Arten, und beide gehören vorher beschrieben.
Am Datum. Das System wird abgeschaltet, die Daten wandern in ein Archiv. Dieser Weg ist der geplante, und er braucht seinerseits einen Vorlauf: Wer greift noch zu, welche Daten müssen aufbewahrt werden, in welcher Form bleiben sie lesbar. Ein Export in ein Format, das in zehn Jahren noch jemand öffnen kann, erfüllt eine Aufbewahrungspflicht besser als ein Server, den in zehn Jahren niemand mehr startet.
Am Auslöser. Etwas tritt ein, das die Entscheidung ungültig macht, und dann wird sie neu getroffen statt fortgeschrieben. Vier Auslöser lohnen es, vorher aufgeschrieben zu werden: Die Ablösung verschiebt sich um mehr als ein halbes Jahr. Die Nutzung steigt statt zu fallen. Eine Sicherheitslücke lässt sich nicht mehr schließen, weil die Version aus der Pflege gefallen ist. Der zuständige Mensch geht.
Der dritte Auslöser ist der, der am häufigsten eintritt und am seltensten als Auslöser behandelt wird. Ein Bestandteil erreicht sein End of Life, und dann stehen drei Möglichkeiten offen: früher abschalten, isolieren und das Risiko schriftlich annehmen, oder doch modernisieren. Weitermachen wie bisher ist keine davon, auch wenn es sich so anfühlt.
Woran Sie merken, dass es keiner mehr ist
Zum Schluss die Prüfung, die ein Jahr später lohnt. Vier Fragen, und jedes Nein bedeutet, dass aus dem Wartungsmodus Vernachlässigung geworden ist.
- Kennt jemand das Enddatum, ohne nachzusehen? Wenn niemand im Raum es nennen kann, existiert es nicht mehr.
- Wann wurde zuletzt eine Sicherung zurückgespielt? Auf diese Frage gibt es eine Antwort mit Datum oder keine.
- Wann lief zuletzt eine Aktualisierung der Laufzeitumgebung? Mehr als ein halbes Jahr ist ein Befund.
- Wer ist zuständig, und weiß diese Person es? Die zweite Hälfte der Frage ist die wichtigere.
Ein System im Wartungsmodus ist ein bewusst eingegangenes Risiko mit einem Ende. Eines in Vernachlässigung ist ein unbekanntes Risiko ohne Ende, und der Unterschied kostet nichts außer Aufmerksamkeit an vier Stellen im Jahr.
Und wenn die Prüfung ergibt, dass die Entscheidung nicht mehr trägt: wie eine schrittweise Modernisierung abläuft, steht auf einer eigenen Seite. Sie ist nach einem ordentlichen Wartungsmodus übrigens billiger als vorher, weil Isolation und Abhängigkeiten dann bereits geklärt sind.
Dieser Artikel gehört zu einer Reihe über Systeme, die es schon gibt. Der Rückblick ordnet alle Artikel der Reihe nach Anlass.
