Was zum Teufel ist DevOps?

Eine kurze Geschichte der Zeit

Um DevOps zu verstehen, müssen wir in die alte Zeit zurückreisen, als es nur noch Programmierer gab.

Wie uns das Tao lehrt:

Die alten Programmierer waren mysteriös und tiefgründig. Wir können ihre Gedanken nicht ergründen, also beschreiben wir nur ihr Aussehen:

• Bewusst, wie ein Fuchs, der das Wasser überquert
• Wach wie ein General auf dem Schlachtfeld
• Freundlich, wie eine Gastgeberin ihre Gäste begrüßt
• Einfach, wie ungeschnitzte Holzklötze
• Undurchsichtig, wie schwarze Tümpel in dunklen Höhlen

Der Programmierer brachte die Maschinensprache hervor. Die Maschinensprache brachte den Assembler hervor. Der Assembler brachte den Compiler hervor. Jetzt gibt es Tausende von Sprachen. Jede Sprache hat ihren Zweck, wie bescheiden sie auch sein mag. Jede Sprache drückt das Yin und Yang der Software aus. Jede Sprache hat ihren Platz innerhalb der Software.

Damals hießen Softwareentwicklungsbüros meist Labors und Programmierer waren Wissenschaftler. Um eine gute Anwendung zu erstellen, mussten Programmierer das Problem, das die Anwendung löste, vollständig verstehen. Sie mussten wissen, wo die Anwendung verwendet wird und auf welchem ​​System sie ausgeführt wird. Im Wesentlichen wussten Programmierer alles über ihre Anwendung, von der Spezifikation über die Entwicklung bis hin zur Bereitstellung und zum Support.

Und dann kam die menschliche Natur ins Spiel und wir fingen an, nach mehr zu fragen. Mehr Geschwindigkeit, mehr Funktionen, mehr Benutzer, mehr von allem.

Als bescheidene, demütige und friedliche Kreaturen hatten Programmierer nur sehr geringe Chancen, eine solche Flut bedürftiger Benutzer zu überleben, die immer nach mehr verlangten. Die beste Chance, sich durchzusetzen, bestand darin, sich in verschiedene Richtungen zu entwickeln und Kasten zu schaffen. Bald starben Programmierer als Vorfahren neuer Rassen namens Entwickler, Softwareingenieure, Netzwerkadministratoren, Datenbankentwickler, Webentwickler, Systemarchitekten, QA-Ingenieure und viele mehr aus. Sich schnell zu entwickeln und sich an Herausforderungen der Außenwelt anzupassen, wurde Teil ihrer DNA. Eine neue Kaste könnte sich innerhalb weniger Wochen entwickeln. Aus Webentwicklern wurden Backend-Entwickler, Frontend-Entwickler, PHP-Entwickler, Ruby-Entwickler, Angular-Entwickler … es ging alles zur Hölle.

Bald vergaßen sie alle, dass sie vom selben Vater, einem Programmierer, stammten. Ein einfacher und friedlicher Wissenschaftler, der die Welt nur zu einem besseren Ort machen wollte. Sie begannen gegeneinander zu kämpfen und behaupteten, dass jeder von ihnen ein echter Nachkomme von „The Programmer“ sei und dass ihr Blut reiner sei als das anderer.

Mit der Zeit reduzierten sie ihre Interaktion auf ein Minimum und sprachen nur noch miteinander, wenn es wirklich nötig war. Sie hörten auf, die Erfolge ihrer entfernten Familienmitglieder zu feiern, und hörten schließlich auf, hin und wieder eine Postkarte zu schicken.

Wenn sie nur ihre Gefühle erforschen würden, würden sie entdecken, dass der Funke des Programmierers in ihren Herzen war und darauf wartete, zu leuchten und der Galaxie Frieden zu bringen.

In ihrem selbstsüchtigen und egozentrischen Rennen um die Eroberung der Welt vergaßen die Nachkommen der Programmierer den eigentlichen Zweck ihrer Arbeit – das Lösen von Problemen für ihre Kunden. Kunden begannen, den Schmerz eines solchen Verhaltens zu spüren, wenn Projekte verzögert, zu teuer oder sogar gescheitert wurden.

Hin und wieder leuchtete ein heller Stern und jemand bekam eine Inspiration, um zu versuchen, Frieden zwischen den Nachkommen zu schließen. Sie kamen mit Wasserfall. Dies war eine brillante Idee, da sie die Tatsache nutzte, dass verschiedene Gruppen von Entwicklern nur bei Bedarf kommunizierten. Wenn eine Gruppe ihren Teil der Arbeit beendet hatte, kommunizierte sie mit der nächsten Gruppe, um die Arbeit durch den Prozess zu schicken, und blickte nie darauf zurück.

Dies funktionierte eine Weile, aber wie immer wollten die Menschen (Kunden) wieder mehr. Sie wollten aktiver am gesamten Prozess der Softwareerstellung teilnehmen, häufiger ihre Meinung äußern und auch dann noch Änderungen einfordern, wenn es zu spät ist.

Softwareprojekte wurden so fehleranfällig, dass sie als Industriestandard akzeptiert wurden. Statistiken zeigten, dass über 50 % der Projekte scheiterten, und es scheint, als wäre nichts dagegen zu tun (ZDNet, CNet)

Jede Generation hatte einige aufgeschlossene Personen, die wussten, dass all diese Gruppen von Entwicklern einen Weg finden müssen, zusammenzuarbeiten, zu kommunizieren und flexibel zu sein, um sicherzustellen, dass ihre Kunden die bestmögliche Lösung erhalten. Bereits 1957 gibt es Spuren dieser Versuche von Kollegen des großen John von Neumann. Wir mussten jedoch bis Anfang 2001 warten, um die Revolution zu starten, als ein schmutziges Dutzend ein agiles Manifest erstellte.

Das Agile Manifest basiert auf zwölf Prinzipien:

1. Kundenzufriedenheit durch frühzeitige und kontinuierliche Lieferung wertvoller Software
2. Begrüßen Sie sich ändernde Anforderungen, auch in der späten Entwicklungsphase
3. Funktionierende Software wird häufig geliefert (Wochen statt Monate)
4. Enge, tägliche Zusammenarbeit zwischen Geschäftsleuten und Entwicklern
5. Projekte bauen auf motivierte Personen auf, denen man vertrauen sollte
6. Das persönliche Gespräch ist die beste Form der Kommunikation (Co-Location)
7. Funktionierende Software ist das wichtigste Maß für den Fortschritt
8. Nachhaltige Entwicklung, die in der Lage ist, ein konstantes Tempo beizubehalten
9. Kontinuierliche Aufmerksamkeit für technische Exzellenz und gutes Design
10. Einfachheit – die Kunst, die Menge an nicht erledigter Arbeit zu maximieren – ist entscheidend
11. Selbstorganisierende Teams
12. Regelmäßige Anpassung an sich ändernde Umstände

Das agile Manifest war der erste große Schritt, um Frieden in die Galaxis zu bringen und das Gleichgewicht der Macht wiederherzustellen. Zum ersten Mal seit sehr langer Zeit basierte die Verbindung aller Beteiligten im Softwareentwicklungsprozess sowohl auf kultureller und „menschlicher“ als auch auf prozeduraler und mechanisierter Weise. Die Leute fingen an, miteinander zu reden, sich regelmäßig zu treffen und ständig Ideen und Kommentare auszutauschen. Sie erkannten, dass sie viel mehr gemeinsam haben, als sie dachten, und Kunden wurden Teil des Teams, nicht nur ein externer Faktor, von dem erwartet wurde, dass er das Geld schickt und keine Fragen stellt.

Es gab noch einige Hürden zu überwinden, aber die Zukunft schien rosiger denn je. Agil zu sein bedeutet, offen und bereit zu sein, sich ständigen Veränderungen anzupassen. Bei allzu vielen Änderungen ist es jedoch schwierig, sich auf das endgültige Ziel und die Umsetzung zu konzentrieren. Und so entstand Lean Software Development.

Süchtig nach LSD (Wortspiel beabsichtigt) und dem Risiko ausgesetzt, verbannt und ausgestoßen zu werden, suchten einige der Nachkommen nach Lösungen außerhalb ihrer Kaste und der Softwareindustrie. Die Rettung fanden sie in den Werken eines großen Autoherstellers. Das Toyota-Produktionssystem war in seiner Einfachheit erstaunlich und es war so offensichtlich, dass seine schlanke Fertigung problemlos auf die Softwareentwicklung angewendet werden kann.

Es gibt 7 Lean-Prinzipien:

1. Abfall beseitigen
2. Bauen Sie Qualität ein
3. Wissen schaffen (Lernen verstärken)
4. Verpflichtung aufschieben (So spät wie möglich entscheiden)
5. So schnell wie möglich liefern
6. Menschen respektieren (Team stärken)
7. Das Ganze optimieren

Zusätzlich zu Agile unterstützten Lean-Prinzipien die Mentalität und den Fokus darauf, die richtigen Dinge zu tun und gleichzeitig während des gesamten Prozesses flexibel zu sein.

Nachdem Agile und Lean von den Softwareentwicklungsteams übernommen wurden, war nur noch ein weiterer Schritt erforderlich, um alle Prinzipien auf die IT als Ganzes anzuwenden – was uns schließlich zu DevOps brachte!

Geben Sie DevOps ein - dreispurige Autobahn

Die Old-School-Ansicht von Softwareentwicklungsteams umfasste Business-Analysten, Systemarchitekten, Front-End-Entwickler, Back-End-Entwickler, Tester und so weiter. Die Optimierung des Softwareentwicklungsprozesses, einschließlich agiler und schlanker Prinzipien, konzentrierte sich hauptsächlich auf diese. Sobald die Anwendung „produktionsbereit“ war, wurde sie an „Operations“ einschließlich Systemingenieuren, Release-Ingenieuren, DBAs, Netzwerktechnikern, Sicherheitsexperten usw. weitergeleitet. Die Beseitigung der großen Mauer zwischen Dev und Ops ist die Hauptantriebskraft von DevOps .

DevOps ist das Ergebnis der Implementierung von Lean-Prinzipien im gesamten IT-Wertstrom. Der IT-Wertstrom erweitert die Entwicklung in die Produktion und kombiniert alle „entfernten Verwandten“, die vom ursprünglichen Programmierer abstammen.

Die beste Erklärung für DevOps-Lösungen wird von Gene Kim gegeben, und wenn Sie The Phoenix Project noch nicht gelesen haben, schlage ich vor, dass Sie sich etwas Zeit nehmen und es tun.

Sie sollten keinen DevOps-Ingenieur einstellen und DevOps sollte keine neue Abteilung in Ihrer IT sein. DevOps ist eine Kultur, Denkweise und Teil der IT als Ganzes. Es gibt keine Tools, die Ihre IT zu einer DevOps-Organisation machen, und kein Grad an Automatisierung wird Ihre Teams in die Lage versetzen, Ihren Kunden maximalen Nutzen zu bieten.

DevOps wird normalerweise als Methode der drei Wege bezeichnet, aber ich sehe sie als drei Spuren derselben Autobahn. Du beginnst auf Spur eins, dann beschleunigst du und wechselst auf Spur zwei, und schließlich rast du auf der dritten Spur vorbei.

• Spur eins – Die Leistung des Systems als Ganzes steht im Mittelpunkt und wird über die Leistung jedes einzelnen Elements des Systems gestellt

• Bahn zwei – Stellen Sie sicher, dass eine konstante Rückkopplungsschleife stromaufwärts gesendet und nicht ignoriert wird

• Spur drei – Experimente fördern, ständig verbessern und schnell scheitern

Spur eins - Auf die Geschwindigkeit kommen

Das Verständnis der Bedeutung des gesamten Systems und die richtige Priorisierung von Arbeitselementen ist das erste, was eine IT-Organisation lernen muss, wenn sie DevOps-Prinzipien anwendet. Niemand im IT-Wertstrom darf einen Engpass schaffen und den Arbeitsfluss reduzieren.

Die Sicherstellung eines unterbrechungsfreien Arbeitsablaufs ist das ultimative Ziel für alle am Prozess Beteiligten. Unabhängig von der Rolle, die eine Person oder ein Team hat, ist es unerlässlich, dass sie versuchen, ein tiefes Verständnis des Systems zu erlangen. Diese Denkweise wirkt sich direkt auf die Qualität aus, da Fehler nie auf der Strecke bleiben, weil sie Engpässe verursachen würden.

Sicherzustellen, dass die Arbeit nicht ins Stocken gerät, reicht nicht aus. Eine produktive Organisation sollte immer versuchen, den Fluss zu erhöhen. Es gibt zahlreiche Methoden, um den Fluss zu erhöhen. Sie können eine Lösung in Theory Of Constraints, Six Sigma, Lean oder Toyota Production System finden. Fühlen Sie sich frei, eine davon auszuwählen, sich Ihre eigenen auszudenken oder sie zu kombinieren.

Den DevOps-Prinzipien ist es egal, zu welchem ​​Team Sie gehören, ob Sie Systemarchitekt, DBA, QA oder Netzwerkadministrator sind. Für alle gelten die gleichen Regeln, und von jedem wird erwartet, dass er zwei einfache Prinzipien befolgt:

• Halten Sie den Systemfluss ununterbrochen
• Erhöhen und optimieren Sie den Workflow jederzeit

Bahn zwei – Gang hoch

Der ununterbrochene Systemfluss ist unidirektional, und es wird erwartet, dass er von der Entwicklung bis zum Betrieb reicht. In einer idealen Welt bedeutet dies, dass Software schnell mit hoher Qualität erstellt, in der Produktion bereitgestellt und den Kunden einen Mehrwert bietet.

DevOps ist jedoch keine Utopie, und wenn eine unidirektionale Bereitstellung möglich wäre, würde die Wasserfallmethode ausreichen. Die Bewertung der Ergebnisse und die Kommunikation nach oben ist sehr wichtig, um die Qualität zu gewährleisten. Der erste „Upstream“-Kommunikationskanal, der implementiert werden muss, ist Ops to Dev.

Sich selbst ein High-Five zu geben ist einfach, aber um Feedback zu bitten und Feedback zu geben, ist der Weg, das wahre Bild zu sehen. Es ist zwingend erforderlich, dass auf jeden kleinen Schritt stromabwärts eine sofortige Bestätigung stromaufwärts folgt.

Es spielt keine Rolle, wie Sie die Rückkopplungsschleife aufbauen. Sie können Entwickler zu Support-Team-Meetings einladen oder den Netzwerkadministrator zur wöchentlichen Sprint-Planung hinzuziehen. Solange Ihr Feedback vorhanden ist und Kommentare aufgenommen und bearbeitet werden, rast Ihr Unternehmen auf der DevOps-Autobahn.

Bahn drei – Warp 10

Die DevOps-Überholspur ist nichts für schwache Nerven. Um auf die DevOps-Überholspur zu kommen, muss Ihre Organisation reif genug sein. Es geht darum, Risiken einzugehen und aus Fehlern zu lernen, ständig zu experimentieren und zu akzeptieren, dass Wiederholung und Übung die Voraussetzung für die Meisterschaft sind. Sehr oft hört man den Begriff Kata, und das aus gutem Grund. Kontinuierliches Training und Wiederholung führen zur Beherrschung, da komplexe Bewegungen zur Routine werden.

Aber bevor Sie anfangen, Bewegungen zu kombinieren, ist es unerlässlich, dass Sie zuerst jeden einzelnen Schritt beherrschen.

„Was für den Meister angemessen ist, ist für den Novizen nicht angemessen. Sie müssen das Tao verstehen, bevor Sie die Struktur transzendieren.“

DevOps Third Way/Fast Lane beinhalten die Zuweisung von Zeit für kontinuierliches Experimentieren auf täglicher Basis, die ständige Belohnung des Teams für das Eingehen von Risiken und das Einführen von Fehlern in das System, um die Widerstandsfähigkeit zu erhöhen.

Um sicherzustellen, dass Ihre Organisation bei der Umsetzung dieser Art von Maßnahmen nicht implodiert, müssen Sie häufige Feedbackschleifen zwischen allen Teams erstellen und gleichzeitig sicherstellen, dass alle Engpässe beseitigt sind und der Systemfluss nicht unterbrochen wird.

Die Umsetzung dieser Maßnahmen macht Ihre Organisation jederzeit wach und in der Lage, schnell und effektiv auf Herausforderungen zu reagieren.

Zusammenfassung – Checkliste für die DevOps-Organisation

Hier ist eine Checkliste, mit der Sie überprüfen können, wie DevOps-fähig Ihre IT-Organisation ist. Bitte zögern Sie nicht, den Artikel zu kommentieren und Ihre eigenen Punkte hinzuzufügen.

• Es gibt keine Mauer zwischen Entwicklungsteam und Betriebsteam. Beide sind Teil desselben Prozesses
• Die Arbeit, die von einem Team zum anderen geschickt wird, ist immer verifiziert und von höchster Qualität
• Es gibt kein „Stapeln“ von Arbeit, und alle Engpässe werden behandelt
• Das Entwicklungsteam verwendet keine Betriebszeit für seine Aktivitäten, da Bereitstellung und Wartung Teil derselben Zeitbox sind
• Das Entwicklungsteam liefert freitags um 17:00 Uhr keinen Code für die Bereitstellung und überlässt es dem Betrieb, seine Arbeit über das Wochenende zu bereinigen
• Entwicklungsumgebungen sind standardisiert, und der Betrieb kann sie einfach reproduzieren und in die Produktion skalieren
• Das Entwicklungsteam kann neue Versionen liefern, wenn sie es für angemessen halten, und der Betrieb kann sie problemlos in der Produktion bereitstellen
• Es gibt klare Kommunikationslinien zwischen allen Teams
• Alle Teammitglieder haben Zeit zu experimentieren und an der Verbesserung des Systems zu arbeiten
• Fehler werden regelmäßig in das System eingeführt (oder simuliert) und behandelt. Die aus jedem Experiment gewonnenen Erkenntnisse werden dokumentiert und mit allen relevanten Personen geteilt. Die Behandlung von Vorfällen ist Routine und wird meist auf bekannte Weise gehandhabt

Fazit

Die Verwendung moderner DevOps-Tools wie Chef, Docker, Ansible, Packer, Troposphere, Consul, Jenkins, SonarQube, AWS usw. bedeutet nicht, dass Sie DevOps-Prinzipien anwenden. DevOps ist eine Denkweise. Wir sind alle Teil des gleichen Prozesses, wir teilen die gleiche Zeit und liefern gemeinsam Wert. Jede am Softwarebereitstellungsprozess beteiligte Person kann das gesamte System beschleunigen oder verlangsamen. Ein während der Entwicklung erstellter Fehler kann das System zum Absturz bringen, ebenso wie die falsche Firewall-Konfiguration.

Alle Menschen sind Teil von DevOps, und sobald Ihre Organisation das verstanden hat, werden Tools und Technologie-Stacks, die Ihnen bei der Verwaltung helfen, auf magische Weise auftauchen.