Ihre Software läuft. Aber ist sie auch gesund?

Die Anwendung ist erreichbar. Kunden können bestellen. Das interne System funktioniert. Deployments gehen irgendwie durch.

Auf den ersten Blick scheint also alles in Ordnung zu sein.

Technische Probleme entstehen jedoch selten über Nacht. Häufig bauen sie sich langsam auf: Updates werden verschoben, Wissen konzentriert sich auf einzelne Personen, Backups werden zwar erstellt, aber nie getestet, und jede neue Funktion dauert etwas länger als die vorherige.

Das System funktioniert noch. Aber seine technische Gesundheit verschlechtert sich.

Diese sieben Warnzeichen helfen dabei, technische Schulden frühzeitig zu erkennen:

1. 01Eine einzelne Person kennt das gesamte System.
2. 02Updates werden ständig verschoben.
3. 03Monitoring bedeutet: "Der Kunde meldet sich."
4. 04Backups existieren, aber niemand hat eine Wiederherstellung getestet.
5. 05Neue Features dauern immer länger.
6. 06Infrastruktur und Code werden immer komplexer.
7. 07Dokumentation existiert nur im Kopf oder in alten Chats.

1. Eine einzelne Person kennt das gesamte System

Das ist eines der gefährlichsten Warnzeichen. Wenn nur eine Person weiß, wie Deployments funktionieren, wo Zugangsdaten liegen, warum bestimmte Komponenten so gebaut wurden und welche Systeme voneinander abhängen, entsteht eine starke Abhängigkeit von dieser Person. In der Praxis wird das oft als Bus Factor bezeichnet.

Das Problem ist nicht, dass diese Person schlechte Arbeit macht. Im Gegenteil: Sie hat vermutlich über lange Zeit Verantwortung übernommen. Das Problem ist, dass das Wissen nicht im System, in den Zugängen und in der Dokumentation verankert ist.

Ein sinnvoller erster Schritt ist eine technische Übergabe. Dokumentieren Sie mindestens:

• Architektur und wichtigste Datenflüsse
• Zugänge und Verantwortlichkeiten
• Deployment-Prozess und Rollback-Weg
• externe Dienste und kritische Abhängigkeiten
• Backup- und Recovery-Prozess

Dafür braucht es kein hundertseitiges Handbuch. Eine aktuelle Übersicht, die eine zweite Person nachvollziehen kann, reduziert das Risiko bereits deutlich.

2. Updates werden ständig verschoben

"Das Update machen wir später" ist einmal kein Problem. Wenn Updates aber regelmäßig vermieden werden, weil niemand die Auswirkungen einschätzen kann, entsteht ein strukturelles Risiko.

Typische Gründe sind veraltete Framework-Versionen, unbekannte Abhängigkeiten, fehlende Tests, manuelle Deployments oder alte PHP-, Node-, Ruby- und Betriebssystemversionen. Jede einzelne Version muss nicht sofort ersetzt werden. Entscheidend ist, ob das Team den Zustand kennt und Änderungen kontrolliert durchführen kann.

Je länger ein Update aufgeschoben wird, desto größer wird der spätere Sprung. Dann geht es nicht mehr um eine normale Wartung, sondern um einen eigenen Migrationsversuch mit schwer vorhersehbaren Nebenwirkungen.

Ein klares Warnsignal ist erreicht, wenn ein normales Dependency- oder Betriebssystem-Update als eigenes Projekt behandelt werden muss. Dann sollte die technische Basis geprüft werden, bevor weitere Funktionen darauf aufgebaut werden.

3. Monitoring bedeutet: "Der Kunde meldet sich"

Ein System sollte nicht erst dann als gestört gelten, wenn ein Nutzer eine E-Mail schreibt. Mindestens bekannt sein sollten die Erreichbarkeit, die Fehlerquote, CPU- und Speichernutzung, freie Festplattenkapazität, fehlgeschlagene Jobs, SSL-Zertifikate, wichtige Logs und relevante Security-Ereignisse.

Monitoring muss nicht bedeuten, jede denkbare Metrik zu sammeln. Das Ziel ist einfacher: Probleme erkennen, bevor sie zum Geschäftsausfall werden. Ein Ping allein reicht dafür nicht. Er kann erfolgreich sein, während der Checkout Fehler liefert oder ein Hintergrundjob seit Stunden nicht mehr läuft.

Für kleine Teams sind wenige verlässliche Signale besser als ein überfülltes Dashboard. Jede Warnung sollte eine Bedeutung, eine zuständige Person und eine erwartete Reaktion haben. Der Artikel Monitoring ohne Alarmmüdigkeit beschreibt, wie sich solche Signale von bloßem Messrauschen trennen lassen.

4. Backups existieren, aber niemand hat eine Wiederherstellung getestet

"Wir haben Backups" ist nur die Hälfte der Antwort. Die wichtigere Frage lautet: Können Sie sie wiederherstellen, und wie lange dauert das?

Ein sinnvolles Backup-Konzept klärt, was gesichert wird, wie oft Sicherungen laufen, wo sie liegen, wer Zugriff hat, wie lange sie aufbewahrt werden und wann zuletzt eine Wiederherstellung getestet wurde. Auch Schlüssel, Secrets, Konfiguration, DNS-Informationen und die Anleitung zum Wiederaufbau können für den Betrieb notwendig sein.

Ein Backup, dessen Wiederherstellung nie geprüft wurde, ist zunächst nur eine Hoffnung. Der Job kann grün sein, obwohl die falschen Verzeichnisse gesichert wurden, die Datenbank unvollständig ist oder niemand mehr den Entschlüsselungsschlüssel findet. Ein Backup- und Restore-Test macht aus dieser Annahme einen Nachweis.

5. Neue Features dauern immer länger

Das Produkt wächst, aber jede Änderung benötigt mehr Zeit. Gleichzeitig steigt die Zahl der Rückfragen, manuellen Tests und unerwarteten Nebenwirkungen. Das ist der Punkt, an dem technische Schulden direkt zum Geschäftsthema werden.

Mögliche Ursachen sind stark gekoppelte Komponenten, fehlende Tests, unklare Datenmodelle, Sonderfälle ohne Dokumentation und Workarounds auf älteren Workarounds. Eine kleine Änderung an einer Stelle bricht dann etwas an einer anderen Stelle. Das Team reagiert vorsichtiger, Releases werden größer und Fehlerkorrekturen dauern länger.

Der Code muss dafür nicht "schön" aussehen. Wartbarkeit zeigt sich daran, wie vorhersehbar eine Änderung ist. Wenn die Antwort auf die Frage "Was ist von diesem Release betroffen?" regelmäßig "Das sehen wir dann" lautet, sollte der Bereich genauer untersucht werden.

Ein guter erster Ansatz ist, die nächsten zwei oder drei geplanten Änderungen zu betrachten. Welche Stellen müssen alle angefasst werden? Wo fehlen Tests? Welche Arbeit entsteht nur, weil eine alte Entscheidung nicht mehr zum Produkt passt? Diese Antworten sind oft aussagekräftiger als ein allgemeines Urteil über Codequalität.

6. Infrastruktur und Code werden immer komplexer

Mehr Technik bedeutet nicht automatisch bessere Technik. Ein Server wird zu mehreren Servern. Dann kommen Container, zusätzliche Datenbanken, Proxies, Monitoring, Automatisierungen und weitere Services hinzu. Jede Entscheidung kann für sich sinnvoll gewesen sein. Das Problem entsteht, wenn niemand mehr die Gesamtarchitektur hinterfragt.

Komplexität kostet nicht nur Geld. Sie vergrößert die Zahl der Zustände, die bei einem Ausfall verstanden werden müssen. Mehr Zugänge müssen gepflegt, mehr Abhängigkeiten aktualisiert und mehr Komponenten überwacht werden.

Die passende Frage ist deshalb nicht: "Welche Technologie fehlt uns noch?" Sondern: "Welche Teile dieser Architektur benötigen wir tatsächlich, und wer kann sie im Störungsfall bedienen?"

Eine Architekturübersicht sollte pro Komponente Zweck, Verantwortlichkeit, Abhängigkeiten und Weg zur Wiederherstellung nennen. Wenn eine Komponente keinen klaren Zweck mehr hat oder nur aus Gewohnheit betrieben wird, ist ihre Vereinfachung oft wertvoller als das nächste Tool.

7. Dokumentation existiert nur im Kopf oder in alten Chats

Slack, Teams, E-Mails und Tickets enthalten oft wichtige technische Informationen. Sie ersetzen aber keine grundlegende Dokumentation. Chatverläufe sind schwer zu durchsuchen, hängen von einzelnen Konten ab und geben selten den aktuellen Stand wieder.

Mindestens dokumentiert sein sollten Architektur, Umgebungen, Verantwortlichkeiten, Deployment, kritische Drittanbieter, Zugriffswege, Backups und Recovery. Dazu gehört auch die Frage, wer bei einem Vorfall entscheiden darf und wen das Team außerhalb der üblichen Arbeitszeit erreicht.

Dokumentation muss nicht alles festhalten. Sie soll dafür sorgen, dass jemand mit technischem Verständnis das System nachvollziehen und die ersten Schritte ausführen kann. Ein kurzes Runbook für einen häufigen Fehler ist mehr wert als ein veraltetes Wiki mit hundert Seiten.

Technische Schulden sind nicht automatisch schlecht

Technische Schulden sind teilweise eine vernünftige Entscheidung. Ein MVP muss nicht dieselbe Architektur besitzen wie eine Plattform mit 100.000 Nutzern. Ein Team darf bewusst eine einfache Lösung wählen, um eine Geschäftsidee zu prüfen oder einen Markt schnell zu erreichen.

Problematisch werden Schulden erst, wenn niemand weiß, dass sie existieren, niemand ihre Auswirkungen kennt und kein Plan für den Umgang mit ihnen existiert. Dann werden aus bewussten Abkürzungen unbemerkte Abhängigkeiten.

Die richtige Frage lautet daher nicht: "Ist dieser Code modern?" Sie lautet: "Kennen wir das Risiko, können wir es begrenzen und passt es noch zu dem Geschäft, das heute darauf angewiesen ist?"

GeschäftsauswirkungWahrscheinlichkeitÄnderungshäufigkeit

Wie priorisiert man technische Schulden?

Nicht jede technische Schwäche verdient sofort ein Projekt. Bewerten Sie jeden Befund zunächst nach drei Faktoren:

Die höchste Priorität haben meist Bereiche mit hoher Geschäftsauswirkung, hoher Wahrscheinlichkeit und häufigen Änderungen. Ein selten genutztes internes Tool mit veralteter Bibliothek kann warten. Ein schlecht getesteter Checkout, der jede Woche geändert wird, wahrscheinlich nicht.

Priorisieren Sie also nicht die technisch interessanteste Baustelle. Priorisieren Sie die Kombination aus Risiko und Reibung, die das Unternehmen tatsächlich spürt.

Ein pragmatischer erster Schritt

Sie müssen nicht sofort alles modernisieren. Beginnen Sie mit einer kurzen Bestandsaufnahme:

1. System und Infrastruktur aufnehmen.
2. Kritische Abhängigkeiten und einzelne Wissensbesitzer identifizieren.
3. Security-, Backup- und Betriebsrisiken prüfen.
4. Die wichtigsten Entwicklungsbremsen erfassen.
5. Befunde nach Geschäftsauswirkung priorisieren.
6. Kleine, kontrollierte Verbesserungen durchführen und dokumentieren.

Das kann ein getesteter Restore sein, ein aufgeräumter Zugang, ein automatisches Deployment, ein sinnvoller Alarm oder ein Runbook für den häufigsten Vorfall. Solche Schritte liefern schnellere Erkenntnisse als ein unklarer Plan für einen kompletten Relaunch.

Für die Softwareseite können Sie mit einer technischen Prüfung Ihrer Software beginnen. Wenn Betrieb, Zugänge, Updates und Monitoring im Vordergrund stehen, ist DevSecOps für bestehende Systeme der passendere Einstieg. Für eine gezielte Stabilisierung von gewachsenem Code eignet sich auch Code Rescue und Legacy-Code.

1. 01Bestand verstehenCode, Infrastruktur und Betriebsabläufe prüfen.
2. 02Risiken priorisierenGeschäftsauswirkung und Aufwand abwägen.
3. 03Gezielt verbessernKleine Änderungen umsetzen und prüfen.

Sie müssen nicht alles neu bauen. Sie müssen wissen, wo Sie anfangen sollten.

Technische Schulden lassen sich selten mit einem einzigen großen Relaunch lösen. Oft bringen gezielte Verbesserungen an Architektur, Deployment, Monitoring, Security oder Dokumentation deutlich mehr.

G Unit Solutions analysiert bestehende Software und Infrastruktur und hilft dabei, die Maßnahmen zu identifizieren, die technisch und wirtschaftlich wirklich sinnvoll sind.

Software · Infrastruktur · Betrieb