Fallanalyse und -lösung: SAP Abstürze, Oberfläche friert ein

Bereits vor ca. einem Jahr erreichte uns eine Anfrage eines Neukunden, bei welchem sich ein IT-Problem in Form von SAP-Abstürzen darstellte. Mehrere Abteilungen hatten das Problem, dass mehrfach pro Tag und Mitarbeiter die SAP-Oberfläche einfror. Die beteiligten Parteien für den Infrastruktur-, den Server- und den Anwendungsbetrieb wiesen jeweils die Verantwortung für die Problemursache von sich; es wurde darauf bestanden, dass der jeweils verantwortete Bereich einwandfrei funktioniere und nicht ursächlich sei.

Eine Regelmäßigkeit der auftretenden Probleme konnte hierbei nicht festgestellt werden, die Abstürze passierten für die Benutzer nicht zeitgleich, und auch die Häufigkeit konnte nicht mit festen Faktoren in Zusammenhang gebracht worden. „Gefühlt“ betraf es einige Mitarbeiter häufiger, andere seltener; die meisten Beschwerden kamen aus zwei Fachabteilungen.

Testgruppe von Anwendern

Nach der initialen Klärung der Zusammenarbeit, der Datenschutz- und Governance-Fragen, einschließlich Abstimmung der Maßnahmen mit dem Betriebsrat wurde zur Eingrenzung des Problem ein UX-Monitoring implementiert. Dieses misst die Performance der einzelnen Anwendungen nicht an rein technischen Parametern im Netzwerk, sondern anhand der tatsächlichen Erfahrung des Anwenders; UX steht hierbei für „User Experience“. Bei Programmfehlern, bzw. -abstürzen wird zudem die Ursache soweit wie möglich analysiert und dargestellt.

Es wurde eine Testgruppe von Anwendern zusammengestellt, welche die Programmabstürze häufig berichteten; diese Testgruppe wurde zwei festen RDS-Servern zugewiesen, welche dann wiederum unter direkte und konstante Beobachtung gestellt wurden. Neben der Verwendung des UX-Monitorings wurde parallel ein Netzwerk-Monitoring der relevanten Teil-Infrastruktur etabliert, um konkrete Problemfälle nachvollziehen zu können. Zudem wurden temporär Teile der Netzwerk-Kommunikation via Wireshark ausgezeichnet, um einen weiteren Anhaltspunkt zur Ursachenforschung zu haben.

Nach einigen Tagen wurden die gesammelten Daten ausgewertet. Hierbei zeigten sich immense Wartezeiten der Benutzeroberfläche, welche über die gesamte Arbeitszeit verteilt auftraten.

Ironischerweise verzeichnete das UX-Monitoring keinerlei relevante Programmabstürze innerhalb des aufgezeichneten Zeitraums, dementsprechend gab es weder Crash-Dumps noch sonstige Informationen. Dies stand jedoch im direkten Widerspruch zu den Aussagen der Anwender, welche im relevanten Zeitraum sehr wohl Programmabstürze erlebt hatten.

Ein anschließend konkret beleuchteter Einzelfall zeigte dann auf, wieso es hier zu unterschiedlicher Wahrnehmung kam: Zwar zeigte sich die SAP-Oberfläche als „eingefroren“, was auch bedeutet, dass das Programmfenster mit einem weißen Schleier belegt wird, und im Programmtitel der Zusatz „Keiner Rückmeldung“ erscheint; jedoch befand sich das Programm in einem Wartezustand und war somit keinesfalls abgestürzt, sondern lediglich „in Bereitschaft“, um die Arbeit fortzusetzen, sobald die Ursache für den Wartezustand beendet war.

Da der Windows-Prozessmonitor hierfür Netzwerk-Datenverkehr als Ursache benannte wurde der Fokus zunächst in diese Richtung gelenkt. Die Analyse des aufgezeichneten Netzwerkverkehrs konnte jedoch keine Hinweise auf abgerissene Verbindungen oder ausstehende Anforderungen geben; vielmehr schien die Aussage „wartet auf die Fertigstellung von Netzwerk-E/A“ falsch zu sein.

Zwei Auswege sind möglich

Letztendlich blieben für die Analyse der konkreten Ursache nur zwei Auswege: Eine Analyse der SAP-Umgebung, einschließlich der konkreten Entwicklung, die Erarbeitung und Erprobung von Test-Szenarien, sowie alle weiteren damit verbundenen Schritte wäre zwar der logische Schritt gewesen, versprach jedoch außer hohen Kosten und einem langwierigen Prozess nur geringe Erfolgsaussichten; der deutlich einfachere Schritt war das Anlegen eines Abbilds des Serverarbeitsspeicher und das nachvollziehen der Prozessketten.

Hierfür wurde im ersten Schritt eine Abbilddatei des betroffenen SAP-Prozesses in den Windows Debugger geladen; nach Laden der Standard-Windows-Symboldateien konnte der Prozess analysiert werden.

Als initiale „Halte“-Ursache wurde das Erreichen eines Haltepunkts im Programm benannt. Was zunächst nach einem Programmtechnischen Problem klingt, ist jedoch im gegebenen Zusammenhang nur logisch; durch das Erstellen eines Arbeitsspeicher-Abbildes wurde das Programm in eben diesen Zustand versetzt. (Schrödingers Katze)

Um die Ursache zu ergründen wurde der SAP-Prozess detailliert analysiert; es wurden die Aufrufketten und Prozessabhängigkeiten nachvollzogen, und alle Aufrufketten soweit nachverfolgt, bis der Arbeitsprozess isoliert werden konnte, auf den die weiteren Prozesse, insbesondere das eingefrorene Fenster wartet.

Als interessanter Nebenaspekt konnte festgestellt werden, dass die Software tatsächlich auf Netzwerkverkehr „wartete“, mittels einer offenen Verbindung, welche für die Kommunikation mit dem Server genutzt wurde. Dieser Prozess war jedoch nicht ursächlich für das Einfrieren des Programmfensters, sondern ein üblicher Standard in der Kommunikation von Anwendungen.

Nachdem die Prozessketten und Warteabhängigkeiten analysiert wurden, konnte ein einzelner Prozessverlauf isoliert werden, welcher für die Blockade verantwortlich war. Interessanterweise konnte jedoch innerhalb des Prozesses eine Drittanbieter-Implementierung gefunden werden, welche sich als tatsächliche Ursache darstellte. Hier hatte ein Programm, welches die Eingabe von Kennwörtern erleichtern soll (SSO-Agent) durch fehlerhafte Interaktion mit der SAP-Oberfläche eben jenen Wartezustand erzeugt, welcher für die eingefrorene Programmoberfläche verantwortlich war.

Gemeinsam mit dem Anbieter der Drittanbieter-Lösung wurde die für das Einfrieren von SAP ursächliche Konfiguration ermittelt und entsprechend angepasst, um das Problem final und an der Quelle zu lösen.