Wartungsplan für Software: 7 Schritte, Audit, Verantwortliche, MTTR

Ein Wartungsplan für Software ist eine betriebliche Vereinbarung: Er regelt die Verantwortung, legt messbare Servicelevel fest und plant Überwachung, Patches und Tests nach dem Start. Beginnen Sie heute damit, den aktuellen Zustand Ihres Systems zu prüfen und eine Person als Wartungsverantwortliche zu benennen. Legen Sie sofort zwei Zahlen fest: ein Ziel für die mittlere Behebungsdauer (MTTR) bei kritischen Fehlern und ein festes Patch-Fenster für regelmässige Aktualisierungen.

---

Kurz gefasst:

• Korrektive und adaptive Wartung sind laufende Kosten, die Systeme betriebsbereit und auf dem Stand externer Veränderungen halten. Sie sind keine Feature-Entwicklung.

• Wartungspläne sollten tägliche automatische Prüfungen, monatliche Patches, vierteljährliche Audits und jährliche Architekturreviews umfassen, abgestimmt auf die Verfügbarkeit der Beteiligten.

• Klare Verantwortlichkeiten sind entscheidend: definierte Rollen für Wartungsverantwortliche, Product Owner, Dev Lead, Pikettdienst und Infrastrukturteam.

• Die Überwachung sollte sich auf Signale wie Anwendungsleistung, Fehlerraten und Kennzahlen zur Nutzerwirkung konzentrieren, mit Alarmen, die an die geschäftliche Auswirkung gekoppelt sind, damit keine Alarmmüdigkeit entsteht.

• Backup- und Notfallwiederherstellungsverfahren müssen regelmässig über geplante Wiederherstellungsübungen getestet werden, mit definierten RPO- und RTO-Werten je nach Kritikalität des Systems.

---

Was ist ein Wartungsplan für Software, und was gehört hinein?

Ein Wartungsplan für Software ist das Dokument, das Ihrem Team und allen, die das System später übernehmen, sagt, wie das Produkt nach der Auslieferung zuverlässig bleibt. Es ist keine Aufgabenliste. Es kommt eher einem operational risk-mitigation framework nahe und vereint Servicelevel-Vereinbarungen, einen Patch-Rhythmus, Überwachungsregeln und ein Vorgehen bei Störungen in einer einzigen Referenz.

Die eigenen Engineering-Richtlinien der NASA behandeln das als formales Ergebnis, nicht als Nebensache. Gemäss SWE-105 umfasst ein konformer Wartungsplan die Einführung des Wartungsprozesses, die Analyse von Problemen und Änderungen, die Umsetzung von Änderungen, Prüf- und Abnahmekriterien, Migrationsverfahren, Ausserbetriebnahmepläne, Software Assurance, Risikobewertung, die Planung von Aktualisierungen, die Pflege der Dokumentation, Lizenzfragen und Backup-Pläne. Die meisten kommerziellen Teams brauchen nie eine Formalität auf NASA-Niveau, aber diese Liste ist eine nützliche Checkliste für den eigenen Plan: Wenn Sie zu einem dieser Punkte keinen Abschnitt vorweisen können, haben Sie eine Lücke und keinen Plan.

Die sofortige Handlung zählt mehr als die Papierarbeit. Führen Sie ein Basis-Audit durch: Was läuft tatsächlich, in welchem Zustand, mit welchen Abhängigkeiten? Und übergeben Sie die Verantwortung an eine namentlich benannte Person, bevor Sie eine einzige Seite Richtlinien schreiben. Alles Weitere in diesem Artikel baut auf diesem Ausgangspunkt auf.

Welche vier Arten der Softwarewartung gibt es?

Jede Wartungsanfrage, die Ihr Team erhält, fällt in eine von vier Kategorien. Diese Einteilung stammt aus der Softwaretechnik und hat sich über Jahrzehnte bewährt. Zu wissen, in welche Kategorie eine Anfrage gehört, entscheidet darüber, wer daran arbeitet, wie schnell und aus welchem Budget.

• Korrektive Wartung behebt Fehler, die im produktiven Betrieb auftreten, etwa ein Bestellformular, das die letzte Ziffer einer Telefonnummer stillschweigend verschluckt. Diese Arbeit ist naturgemäss reaktiv und meist die Aufgabe mit der höchsten Priorität auf Ihrem Board.

• Adaptive Wartung hält die Software funktionsfähig, während sich ihr Umfeld verändert, zum Beispiel die Anpassung einer Zahlungsanbindung, nachdem der Anbieter eine API-Version abgekündigt hat. Den Zeitpunkt bestimmen Sie hier nicht. Das tut die Aussenwelt.

• Perfektionierende Wartung verbessert etwas, das bereits funktioniert, etwa einen Bericht, der zwölf Sekunden zum Laden braucht. Niemand hat dafür einen Fehler gemeldet. Die Leute haben einfach begonnen, sich über die träge Anwendung zu beklagen.

• Präventive Wartung verhindert künftige Ausfälle, etwa indem ein Modul mit hoher zyklomatischer Komplexität überarbeitet wird, bevor es die nächsten drei Fehler verursacht. Sie wirkt selten dringend, und genau deshalb wird sie übersprungen.

Machen Sie bei Ihrem Audit jede Art sichtbar, indem Sie Ihre Daten jeweils anders befragen. Für die korrektive Arbeit ziehen Sie offene Tickets und Fehlerprotokolle heran. Für die adaptive Arbeit prüfen Sie Änderungsprotokolle von Anbietern und Abkündigungshinweise. Für die perfektionierende Arbeit sehen Sie sich Leistungsdashboards und Rückmeldungen der Nutzer:innen an. Für die präventive Arbeit durchsuchen Sie Berichte zur Codekomplexität und das Alter Ihrer Abhängigkeiten.

Der Budgetaspekt wiegt schwerer, als die meisten Verantwortlichen zugeben. Korrektive und adaptive Arbeit sind echte Wartungskosten, sie halten das bestehende Produkt am Leben. Perfektionierende Arbeit, die das Verhalten für Nutzer:innen spürbar verändert, gehört dagegen oft in die Produkt-Roadmap: finanziert und priorisiert wie ein Feature, statt stillschweigend in einem Wartungsvertrag aufzugehen.

Wie bauen Sie einen Wartungsplan Schritt für Schritt auf?

Der Aufbau des Plans ist eine Abfolge, kein Brainstorming. Jeder Schritt bereitet den nächsten vor, und wer einen überspringt, erlebt das drei Monate später meist als Feuerwehrübung.

1. Führen Sie das umfassende Audit durch. Erfassen Sie jeden Dienst, jede Bibliothek und jede Anbindung im produktiven Betrieb, bilden Sie deren Abhängigkeiten ab und übertragen Sie zwölf Monate Störungshistorie in ein Risikoregister. Halten Sie alles fest, was auf einer nicht mehr unterstützten Sprachversion läuft oder an einem auslaufenden Anbietervertrag hängt.

2. Legen Sie Ziele und Kennzahlen fest. Übersetzen Sie das Geschäftsrisiko in Zahlen: ein Servicelevel-Ziel für die Verfügbarkeit, ein MTTR-Ziel je Schweregrad, ein Fehlerbudget dafür, wie viele Störungen akzeptabel sind, bevor Sie neue Releases stoppen.

3. Erstellen Sie Zeitplan und Patch-Fenster. Die meisten Teams pendeln sich auf einen Rhythmus ein: tägliche automatische Prüfungen, monatliche Patches und Triage, vierteljährliche tiefere Audits und eine jährliche Überprüfung der Architektur für alles Geschäftskritische. Dieser Takt findet sich in der Fachliteratur zum Betrieb immer wieder. Richten Sie das Fenster nach Ihren Anspruchsgruppen aus, nicht umgekehrt: Ein Detailhändler patcht nicht während seines eigenen Black Friday.

4. Sichern Sie Änderungs- und Versionskontrolle ab. Jede Auslieferung sollte über ein Code-Review, ein markiertes Release und einen dokumentierten Rückweg laufen. Das Risiko von Rückschritten sinkt deutlich, sobald die Frage «Wer hat diese Änderung freigegeben?» kein Rätsel mehr ist.

5. Richten Sie Überwachung mit priorisierten Alarmen ein. Konfigurieren Sie die Alarmierung so, dass ein erschöpfter Datenbank-Verbindungspool jemanden um 2 Uhr nachts weckt, während ein kosmetischer CSS-Fehler bis zum Morgenmeeting warten kann.

6. Definieren Sie Testhürden. Verlangen Sie automatisierte Regressionstests, ein Canary-Release an eine kleine Nutzergruppe und einen definierten Auslöser für den Rückweg, bevor etwas den vollen produktiven Verkehr erreicht.

7. Legen Sie den Überprüfungsrhythmus fest. Nehmen Sie den Plan selbst zu festen Terminen erneut zur Hand, nicht nur das System, das er schützt. So passen die Servicelevel und Prioritäten auch ein Jahr später noch zur Realität.

Praxistipp: Schreiben Sie Ihr Rückfallverfahren, bevor Sie es brauchen, nicht während der Störung. Ein Rückfallplan, der um 3 Uhr nachts unter Druck entsteht, ist die Quelle der meisten Fehlentscheidungen.

Vorlagen, die diese sieben Schritte in Abschnitte zu Umfang, Rollen und Überprüfung gliedern, gibt es bereits, und eine davon zu übernehmen ist besser, als starting from a blank page.

Wer ist wofür verantwortlich, und wie strukturiert man Servicelevel?

Verantwortung scheitert lautlos, wenn sie nur angenommen und nicht zugewiesen wird. Halten Sie vor der ersten Störung schriftlich fest, wer was tut, nicht erst mittendrin.

• Wartungsverantwortliche Person verantwortet den Plan selbst, den Audit-Rhythmus und die Beziehungen zu Anbietern.

• Product Owner entscheidet, ob eine Anfrage Wartung oder ein Feature ist, und gibt Prioritätsentscheide frei, die Nutzer:innen betreffen.

• Dev Lead verantwortet Codequalität, Review-Standards und den Rückstand an technischen Schulden.

• Pikettdienst verantwortet die Erstreaktion bei laufenden Störungen und folgt dabei dem Eskalationsweg, statt einen zu improvisieren.

• Betrieb und Infrastruktur verantworten die Umgebung selbst: Server, Auslieferungen, Backups und Skalierung.

Prioritätsstufen übersetzen Geschäftsrisiko in verbindliche Reaktionszeiten. Eine praktikable Struktur sieht so aus: P1 für vollständige Ausfälle (Reaktion in unter 15 Minuten, Behebungsziel unter vier Stunden), P2 für eingeschränkte Kernfunktionen (Reaktion innerhalb einer Stunde, Behebung innerhalb eines Arbeitstags), P3 für kleinere Fehler mit Umgehungslösung (Reaktion innerhalb eines Tages, Behebung innerhalb einer Woche) und P4 für kosmetische Probleme (gebündelt im nächsten regulären Release). Die Reaktionszeit ist der Moment, in dem jemand das Problem bestätigt. Die Behebungszeit ist der Moment, in dem es tatsächlich gelöst ist. Beides in der Formulierung der Servicelevel zu vermischen, ist einer der häufigsten Fehler von Teams.

Wirksame Servicelevel gehen über Verfügbarkeitsprozente hinaus. Mittlere Behebungsdauer, mittlere Zeit zwischen Ausfällen und Fehlerbudgets liefern betriebliche Kennzahlen, die direkt an das anknüpfen, was dem Unternehmen wirklich wichtig ist. Während einer Störung muss der Eskalationsweg eindeutig sein: Wer wird zuerst alarmiert, nach welcher Zeitspanne geht es an den Dev Lead, und ab wann wird der Product Owner einbezogen, um mit Kundinnen und Kunden zu kommunizieren.

Wie wird aus präventiver Wartung durch Überwachung vorausschauende Wartung?

Präventive Wartung läuft nach Kalender. Vorausschauende Wartung läuft nach Signalen und erkennt Probleme, bevor jemand ein Ticket eröffnet. Der Wechsel gelingt, sobald Sie die Überwachung als tatsächliche Quelle der Wahrheit behandeln und nicht als Dashboard, das niemand anschaut, bis etwas kaputt ist.

Zu den beobachtenswerten Signalen gehören Leistungskennzahlen der Anwendung, strukturierte Protokolle, die Länge von Auftragswarteschlangen, Protokolle langsamer Datenbankabfragen, Fehlerraten pro Endpunkt und die Core Web Vitals für alles, was Kundinnen und Kunden im Web sehen. Die Gestaltung der Alarme ist ebenso wichtig wie die Wahl der Signale.

• Koppeln Sie jeden Alarm an eine geschäftliche Auswirkung, nicht an einen rohen Messwert: «Fehlerrate im Bestellprozess über 2 %» schlägt «CPU über 80 %» fast immer.

• Leiten Sie wenig dringende Signale in eine tägliche Zusammenfassung statt an den Pikettdienst. Alarmmüdigkeit ist der Grund, weshalb Teams Alarme irgendwann komplett ignorieren.

• Nutzen Sie Trendlinien im Wochenvergleich, nicht einzelne Ausschläge, um zu entscheiden, wann eine Überarbeitung eingeplant statt erneut verschoben wird.

Rund ein Drittel aller Engineering-Teams erfährt von grösseren Ausfällen noch immer zuerst durch Kundenbeschwerden, bevor die eigene Überwachung anschlägt. Diese Lücke taucht in Nachbetrachtungen quer durch die Branche immer wieder auf. Ein praktikabler Triage-Ablauf sieht so aus: Der Alarm wird ausgelöst, der Pikettdienst bestätigt ihn innerhalb der vereinbarten Reaktionszeit, der Schweregrad wird anhand der Auswirkung auf Nutzer:innen festgelegt, danach geht das Ticket je nach Ursache in den korrektiven, adaptiven oder präventiven Rückstand. Werkzeuge wie KI-gestützte Anomalieerkennung kommen zunehmend zum Einsatz, um Abweichungen bei Fehlerraten zu erkennen, bevor sie einen harten Schwellenwert überschreiten. Genau hier kann Automatisierung den manuellen Triage-Aufwand erheblich verringern.

Welche Backup- und Notfalltests sollten Pflicht sein?

Ein ungetestetes Backup ist eine Hoffnung, kein Plan. Diesen Satz sollte man wörtlich nehmen und nicht als Slogan. Der einzige Weg, sicher zu wissen, dass Ihr Wiederherstellungsprozess funktioniert, ist, ihn regelmässig durchzuführen und festzuhalten, was dabei passiert ist.

1. Legen Sie RPO und RTO nach Kritikalität des Systems fest. Eine Zahlungsdatenbank braucht vielleicht einen Wiederherstellungspunkt im Minutenbereich und eine Wiederherstellungszeit unter einer Stunde, während ein internes Auswertungswerkzeug bei beidem einen ganzen Tag verkraftet.

2. Planen Sie Wiederherstellungsübungen, nicht nur Backups. Vierteljährlich für kritische Systeme, halbjährlich für alles andere, mit protokollierten Ergebnissen, die von der wartungsverantwortlichen Person geprüft werden.

3. Halten Sie Backups geografisch getrennt von der Hauptumgebung und prüfen Sie die Integrität der Sicherungsdateien selbst, nicht nur die Bestätigung, dass ein Auftrag abgeschlossen wurde.

4. Dokumentieren Sie Rückfall- und Notfall-Release-Schritte zusammen mit dem Notfallplan, denn eine fehlerhafte Auslieferung und ein Rechenzentrumsausfall verlangen oft dieselbe schnelle, ruhige Reaktion.

Welche Dokumentation muss sich ändern, wenn Sie ein System migrieren oder abschalten?

Dokumentation veraltet schneller als fast alles andere in einem Wartungsplan, und veraltete Dokumentation ist schlimmer als gar keine, weil sie die nächste Person aktiv in die Irre führt.

• Aktualisieren Sie Architekturdiagramme, Handbücher für den Betrieb und Release Notes im selben Pull Request wie die Codeänderung, nicht als separate Aufgabe, zu der niemand kommt.

• Planen Sie Migrationen mit einer Phase des Parallelbetriebs, einem klaren Skript für die Datenübernahme und einer frühzeitigen Ankündigung an die betroffenen Nutzer:innen, bevor Sie umschalten.

• Definieren Sie ausdrückliche Kriterien für die Ausserbetriebnahme alter Systeme: Nutzungsschwellen, Kosten für den Unterhalt, Sicherheitsrisiken. Archivieren Sie die Daten vor der Abschaltung, nach denselben Grundsätzen für Ausserbetriebnahme und Migration, die SWE-105 für regulierte Systeme verlangt.

Wie führt ein von Senior-Leuten geführtes Studio einen Wartungsvertrag in der Praxis?

Die Wartungsarbeit baut idealerweise auf dem Grundsatz auf, dass die erfahrenen Leute, die das ursprüngliche Projekt aufgesetzt haben, bei der Übergabe an Bord bleiben. So versteht die Person, die das System betreut, bereits, weshalb es so gebaut wurde. Diese Kontinuität nimmt das Rätselraten weg, das sonst folgt, wenn ein Wartungsvertrag den Besitzer wechselt.

Ein typischer Monatsvertrag deckt Überwachung und Triage von Alarmen, Sicherheitspatches, kleine funktionale Verbesserungen und die Reaktion auf Störungen ab. Für Teams mit älteren Systemen beginnt die Entwicklungs- und Migrationsarbeit von Ampersand Labs oft als Wartungsgespräch, aus dem sich der Bedarf für einen Plattformwechsel ergibt: Eine veraltete Technologie wird auf etwas Wartbares umgestellt, bevor kleine Korrekturen strukturell unmöglich werden.

Wo finden Sie Standards und Vorlagen als Ausgangspunkt?

Für Teams, die eine formale Nachvollziehbarkeit brauchen, bleibt SWE-105 die klarste öffentliche Referenz für die erforderlichen Bestandteile eines Plans. Ergänzen Sie sie mit praxisnahen Hinweisen zu Kosten und Rhythmus, um ein realistisches Budget zu setzen, und nehmen Sie Ampersand Labs als Ausgangspunkt, wenn Sie den ganzen Plan lieber einem Team übergeben, das bereits einen führt.

Ein Wartungsplan, der nicht von Kopfwissen abhängt

Die meisten Wartungsprobleme lassen sich auf eines zurückführen: Die Person, die das System verstanden hat, ist gegangen, und niemand hat aufgeschrieben, weshalb bestimmte Entscheidungen so getroffen wurden. Lösen lässt sich das, indem die erfahrenen Entwickler:innen, die ein Projekt aufsetzen, auch nach dem Start für die Betreuung verfügbar sind, statt eines wechselnden Supportdesks, das fremde Notizen liest.

Der monatliche Support- und Wartungsdienst umfasst Überwachung, Patches und Störungsbehebung, aufgebaut genau so, wie dieser Artikel es beschreibt, mit klaren Reaktionszielen statt vager Versprechen. Für Teams, die viel wiederkehrende Triage-Arbeit stemmen, kann der Dienst zur KI-Automatisierung zusätzlich die manuelle Bearbeitung von Alarmen reduzieren. Wenn Ihr Produkt Altlasten im Code mitträgt, die sich mit Wartung allein nicht beheben lassen, zeigt die Seite mit den Fallstudien, wie frühere Migrationen von A bis Z abgewickelt wurden. Melden Sie sich über die Kontaktseite von Ampersand Labs, um ein Wartungsaudit für Ihr System aufsetzen zu lassen.

Quellen

• SWE-105

• operational risk-mitigation framework

Häufige Fragen

Was gehört in einen Wartungsplan?

Ein vollständiger Plan deckt Verantwortlichkeiten und Rollen ab, Servicelevel-Ziele für Reaktion und Behebung, einen Zeitplan für Patches und Tests, Regeln für Überwachung und Alarmierung, Verfahren für Backup und Notfallwiederherstellung sowie die Dokumentation für Migration oder Ausserbetriebnahme. Damit spiegelt er die in SWE-105 aufgeführten Elemente.

Welche vier Arten der Softwarewartung gibt es?

Korrektiv (Fehler beheben), adaptiv (an Veränderungen des Umfelds anpassen), perfektionierend (bestehende Funktionen verbessern) und präventiv (künftigen Ausfällen zuvorkommen). Damit ist praktisch jede Wartungsanfrage abgedeckt, die ein Team erhält.

Welches sind die sieben Phasen des Softwarelebenszyklus?

Üblicherweise genannt werden Planung, Anforderungsanalyse, Entwurf, Entwicklung, Test, Auslieferung und Wartung. Die Wartung ist dabei die längste Phase, weil sie nach dem Start über die gesamte Lebensdauer des Produkts andauert.

Wie oft sollte ein Wartungsplan überprüft werden?

Ein praktikabler Rhythmus sind tägliche automatische Prüfungen, monatliche Patches und Triage, vierteljährliche tiefere Audits und eine jährliche Überprüfung der Architektur für geschäftskritische Systeme.

Wie viel Budget sollte ein Unternehmen für Softwarewartung einplanen?

Wartungskosten werden meist als Anteil der ursprünglichen Entwicklungskosten kalkuliert und als laufender Betrieb geführt, nicht als einmalige Ausgabe. Denn über die gesamte Lebensdauer betrachtet macht die Wartung häufig den grösseren Teil der Gesamtkosten eines Systems aus.

Empfohlen

• Softwarewartung Zürich, monatliche Betreuung

• Software-Audits & technische Due Diligence Zürich

• Interims-CTO Zürich, CTO auf Zeit und in Teilzeit

• Migration von Altsystemen & Plattformwechsel Zürich