Skip to content

Kein Produktionssystem ...

gedanken Was mich in meiner beruflichen Laufbahn als Systemadministrator immer am meisten gestört hat, war die Aufteilung der betreuten Systeme in Produktionssysteme nicht Nicht-Produktionssysteme.

Dabei war es meist so, dass die Produktionssysteme sofort Support bekommen und die anderen Systeme später, wobei später auch heissen konnte "Wenn jemand Lust hat, sich darum zu kümmern.".

Nahezu klassisch ist die Unterteilung in Entwicklungsmaschinen (DEV), Testsysteme (ET, IT), Abnahmesysteme (PT/A, UAT), Backupsysteme (BAK, BCP) und Produktionssysteme (PROD). Und das ist dann gleich auch die Reihenfolge, in der die Systeme betreut werden und - das ist der Grund für diesen Artikel - ich halte diese Reihenfolge für falsch.

Natürlich braucht man eine Unterteilung der Wichtigkeit, um eine Reihenfolge der Bearbeitung festzulegen.

Hier werden meistens Service Level Agreements (SLAs) benutzt, die genau bestimmen, innerhalb welcher Zeit welche Systeme betreut werden müssen oder - mal ganz platt - wer am meisten Geld bezahlt, bekommt den schnellsten Support. Leider werden auch diese SLAs so abgeschlossen, dass die oben angegebene Reihenfolge abgedeckt wird.

Unstrittig ist, dass die Produktions- und die Backupsysteme die höchste Aufmerksamkeit geniessen müssen, da sie meistens für das Kerngeschäft entscheidend sind und häufig auch direkt mit den Kunden zu tun haben, die man durch einen Ausfall vergraulen könnte. Das heisst, hier kann nicht nur finanzieller Schaden entstehen, hier kann auch der Ruf geschädigt werden (was indirekt wieder zu einem finanziellen Schaden führt).

Aber was kommt danach? Für mich persönlich kommen danach tatsächlich die DEV-Maschinen und die Testsysteme. Das sind nämlich Produktionssysteme für Entwickler und für Tester. Es ist relativ leicht auszurechnen, welcher Schaden entsteht, wenn eine komplette Entwicklungsabteilung Däumchen dreht und nur Geld kostet, dafür aber keine produktive Arbeit schafft. Gleiches gilt für Testsysteme und Tester, wobei hier meist in kleineren Umgebungen die Tester aus den Fachabteilungen kommen und auch noch produktive Arbeit zu leisten haben.

Eure Meinung?

Trackbacks

Keine Trackbacks

Kommentare

Ansicht der Kommentare: Linear | Verschachtelt

bruno am :

*Meine Meinung ist in dem Fall ganz schlicht und einfach Nein. ;-)
Und zwar nicht aus dem Grund, weil ich für meine Entwicklungs- und Testmaschine "schlechteren" Support der Admins möchte, sondern weil die Acceptance- und Integrationstestumgebungen "wichtiger" sind.
Zwei Szenarien:
1. Die Accpetanceumgebung wird genutzt um a) ein System vor Produktionseinführung vollumfänglich unter "Live" Bedingungen zu testen. Das kann eine in sich geschlossene Anwendung sein oder eine systemübergreifende "Durchgängigkeitsumgebung". Auf alle Fälle verlangen solche Umgebungen einen relativ grossen Vorbereitungs- und Installationsaufwand und sind zeitlich normalerweise in einem engen Terminkorsett. Die personellen Resourcen, die für Acceptancetests aufgeboten werden, sind i.d.R. auch erheblich (intern und ggf. extern).
2. (alleinstehend oder gemeinsam mit 1.)
Die Accpetanceumgebung dient, z.B. bei uns, als Supportumgebung. D.h. wir benötigen sie für den täglichen Support, da wir Problemfälle der User nicht im produktiven Betrieb nachstellen können, sie aber schnellstmöglich lösen müssen. Die produktiven SLA spielen da also auch mit rein.

Wenn meine DEV/TST-Umgebung down ist, ist das zwar nicht schön. Däumchen drehen tue ich deswegen aber keinesfalls (und ich wüsste auch keinen Entwickler, der effektiv nichts zu tun hat, wenn eine seiner Umgebungen mal down ist). Wenn aber die Acceptance weg ist und aktuelle zeitnahe Test- und Einführungstermine gefährdet sind, drehen etwas andere Kaliber als wir "kleinen" Entwickler langsam aber sicher im roten Bereich. Oder wenn unsere (Support-)Acceptance weg ist, dann sind wir effektiv eingeschränkt in unserer Leistungsfähigkeit und können ggf. einen Supportfall nicht so schnell lösen, wie es eigentlich möglich wäre. Und das kostet wieder reales Geld.

Dirk Deimeke am :

*Ok, einverstanden, das sind natürlich wichtige Punkte.

Wobei ich sagen muss, dass die Test- und Acceptance-Umgebungen, die ich kenne, nicht alle in der von Dir beschriebenen Weise verwendet werden.

bruno am :

*Ok, die Verwendung von Acceptancesystemen als Prodsupportumgebung ist sicher nicht usus. Aber die Acceptanceumgebung als (system- und programmtechnisch) produktivgleiches Integrationstestsystem sollte eigentlich der Standard sein. Darum geht es ja dabei, mit einer "fertigen" Anwendung (ggf. über mehrere Systeme/Applikationen) zu testen, Abnahmen durchzuführen und das möglichst mit einem realistischen Mengengerüst (sprich produktionsnahen Daten). D.h. da sind die Entwickler mit einbezogen, die Fachabteilungen (ggf. sogar die Revision) und (je nach Testfall) das Management.

Ich mein, ich habe auch gerne einen optimalen Support auf den Testsystemen, ok, nein, ich erwarte den optimalen Support auf allen Systemen ;-) Aber wir haben grössere Probleme, wenn die Acceptance nicht verfügbar ist, als wenn die Entwicklungsserver abrauschen. Daher sehe ich die Priorisierung schon:
Produktion->Acceptance->Entwicklung->Test.

Dirk Deimeke am :

*Ich kann die Gründe nachvollziehen!

Für andere sieht es vermutlich wieder anders aus.

Lars Fischer am :

*Also ich bin auch Entwickler und ich installiere und betreue in der Regel alle Entwicklungssysteme / Software selbst, manchmal sogar produktive Maschinen. Von einem kompetenten Admin träume ich manchmal schon, egal in welcher Reihenfolge die Systeme betreut werden :-)

Dirk Deimeke am :

*Die beschriebenen Verfahren kommen erst in mittleren bis grossen IT-Umgebungen zum Einsatz. Dort gibt es dann auch Spezialisten für die Administration.

Federico Hernandez am :

*Das die Systeme von Entwicklern deren Produktionssysteme sind, sehe ich auch so. Oft werden die jedoch (teilweise leider) von den Entwicklern selbst administriert.

Worauf ich immer wieder Hinweise ist aber, das auch die Abnahme- und Testsysteme so administriert werden sollten, wie auch Produktionssysteme. Das ist nicht immer der Fall. Auch die Systemadministrationsprozeduren auf den Produktionssystemen müssen abgenommen und getestet werden. Hier ist man aber oft schlampig und so wird nur auf die Funktion der Systeme geschaut.

Dirk Deimeke am :

*Das ist wahr, das habe ich häufig auch erlebt.

Je grösser die IT ist, desto näher sind die Prozesse aber so, wie sie sein sollten.

Lars Fischer am :

*Wobei ich vielen (hauptamtlichen) Administratoren oft helfen muss, da sie nicht in der Lage sind, Ihre Arbeit selbständig auszuführen. Es gibt eben insgesamt einfach zu viele maximal durchschnittliche Leute in der Informatik.

Dirk Deimeke am :

*Das liegt an der Definition des Wortes Durchschnitt ;-)

(Ich durfte auch schon oft genug Entwicklern helfen, das ist also nichts unnormales. Niemand kann alles wissen.)

Kommentar schreiben

Gravatar, Favatar, Pavatar, Identica, Twitter, MyBlogLog Autoren-Bilder werden unterstützt.
BBCode-Formatierung erlaubt
Umschließende Sterne heben ein Wort hervor (*wort*), per _wort_ kann ein Wort unterstrichen werden.
Standard-Text Smilies wie :-) und ;-) werden zu Bildern konvertiert.
Die angegebene E-Mail-Adresse wird nicht dargestellt, sondern nur für eventuelle Benachrichtigungen verwendet.
:'(  :-)  :-|  :-O  :-(  8-)  :-D  :-P  ;-) 
Formular-Optionen