Releasewechsel R/3

Kunde: Maschinenfabrik
Zeitraum: 02.01.1998 bis 04.01.1998

Meine Aufgabe war der Releasewechsel eines R/3 Systems von Version 3.0E nach 3.1H. Der Releasewechsel erforderte eine minutiöse, ingenieurmäßige Planung, um erstens den Erfolg des Projektes zu gewährleisten und zweitens um Produktivdatenverlust zu vermeiden. Die Komplexität des Releasewechsels kommt u.a. davon, dass die systemtechnischen Modifikationen des Kunden mit den Modifikationen des Herstellers abgeglichen werden müssen. Wird dies nicht präzise durchgeführt, droht Datenverlust, der u.U. erst Tage nach dem Releasewechsel vom Kunden festgestellt wird.

Ein fehlerfreies R/3 System auf dem nächsten Release-Stand.

Vorbereitung
In Zusammenarbeit mit den Systemtechnikern des Kunden musste ein genaues Bild der Systemkonfiguration erarbeitet werden. Hardware Sizing überprüfen: ist die Hardwareausstattung und -konfiguration ausreichend? Wenn dies nicht erfolgt, kann es dazu kommen, dass der Kunde trotz erfolgreichem Releasewechsel seine Software nicht mehr produktiv einsetzen kann. Eingriff in das Betriebssystem: UNIX Kernelparameter-Änderungen, Neukompilieren des Betriebssystems, Austausch der Start/Stop Skripte und weiterer Hilfs- und Dienstprogramme (z.B. für Datenbank-Backup). Ablaufplan erstellen: Erfahrungswerte mit vorhergehenden Releasewechseln erlauben das Abschätzen der Laufzeiten der einzelnen Upgradephasen. Für den Releasewechsel des Produktivsystem stand nur ein relativ kleines Wartungsfenster zur Verfügung. Dies bedingte, dass der Upgrade auch nachts laufen musste. Der Ablaufplan definierte, wann ein manueller Eingriff zu erfolgen hatte. Filesystem für den Releasewechsel im Betriebssystem anlegen und konfigurieren. Installation der Hilfs- und Dienstprogramme für den Upgrade. Modifikation dieser Programme (patchen) gemäß aktuellen Hinweisen des Herstellers. Freiplatz in den UNIX Filesystemen und Freiplatz in dem Datenbanksystem prüfen gemäß Angaben des Herstellers. Gegebenenfalls Freiplatz schaffen durch Reorganisation bzw. Erweiterung des Datenbanksystems. R/3 System vorbereiten (z.B. mit dem Zielrelease inkompatible Daten aus dem Datenbanksystem löschen). Datenbanksystem umkonfigurieren / umparametrisieren. Sicherung des Betriebssystems (inklusive R/3 Kernel) und des Datenbanksystems. Spezielle Datenbank-Indizes erzeugen, um die Laufzeit des Releasewechsels zu verringern. System isolieren: Jobs ausplanen, System für Endanwender sperren. Datenbankbackup ausplanen. Deaktivieren der Systemüberwachungssoftware.
Durchführung
Upgrade des Datenbanksystems und anschließender Test des Gesamtsystems. Upgrade der R/3 Frontends auf den Arbeitsplätzen der Systemtechniker (die bei dem Upgrade unterstützen). Upgrade des R/3 Systems. Überwachen der einzelnen Phasen gemäß zuvor erstelltem Ablaufplan. Da immer wieder einzelne Phasen aufgrund von Softwarefehlern abbrachen, musste ich häufig eingreifen, d.h. die Fehlersituation analysieren (dazu stehen systemtechnische Logs und Traces zur Verfügung), die Fehler beheben und die Upgradeprozedur wiederanstarten. Der Ablaufplan musste dann immer entsprechend angepasst werden. Mitten im Upgrade musste ich (geplant) mittels der Transaktion SPDD die Tabellenstrukturen der vom Kunden modifizierten Tabellen mit den Modifikationen des Herstellers abgleichen.
Nachbereitung
Die Aktionen der Nachbereitungsphase sind so vielfältig, dass sie hier kaum umfassend dargestellt werden können. Ich führe nur einige Beispiele an: Durchsicht aller Systemprotokolle (Logs, Traces) mithilfe von Hilfs- und Dienstprogrammen des Betriebssystems und des Herstellers. Reaktivieren/Reorganisieren der Systemüberwachungssoftware. Systemstatistiken im Datenbanksystem neu generieren. R/3 Kernel patchen, Supportpackages einspielen. Software-Transportmanagement-System einrichten, Abgleich der modifizierten ABAP Objekte.
Test
In Zusammenarbeit mit dem Kunden testete ich wichtige Systemtransaktionen, um sicherzustellen, dass die Basis des Systems ordnungsgemäß funktionierte.
Wiederaufnahme des Betriebs
Öffnen des Systems. Einplanen der Jobs. Aktivierung der regelmäßigen Datenbanksicherung. Übergabe an die Systemtechniker.

Informationstechnologie, SUN SOLARIS, SAP Datenbanksystem, Architektur von R/3, Prozessablauf eines R/3 Releasewechsels und die damit verbundenen Hilfs- und Dienstprogramme.

Von 1998 bis 2004 habe ich ca. 20 Releasewechsel dieser Art geplant und durchgeführt.