Kein Produktionssystem ...
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?
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?
Kommentare
Ansicht der Kommentare: Linear | Verschachtelt
bruno am :
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 :
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 :
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 :
Für andere sieht es vermutlich wieder anders aus.
Lars Fischer am :
Dirk Deimeke am :
Federico Hernandez am :
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 :
Je grösser die IT ist, desto näher sind die Prozesse aber so, wie sie sein sollten.
Lars Fischer am :
Dirk Deimeke am :
(Ich durfte auch schon oft genug Entwicklern helfen, das ist also nichts unnormales. Niemand kann alles wissen.)