DevOps aus Sicht eines Systemadministrators

Dieser Artikel gibt meine Privatmeinung wieder und nicht die der Firmen, in denen ich bisher gearbeitet habe und aktuell arbeite.

 

Als “klassischer Systemadministrator” – falls es in der heutigen Buzzword geschwängerten Zeit so etwas überhaupt noch gibt – habe ich in kleinen, mittleren und sehr grossen Umgebungen gearbeitet und im Rahmen meiner Berufskarriere einen Haufen an Titeln angehäuft (alle gerne mit einem “Senior” davor, sonst sind sie ja nichts wert): Systems Administrator, Systems Engineer, Technical Architect, Technical Solution Engineer.

 

“Klassische Systemadministration” zerfällt in wenigstens drei Rollen, die in mittelgrossen und grossen Unternehmen durch unterschiedliche Personen wahrgenommen werden, nämlich Architecture, Engineering und Operations.

 

Salopp gesprochen, malt Architecture “bunte Bilder”, Engineering macht einen Realitätscheck und überführt die Resultate in die Produktion zuletzt sorgt Operations für einen möglichst reibungslosen Betrieb. Schnittstellen existieren meist nur zwischen Operations und Engineering, sowie Engineering und Architecture.

 

In der “klassischen Administration” werden alle drei Rollen von einer Person bzw. einem Team übernommen und die zuvor genannten Schnittstellen entfallen.

Anmerkung: In Kleinstunternehmen übernehmen Systemadministratoren auch noch den Applikationsbetrieb inklusive Aktualisierungen.

 

Da die Anforderungen an Applikation und System aber sehr unterschiedlich sind, gibt es zwei Berufsfelder und sogar Lehrberufe, nämlich den Systemtechniker auf der einen und den Applikationsentwickler auf der anderen Seite.

 

Die vorrangigen Ziele von Systemtechnikern und Applikationsentwicklern beissen sich ein wenig. Während die einen Stabilität als Fokus haben, steht bei den anderen die Umsetzung neuer Features als erstes auf dem Programm. Das hat nicht zuletzt damit zu tun, dass Systemtechniker in der Regel nur mit anderen IT-Personen reden und Applikationsentwickler überwiegend mit Vertretern der Fachabteilungen. Dieser unterschiedliche Fokus, die unterschiedlichen Anforderungen und Kundenkreise führen im Dialog zu sehr vielen Missverständnissen.

 

Jetzt kommt mit DevOps eine neue Strömung, die vieles verändern und alles besser machen möchte. So wahnsinnig neu ist einiges davon nicht, allerdings hat es jetzt einen hübschen neuen Namen bekommen. Ich beleuchte das einmal aus Sicht des Administrators.

 

Was ist DevOps überhaupt?

Wie bei allen modernen Modethemen gibt es auch bei DevOps ein stark unterschiedliches Verständnis davon, was der Name bedeutet und wie DevOps definiert ist.

 

Hier einmal Beispiele dafür, wie unterschiedlich die Auffassung von DevOps sein kann.

 

Variante 1

DevOps beschreibt die Administration von Systemen mit den Methoden, die Entwickler benutzen (Versionskontrolle, gut kommentierte Konfigurationsdateien, …).

 

Das machen erfahrene Administratoren schon sehr lange (oder etwa nicht?).

 

Variante 2

DevOps ist “agiles Projektmanagement” (was auch immer darunter verstanden wird, Scrum? Kanboard? …). Systeme werden in Sprints weiterentwickelt.

Auch das passiert schon sehr lange. Systeme werden stetig weiterentwickelt und verbessert, Stichwort: Continous Improvement. Admins scheinen da ein Marketingproblem zu haben und die Entwickler erfinden oder benutzen die cooleren Begriffe.

 

Achtung bei Hype-Themen!

Jeder versteht etwas anderes unter dem Hype-Begriff und vieles lässt sich nicht in kleineren Unternehmen umsetzen. Methoden, die auf zehntausenden von gleichartigen Servern funktionieren, versagen eventuell in Unternehmen mit einigen zehn oder hundert Servern.

Nebenbei: Wie viele unterschiedliche Definitionen von Cloud kennt Ihr? Ich komme auf etwa sieben, inklusive der nicht ernst gemeinten Variante: C.l.o.u.d. steht für “Can’t locate our users data”.

 

Variante 3

DevOps ist “Infrastruktur als Code”.

 

Das ist neu und das erste Mal, dass ein neuer Begriff sinnvoll ist, diese Variante ist ein Bestandteil der DevOps-Bewegung. Mit Konfigurationsmanagementsystemen – Asible, CFEngine, Chef, Puppet, Sal

tStack, … – lassen sich Zielzustände von Servern beschreiben.

 

Variante 4

DevOps heisst Entwicklern Produktionsverantwortung (Betrieb) inklusive Zugriffsrechten zu geben.

 

Das tut Admins weh und rüttelt am Selbstverständnis, ist aber meiner Meinung nach der richtige Weg, zukünftig IT zu betreiben. Schwierig in dem Zusammenhang ist, dass viele Entwickler, das als Grundlage für eine Tirade gegen Admins nehmen (sie haben es nicht verstanden).

Zitat: “Jetzt haben wir Entwickler endlich Zugriff auf die Produktion, jetzt zeigen wir Euch, wo es lang geht und wie Agil funktioniert.”

Spannenderweise tut das auch Entwicklern weh, weil sie mit Themen konfrontiert werden, mit denen sie noch nie zu tun hatten, wie beispielsweise das Leisten von Bereitschaftsdiensten (Pikett). Da können sie von den Admins lernen und beginnen zu verstehen, warum viele Admins sehr oder vielleicht zu konservativ mit Veränderungen umgehen.

 

Variante 5 – die vermutlich richtige

“DevOps is agile IT delivery, required to match the cadence of agile IT development.

DevOps is a philosophy, not a method, or framework, or body of knowledge, or shudder vendor’s tool.

DevOps is the philosophy of unifying Development and Operations at the culture, practice, and tool levels, to achieve accelerated and more frequent deployment of changes to Production.”

Quelle: http://www.itskeptic.org/content/define-devops

 

Frei übersetzt:

“DevOps ist die agile Bereitstellung von IT-Diensten, die benötigt wird, um mit dem Rhythmus der agilen IT Entwicklung mitzuhalten.

DevOps ist eine Philosophie, und weder eine Methode noch ein Framework, eine Wissenssammlung oder schüttel irgendein Hilfsmittel von einer Firma.

DevOps ist die Philosophie, Entwicklung und Betrieb in Bezug auf Kultur, Praxis und Werkzeugen zu vereinen, um eine beschleunigte und häufigere Bereitstellung von Änderungen in der Produktion zu erreichen.”

 

Und, wie jeder Kultur- und Paradigmenwechsel, ist auch DevOps ein schmerzhafter Prozess.

 

Produktionseinführungen – Deployments

Um zu verstehen, warum DevOps wichtig ist, müssen wir einen Blick darauf werfen, wie Produktionseinführungen im klassischen Fall aussehen. Dabei kann man aufgrund unterschiedlicher Kulturen eine grundlegende Unterscheidung zwischen Europa und Amerika treffen. Mischformen sind relativ häufig anzutreffen.

 

Europa: Zurück auf “Los!”

Eine neue Software wird inklusive der Konfigurationen ausführlich getestet und dann zu einem vorher definierten Zeitpunkt in die Produktion übernommen. Wenn etwas schief geht, wird die Produktionsumgebung auf den Ursprungszustand zurückgedreht. In einem der kommenden Wartungsfenster wird ein neuer Versuch mit der dann hoffentlich fehlerfreien Version unternommen.

 

Amerika: “Zurück in die Zukunft”

Eine neue Software wird inklusive der Konfigurationen ausführlich getestet und dann zu einem vorher definierten Zeitpunkt in die Produktion übernommen.

Wenn etwas schief geht, wird innerhalb des zur Verfügung stehenden Zeitraumes versucht, die Software trotzdem in die Produktion zu übernehmen.

Am “Point of no return”, dem Zeitpunkt, zu dem noch ein Zurückrollen auf den Ursprungszustand möglich ist, ohne das Wartungsfenster zu verlassen, wird entschieden, ob weiter versucht wird, die Software zum Laufen zu bekommen oder die Produktionsumgebung auf den Ursprungszustand zurückgesetzt wird.

In einem der kommenden Wartungsfenster wird ein neuer Versuch mit der dann hoffentlich fehlerfreien Version unternommen.

 

Deploymentzyklus – Alt

Üblicherweise haben Applikationen eine sehr begrenzte Anzahl von Wartungsfenstern pro Jahr (häufig nur zwei).

Major releases, das sind die mit richtig vielen Änderungen, erscheinen nur einmal alle paar Jahre.

Grössere Releases enthalten meist einige zehn vielleicht sogar einige hundert Changes und erfüllte Feature Requests.

 

Die Wahrscheinlichkeit, dass etwas (richtig) schief geht, ist nicht zu unterschätzen.

 

Frage

Wenn Ihr Kunde wäret, würdet Ihr dann gerne ein oder mehrere Jahre darauf warten, dass Eure Wünsche umgesetzt werden?

 

Ich würde den Dienstleister wechseln.

(Wir wechseln ja sogar den Versandhändler, wenn er nicht von Heute auf Morgen liefert …).

 

Deploymentzyklus – Neu

Gelernt vom Open-Source-Mantra “Release early, release often”, versucht man nun auch kleinere Änderungen direkt in Produktion zu bringen.

Auch dort gibt es eine Wahrscheinlichkeit, dass etwas schief geht.

 

Aber sowohl das Zurückdrehen, wie auch vorwärts verändern bis es wieder funktioniert, ist wesentlich weniger komplex.

 

DevOps – New Culture

Mit einer neuen Kultur werden mehrfach täglich kleine Änderungen in die Produktion überführt. Fehler sind erlaubt und sollten schnellstmöglich bereinigt werden.

 

Wenn wir Admins entscheiden dürften …

… würden viele von uns ihre Server lieber täglich patchen als nur wenige Male im Jahr.

Das haben wir bis jetzt nie tun dürfen, weil aus verständlichen Gründen die Applikationsentwickler Zeit für Tests brauchen und unsere Systeme niedrigere Priorität bekommen haben als die neuen Features der Applikationen, die darauf laufen.

 

Mit DevOps bekommen auch wir eine Chance, relevante Patches schneller auf die Systeme zu bringen.

 

Rolling Releases?

Wenn das auch in die (Business-)Distributionen von Betriebssystemen einfliesst, bekommen wir Rolling Releases, einige Hersteller haben das mittlerweile verstanden.

Achtung: Der Begriff “Rolling Release” bietet auch einige Möglichkeiten für Missverständnisse.

Er bedeutet nicht, dass die aktuellste Betriebssoftware auf Systemen installiert wird, sondern dass kontinuierlich aktualisiert wird

 

Partnerschaft

Entwickler und Admins verstehen sich als Partner, um durch Technik dem Business Hilfsmittel an die Hand zu geben, mit dem sich die Geschäftsziele besser erreichen lassen und ein Mehrwert generiert wird.

 

Fazit

Kunden sind nicht (mehr) bereit zu warten bis ein Dienstleister in Monaten oder Jahren die Kundenwünsche umsetzt.

Die IT, bestehend aus Systemtechnikern und Applikationsentwicklern (oder -betreuern), muss schneller werden als sie es bisher war.

Eine Beschleunigung der Prozesse ist mit alten Verfahren nicht möglich, daher muss ein Wechsel der Kulturen her.

Systemtechniker können und werden genauso von Applikationsentwicklern lernen, wie umgekehrt.

 

Es gibt sehr viele Missverständnisse, ein Kulturwechsel könnte diese auflösen.