Transporte/Systemadministrator/Entwickler
5 Beiträge
•
Seite 1 von 1
5 Beiträge
Seite 1 von 1
Hallo miteinander,
können Transporte im laufenden Betrieb überhaupt nachhaltigen Schaden im System verursachen?
Wie sollte die Handhabung von Transporten organisiert sein?
4 Entwickler/Modulbetreuer, 2 Systemer (die auch das Netzwerk betreuen), ca. 120 User.
Derzeit haben wir das ohne größere Reglementierungen so geregelt, dass die Entwickler den Anteil der Objekte, die sich auf Auswertungen beschränken bzw. "isolierte" Eigenentwicklungen (also nicht Call Transaction, ohne Userexit etc.) betreffen, selbst transportieren - Updates (SAP-Hinweise etc.) werden von den Admins eingespielt. Die SAP-Erfahrung ist allgemein eher bei den Entwicklern etwas tiefer.
Ist das so OK oder sollte das anders geregelt sein?
Gruß
gabap
können Transporte im laufenden Betrieb überhaupt nachhaltigen Schaden im System verursachen?
Wie sollte die Handhabung von Transporten organisiert sein?
4 Entwickler/Modulbetreuer, 2 Systemer (die auch das Netzwerk betreuen), ca. 120 User.
Derzeit haben wir das ohne größere Reglementierungen so geregelt, dass die Entwickler den Anteil der Objekte, die sich auf Auswertungen beschränken bzw. "isolierte" Eigenentwicklungen (also nicht Call Transaction, ohne Userexit etc.) betreffen, selbst transportieren - Updates (SAP-Hinweise etc.) werden von den Admins eingespielt. Die SAP-Erfahrung ist allgemein eher bei den Entwicklern etwas tiefer.
Ist das so OK oder sollte das anders geregelt sein?
Gruß
gabap
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Also bei uns wird es so gehandhabt das Transporte prinzipiell nur durch die Systemadmins ausgeführt werden. Jeder Transportauftrag schriftlich (Mail) angefordert werden muss (gibt ansonsten mit der Revision Probleme)
Entwickler sollten nur in der Entwicklungs-Testumgebung aktiv sein ansonsten nirgendwo. Was sagt denn die IT-Prüfung/Revision zu euer Vorgehen ?
Gruß
Jürgen
Entwickler sollten nur in der Entwicklungs-Testumgebung aktiv sein ansonsten nirgendwo. Was sagt denn die IT-Prüfung/Revision zu euer Vorgehen ?
Gruß
Jürgen
Hi gabap,
nachhaltigen schaden können die Transporte natürlich anrichten, wenn sie nicht richtig getestet wurden. Aber dann ist es auch egal, wer die transportiert hat...
Zu Unmut bei den Anwendern können Transporte aber durchaus führen, wenn z.B. Änderungen an Userexits in der Auftragserfassung vorgenommen werden und die im laufenden Betrieb transportiert werden. Dann gibts nämlich kurzdumps: "Load_program_lost". Deswegen kenne ich die Regelung, dass ins Produktivsystem nur nach 18:00 oder 19:00 transportiert wird und auch der entsprechende Entwickler dann noch erreichbar sein muss, wenn nämlich was nicht funktioniert.
Man kann die Transporte natürlich auch morgens um 6:00 durchführen, aber dann sollte lieber auch jemand da sein... und es ist i.d.R. problematischer, früh da zu sein, als eine Stunde länger zu bleiben...
Bezügl. der Transportberechtigung dürfen meiner Erfahrung nach Entwickler so lange selbst transportieren, bis etwas passiert... Zb. dass sich Transporte überholen und dann im Produktivsystem Syntaxfehler auftauchen. Danach gibt's Formblätter und Transportberechtigungsentzug und es transportieren nur noch die Sysadmins nach Unterschrift des Modulverantwortlichen. Alles Quatsch, weil wenn Transporte sich überholen, merkt man das auch mit einem Formblatt nicht.
Es gibt von der Firma Realtech ein Transporttool das in der Chemie-Industrie wohl häufig eingesetzt wird, weil hier nicht nur Berechtigungen und Freigaben zu den Transporten online verwaltet werden können, sondern auch die Änderungen protokolliert werden können (Stichwort Revision). Zudem verhindert das Tool unter anderem, dass sich Transporte überholen (Einer der häufigsten und Folgeschwersten Fehler).
Gruß,
Enno
nachhaltigen schaden können die Transporte natürlich anrichten, wenn sie nicht richtig getestet wurden. Aber dann ist es auch egal, wer die transportiert hat...
Zu Unmut bei den Anwendern können Transporte aber durchaus führen, wenn z.B. Änderungen an Userexits in der Auftragserfassung vorgenommen werden und die im laufenden Betrieb transportiert werden. Dann gibts nämlich kurzdumps: "Load_program_lost". Deswegen kenne ich die Regelung, dass ins Produktivsystem nur nach 18:00 oder 19:00 transportiert wird und auch der entsprechende Entwickler dann noch erreichbar sein muss, wenn nämlich was nicht funktioniert.
Man kann die Transporte natürlich auch morgens um 6:00 durchführen, aber dann sollte lieber auch jemand da sein... und es ist i.d.R. problematischer, früh da zu sein, als eine Stunde länger zu bleiben...
Bezügl. der Transportberechtigung dürfen meiner Erfahrung nach Entwickler so lange selbst transportieren, bis etwas passiert... Zb. dass sich Transporte überholen und dann im Produktivsystem Syntaxfehler auftauchen. Danach gibt's Formblätter und Transportberechtigungsentzug und es transportieren nur noch die Sysadmins nach Unterschrift des Modulverantwortlichen. Alles Quatsch, weil wenn Transporte sich überholen, merkt man das auch mit einem Formblatt nicht.
Es gibt von der Firma Realtech ein Transporttool das in der Chemie-Industrie wohl häufig eingesetzt wird, weil hier nicht nur Berechtigungen und Freigaben zu den Transporten online verwaltet werden können, sondern auch die Änderungen protokolliert werden können (Stichwort Revision). Zudem verhindert das Tool unter anderem, dass sich Transporte überholen (Einer der häufigsten und Folgeschwersten Fehler).
Gruß,
Enno
Hallo Enno,
danke für die ausführliche Antwort.
Es liegt kein konkreter Fehlerfall vor - wie gesagt: Im Falle Userexits etc. geben die Entwickler schon im ureigensten Interesse die Sachen an die Admins zur Einplanung weiter.
Eine kundeneigene BDE läuft z.B. aber 24 Stunden im 3-Schichtbetrieb - da muss man halt in Gottes Namen "miteinander schwätzen" (das bringt eh viele Vorteile mit sich
). 
Mir geht es um ein effektives und harmonisches miteinander - dazu gehört natürlich auf beiden Seiten (Admin/Entwickler) ein gutes Stück Vertrauen.
Das hört wohl naturgemäß ab einer gewissen Unternehmensgrösse auf, da muss dann wohl nach Vorschrift x und Genehmigung y und Qualitätskontrolle z vorgegangen werden.
Aktueller Hintergrund für meinen Beitrag sind bei uns sporadisch auftauchende Performanceprobleme, bei denen sich allerdings in jüngster Vergangenheit konkretisiert, dass Eigenentwicklungen NICHT die Ursache sind.
Trotzdem taucht u.a. auch die Meinung auf, dass man die Sache mit den Transporten anders organisieren sollte blabla... - was nach meiner Meinung das Unternehmen nicht effizienter macht.
Gruß und schönen Abend
gabap
danke für die ausführliche Antwort.
Es liegt kein konkreter Fehlerfall vor - wie gesagt: Im Falle Userexits etc. geben die Entwickler schon im ureigensten Interesse die Sachen an die Admins zur Einplanung weiter.
Eine kundeneigene BDE läuft z.B. aber 24 Stunden im 3-Schichtbetrieb - da muss man halt in Gottes Namen "miteinander schwätzen" (das bringt eh viele Vorteile mit sich
). Mir geht es um ein effektives und harmonisches miteinander - dazu gehört natürlich auf beiden Seiten (Admin/Entwickler) ein gutes Stück Vertrauen.
Das hört wohl naturgemäß ab einer gewissen Unternehmensgrösse auf, da muss dann wohl nach Vorschrift x und Genehmigung y und Qualitätskontrolle z vorgegangen werden.
Aktueller Hintergrund für meinen Beitrag sind bei uns sporadisch auftauchende Performanceprobleme, bei denen sich allerdings in jüngster Vergangenheit konkretisiert, dass Eigenentwicklungen NICHT die Ursache sind.
Trotzdem taucht u.a. auch die Meinung auf, dass man die Sache mit den Transporten anders organisieren sollte blabla... - was nach meiner Meinung das Unternehmen nicht effizienter macht.
Gruß und schönen Abend
gabap
Seite 1 von 1
Vergleichbare Themen
0
Antw.
Antw.
2902
Views
Views
2
Antw.
Antw.
616
Views
Views
18
Antw.
Antw.
5695
Views
Views
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.