Was ist DevOps und was nicht?

Natürlich sagt Euch der Begriff DevOps was, oder? Auf diesem Blog sind nur Profis, IT-Veteranen, Geeks, Nerds oder kurzum die besten Leser der Welt unterwegs. Somit gehe ich also davon aus, dass ihr das Wort DevOps schon mal mehrfach gehört habt und es grob einordnen könnt. Für alle anderen (Herzlich Willkommen) trotzdem ein paar Worte zum Hintergrund. Der Ursprung dieses aus Development und Operations zusammengesetzten und dann gekürzten Hauptworts liegt in Belgien. Neben EU-Richtlinien und erträglichem Bier wurde der Begriff durch die DevOpsDay 2009 in Ghent, genauer Patrick Debois, geprägt. Seitdem gibt es eine wachsende Gruppe von „Hardcore-Hackern“, welche die DevOps Kultur in alle Welt tragen.
Mit dem Wort Kultur ist bereits auch ganz gut beschrieben, was DevOps ist bzw. sein könnte. Dem ein oder anderen Produktmanager und Business-Developer wird es jetzt eiskalt den Rücken runterlaufen. Kein Tool, kein Standard, keine Zertifizierung -> Da kann ich doch zum Quartalsende gar kein Lizenzbundle draus machen. Nun Freunde, ich arbeite lange genug in der IT um Tools dieser Art trotzdem vorauszusagen und vielleicht steht der Oracle DevOps Developer oder Borland DevOps Builder ja schon in den Startlöchern und wird zur nächsten CeBIT 2013 released.
Kommt schon Jungs!
Eigentlich, zumindest verstehe ich es so, ist DevOps nur der Versuch mit dem Kastendenken innerhalb der IT, aber auch innerhalb eines Teams aufzuräumen. Die Knackpunkte sind hier sowohl in der Zusammenarbeit, als auch in den grundsätzlichen Entscheidungsfindungsprozessen.
Das Hin-und-her zwischen Entwicklung und Betrieb ist nicht selten ein etablierter Bestandteil des täglichen Miteinanders in großen IT-Bereichen. Ob nun die Entwickler nicht sauber dokumentiert haben oder der Betrieb einfach nur unfähig ist, die Software zu installieren, lässt dabei meist nicht final klären, sicher ist nur das mehr Energie in Schuldzuweisungen verpufft, als in der Lösungssuche. Hat man vor einigen Jahren noch im Wasserfall-Prinzip und großen Iterationszyklen entwickelt, so geht es heute fast täglich heiß her. Die Anforderungen an eine schnelle und gute Zusammenarbeit zwischen Betrieb und Entwicklung sind daher elementar und vermutlich auch einer der Hauptgründe der DevOps-Bewegung. Konnte man sich früher nach einem unglücklichen Release noch einige Wochen in der Kantine aus dem Weg gehen, steht der Entwickler heute am nächsten Tag schon wieder vor der Tür und will einen Fix einspielen. An das „Schau mal, die Trottel von der Entwicklung“ kann ich mich übrigens noch wahrhaftig erinnern, jedoch ist es schon fast 15 Jahre her.
Diese Barriere zu brechen, und das ist wahrlich eine schwierige Herausforderung, wäre eine der größten Leistungen, die DevOps erbringen könnte. Und keine Angst, vielleicht sitzt man hier und dort schon nebeneinander, hat den Admin mit Ruby-Fähigkeiten ins Dev-Team integriert und installiert zusammen das neueste Release. Dann, auch wenn es nicht so genannt wird, seid ihr vielleicht schon Ultra-DevOps!
Was brauch ich und wie geht’s?
Wer bis zu diesem Absatz vorgedrungen ist, hat auf jeden Fall Geduld mitgebracht und vermutlich ist schon lange klar, dass die Frage nach dem „Was brauch ich und wie geht’s?“ nicht allgemein beantwortet werden kann. Neben der Bereitschaft, Fehler zu machen und den Möglichkeiten, diese auch schnell zu beheben, gibt es jedoch einige Tools, die es einfacher machen mit schnellen Releasezyklen, vielen Abhängigkeiten und utopischen Anforderungen aus dem Produktmanagement umzugehen. Dies fängt bei Continuous Integration mit bspw. Jenkins an. Nur nur durch permanente Qualitätskontrolle und Review der durchgeführten Änderungen können Fehler auch langfristig zurückverfolgt und im Idealfall vor dem Release identifiziert und beseitigt werden. Darauf aufbauend empfiehlt sich auf jeden Fall ein methodischer Prozess der automatischen Softwareverteilung und Installation mit Puppet, Chef oder CFEngine. Ein ordentlich beschriebener Konfigurationsprozess ist hinzu schon die halbe Doku. Das sind nur ein paar Beispiele und die Tools, die das Leben leichter machen, werden täglich mehr. Leider sind sie dank der Faulheit mancher Entwickler nur durch stundenlanges Rumsuchen auf GitHub zu finden. Arghh, jetzt kommen meine Operations-Wurzeln wieder durch.
Wenn ich es nicht überwachen kann, dann existiert es nicht!

Ein ganz wichtiger Teil der DevOps-Kultur ist aus meiner Sicht das Treffen von Entscheidung auf Basis von Messwerten. Ob die verwendeten Werte hierbei aus traditionellen Tools wie Icinga und Nagios oder neueren Trends wie collectd, logstash, Graylog oder später zur Darstellung Graphite kommen, spielt dafür keine Rolle. Entscheidend ist eben die Arbeit auf Basis von Fehlern, Erkenntnissen und Messwerten und nicht auf Basis von HIPPO*-Decisions.  Dies ist nicht immer einfach, und wenn ein Vorschlag mit der Antwort „Proof it“ in Frage gestellt wird, vielleicht auch aufwändig. Am Ende werden regelmäßige Iteration und der ehrliche Umgang miteinander jedoch fast automatisch zum besten Ergebnis führen. Und mal ehrlich, wenn wir ITler nicht in der Lage sind, unsere Entscheidungen auf Basis von Messwerten zu treffen, wer soll es sonst schaffen. Jeder Controller und Unternehmensprüfer, der wochenlang Zahlen aus Ordnern akribisch in Excel-Listen überführen muss, würde sich zwei Finger abhacken, wenn ihm alle Informationen digitalisiert zur Verfügung gestellt würden. Wir sind nur häufig einfach zu faul, was daraus zu machen. An den möglichen Stellen konfigurieren und tunen wir dann so lange ohne Zwischenmessung rum, bis es letztendlich besser läuft als am Anfang. Warum weiß dann eben auch keiner und die Reproduzierbarkeit ist fast unmöglich.
Um was geht es eigentlich?
Man sollte ja eigentlich glauben, dass „To-Be-Online“ die übergeordnete Motivation der täglichen Arbeit ist. Kurz also den oder die Services für interne und/oder externe Kunden zur Verfügung zu stellen und damit die Wertschöpfungskette aufrecht zu  erhalten. Kurz gesagt: Womit verdienen wir eigentlich unser Geld. Diese Betrachtung kommt ihm Dickicht der Schuldzuweisungen und bei heissen Diskussionen häufig zu kurz. Kann man seine internen Leitlinien jedoch dem Grundsatz „Service First“ unterstellen, verschwinden die unüberwindbaren Grenzen zwischen Development und Operations. Das gemeinsame Ziel der Verfügbarkeit macht es leichter und der ggf. notwendige Rollback geht zusammen mit dem zuständigen Developer mit Sicherheit leichter von der Hand. Die Verantwortung für das Produkt X motiviert dabei auch um Längen mehr, als die Bereitstellung eines WAR-Files in irgendeinem einem Tomcat oder JBoss.
Mein Fazit
Zusammengefasst ist DevOps für mich:

• Offenheit: Jeder, der kann, darf auch, aber bitte mit Hirn.
• Automatisierung: Voraussetzung für schnelle reproduzierbare Arbeit mit Korrekturmöglichkeit
• Entscheidungsklarheit: „Trial and Error“ und das auf  Basis von messbaren Informationen
• Produktsicht: Funktionsfähigkeit kommt vor technischen Unzulänglichkeiten

* Highest Paid Person Opinion (DANKE KRIS)
(Monitoring-Picture von Noah Sussmann)

Bernd Erk

CEO

---

Bernd ist Geschäftsführer der NETWAYS Gruppe und verantwortet die Strategie und das Tagesgeschäft. Bei NETWAYS kümmert er sich eigentlich um alles, was andere nicht machen wollen oder können (meistens eher wollen). Darüber hinaus startete er früher das wöchentliche Lexware-Backup, welches er nun endlich automatisiert hat. So investiert er seine ganze Energie in den Rest der Truppe und versucht für kollektives Glück zu sorgen. In seiner Freizeit macht er mit sinnlosen Ideen seine Frau verrückt und verbündet sich dafür mit seinen beiden Söhnen und seiner Tochter.

Lies mehr von Bernd und triff unser Team