DevOps für Startups

Disclaimer: Ich habe mich entschieden, diesen Artikel zu schreiben, da ich ständig nach “DevOps” gefragt werde und ob man es braucht. Dies ist meine persönliche Sicht darauf - der Umfang ist mein eigener. DevOps hat weit mehr Bereiche der Softwareentwicklung beeinflusst als die, die ich hier erwähne, und es gibt wahrscheinlich genauso viele Definitionen von DevOps wie Menschen, die müde sind, DevOps zu erklären. Falls Sie Ihre eigene Definition des missverständlichsten Begriffs seit “Cloud” gefunden haben, können Sie vielleicht zu den praktischeren Beispielen am Ende des Artikels scrollen.

DevOps Erklärer

In den letzten Jahren hatte ich das Glück, in verschiedenen Startups in unterschiedlichen Phasen ihres Lebenszyklus zu arbeiten. Wie zu erwarten war, tauchte das Wort DevOps als leerer Buzzword-Begriff überall auf und jeder wollte seinen “DevOps Engineer” oder “DevOps machen”. Mit diesem Artikel versuche ich, auf den Grund zu gehen, was DevOps für Sie bedeuten sollte und was für Sie als Startup wichtig sein könnte, das Produktionssysteme betreibt und Softwareentwicklung betreibt. Wie man vermuten würde, war dies bei vielen Gelegenheiten ein heißes Thema, bei dem ich mich mit Kollegen und Freunden sowohl im IT-Betrieb als auch in der Softwareentwicklung wiederfand. Ich habe eine starke Meinung zu den Konzepten hinter “DevOps”, die meiner Meinung nach Ihnen einen Vorsprung vor Ihrer Konkurrenz verschaffen können, allerdings nur, wenn Sie “DevOps” richtig in Ihrer Organisation anwenden.

Ein Wort, viel Skalierung, zu modern?

Eines ist sicher: Wenn jemand in einem Startup “DevOps” sagt, meint er höchstwahrscheinlich, dass der IT-Betrieb sich nicht selbst und den Nutzern im Weg stehen sollte, um zu skalieren und letztendlich erfolgreich zu sein. Sie meinen vielleicht auch, dass sie in ihrem zukünftigen Unternehmen kein IT-Operations-Silo/keine IT-Abteilung haben möchten, weil es dazu führen könnte, dass genau diese Abteilung ihrem Erfolg im Weg steht. Kapazitätsplanung, Server etc. stehen ihnen nur im Weg, und AWS zeigt uns, dass wir in der modernen IT Kapazität auf Abruf haben können, jederzeit experimentieren und skalieren können. Die Vergangenheit zeigt viele Beispiele, dass es nicht so einfach ist, aber so wird es verkauft und einige schaffen es, das Cloud-Puzzle auf ihre Infrastruktur anzuwenden.

Der Kern der Sache

Auf den Punkt gebracht führt uns das zu diesem einen Rockstar-Jobtitel eines “DevOps Engineers”, der weithin diskutiert ein grundlegender Fehler des Konzepts von DevOps als Kultur der Zusammenarbeit zwischen Softwareentwicklung und IT-Betrieb sowie der Praxis der Anwendung von Softwareentwicklungskonzepten im IT-Betrieb ist. Mit der Art und Weise, wie “DevOps” in den meisten Startups wahrgenommen wird, suchen sie meist nach einem Production/Site Reliability Engineer, der dafür verantwortlich ist, dass der IT-Betrieb der Skalierung nicht im Weg steht und die Zuverlässigkeit und Geschwindigkeit von Deployments und letztendlich ein erfolgreiches Produkt sicherstellt. Die Verwendung des Wortes “DevOps” als Jobtitel ist jedoch eher fehlerhaft, da Sie eigentlich wollen, dass Ihre IT-Operations-Arbeit Hand in Hand mit Ihrer Softwareentwicklung geht und noch besser, dass Ihr Softwareentwicklungsteam an die täglichen Betriebsfragen denkt. Dies ist eher eine organisatorische/kulturelle Veränderung in der Denkweise Ihrer Entwicklungsteams oder Ihrer Betriebsteams als eine Position, die Sie einfach besetzen können.

Wie sind wir hierher gekommen

IT-Operations war bis mindestens 2009 und dem “Frühling des DevOps” höchstwahrscheinlich als Silo / funktionales Team in Ihrem Organigramm vertreten. Angesichts dessen und wie lange es dauert, bis Menschen ihre Denkweise an die neue Realität der softwaredefinierten Umgebung (Netzwerk, Storage, Compute etc.) anpassen, sehen wir deutlich, wie leicht selbst Startups in das alte Muster von Dev und Ops zurückfallen können, anstatt beide hauptsächlich als Softwareentwicklungsjobs mit unterschiedlichen Problemumfängen zu sehen.

“SRE ist das, was passiert, wenn man einen Softwareentwickler bittet, den Betrieb zu gestalten und zu führen.” (Ben Treynor Sloss, VP 24x7, Google)

Kurz gesagt, während ein Softwareentwickler vielleicht mehr an der Bereitstellung von Features interessiert ist, könnte ein SRE mehr an der Stabilität der gesamten Delivery Pipeline interessiert sein, obwohl beide mit Softwareentwicklungsprinzipien angegangen werden.

Die Realität holt ein

Da es den ganzen Bereich der softwaredefinierten Umgebung, Cloud, wie auch immer Sie es nennen, bis vor 10 Jahren nicht gab und er wirklich erst in den letzten 5 Jahren an Schwung gewonnen hat, können Sie möglicherweise leichter einen erfahrenen IT-Operations-Engineer im traditionellen Sinne einstellen als Softwareentwickler mit Fokus auf Zuverlässigkeit/Skalierung. Auch werden Sie vielleicht Softwareentwickler finden, die nicht zu viel über IT-Operations nachdenken möchten, da es als nicht Teil ihrer Arbeit angesehen wird und manchmal einfach als “im Weg stehend” beim Ausrollen von Features und letztendlich beim Erreichen eines erfolgreichen Produkts innerhalb ihres Bereichs.

Dieses Denken ist für mich jedoch grundlegend falsch, denn ohne Widerstandsfähigkeit, einen Plan zur Skalierung, wie Ihr Produkt mit Ihrer Infrastruktur funktioniert, und gute Baseline-Performance Ihres Produkts - wenn etwas schief geht, können Sie sich schnell in einer Spirale von Ops vs. Dev Teams wiederfinden, die ein Spiel des “Schuld-Ping-Pongs” spielen, anstatt am gemeinsamen Ziel der Produktverbesserung zu arbeiten.

Mach es einfach, es ist ja schließlich ein Startup!

Zum Beispiel gibt es meiner Meinung nach 2016 keinen Grund mehr für ein Startup, Server zu betreiben, ohne sie aus einer Codebasis reproduzieren zu können. Es gibt keine Möglichkeit, dass Sie die Dinge gerade richtig machen, wenn Sie Ihre Dienste nicht mit einem einzigen Klick reproduzieren können. Seien es unveränderliche Funktionen, Container, Server oder eine Codebasis. Wenn Sie einmal manuelle IT-Operations gemacht haben, ist es schwer, sich wieder herauszukämpfen. Jeder Teil Ihrer Infrastruktur, den Sie im aktuellen Zeitalter der Cloud/softwaredefinierten Umgebung manuell erstellt haben, ist an sich technische Schuld für einen Softwareentwickler.

Feedback-Schleifen

Wenn Sie bis hierher gekommen sind, haben Sie bereits eine Reihe von Feedback-Schleifen zur Hand. Sie stellen jetzt sicher, dass Sie Ihre wesentlichen Systeme immer aus Ihrer Codebasis wiederherstellen können, kontinuierlich!

Sie haben Teile der Disaster Recovery richtig gemacht, jetzt geht es darum, nicht nur Feedback von Ihren Bereitstellungsmechaniken zu bekommen, sondern auch von den Mechaniken, die die Produktion am Laufen halten. Überprüfen Sie, was passiert, wenn diese eine Maschine in Ihrem Cluster ausfällt (erst in Staging, dann in Produktion), überprüfen Sie, was bei einem Datenbank-Failover passiert. Automatisieren Sie es, führen Sie es regelmäßig aus, bauen Sie Feedback-Schleifen auf, um sicherzustellen, dass Sie online bleiben können, auch wenn die Welt gegen Sie steht.

Post Mortem

Selbst mit all den beschriebenen Praktiken kann es schiefgehen. Jetzt müssen Sie sicherstellen, dass Sie das richtige Medium zur Hand haben, in dem Sie über diese Fehler produktiv sprechen können. Es ist wahrscheinlich ein systemischer Fehler. Selbst wenn Ihr Kollege ein Drop Table in der Produktion ausgeführt hat, ist es ein Problem des zugrundeliegenden Systems, dass sie das überhaupt tun konnten. Indem Sie sich auf die Schwächen Ihres Systems konzentrieren und sie in Ihre Systemstärken umwandeln, werden Sie unweigerlich zu einem System gelangen, das immer widerstandsfähiger wird.

Mit einem Fokus Ihrer Systemverbesserung auf die mittlere Reparaturzeit, da Systeme unvermeidlich ausfallen, und weniger auf die mittlere Zeit zwischen Ausfällen, werden Sie zu einem widerstandsfähigeren System gelangen, das sich fließender an sich ändernde Umgebungen und Anforderungen anpassen lässt.

Zusammenfassung

Es gibt so viele Bereiche, die DevOps und Agile beeinflusst haben, die meine tägliche Arbeitsumgebung zum Besseren verändert haben, dass sie nie in einem Beitrag oder Buch Platz finden werden. Dies war ehrlich gesagt ein langer Beitrag, der eine Reihe von Punkten auslässt und sich auf die Systemresilienz-Seite der Dinge konzentriert.

Am Ende gibt es so viel bereits geleistete Arbeit zu jedem der Themen, die man als “DevOps-Sache” betrachten könnte. Halten Sie Ihre Augen offen, seien Sie bescheiden, bleiben Sie nicht in der Vergangenheit stecken, machen Sie keine sich wiederholenden Aufgaben. Denken Sie über Ihr Produkt, Ihre Infrastruktur, Ihre Organisation als System nach - als das Team von Menschen, Maschinen, Software. Dinge werden schief gehen, Menschen werden Fehler machen, Teile werden fehlen, kaputtgehen oder Sie werden einfach zu viele Aufträge zu verarbeiten haben.

Sicherzustellen, dass Sie ständig einen systemischen Überblick behalten können und versuchen, das System so widerstandsfähig wie möglich zu machen, während Sie die Entwicklungsgeschwindigkeit und Innovation steigern, ist für mich die Essenz von DevOps.