Robuste Softwarearchitekturen: 20 Stolperfallen für IT-Architekten

Unternehmenssoftware ist meist gekennzeichnet durch viele Schnittstellen und Systemkomponenten. Es müssen vorhandene Daten integriert und laufende Systeme der Nachbarabteilungen angebunden werden. Die Integration und der sichere Betrieb einer solchen Software, kann trotz SOA-Prinzipien, Design-Patterns und Qualitättssicherung, für jeden Projektleiter zur echten Herausforderung werden.

20 Stolperfallen auf dem Weg zum robusten IT-System:

1. Sicherheitsschotts und Drehzahlbegrenzer (Bulkhead):
   Schnittstellen ohne Volumenregulierung nehmen beliebig viele Anfragen entgegen. Systemteile fallen aus, die Betriebsstabilität ist gefährdet. Für jede wichtige Schnittstelle sollte ein Maximallast einstellbar sein.

1. Selbst- und Fremdzerstörung (Attacks of Self-Denial):
   Ein System wird von außen – zum Teil wider besseres Wissen – so missbraucht, dass die Stabilität beeinträchtigt ist.  Klassischerweise klickt ein User aufgrund schlechter Antwortzeiten hektisch auf dem Bildschirm und verschlimmert dadurch die Situation.
2. Kettenreaktion (Chain Reactions):
   Durch den Ausfall einer Komponente, eines Systemteils steigt die Wahrscheinlichkeit für den Ausfall anderer Komponenten, Systeme oder Teilsysteme. Hier muss möglichst unabhängig z.B. nach SOA-Prinzipien entwickelt werden.
3. Geblockte Threads (Blocked Threads):
   Alle großen Systeme benötigen parallel laufende Instanzen oder Threads. Die Situation bei 10.000 gleichzeitigen Anwendern etc. sind aber kaum vorher testbar. Hängende Anfragen blockieren nachfolgende Anfragen und führen zu Aufschaukeleffekten, bis das gesamte System steht.
4. Entkopplung durch Middleware (Decoupling Middleware):
   Entkopplung durch den Einsatz von Middleware heißt, die eigene Anwendung oder deren Komponenten so untereinander oder mit anderen Systemen zu verbinden, dass sie auch ohne Verfügbarkeit der anderen Systeme weiter arbeiten kann.
5. Skalierungseffekte (Scaling Effects):
   Anwendungen haben wegen der Dimensionsunterschiede von Test und Produktion oft kein genaues Verständnis dafür, wie gut sich im Systemverbund skalieren lässt. Aufrüstung von Server-Ressourcen führt dann eventuell zu keiner oder nur kleiner Performance-Verbesserung.
6. Schnittstellenfehler (Integration Points):
   Schnittstellen sind im Abhängigkeitsgeflecht einer Konzern-IT unvermeidlich. Jede Schnittstelle birgt aber auch ein Risiko für die IT-Stabilität.
7. Kaskadierende Fehler (Cascading Failures):
   Ein kaskadierendes Fehlverhalten liegt vor, wenn ein Fehler in einer Schicht eines Systems eine Fehlersituation in einer anderen Schicht (typischerweise ist dies die aufrufende Ebene) verursacht, der Fehler sich also über Schichten oder Systeme hinweg fortpflanzt.
8. Automatisierte Test-Frameworks (Test Harness):
   Neben den (vorausgesetzten) funktionalen Tests ist die Durchführung von Tests mit fehlerhaften Daten und unsinnigen Eingaben sowie Stresstests auf unterschiedliche Anwendungsteile wichtig, um deren Robustheit zu überprüfen. Dies lässt sich nur mit geeigneten Frameworks leisten.
9. Schutzschalter (Circuit Breaker):
   Der Schutzschalter (Begriff aus Elektrizität) ist ein Mechanismus, der Aufrufe auf essentielle Teilfunktionen unterlässt, solange dort ein Problem besteht, und dadurch die Auswirkungen entsprechender Fehler vermeidet. Mit dem Schutzschalter ist ein Algorithmus verknüpft, der den Schalter bei Bedarf schließt, aber auch automatisch wieder in zwei Teilschritten öffnet.
10. Schnelle Rückmeldung (Fail Fast) und Timeout:
    Anwender benötigen eine schnelle Rückmeldung, im Gut- wie im Schlechtfall. Auf Wartezeit und Sanduhr reagieren sie sonst problemverstärkend (Mehrfachklicks usw.). Notwendige Bedingungen für eine Transaktion sollten vorab geprüft werden und ggf. zu einer unmittelbaren Fehlermeldung führen.
11. Flaschenhals (Unbalanced Capacieties):
    Transaktionen, die aufeinanderfolgende Systeme durchlaufen, können einen Flaschenhals aufdecken, weil die jeweils verkrafteten Mengen in Systemketten nicht vollständig ausbalanciert werden können (z.B. erzeugt das Front End unter Spitzenlast mehr Transaktionen, als das Backend verkraften kann).
12. Definiertes Zustand (Steady State)
    „Steady Staet“ bedeutet, dass ein IT-System jederzeit in einem definierten Zustand sein sollte und zählt einige klassische Fehler in diesem Bereich auf, zu denen insbesondere unkontrollierte Veränderungen und mangelhafte Systembereinigung gehören.
13. Lange Antwortzeiten (Slow Responses):
    Lange Antwortzeiten können manchmal schlimmer sein als unmittelbare Fehler-Rückmeldungen, da ein Fehler den Vorgang sofort abbricht, während der langen Wartezeit jedoch die Ressourcen der beteiligten Systeme beansprucht werden. Dies gilt für die Ressourcen aller beteiligten Kommunikationspartner.
14. Unbegrenzte Ergebnismengen (Unbounded Result Sets):
    Die Abfrage von Datenmengen sollte immer unter Angabe von Begrenzungen stattfinden. Eine nicht begrenzte Ergebnismenge bei Datenbank-Abfragen kann zu Endlosschleifen oder Speicherüberlauf führen.
15. Definierter Handshake (Handshaking):
    Handshaking als IT-betriebliche Entwurfsmuster ist ein Verfahren, mit dem Partnersysteme gegenseitig ihr Lastaufkommen steuern können. Ein Serversystem kann durch Handshaking mit seinen Clients seinen eigenen Workload drosseln, wenn er Engpass-Situationen feststellt.
16. Standardisierte Logfiles (Logfiles):
    Jede Anwendung schreibt Logfiles, oft aber fehlen wichtige Informationen, die mit einfachen Handgriffen nachzurüsten wären, bzw. – wenn bereits in der Entwicklung berücksichtigt – die betriebliche Fehlersuche erheblich erleichtern würden.
17. Synthetische Transaktionen (Synthetic Transactions):
    Jede Anwendung sollte über den gesamten Online-Zeitraum mit Anfragen getestet werden, die möglichst weitgehend denen der Anwender entsprechen. Die Anwendung kann zu einem Zeitpunkt abstürzen, zu dem keine Anwender online sind – ohne synthetische Transaktionen wird der Absturz ggf. nicht bemerkt.
18. Transparenz bis zum Anwender (E2E Transparency):
    Entscheidend für die wahrgenommene Stabilität und IT-Qualität einer Anwendung ist nicht nur, dass alle Services laut Systemüberwachung verfügbar sind und die Gesamtauslastung im Rechenzentrum im grünen Bereich. Der Anwender sieht einzig und allein, was davon bei ihm auf dem PC ankommt und passiert.
19. Systemübergreifende Transparenz (Compound Transparency):
    Eine einzelne Anwendung kann – isoliert betrachtet – einwandfrei arbeiten. Im Systemverbund mit anderen Anwendungen in der Prozesskette kann sich das Gesamtverhalten ganz anders darstellen. Die Anwendungsverantwortlichen benötigen ein Bewusstsein dafür, dass sie Teil eines Ganzen sind.

Für jeden dieser Punkte gibt es Design- bzw. Vorgehensmuster. Denn Fehler bereits bei der Architekturplanung zu vermeiden ist deutlich günstiger, als im Nachhinein das System flicken zu müssen.