Software Wartung und Betrieb nach dem Start: Was danach geregelt sein muss

Das Muster ist bekannt. Eine Software, die vor zwei Jahren eingeführt wurde, zeigt plötzlich eine Fehlermeldung. Die Mitarbeiterin im Büro ruft den Ansprechpartner von damals an, der inzwischen in einem anderen Projekt steckt. Der Zugang zum Server liegt bei einem Dienstleister, den niemand mehr kennt, und das Passwort steht vermutlich in einer E-Mail von damals. Bis jemand die Lage versteht, ist der Nachmittag vorbei.

In diesem Szenario hat das Projekt nichts falsch gemacht. Die Software erfüllt ihren Zweck, die Abnahme war sauber, die Nutzer sind zufrieden. Was fehlt, ist ein Betriebsmodell, denn im Projekt gab es dafür keinen Platz. Entwicklung hat ein Ende und ein Budget, Betrieb hat weder das eine noch das andere. Er läuft, solange das Unternehmen läuft.

Dieser Beitrag beschreibt, was nach dem Start geregelt sein sollte. Er richtet sich an Geschäftsführung und interne Verantwortliche, die eine individuelle Software nutzen oder planen und wissen wollen, welche Fragen sie vor dem Go-live stellen müssen. Es geht nicht um ein Werkzeug, sondern um Zuständigkeiten, Rhythmen und Nachweise.

Ein hilfreicher Gedanke vorab: Software verhält sich wie ein Gebäude, nicht wie ein Möbelstück. Sie altert auch ohne Nutzung, weil sich ihre Umgebung verändert. Browser, Betriebssysteme, Bibliotheken und Sicherheitslagen bewegen sich weiter, ob Ihr Unternehmen etwas ändert oder nicht.

Die häufigste Betriebsstrategie lautet: nichts anfassen, solange es läuft. Sie wirkt vernünftig, weil jede Änderung ein Risiko trägt. Sie verschiebt das Risiko aber nur. Eine Anwendung, die zwei Jahre kein Update gesehen hat, wird nicht stabiler, sondern ihr Abstand zur Umgebung wächst. Wenn der Sprung später doch nötig wird, ist er groß, schwer zu testen und selten planbar.

Dahinter stehen mehrere Fehlerbilder, die sich selten einzeln zeigen. Abhängigkeiten, also fremde Bibliotheken, aus denen moderne Software zum großen Teil besteht, erhalten Sicherheitskorrekturen, die nie eingespielt werden. Backups laufen jede Nacht, doch niemand hat je eine Wiederherstellung probiert. Der Zugang des ehemaligen Entwicklers ist noch aktiv. Das Zertifikat läuft ab, und niemand hat den Termin im Kalender.

Hinzu kommt eine organisatorische Schwäche: Wissen steckt in Köpfen. Wer die Anwendung gebaut hat, kennt Eigenheiten, die nirgends stehen, etwa warum ein nächtlicher Job um drei Uhr laufen muss oder welche Einstellung beim Umzug des Servers mitgenommen werden muss. Verlässt diese Person das Projekt, geht das Wissen mit, und der Betrieb wird zum Ratespiel.

Die Konsequenz ist keine Panik, sondern Nüchternheit. Ein Betriebskonzept muss nicht groß sein, aber es muss existieren und jemandem gehören. Die Fragen, die es beantwortet, sind überschaubar, und die meisten lassen sich in einem halben Tag klären, wenn man sie vor dem Ausfall stellt statt danach.

Um Betrieb greifbar zu machen, hilft eine Zerlegung in Schichten, die aufeinander aufbauen. Unten liegt die Infrastruktur: Server, Netzwerk, Betriebssystem. Darauf läuft die Laufzeitumgebung mit ihren Bibliotheken, darüber die eigentliche Anwendung mit den Daten. Jede Schicht hat eigene Alterungsgeschwindigkeiten, eigene Zuständige und eigene Fehlerbilder, und sie lassen sich getrennt betrachten.

Quer dazu laufen Themen, die jede Schicht berühren: Zugriffe, Datenschutz, Überwachung und Dokumentation. Sie werden gern vergessen, weil sie keiner einzelnen Schicht gehören. Ein Rollenkonzept etwa ist weder Serverthema noch reine Anwendungslogik, und ein Löschkonzept betrifft Datenbank, Backups und Protokolle gleichermaßen.

Nützlich ist die Zerlegung vor allem, um Zuständigkeiten zu klären. Bei einem Ausfall entscheidet sich in Minuten, ob die Ursache unten oder oben liegt. Wenn aber nicht festgelegt ist, wer für welche Schicht verantwortlich ist, beginnt die Suche beim Dienstleister, der auf den Hoster zeigt, der auf die Anwendung verweist. Eine einfache Tabelle mit Schicht, Verantwortlichem und Vertreter löst dieses Problem überraschend zuverlässig.

Die Reihenfolge der Betrachtung folgt dem Schaden, nicht der Technik. Wir beginnen mit dem, was bei Verlust am teuersten ist: den Daten und dem Zugriff darauf. Erst danach lohnt es sich, über Komfort, Performance und Weiterentwicklung zu sprechen.

Für den Betrieb stehen drei Modelle zur Wahl, und keines ist immer richtig. Beim Eigenbetrieb übernimmt das Unternehmen Hosting und Pflege selbst oder mit einem IT-Dienstleister vor Ort. Das gibt Kontrolle, verlangt aber Fachwissen und Bereitschaft, auch nachts erreichbar zu sein. Für kleine Unternehmen ist das selten realistisch, außer die Anwendung ist unkritisch.

Beim zweiten Modell betreibt der Entwickler die Software mit einem Wartungsvertrag. Der Vorteil ist, dass Code und Betrieb in einer Hand liegen und Fehler schnell eingegrenzt werden. Der Nachteil ist die Abhängigkeit: Wird der Vertrag schwierig oder der Anbieter ändert seine Ausrichtung, steht das Unternehmen vor einem Wechsel, der ohne gute Dokumentation teuer wird. Genau deshalb gehört Ausstiegsfähigkeit von Anfang an in das Konzept.

Das dritte Modell trennt die Verantwortung. Ein Hosting-Anbieter betreibt die Infrastruktur, der Entwickler pflegt die Anwendung, und eine dritte Stelle, oft die Geschäftsführung oder ein interner Verantwortlicher, hält die Fäden zusammen. Es ist das robusteste Modell, aber auch das mit den meisten Schnittstellen. Es funktioniert nur mit klar benannten Ansprechpartnern und einem gemeinsamen Dokument, in dem steht, wer was tut.

Wir empfehlen in der Regel die Trennung von Infrastruktur und Anwendung, sofern das Unternehmen keine eigene IT hat. Sie begrenzt die Abhängigkeit und lässt den Wechsel eines Teils zu, ohne alles neu zu bauen. Bedingung ist, dass die Anwendung ohne Sonderwissen auf einem anderen Server wieder aufgebaut werden kann, und das lässt sich prüfen, statt es zu glauben.

Ein Betriebsgerüst besteht aus wenigen Bausteinen, die wir vor dem Go-live als Prüfliste durchgehen. Der erste ist ein Wartungsrhythmus: Abhängigkeiten und Betriebssystem werden in festen Abständen geprüft, Sicherheitskorrekturen mit hoher Dringlichkeit werden außerplanmäßig behandelt. Der Rhythmus ist weniger eine Frage der Technik als der Verabredung, denn sie sorgt dafür, dass es jemand tut.

Der zweite Baustein ist das Rollenkonzept. Es regelt, wer in der Anwendung was sehen und ändern darf, und es folgt dem Prinzip der geringsten Rechte: Jede Person erhält genau die Zugriffe, die sie für ihre Aufgabe braucht. Dazu gehört ein Verfahren für Ein- und Austritte, damit Konten ausgeschiedener Mitarbeiter nicht jahrelang aktiv bleiben. Das gilt ebenso für technische Zugänge wie Serverkonten, Datenbankbenutzer und Schnittstellenschlüssel.

Drittens die Dokumentation. Gemeint ist keine Prosa-Bibliothek, sondern ein schlankes Betriebshandbuch: Architekturskizze, Liste der Umgebungen, Ablage der Zugangsdaten in einem Passwortmanager, Beschreibung der geplanten Jobs, Wiederanlauf-Schritte und Ansprechpartner. Es sollte so geschrieben sein, dass eine fachkundige, aber unbeteiligte Person die Anwendung in einem Tag verstehen kann.

Viertens die Eigentumsfragen, die oft erst im Streitfall auffallen. Wem gehört der Quellcode, wer darf ihn ändern oder weitergeben, und wo liegt er? Wir halten es für sinnvoll, dass der Code in einem Repository liegt, auf das der Auftraggeber eigenen Zugriff hat, und dass die Nutzungsrechte im Vertrag eindeutig geregelt sind. Rechtliche Details gehören in den Vertrag und in die Prüfung durch einen Juristen, hier geht es um die technische Seite: Der Zugriff darf nicht allein vom Wohlwollen des Dienstleisters abhängen.

Bei Sicherheitsupdates zählt weniger die Häufigkeit als die Fähigkeit, sie gefahrlos einzuspielen. Dafür braucht es eine Testumgebung, die der Produktion ähnelt, automatisierte Tests für die wichtigsten Abläufe und ein Verfahren, Änderungen zurückzunehmen. Dann ist ein Update ein Routinevorgang. Ohne diese Voraussetzungen wird jedes Update zur Mutprobe, und aus Vorsicht unterbleibt es. Werkzeuge, die Abhängigkeiten auf bekannte Schwachstellen prüfen, liefern dafür die Datengrundlage, ersetzen aber nicht die Bewertung, ob eine Meldung die eigene Anwendung wirklich betrifft.

Bei Backups ist die Faustregel eindeutig: Ein Backup, das nie zurückgespielt wurde, ist eine Hoffnung. Wir planen deshalb regelmäßige Wiederherstellungstests in einer getrennten Umgebung ein und prüfen dabei zwei Dinge. Erstens, ob die Daten vollständig und lesbar sind. Zweitens, wie lange es dauert, bis die Anwendung wieder läuft. Diese Zeit ist die tatsächliche Wiederherstellungszeit, und sie weicht oft stark von der Annahme ab. Zusätzlich gehört mindestens eine Kopie an einen anderen Ort, getrennt vom Server und seinen Zugangsdaten, damit ein Angriff oder Fehler nicht gleichzeitig die Sicherung zerstört.

Das Monitoring beantwortet eine einfache Frage: Merken wir es vor den Nutzern? Dafür genügen oft wenige Prüfungen. Ist die Anwendung von außen erreichbar, läuft die Datenbank, ist genug Speicherplatz frei, läuft der nächtliche Job durch, wann endet das Zertifikat? Meldungen sollten bei jemandem ankommen, der handeln kann, und selten genug sein, dass sie ernst genommen werden. Ein Alarm, der täglich zehnmal grundlos kommt, wird bald ignoriert.

Protokolle ergänzen das Bild. Fehlerprotokolle der Anwendung zeigen Probleme, die kein Nutzer meldet, etwa fehlgeschlagene Schnittstellenaufrufe. Sie dürfen allerdings keine unnötigen personenbezogenen Daten sammeln und sollten nach einer festgelegten Frist gelöscht werden. Damit berühren sie das Löschkonzept, das wir im Kapitel zu den Sonderfällen aufgreifen.

Der erste Sonderfall betrifft den Datenschutz. Personenbezogene Daten dürfen nicht beliebig lange gespeichert werden, und das gilt auch für Backups und Protokolle. Ein Löschkonzept legt fest, welche Daten wie lange aufbewahrt und wann sie gelöscht werden, und es berücksichtigt gesetzliche Aufbewahrungspflichten. Das ist als technische Orientierung gemeint, nicht als Rechtsberatung. Die konkreten Fristen sollten Sie mit Ihrer Datenschutzbeauftragten oder einem Rechtsbeistand klären. Technisch lohnt es sich, Löschung als Funktion einzuplanen, denn nachträglich ist sie meist aufwendig.

Der zweite Fall ist der Personalwechsel auf beiden Seiten. Verlässt eine Mitarbeiterin den Betrieb, müssen Konten in der Anwendung, im Passwortmanager und beim Hoster angepasst werden. Wechselt beim Dienstleister der Entwickler, sollte eine zweite Person die Anwendung kennen. Das lässt sich prüfen: Fragen Sie, wer im Urlaubsfall eingreift, und lassen Sie sich die Antwort zeigen, nicht erzählen.

Drittens die Altlast. Manche Anwendungen laufen auf Versionen, für die es keine Sicherheitskorrekturen mehr gibt. Dann ist Wartung im Kern eine Modernisierungsfrage. Wir bewerten nach Risiko: Ist die Anwendung aus dem Internet erreichbar, enthält sie sensible Daten, ist sie geschäftskritisch? Je nach Antwort reicht eine Abschottung im Netzwerk für eine Übergangszeit, oder ein schrittweiser Umbau wird dringlich. Ein kompletter Neubau ist selten der erste Schritt.

Der vierte Fall ist der Sicherheitsvorfall. Wer vorher festlegt, wen er informiert, was zuerst abgeschaltet wird und wer mit Kunden spricht, handelt im Ernstfall ruhiger. Ein einseitiger Notfallplan genügt: Kontakte, erste Schritte, Ort der Sicherungen. Meldepflichten bei Datenpannen existieren, ihre Details gehören in eine Prüfung durch Fachleute und werden hier bewusst nicht ausgeführt.

Schließlich der Ausstieg. Eine Software ist ausstiegsfähig, wenn Daten in einem offenen Format exportiert werden können, der Code beim Auftraggeber liegt und die Umgebung dokumentiert ist. Das Ziel ist nicht, zu wechseln, sondern die Verhandlungsposition zu behalten.

Ein Betriebskonzept macht Software nicht unverwundbar. Es verändert die Wahrscheinlichkeit und die Folgen von Störungen. Ausfälle werden seltener, weil bekannte Schwachstellen geschlossen werden, und sie dauern kürzer, weil der Wiederanlauf geübt ist. Eine Zusage, dass nichts passiert, kann seriös niemand geben, und wer sie gibt, verkauft Sicherheit, die es nicht gibt.

Messen lässt sich der Nutzen an wenigen Größen. Dazu zählen die Verfügbarkeit über einen Monat, gemessen von außen, die gemessene Zeit bis zur Wiederherstellung aus dem Backup, das Alter der eingespielten Sicherheitskorrekturen und die Zahl bekannter, offener Schwachstellen in Abhängigkeiten. Hinzu kommen weiche Indikatoren: Wie lange braucht ein neuer Entwickler, um die Anwendung lokal zu starten, und wie viele Störungen meldeten zuerst die Nutzer?

Der Aufwand ist laufend und sollte so behandelt werden wie Wartung an anderen Anlagen. Als Orientierung dient ein Verhältnis zur Entwicklung, das sich nach Umfang und Kritikalität der Anwendung richtet. Eine allgemeine Prozentzahl wäre unseriös, denn kleine, gut gebaute Anwendungen brauchen wenig, vernetzte mit vielen Schnittstellen deutlich mehr. Wir nennen eine Schätzung erst nach einer Bestandsaufnahme.

Nach einem halben Jahr zeigt sich, ob das Konzept trägt. Wurden die Rhythmen eingehalten, wurde der Restore-Test wiederholt, sind Zugänge aktuell? Wo nicht, liegt es selten an der Technik. Meist fehlt eine Zeitscheibe im Kalender oder eine klare Zuständigkeit. Das sind lösbare Probleme, aber sie lösen sich nicht von selbst.

Eine der häufigsten Quellen für Streit ist die unklare Grenze zwischen Wartung und Weiterentwicklung. Wartung erhält den bestehenden Zustand: Sicherheitskorrekturen, Anpassung an neue Umgebungen, Überwachung. Fehlerbehebung beseitigt Abweichungen vom vereinbarten Verhalten. Weiterentwicklung erweitert den Funktionsumfang und ist ein neues Vorhaben mit eigenem Aufwand. Wer das vorher festlegt, vermeidet Diskussionen, wenn der Wunsch nach einem neuen Feld plötzlich als Fehler bezeichnet wird.

Grenzfälle gibt es dennoch. Ändert sich ein Format bei einer angebundenen Schnittstelle, ist die Anpassung Wartung oder Weiterentwicklung? Wir ordnen sie der Wartung zu, wenn das bestehende Verhalten erhalten bleiben soll, und der Weiterentwicklung, wenn sich der Funktionsumfang ändert. Wichtig ist, dass Auftraggeber und Dienstleister die Regel kennen, bevor der erste Fall eintritt.

Praktisch bewährt sich ein gemeinsames Verzeichnis offener Wünsche, das nach Dringlichkeit und Nutzen geordnet wird. Daraus entsteht in festen Abständen ein kleines Paket zur Umsetzung, statt dass jede Idee sofort einen Eingriff auslöst. Das schont Budget und Stabilität, denn jede Änderung ist auch ein Risiko, und gebündelte Änderungen lassen sich besser testen.

Ein Punkt, den viele unterschätzen: Technische Schulden wachsen auch durch gut gemeinte Schnellschüsse. Ein Provisorium, das nie ersetzt wird, ist nach zwei Jahren ein Teil des Systems. Ein Anteil der Wartungszeit sollte deshalb für Aufräumen reserviert bleiben, damit Weiterentwicklung nicht jedes Mal teurer wird als beim Mal davor.

Eine Individualsoftware ist ein Werkzeug mit Lebenszyklus. Ihr Wert hängt davon ab, ob sie nach Jahren noch sicher läuft, ob sich Daten zurückholen lassen und ob das Unternehmen sie auch mit einem anderen Partner weiterführen könnte. Die Antworten darauf sind keine Frage großer Budgets, sondern kleiner, verbindlicher Entscheidungen, die man am besten vor dem Start trifft.

Der nächste Schritt ist übersichtlich. Prüfen Sie für Ihre Software vier Dinge: Wer hat Zugriff, wann wurde zuletzt eine Wiederherstellung getestet, wie alt sind die letzten Sicherheitskorrekturen und liegt der Code bei Ihnen? Kann eine der vier Fragen nicht in wenigen Minuten beantwortet werden, ist das Ihr Startpunkt.

Planen Sie dafür einen festen, kleinen Termin pro Quartal ein. Eine Stunde genügt, um Zugänge, Backup-Test, Korrekturstand und offene Wünsche durchzugehen und die Ergebnisse im Betriebshandbuch zu vermerken. Dieser Termin ist unscheinbar, aber er ist der Unterschied zwischen einem Betrieb, der gepflegt wird, und einem, der nur hoffentlich weiterläuft.

Wir schauen uns das gern gemeinsam an, mit einer Bestandsaufnahme und einer ehrlichen Einschätzung, welcher Betriebsrahmen zu Ihrer Anwendung passt. Ob Sie den Betrieb am Ende selbst führen, auslagern oder teilen, entscheiden Sie. Unsere Aufgabe ist, dass die Entscheidung auf bekannten Tatsachen beruht.