Software-Wartungsverträge: Was ein fixer monatlicher Update-Zyklus enthalten sollte

Die meisten Unternehmen, die einen Software-Wartungsvertrag unterschreiben, fragen nie, was die monatliche Gebühr tatsächlich bringt. Sie wissen, dass sie jemanden wollen, der „das System aktuell hält", und sie gehen davon aus, dass der Vertrag das abdeckt. In der Praxis sind viele Wartungsverträge bewusst vage formuliert, weil vage sich leichter verkaufen und leichter unterliefern lässt. Wenn Sie einen Software-Wartungsvertrag evaluieren oder sich fragen, ob der, den Sie bereits bezahlen, die Verlängerung wert ist, gibt es eine kurze Liste von Dingen, die schriftlich festgehalten sein sollten. Hier ist, worauf Sie achten sollten.

Was ein fixer monatlicher Update-Zyklus tatsächlich abdeckt

Ein Software-Wartungsvertrag ist eine laufende Vereinbarung, ein System aktuell und funktionsfähig zu halten, meist monatlich abgerechnet, statt als einmaliges Projekt. Das klingt einfach, aber „aktuell halten" kann fast alles bedeuten, je danach, wen man fragt. Ein schwacher Vertrag sagt, dass der Anbieter „regelmäßige Wartung durchführt". Ein nützlicher sagt, was aktualisiert wird, nach welchem Zeitplan, und was passiert, wenn ein Update etwas kaputt macht.

Mindestens sollte ein fixer monatlicher Zyklus die gewarteten Ebenen benennen: die Laufzeitumgebung (PHP, Node, was auch immer die Anwendung ausführt), das Framework, Drittanbieter-Pakete und das Betriebssystem oder Container-Image darunter. Jede dieser Ebenen bewegt sich in einem anderen Tempo. PHP veröffentlicht Sicherheitsreleases nach einem vorhersehbaren Zeitplan. Ein Framework wie Symfony hat seinen eigenen Long-Term-Support-Takt. npm-Pakete in einem fünf Jahre alten Frontend können Dutzende veraltete Abhängigkeiten haben, ohne klare Reihenfolge, in der man sie aktualisieren sollte. Ein Vertrag, der das alles als einen undifferenzierten „Updates"-Posten behandelt, wurde nicht zu Ende durchdacht, und das zeigt sich später meist entweder darin, dass nichts aktualisiert wird, oder dass alles gleichzeitig aktualisiert wird, auf eine Art, die die Anwendung kaputt macht.

Update-Frequenz sollte eine Zahl sein, kein Gefühl

Fragen Sie nach einem konkreten Takt. Monatliche Abhängigkeits-Updates mit einem quartalsweisen Review des gesamten Stacks sind eine vernünftige Grundlage für die meisten Geschäftsanwendungen. Wöchentlich ist manchmal gerechtfertigt bei Systemen, die Zahlungsdaten oder regulierte Informationen verarbeiten, wo die Kosten einer bekannten, ungepatchten Schwachstelle höher sind als die Kosten häufigerer Testzyklen. Was auch immer die Zahl ist, sie sollte im Vertrag festgehalten werden, nicht als „laufend" oder „nach Bedarf" beschrieben. Ein Anbieter, der sich auf keine Zahl festlegen kann, sagt Ihnen damit, dass Updates passieren, wenn man dazu kommt, was in der Praxis bedeutet: nachdem etwas kaputtgegangen ist.

Testing muss passieren, bevor irgendetwas die Produktion erreicht

Das ist der Teil, den die meisten Wartungsverträge überspringen, und es ist der Teil, der Sie tatsächlich schützt. Ein ungetestetes Update ist eine Wette, keine Wartungsaufgabe. Der Vertrag sollte beschreiben, was vor einem Release getestet wird: automatisierte Testsuiten, wo vorhanden, ein manueller Smoke-Test der Kernabläufe (Login, Checkout, was auch immer das Geschäft braucht), wo nicht, und eine Staging-Umgebung, die der Produktion eng genug entspricht, damit ein bestandener Test dort tatsächlich etwas bedeutet. Erwähnt der Wartungsvertrag überhaupt keine Staging-Umgebung, fragen Sie nach, wo Updates getestet werden, bevor Ihre Kunden sie sehen. Manchmal ist die ehrliche Antwort, dass sie es nicht werden, und Updates gehen direkt in die Produktion. Das ist eine Vereinbarung, mit der manche Unternehmen bei einem internen Tool mit niedrigem Risiko leben können. Es ist keine, die Sie für etwas Kundenorientiertes wollen.

Ein guter Wartungsvertrag sagt auch, was passiert, wenn ein Test fehlschlägt. Der Standardfall sollte sein, dass das Update zurückgehalten und untersucht wird, nicht dass es wegen einer Deadline durchgedrückt wird, nur weil der monatliche Zyklus sagt, dass heute Update-Tag ist.

Breaking Changes brauchen einen Verantwortlichen, bevor sie passieren

Composer-Updates in einem Legacy-PHP-Projekt ohne klare Routine sind einer der häufigsten Wege, wie ein Wartungszyklus unbemerkt zu einem Notfall wird. Ein Dependency-Bump kann still eine Methodensignatur ändern, eine Funktion, die Ihr Code aufruft, als veraltet markieren, oder ein Standardverhalten gerade genug verschieben, um Daten zu beschädigen, ohne einen Fehler auszulösen. Der Wartungsvertrag sollte festlegen, wer dafür verantwortlich ist, das zu erkennen, wie (automatisierte Tests, ein Changelog-Review, ein Diff der Breaking-Change-Hinweise der Abhängigkeit), und wie die Reaktion aussieht, wenn es trotzdem passiert. „Wir werden das untersuchen" ist kein Plan. „Wir machen innerhalb einer Stunde einen Rollback und der Fix wird mit einer Root-Cause-Notiz in den nächsten Zyklus eingeplant" ist einer.

Hier wollen Sie auch Klarheit über den Scope. Deckt der Wartungsvertrag die Behebung eines Breaking Change ab, den das Update selbst verursacht hat, oder gilt das als neue, abrechenbare Arbeit? Anbieter handhaben das unterschiedlich, und das sollte keine Überraschung sein, die man mitten in einem Vorfall entdeckt.

Sicherheitspatches haben eine andere Uhr als alles andere

Routinemäßige Dependency-Bumps können auf den monatlichen Zyklus warten. Eine veröffentlichte Schwachstelle in etwas, worauf Ihre Anwendung angewiesen ist, kann das nicht. Der Vertrag sollte diese beiden Kategorien explizit trennen und sich für die zweite auf eine schnellere Reaktionszeit festlegen, typischerweise innerhalb von 24 bis 72 Stunden nach Veröffentlichung einer kritischen CVE, abhängig von der Exposition. Wenn Ihr Wartungsvertrag keine Sprache enthält, die „Sicherheitspatch" von „Routine-Update" unterscheidet, verlassen Sie sich auf das Urteilsvermögen des Anbieters bezüglich Dringlichkeit, und dieses Urteilsvermögen steht nirgendwo schriftlich fest, worauf Sie sich berufen könnten.

Das gilt umso mehr für Software, die intern niemand mehr gut genug versteht, um das Risiko selbst einzuschätzen. Ein Unternehmen, das auf PHP 8.1 oder älter läuft, oder irgendetwas, das sich seinem eigenen End-of-Life-Datum nähert, braucht einen Wartungspartner, der diese Termine im Auftrag des Unternehmens verfolgt und rechtzeitig Bescheid gibt, bevor der Support endet, nicht danach. Wir haben bereits behandelt, wie sich das Risiko nicht mehr unterstützter PHP-Versionen in der Praxis tatsächlich zeigt, und die Kurzfassung lautet: „Es läuft noch" ist nicht dasselbe wie „es ist noch sicher zu betreiben".

Reporting sollte Ihnen etwas sagen, auf das Sie reagieren können

Ein nicht-technischer Inhaber braucht kein Changelog voller Paketversionsnummern. Nützlich ist eine kurze monatliche Zusammenfassung: was aktualisiert wurde, was getestet wurde, was als Risiko markiert wurde, und was eine Entscheidung von Ihrer Seite braucht. Wenn Ihr aktueller Wartungsvertrag einen Bericht sendet und Sie beim Lesen nicht erkennen könnten, ob letzten Monat etwas Wichtiges passiert ist, erfüllt das Reporting seinen Zweck nicht. Fragen Sie nach einem Format, das auf eine Seite passt und mit dem beginnt, was Sie tatsächlich wissen müssen, was fast immer lautet: „Ist etwas kaputt oder gefährdet, und braucht es Ihr Einverständnis?"

Reaktionszeiten gehören in den Vertrag, nicht in ein mündliches Versprechen

Wie schnell reagiert der Anbieter, wenn außerhalb des normalen Zyklus etwas schiefgeht? Dafür sollte eine Zahl stehen, gestaffelt nach Schweregrad. Ein komplett ausgefallener Server rechtfertigt vielleicht eine Reaktionszusage innerhalb einer Stunde. Ein kosmetischer Bug kann vernünftigerweise bis zum nächsten Werktag warten. Hat der Vertrag nur eine Reaktionszeit für jede Art von Problem, bleibt irgendjemand früher oder später hinter einem niedrig priorisierten Ticket hängen, während etwas Dringendes unbearbeitet bleibt, oder der Anbieter verbraucht sein Zeitbudget für kleine Fixes und hat nichts mehr übrig, wenn es wirklich zählt.

Was Sie vor der Unterschrift fragen sollten

Bevor Sie einen Software-Wartungsvertrag unterschreiben, fragen Sie schriftlich nach dem Update-Takt, fragen Sie, was wo getestet wird, fragen Sie, wer einen Breaking Change verantwortet, wenn er passiert, fragen Sie nach dem Sicherheitspatch-Reaktionsfenster getrennt vom Routinefall, fragen Sie, wie der monatliche Bericht aussieht, und fragen Sie nach Reaktionszeiten nach Schweregrad. Ein Anbieter, der alle sechs Fragen klar und konkret beantworten kann, hat diesen Prozess tatsächlich schon durchlaufen. Ein Anbieter, der in Allgemeinheiten antwortet, bittet Sie, einem Prozess zu vertrauen, den er nicht aufgeschrieben hat, was bedeutet, dass er in irgendeiner konsistenten Form wahrscheinlich noch gar nicht existiert.

Wenn Sie einen Wartungsvertrag gegen die Alternative abwägen, Updates selbst zu übernehmen oder sie liegen zu lassen, bis etwas kaputtgeht, hilft es zunächst zu wissen, wie exponiert Ihr aktuelles System tatsächlich ist. Ein kurzes Codebase-Assessment, bevor Sie sich auf einen monatlichen Vertrag festlegen, zeigt Ihnen, was Sie eigentlich bezahlen, jemanden zu warten, und ob der angebotene Wartungsvertrag dem tatsächlichen Risiko in Ihrem System entspricht statt einem generischen Paket. Bei Codebasen mit echten technischen Schulden kann eine laufende Code-Qualitätsberatung die Wartung auch in einen größeren Plan einbinden, diese Schulden abzubauen, statt den aktuellen Zustand nur unbegrenzt zu patchen.

Wenn Sie eine zweite Meinung zu einem angebotenen Wartungsvertrag wollen, oder wissen möchten, was ein fixer monatlicher Zyklus für Ihren spezifischen Stack kosten sollte, schreiben Sie uns an hello@wolf-tech.io oder schauen Sie sich an, was wir auf wolf-tech.io machen. Wir sagen Ihnen offen, ob das, was auf dem Tisch liegt, das abdeckt, was es abdecken sollte.