Was bedeutet eigentlich DevOps nach unserem Verständnis?

TL;DR: „Working together without being huge assholes to each other“ oder charmanter formuliert der Aufbruch vom Silodenken für einzelne Abteilungen, bessere Kommunikation zwischen Teams und ein iterativer Ansatz.

Wer die Geschichte zu diesem Zitat erfahren möchte oder die Historie von DevOps im Detail nachvollziehen möchte, kann hier weiterlesen.
Zu nächsten Frage gehts hier!

DevOps ist weder eine Jobbezeichnung noch ein Toolset! Um zu verstehen was es stattdessen ist, lohnt sich ein kurzer Blick in die Vergangenheit: Ursprünglich bedeutet es eigentlich „nur“ die Idee einer besseren Zusammenarbeit von Dev- und Ops-Teams.

Patrick Debois, Andrew Shafer und andere „Pinoniere der DevOps Bewegung“ benutzten ab 2007 agile Methoden aus der Softwareentwicklung um andere Bereiche der IT zu optimieren, ausgehend von der Fragestellung wie man IT Infrastruktur eigentlich agiler gestalten könnte.

„Working together without being huge assholes to eachother“ war die Premise mit der John Allspaw und Paul Hammond 2009 ihre Idee von guter Zusammenarbeit von Entwicklung und Betrieb bei flickr auf der Velocity Konferenz präsentierten. Das wiederum nahm Patrick Debois schließlich zum Anlass um die ersten offiziellen „DevOpsDays“ zu organisieren – der Rest ist Geschichte.

Heute ist DevOps aber weit mehr als das. Man braucht keine Entwicklungsabteilung um DevOps zu praktizieren – aus den Ursprungsgedanken ist eine Philosophie entstanden, welche generell für den Aufbruch von Silodenken, bessere Kommunikation zwischen Teams und letztlich einem iterativen Ansatz steht.

Welche Teilaspekte hat DevOps und welche davon gibt es vielleicht schon in ihrem Unternehmen?

TL;DR

Das ganze ist ein 3 stufiger Prozess:
1. Effizient und standardisiert Automatisieren
2. Effizient Feedback in 1. Stufe einarbeiten
3. Lern-, Fehler und Kommunikationskultur etablieren und fördern

Im Detail erläutern wir das nachstehend. Zur nächsten Frage gehts hier!

Ziemlich sicher kennen Sie die liegende DevOps 8 – die verdeutlichen soll, dass DevOps für einen fortwährenden Prozess steht. Unserer Meinung nach lassen sich die einzelnen Teilaspekte aber noch besser verstehen wenn man das System der „Three Ways“ [Entwickelt wurde das ganze von Gene Kim, Jez Humble, Patrick Debois und John Willis] betrachtet.

Der erste Weg

Der erste Weg beschreibt die Performance des Wertschöpfungsprozesses.
Klingt hochtrabend – bedeutet aber letztlich nur wie gut beispielweise die Pipeline ist, mit der neuer Code ausgerollt wird, oder mit der Inhouse Infrastrukur automatisiert wird.
Wichtige Faktoren sind hier feste Standards und effiziente Automatisierungsprozesse.

Der zweite Weg

Ein wichtiger Unterschied zum klassischen Wasserfallmodell ist das Einarbeiten und Verstärken von Feedbackschleifen in den ersten Weg. Für uns bedeutet das beispielsweise regelmäßige „orcharhino-Treffen“ von Consultants, Support, QA Abteilung und Engineering Team. Test- und direktes Kundenfeedback landet auf diese Weise sehr schnell direkt bei den Personen, die für die Umsetzung verantwortlich sind. Bugs können wir damit schon vor dem Release beheben (natürlich immer 😉) und neue Featurerequests unkompliziert einarbeiten.

Der dritte Weg

Um final dann beim dritten Weg und letztlich dem kompletten DevOps Prinzip anzukommen fehlt, noch der Bestandteil der DevOps Kultur. Zu den wichtigsten Teilaspekten zählen hier sicherlich gute Kommunikation, eine gute Fehlerkultur, eine funktionierende Lernkultur und natürlich ein gutes Teamgefüge.

Bei uns gehören unter anderem regelmäßige teamübergreifende Workshops zur Lernkultur, die gleichzeitig das Teamgefüge verstärken.
Beispielsweise entwickelte ein Team aus Consultants, interner IT und Entwicklungsabteilung eine Art Self-Service Portal für Server und Applikationen bei einem Cloud-Provider. Diese Portal benutzen wir nicht nur für unsere orcharhino Tests, sondern auch für das Deployment unserer Trainingslabs oder neue Kunden PoCs.

Von dieser Zusammenarbeit profitieren nicht nur alle beteiligten Teams und die ganze ATIX, sondern am Ende auch unsere Kunden.

Macht DevOps auch ohne Dev-Abteilung Sinn?

Klares ja! Aus den Ursprungsgedanken ist eine Philosophie entstanden, die generell für den Aufbruch von Silodenken, bessere Kommunikation zwischen Teams und letztlich einen iterativen Ansatz steht.

Und ATIX beherrscht DevOps?

So ist es – nicht nur leben wir inhouse DevOps tagtäglich. Aus vielen Kundenprojekten haben wir zusätzliche Erfahrungswerte für Do’s und Don’ts.

Was kann ATIX für Ihre bestehende oder geplante DevOps Kultur tun?

Wir helfen ihnen bei der Einführung einer kompletten DevOps Strategie, aber auch gerne bei Teilaspekten. Dabei entwickeln wir nicht nur Strategie, die zu Ihren Anforderungen passt, sondern helfen Ihnen auch bei der (projekt)technischen Umsetzung.

Für einen ersten unverbindlichen und vor allem kostenlosen Schritt können Sie über unser Kontaktformular unten eine DevOps Sprechstunde buchen.

Wie bekommen Sie eine kostenlose DevOps Sprechstunde mit unseren Experten?

Sie geben unten im Formular ihre Kontaktdaten ein – um alles andere kümmern wir uns dann.

Wir melden uns bei ihnen und vereinbaren einen Termin mit einem oder mehreren unserer Consultants.

Kontaktieren Sie uns gerne unverbindlich für eine kostenlose DevOps Sprechstunde. Wir melden uns bei Ihnen und gemeinsam besprechen wir für 1h
all Ihre konkreten DevOps Fragen. Wenn wir sie überzeugen können freuen wir uns
natürlich auch über eine längerfristige Zusammenarbeit.