Dirks Logbuch

Nach dem gestrigen Jobangebot bin ich auf Google+ gefragt worden, was denn eigentlich System Engineering sei. Was ich unter Senior verstehe, habe ich in diesem Posting versucht zu verdeutlichen. Hier folgt nun die Einordnung von System Engineering in die wunderbare Welt der Systemtechnik oder Systemintegration

Zunächst eine Begriffsklärung und Unterscheidung:

System Administrators (SA) sorgen für den Betrieb von Systemen und System Engineers (SE) implementieren Lösungen und erstellen Betriebs- und andere Konzepte. Die Grenzen sind fliessend.

Gerade weil die Grenzen fliessend sind, kann es sein, dass die Ausprägung je nach Unternehmen unterschiedlich ist. Häufig ist es so, dass System Administrators 1st- oder 2nd-Level-Support leisten und System Engineers als Stufe dahinter 2nd- bzw. 3rd-Level-Support bieten.

Neue Ansätze - wie beispielsweise DevOps - sorgen für eine Neuausrichtung und ein neues Rollenkonzept. Da ist gerade einiges in Bewegung, auch die generelle Unterscheidung zwischen "Systembetrieb" (oder Systemtechnik oder Systemintegration) und "Anwendungsentwicklung" ändert sich. (Amazon, Facebook und Google machen das vor und das, was sie herausfinden, "tröpfelt" auch in kleinere Umgebungen.) Wer in kleinen Umgebungen arbeitet, bekommt von diesen Konzepten nichts mit, da gibt es zumeist "Mädchen für alles" und keine weitere Unterscheidung.

Projekt

In der Regel ist der Startpunkt für neue Installationen oder Umgebungen ein Kundenauftrag, eine strategische Entscheidung oder schlicht der Wunsch nach etwas Neuem. Das wird im Normalfall durch ein Projekt abgebildet.

Ich werde im Folgenden die englischen Fachbegriffe verwenden und mich nur auf den "für uns" relevanten Teil stürzen. Was Projekte sind und wie diese verwaltet werden, können andere Personen besser beschreiben.

In einer ersten Phase setzt sich ein Architekturteam an die Arbeit und beschreibt die Lösung auf zwei Ebenen, die für uns relevant sind: Ein Gesamtbild - "Big picture" - der Lösung und eine Infrastruktur-Sicht (da finden wir uns wieder). Es ist hilfreich, das grosse Bild zu kennen, um Entscheidungen zu verstehen. Beteiligt sind "Solution Design" bzw. "Solution Architecture" und "Infrastructure Design" bzw. "Infrastructure Architecture".

In der nächsten Phase kümmern sich "Technical Architects" (bei T-Systems heissen die "Technical Solution Engineers") um die Umsetzung der Ideen. Es wird ein konzeptionelles Bild auf Ebene der jeweiligen Technologie in den Feldern System (<- wir), Database, Middleware, Software und Infrastructure gebaut und ein "Proof of concept" entwickelt. Damit wird grundlegend gezeigt, dass die Bilder, die die Architekten malen auch tatsächlich umsetzbar sind.

Jetzt kommen wir:

Wir bauen Testsysteme und erstellen Operating System Builds, die später betrieben werden können. Diese Builds werden auch benutzt, um Systemseitig Patches und Upgrades zu testen. Sinn dahinter ist, den Aufbau eines Systems nachverfolgbar und wiederholbar zu halten, sowie die Grössenordnung der verwendeten Systeme sicher zu stellen.

Der Aufbau von Werkzeugkästen, die den Administratoren später im Betrieb nützlich sind, gehört ebenfalls zu unseren Aufgaben und in manchen Umgebungen werden diese Hilfssysteme (als Beispiele Imageserver und Konfigurationsmanagementsysteme wie Puppet oder Chef) sogar vom Engineering betrieben.

Dieses Engineering (gibt es dafür eigentlich ein sinnvolles deutsches Wort) passiert wie die technische Architektur in den gleichen Feldern: System, Database, Middleware, Software und Infrastructure.

Der für viele unangenehme Teil der Arbeit ist das Schreiben von Betriebskonzepten, häufig in englischer Sprache, und Betriebshandbücher. Und auch die weitergehende Pflege dieser Dokumentation.

Am Ende der Projektphase werden die Systeme dem Betrieb übergeben und von "Betrieblern" verwaltet.

Betrieb

Als Beispiel für den Betrieb nehme ich einmal den "Lebenslauf eines Systems".

Als allererstes müssen die Systeme gekauft werden. In grösseren Umgebungen sorgt eine Einkaufsabteilung (Purchase department) dafür.

Eine Provisionierungs-Abteilung (= Aufbau der Geräte nach Vorgaben des Engineerings) baut die Systeme auf, montiert Sie ins Rack, verkabelt sie, installiert das Basissystem, konfiguriert das Netzwerk und bindet sie ans LDAP (oder Active Directory oder NIS oder ...) an.

Anschliessend passiert das "Customizing" bzw. die Anpassung an die spezifische Aufgabe. Das wird in machen Firmen durch das Engineering erledigt, im Normalfall (die Vorgaben sind ja dokumentiert) durch das Provisioning und später im Betrieb explizit durch die System Administratoren bzw. das Operation Team.

System Administration bzw. Operation ist verantwortlich für den kompletten Betrieb des Servers und leistet 1st Level Support. Das sind insbesondere die drei Felder Incident Management, Problem Management und Change Management.

Zum Ende der Lebenszeit der Systeme werden diese durch ein (end-of-life-Provisioning-Team) heruntergefahren, ausgebaut und entsorgt.

Im Betrieb gibt es natürlich auch eine Schnittstelle zum Engineering und (fast noch wichtiger) eine Feedback-Schleife. Engineering-Teams leisten häufig 2nd Level Support und helfen weiter, wenn der 1st Level an seine Grenzen gekommen ist. Neben Incident Management wird vor allem beim Problem Management (oder bei Taskforces) unterstützt.

Das, was dort herausgefunden wird, fliesst wieder in die weiter oben angeführten Builds ein und auch in die Architektur. Mit dem, was im Betrieb funktioniert (oder auch nicht) müssen Produkte und Designs angepast werden.

Nur aus Gründen der Komplettheit sei erwähnt, das der Hersteller meistens den 3rd Level besetzt und die Sachen, die dort gefunden werden natürlich auch Einfluss auf Betrieb, Engineering, Architecture und Design haben.

Wenn Ihr Euch tiefer in das Thema einarbeiten wollt, ist ITIL das passende Stichwort dazu. ITIL beinhaltet eine Serie an bewährten Verfahren, die man im IT Service Management verwenden kann. ITIL Wissen zu haben, schadet niemandem, der in der IT arbeitet. Viele Arbeitgeber fordern das sogar ein.

Das gibt meine Meinung und meine Erfahrungen wieder. Wie immer sind Euer Feedback und Eure Rückfragen herzlich Willkommen.