Smashing Podcast Folge 42 mit Jeff Smith: Was ist DevOps?

In dieser Folge sprechen wir über DevOps. Was ist das und ist es eine Saite, die Sie Ihrem Webentwicklungsbogen hinzufügen sollten? Drew McLellan spricht mit dem Experten Jeff Smith, um es herauszufinden.

Notizen anzeigen

• Jeff auf Twitter
• Jeffs Buch Operations Anti-Patterns, DevOps Solutions
• Erreichbare DevOps

Wöchentliches Update

• Die Lücke zwischen Designern und Entwicklern schließen, geschrieben von Matthew Talebi
• Nützliche React-APIs zum Erstellen flexibler Komponenten mit TypeScript, geschrieben von Gaurav Khanna
• Intelligente CSS-Lösungen für allgemeine UI-Herausforderungen, geschrieben von Cosima Mielke
• Tipps und Tricks zur Bewertung von UX/UI-Designern geschrieben von Nataliya Sambir
• Lösen von CLS-Problemen auf einer Next.js-basierten E-Commerce-Website, geschrieben von Arijit Mondal

Abschrift

Drew McLellan: Er ist ein DevOps-Praktiker, der sich auf erreichbare Ebenen von DevOps-Implementierungen konzentriert, unabhängig davon, wo Sie sich auf Ihrer Reise befinden. Er ist Director of Production Operations bei der digitalen Werbeplattform Centro und tritt als öffentlicher Redner auf, der sein DevOps-Wissen mit einem Publikum auf der ganzen Welt teilt. Er ist der Autor des Buches „Operations Anti-Patterns, DevOps Solutions“ für Manning Publishing, das zeigt, wie man DevOps-Techniken in den unvollkommenen Umgebungen implementiert, in denen die meisten Entwickler arbeiten. Wir wissen also, dass er ein Experte für DevOps ist, aber kannten Sie George? Clooney hält ihn für den besten Papierfliegerbauer einer Generation? Meine Smashing-Freunde, bitte heißen Sie Jeff Smith willkommen. Hallo Jeff. Wie geht es dir?

Jeff Smith: Ich bin super, Drew, wie geht es dir?

Drew: Mir geht es gut. Danke. Das ist gut zu hören. Deshalb wollte ich heute mit Ihnen über das Thema DevOps sprechen, das einer Ihrer Schwerpunkte ist. Viele unserer Zuhörer werden in die Web- und App-Entwicklung involviert sein, sind aber vielleicht nur ansatzweise mit dem vertraut, was auf der operativen Seite der Dinge passiert. Ich weiß, dass diejenigen von uns, die möglicherweise in größeren Unternehmen arbeiten, ganze Teams von Kollegen haben, die Operationen durchführen. Wir sind einfach dankbar, dass sie es gut machen, was auch immer sie tun. Aber DevOps wird immer häufiger erwähnt, und es scheint eines dieser Dinge zu sein, die wir als Entwickler wirklich verstehen sollten. Also Jeff, was ist DevOps?

Jeff: Wenn Sie also 20 Personen fragen, was DevOps ist, erhalten Sie möglicherweise 20 verschiedene Antworten. Also werde ich Ihnen meine Meinung sagen, in Ordnung, und wissen, dass Sie, wenn Sie auf einer Konferenz sind und dies erwähnen, mit jemandem in einen Faustkampf geraten könnten. Aber für mich geht es bei DevOps wirklich um diese Beziehung zwischen, und wir konzentrieren uns auf Dev und Ops, aber wirklich um diese Beziehung zwischen den Teams und wie wir unsere Arbeit strukturieren und, was noch wichtiger ist, unsere Ziele und Anreize strukturieren, um sicherzustellen, dass sie es sind so ausgerichtet, dass wir auf ein gemeinsames Ziel hinarbeiten. Und viele der Kernideen und -konzepte von DevOps stammen aus der alten Welt, in der Dev und Ops immer gegensätzlich waren, wo es diesen ständigen Konflikt gab. Und wenn man darüber nachdenkt, liegt es an der Art und Weise, wie diese beiden Teams motiviert werden. Ein Team wird motiviert, Änderungen voranzutreiben. Ein anderes Team wird dazu angeregt, Stabilität zu bewahren, was weniger Änderungen bedeutet.

Jeff: Wenn du das tust, erschaffst du diesen inhärenten Konflikt und alles fließt von dort aus. Bei DevOps geht es also wirklich darum, diese Teams und Ziele so aufeinander abzustimmen, dass wir auf eine gemeinsame Strategie hinarbeiten, aber dann auch Praktiken von beiden Seiten übernehmen, damit der Entwickler mehr über Ops versteht und der Ops mehr über Dev versteht, um zu gewinnen und zu teilen Empathie miteinander, damit wir verstehen, woher der andere kommt.

Jeff: Aber dann auch, um unsere Arbeit zu verbessern. Denn noch einmal, wenn ich Ihre Perspektive verstehe und sie in meiner Arbeit berücksichtige, wird es für jeden von uns viel vorteilhafter sein. Und es gibt eine Menge, was Ops von Entwicklern in Bezug auf Automatisierung lernen können und wie wir Dinge angehen, damit sie leicht reproduzierbar sind. Es ist also diese Mischung und Fähigkeiten. Und was Sie jetzt sehen, ist, dass dies für verschiedene Gruppenkombinationen gilt, also hören Sie Dinge wie DevSecOps, DevSecFinOps, DevSecFinHROps. Es wird einfach weiter wachsen und wachsen und wachsen. Es ist also wirklich eine Lektion, die wir in der gesamten Organisation ausmerzen können.

Drew: Es geht also darum, einige der Konzepte, die wir als Entwickler verstehen, zu nutzen und unsere Ideen weiter in die Organisation zu tragen und gleichzeitig so viel wie möglich aus dem Betrieb zu lernen, um zu versuchen, alle voranzubringen.

Jeff: Absolut, ja. Und ein weiterer Aspekt von Ops, und Sie haben es ein wenig in der Einleitung erwähnt, ist, dass wir denken, dass es nur für diese größeren Organisationen mit engagierten Ops-Teams und solchen Dingen ist, aber eine Sache, an die Sie denken sollten, ist, dass Ops in Ihrer Organisation passieren, unabhängig von der Größe. Es ist nur eine Frage, ob Sie es tun oder ob es ein separates Team gibt, aber irgendwie stellen Sie Code bereit. Irgendwie läuft irgendwo da draußen ein Server. Es gibt also irgendwo in Ihrer Organisation Ops, unabhängig von der Größe. Die Frage ist, wer macht das? Und wenn es sich um eine einzelne Person oder eine einzelne Gruppe handelt, ist DevOps für Sie vielleicht sogar noch wichtiger, da Sie verstehen müssen, welche Art von Dingen Ops tut.

Drew: Wie wichtig ist es Ihrer Meinung nach für uns als professionelle Entwickler, ein gutes Verständnis dafür zu haben, was DevOps ist und was es bedeutet, es zu implementieren?

Jeff: Ich denke, es ist super wichtig, besonders in dieser Phase der DevOps-Reise. Und der Grund, warum ich es für wichtig halte, ist, dass wir meiner Meinung nach immer effizienter sind, wenn wir verstehen, was unsere Kollegen tun. Aber die andere Sache ist, dass Sie betriebliche Belange während Ihrer Designentwicklung und Implementierung jeder Technologie berücksichtigen können. Eine Sache, die ich in meiner Karriere gelernt habe, ist, dass, obwohl ich dachte, dass Entwickler Meister des Universums sind und alles verstehen, was mit Computern zu tun hat, sich herausstellt, dass dies nicht der Fall ist. Es stellt sich heraus, dass sie viele Dinge in Bezug auf das Verständnis an die Ops auslagern, und manchmal führt dies zu bestimmten Designentscheidungen oder Implementierungsentscheidungen, die für eine Produktionsbereitstellung möglicherweise nicht optimal sind.

Jeff: Sie mögen in der Entwicklung und beim Testen und solchen Dingen gut sein, aber sobald Sie die Produktion erreicht haben, ist es ein bisschen anders. Das heißt nicht, dass sie über das gesamte Fachwissen verfügen müssen, aber sie müssen zumindest genug wissen, um zu wissen, was sie nicht wissen. Sie wissen also, wann sie die Ops frühzeitig einschalten müssen, denn das ist ein allgemeines Muster, das wir sehen, wenn die Entwicklung eine Entscheidung trifft. Ich werde nicht einmal sagen, eine Wahl zu treffen, weil sie sich nicht einmal bewusst sind, dass es eine Wahl ist, aber es passiert etwas, das zu einer suboptimalen Entscheidung für die Ops führt, und die Entwicklung war sich dessen überhaupt nicht bewusst. Also nur ein bisschen mehr Wissen über Ops zu haben, auch wenn es gerade ausreicht zu sagen, vielleicht sollten wir Ops dazu bringen, um ihre Perspektive zu bekommen, bevor wir weitermachen. Das könnte natürlich viel Zeit und Energie und Stabilität sparen, da es sich auf alle Produkte bezieht, die Sie veröffentlichen.

Drew: Ich sehe so viele Parallelen zu der Art und Weise, wie Sie über die Beziehung zwischen Dev und Ops sprechen, wie wir sie zwischen Design und Dev haben, wo Sie Designer haben, die vielleicht daran arbeiten, wie eine Benutzeroberfläche funktioniert und aussieht, und ein gutes Verständnis haben wie das tatsächlich in die Entwicklungsrolle eingebaut werden soll, und das Einbeziehen von Entwicklern zur Beratung kann die Gesamtlösung wirklich verbessern, einfach durch diese klare Kommunikation und das Verständnis dafür, was der andere tut. Scheint, als ob das gleiche Prinzip bei DevOps zum Einsatz kommt, was wirklich, wirklich gut zu hören ist.

Drew: Wenn ich an das denke, was ich über DevOps höre, höre ich Begriffe wie Kubernetes, Docker, Jenkins, CircleCI. Ich höre seit Jahren von Kubernetes. Ich habe immer noch keine Ahnung, was es ist, aber nach dem, was Sie sagen, geht es bei DevOps anscheinend nicht nur um … Wir sprechen hier nicht nur über Tools, oder? Aber mehr über Prozesse und Kommunikationswege zu Workflows, richtig?

Jeff: Absolut. Also war mein Mantra in den letzten 20 Jahren immer People Process Tools. Sie bringen Menschen dazu, sich der Vision anzuschließen. Von dort aus definieren Sie, wie Ihr Prozess aussehen soll, um diese Vision zu erreichen. Und dann führen Sie Tools ein, die Ihren Prozess modellieren. Also stelle ich Tools immer am Ende der DevOps-Konversation, hauptsächlich weil es keine Rolle spielt, wenn Sie dieses Buy-In nicht haben. Ich könnte mit der größten Continuous Deployment-Pipeline aller Zeiten aufwarten, aber wenn die Leute nicht von der Idee überzeugt sind, jede Änderung direkt in die Produktion zu bringen, spielt das keine Rolle, oder? Was nützt das Werkzeug? Diese Tools sind also definitiv Teil des Gesprächs, nur weil sie eine standardisierte Methode darstellen, um einige gemeinsame Ziele zu erreichen, die wir definiert haben.

Jeff: Aber Sie müssen sicherstellen, dass die definierten Ziele für Ihr Unternehmen sinnvoll sind. Vielleicht ist Continuous Deployment für Sie nicht sinnvoll. Vielleicht möchten Sie nicht jede einzelne Änderung in der Minute versenden, in der sie herauskommt. Und es gibt viele Unternehmen und Organisationen und Gründe, warum Sie das nicht tun möchten. Vielleicht ist so etwas wie eine kontinuierliche Bereitstellungspipeline für Sie nicht sinnvoll. Während also die Tools wichtig sind, ist es wichtiger, sich auf das zu konzentrieren, was Ihrem Unternehmen einen Mehrwert bringt, und dann die Tools zu modellieren und zu implementieren, die dazu erforderlich sind.

Jeff: Aber gehen Sie nicht online und finden Sie heraus, was alle tun, und sagen Sie, na ja, wenn wir DevOps machen wollen, müssen wir zu Docker und Kubernetes wechseln, weil das die Toolkette ist. Nein, das ist es nicht. Sie brauchen diese Dinge vielleicht nicht. Nicht jeder ist Google. Nicht jeder ist Netflix. Hören Sie auf, Beiträge von Netflix und Google zu lesen. Bitte hören Sie einfach auf, sie zu lesen. Weil es die Leute ganz aufgeregt macht und sie sagen, nun, das ist es, was wir tun müssen. Und es ist so, nun, sie lösen ganz andere Probleme als die Probleme, die Sie haben.

Drew: Wenn ich also sage, ich starte ein neues Projekt, bin ich vielleicht ein Startup-Unternehmen, das Software als Serviceprodukt erstellt. Ich habe drei Entwickler, ich habe ein leeres Git-Repo und ich träume von Börsengängen. Wie lauten die Namen der Bausteine, die ich in Bezug auf Menschen und Prozesse haben sollte, um voll und ganz auf einen DevOps-Ansatz zum Erstellen dieses Produkts zu setzen, und wo fange ich an?

Jeff: In Ihrem speziellen Beispiel würde ich also als Erstes damit beginnen, so viel wie möglich auf das meiste zu setzen und so etwas wie Heroku oder etwas in diesem Sinne zu verwenden. Weil Sie so begeistert sind von all diesem AWS-Zeug, Docker-Zeug, und in Wirklichkeit ist es so schwer, nur ein erfolgreiches Produkt zu entwickeln. Die Idee, dass Sie sich auf den DevOps-Teil davon konzentrieren, ist wie: Nun, ich würde sagen, lagern Sie so viel von diesem Zeug wie möglich aus, bis es tatsächlich zu einem Schmerzpunkt wird. Aber wenn Sie an dem Punkt sind, an dem Sie sagen, okay, wir sind bereit, dieses Zeug ins Haus zu nehmen und wir sind bereit, es auf die nächste Ebene zu bringen. Ich würde sagen, der erste Ansatzpunkt ist, wo sind Ihre Schmerzpunkte? was sind die Dinge, die dir Probleme bereiten?

Jeff: Für manche Leute ist es also so einfach wie automatisiertes Testen. Die Idee, hey, wir müssen jedes Mal Tests durchführen, wenn jemand einen Commit macht, weil wir manchmal Sachen versenden, die von Unit-Tests abgefangen werden, die wir bereits geschrieben haben. Dann fangen Sie vielleicht mit Continuous Integration an. Vielleicht dauert es Stunden, bis Ihre Bereitstellungen abgeschlossen sind, und sie sind sehr manuell. Dann konzentrieren Sie sich darauf und sagen: Okay, welche Automatisierung brauchen wir, um dies zu einer Ein-Knopf-Klick-Angelegenheit zu machen? Aber ich hasse es, ein allgemeines vorzuschreiben, hier fangen Sie an, nur weil Ihre spezielle Situation und Ihre speziellen Schmerzpunkte anders sein werden. Und die Sache ist, wenn es ein Schmerzpunkt ist, sollte es Sie anschreien. Es sollte Sie absolut anschreien.

Jeff: Es sollte eines dieser Dinge sein, bei denen jemand sagt, oh, was nervt in Ihrer Organisation? Und es sollte so sein, oh, ich weiß genau, was das ist. Wenn Sie also aus dieser Perspektive an die Sache herangehen, werden Ihnen die nächsten Schritte in Bezug darauf, was Sie aus der DevOps-Toolbox auspacken und mit der Arbeit beginnen müssen, meiner Meinung nach ziemlich offensichtlich. Und dann werden es diese minimalen inkrementellen Änderungen, die immer wieder kommen, und Sie bemerken, dass Ihr Appetit auf minderwertige Sachen sehr gering wird, wenn Sie neue Fähigkeiten erhalten. Also gehst du davon aus, oh ja, Bereitstellungen dauern drei Stunden und das ist in Ordnung. Sie haben sich etwas Mühe gegeben und als Nächstes denken Sie in drei Wochen: Mann, ich kann nicht glauben, dass der Einsatz immer noch 30 Minuten dauert. Wie bekommen wir das von 30 Minuten herunter? Ihr Appetit auf Verbesserung wird unersättlich. Also fließen die Dinge einfach von dort aus.

Drew: Ich habe Ihr kürzlich erschienenes Buch gelesen und das hebt hervor, was Sie die vier Säulen von DevOps nennen. Und keines davon ist, wie erwähnt, ein Tool, aber es gibt diese vier Hauptschwerpunkte, wenn Sie so wollen, für DevOps. Mir ist aufgefallen, dass das erste davon Kultur ist, ich war davon ziemlich überrascht, erstens, weil ich erwartet hatte, dass Sie mehr über Werkzeuge sprechen würden, und wir verstehen jetzt warum, aber wenn es um Kultur geht, scheint es einfach seltsam zu sein was am Anfang zu haben ist. Es gibt eine Grundlage für einen technischen Ansatz. Wie wirkt sich die Kultur darauf aus, wie erfolgreich die DevOps-Implementierung innerhalb einer Organisation sein kann?

Drew: … wie erfolgreich die Implementierung von DevOps in einem Unternehmen sein kann.

Jeff: Kultur ist wirklich das Fundament von allem, wenn man darüber nachdenkt. Und es ist wichtig, weil Kultur, und wir gehen in diesem Buch etwas tiefer darauf ein, aber Kultur schafft wirklich die Voraussetzungen für Normen innerhalb der Organisation. Rechts. Sie waren wahrscheinlich in einem Unternehmen, wo es keine große Sache ist, wenn Sie eine PR ohne automatisierte Tests einreichen. Die Leute akzeptieren es und machen weiter.

Jeff: Aber dann gibt es andere Orgs, wo das eine Todsünde ist. Rechts. Wo, wenn Sie das getan haben, ist es wie: „Whoa, bist du verrückt? Was machst du gerade? Hier gibt es keine Testfälle.“ Rechts. Das ist aber Kultur. Das ist die Kultur, die diese Norm durchsetzt, um zu sagen: „Das ist einfach nicht das, was wir tun.“

Jeff: Jeder kann ein Dokument schreiben, das besagt, dass wir automatisierte Testfälle haben werden, aber die Kultur der Organisation ist es, die diesen Mechanismus bei den Menschen durchsetzt. Das ist nur ein kleines Beispiel dafür, warum Kultur so wichtig ist. Wenn Sie eine Organisation haben, in der die Kultur eine Kultur der Angst ist, eine Kultur der Vergeltung. Es ist, als ob Sie einen Fehler machen, richtig, das ist ein Sakrileg. Rechts. Das kommt einem Verrat gleich. Rechts.

Jeff: Sie schaffen Verhaltensweisen in dieser Organisation, die allem entgegenstehen, was riskant sein oder möglicherweise scheitern könnte. Und das lässt am Ende viele Möglichkeiten auf dem Tisch. Wenn Sie hingegen eine Kultur schaffen, die das Lernen aus Fehlern umfasst, nehmen Sie diese Idee der psychologischen Sicherheit an, in der Menschen experimentieren können. Und wenn sie falsch liegen, können sie herausfinden, wie sie sicher scheitern und es erneut versuchen können. Sie bekommen eine Kultur des Experimentierens. Sie erhalten eine Organisation, in der die Menschen offen für neue Ideen sind.

Jeff: Ich denke, wir waren alle in diesen Unternehmen, wo es so ist: „Nun, so wird es eben gemacht. Und niemand ändert das.“ Rechts. Das wollen Sie nicht, denn die Welt verändert sich ständig. Aus diesem Grund stellen wir die Kultur in den Mittelpunkt, denn viele Verhaltensweisen innerhalb einer Organisation sind auf die vorhandene Kultur zurückzuführen.

Jeff: Und die Sache ist die, kulturelle Akteure können gut oder schlecht sein. Rechts. Ironischerweise, und darüber sprechen wir auch in dem Buch, braucht es nicht so viele Menschen, wie Sie denken, um die Unternehmenskultur zu verändern. Rechts. Denn bei den meisten Menschen gibt es Verleumder und dann Befürworter und dann Zaunsitter, wenn es um jede Art von Veränderung geht. Und die meisten Menschen sind Zaunsitter. Rechts. Es braucht nur eine Handvoll Unterstützer, um wirklich das Zünglein an der Waage zu sein. Aber im gleichen Sinne braucht es auch nur eine Handvoll Kritiker, um das Zünglein an der Waage zu sein.

Jeff: Es braucht nicht viel, um die Kultur zum Besseren zu verändern. Und wenn Sie diese Energie hineinstecken, auch ohne eine Führungskraft zu sein, können Sie die Kultur Ihres Teams wirklich beeinflussen, was dann letztendlich die Kultur Ihrer Abteilung beeinflusst, die wiederum letztendlich die Kultur der Organisation beeinflusst.

Jeff: Sie können diese kulturellen Veränderungen als individueller Mitwirkender vornehmen, indem Sie diese Ideen und Verhaltensweisen lautstark vertreten und sagen: „Das sind die Vorteile, die wir daraus ziehen.“ Deshalb denke ich, dass die Kultur im Vordergrund stehen muss, denn man muss alle für diese Idee begeistern und sie müssen verstehen, dass es sich als Organisation lohnen wird, und sie unterstützen.

Drew: Ja. Es muss eine Lebensweise sein, denke ich.

Jeff: Genau.

Drew: Ja. Ich interessiere mich sehr für den Bereich Automatisierung, weil ich in meiner Karriere noch nie eine Automatisierung gesehen habe, die eingeführt wurde und nicht von Nutzen war. Rechts. Ich meine, abgesehen von der seltsamen Sache vielleicht, wo etwas automatisiert ist und es schief geht. Wenn Sie sich die Zeit nehmen, sich hinzusetzen und etwas zu automatisieren, das Sie bisher manuell erledigt haben, sparen Sie im Allgemeinen immer Zeit und Kopfraum, und es ist nur eine Last von Ihren Schultern.

Drew: Welche Art von Dingen würden Sie bei einem DevOps-Ansatz in Ihren Arbeitsabläufen automatisieren? Und welche Vorteile würden Sie davon erwarten, wenn Sie Dinge manuell erledigen?

Jeff: Wenn es um Automatisierung geht, gibt es sehr selten eine Zeit, in der die Automatisierung das Leben nicht besser gemacht hat. Rechts. Das Problem, auf das die Leute stoßen, ist, die Zeit zu finden, diese Automatisierung aufzubauen. Rechts. Und meistens geht es bei meinem jetzigen Job bei uns eigentlich um die Anfrage. Rechts. Denn irgendwann muss man sagen: „Ich höre auf, das manuell zu machen, und ich werde es automatisieren.“

Jeff: Und es muss vielleicht der Zeitpunkt sein, an dem Sie eine Anfrage erhalten, in der Sie sagen: „Weißt du was? Das dauert zwei Wochen. Ich weiß, dass wir es normalerweise in ein paar Stunden abwickeln, aber es wird zwei Wochen dauern, weil dies die Anfrage ist, die automatisiert wird.“ In Bezug auf die Identifizierung dessen, was Sie automatisieren. Bei Central verwende ich den Prozess, bei dem ich im Grunde genommen alle verschiedenen Arten von Anfragen, die über einen Zeitraum von vier Wochen eingingen, nehmen wir mal an. Und ich würde sie in geplante Arbeit, ungeplante Arbeit, wertschöpfende Arbeit, Schwerstarbeit einteilen. Mühsal ist Arbeit, die nicht wirklich nützlich ist, aber aus irgendeinem Grund muss meine Organisation sie erledigen.

Jeff: Und dann die Dinge zu identifizieren, die lauten: „Okay, was ist die niedrig hängende Frucht, die wir einfach loswerden könnten, wenn wir dies automatisieren würden? Was können wir tun, um dies zu vereinfachen?“ Und eines der Kriterien war das Risiko des Prozesses. Rechts. Automatisierte Datenbank-Failover sind etwas beängstigend, weil Sie sie nicht so oft durchführen. Und Infrastrukturänderungen. Rechts. Wir sagen: „Wie oft machen wir das?“ Wenn wir es einmal im Jahr machen, lohnt es sich vielleicht nicht, es zu automatisieren, weil es sehr wenig Wert hat. Aber wenn es eines dieser Dinge ist, die wir zwei-, dreimal im Monat bekommen, okay, schauen wir uns das an. Alles klar.

Jeff: Nun, was können wir tun, um das zu beschleunigen? Und die Sache ist die, wenn wir über Automatisierung sprechen, haben wir sofort gesagt: „Ich klicke auf eine Schaltfläche, und das Ding wird einfach magisch erledigt.“ Rechts. Aber es gibt so viele verschiedene Schritte, die Sie in der Automatisierung tun können, wenn Sie sich unwohl fühlen. Rechts. Angenommen, Sie haben 10 Schritte mit 10 verschiedenen CLI-Befehlen, die Sie normalerweise ausführen würden. Ihr erster Schritt zur Automatisierung könnte so einfach sein wie: Führen Sie diesen Befehl aus oder zeigen Sie diesen Befehl zumindest an. Rechts. Sagen Sie: „Hey, das werde ich ausführen. Glaubst du, es ist in Ordnung?“ "Jawohl." "In Ordnung. Dies ist das Ergebnis, das ich erhalten habe. Darf ich fortfahren?“ "Jawohl." "In Ordnung. Das ist das Ergebnis, das ich bekommen habe.“ Rechts.

Jeff: So hat man immer noch ein bisschen Kontrolle. Sie fühlen sich wohl. Und dann, nach 20 Hinrichtungen, merkst du, dass du nur zuschlägst, ja, ja, ja, ja, ja, ja. Du sagst: „In Ordnung. Verketten wir all diese Dinge und machen wir einfach alles zu einem.“ Es ist nicht so, dass Sie ins tiefe Ende springen, darauf klicken und es sofort vergessen müssen. Sie können sich darauf einlassen, bis Sie sich wohl fühlen.

Jeff: Das sind die Dinge, die wir im Rahmen unserer Automatisierungsbemühungen getan haben. Wie können wir die Bearbeitungszeit dafür beschleunigen und den Aufwand unsererseits reduzieren? Es mag am ersten Tag nicht 100 % sein, aber das Ziel ist immer, 100 % zu erreichen. Wir beginnen mit kleinen Stücken, von denen wir Teile davon automatisieren, mit denen wir uns wohl fühlen. Jawohl. Wir sind sehr zuversichtlich, dass dies funktionieren wird. Bei diesem Teil sind wir etwas unsicher, also holen wir uns vielleicht einfach eine menschliche Bestätigung, bevor wir fortfahren.

Jeff: Die andere Sache, die wir uns angesehen haben, ist, dass wir über Automatisierung sprechen, aber welchen Wert fügen wir einem bestimmten Prozess hinzu? Und das ist besonders hervorstechend für Ops. Weil ops oft als Mittelsmann für einen Prozess fungiert. Dann ist ihre Beteiligung nichts weiter als eine Zugangssache. Rechts. Es ist wie, nun, Ops muss es tun, weil Ops die einzige Person ist, die Zugriff hat.

Jeff: Nun, es ist wie, nun, wie lagern wir diesen Zugriff aus, damit die Leute es tun können? Denn die Realität sieht so aus, dass wir uns keine Sorgen darüber machen, dass Entwickler Zugriff auf die Produktion haben. Rechts. Wir befürchten, dass Entwickler uneingeschränkten Zugriff auf die Produktion haben. Und das ist wirklich eine Sicherheitssache. Rechts. Wenn meine Werkzeugkiste nur scharfe Messer enthält, werde ich sehr vorsichtig sein, wem ich das gebe. Aber wenn ich den Werkzeugkasten mit einem Löffel und einem Hammer aufmischen kann, damit die Leute das richtige Werkzeug für den Job auswählen können, dann ist es viel einfacher, das auszuleihen.

Jeff: Wir hatten zum Beispiel einen Prozess, bei dem Leute aus irgendeinem Grund Ad-hoc-Ruby-Skripte in der Produktion ausführen mussten. Rechts. Sie müssen Daten bereinigen, eine schlechte Aufzeichnung korrigieren, was auch immer. Und das würde immer durch mein Team kommen. Und es ist so, nun, wir fügen dem keinen Wert hinzu, weil ich dieses Ticket nicht genehmigen kann. Rechts. Ich habe keine Ahnung. Sie haben die Software geschrieben, also was nützt es mir, über Ihrer Schulter zu sitzen und zu sagen: „Nun, ich denke, das ist sicher“? Rechts. Ich habe der Eingabe keinen Wert hinzugefügt, weil ich nur genau das eingebe, was Sie mir gesagt haben. Rechts.

Jeff: Und im schlimmsten Fall bin ich am Ende wirklich nur eine Straßensperre für Sie, weil Sie ein Ticket einreichen und dann darauf warten, dass ich vom Mittagessen zurückkomme. Ich bin vom Mittagessen zurück, aber ich muss an diesen anderen Dingen arbeiten. Wir sagten: „Wie können wir dies automatisieren, damit wir es in die Hände von Entwicklern legen können, während wir gleichzeitig alle diese Audit-Bedenken ansprechen, die wir haben könnten?“

Jeff: Wir haben es in einen JIRA-Workflow integriert, wo wir einen Bot hatten, der die Ausführung von Befehlen automatisierte, die im JIRA-Ticket angegeben waren. Und dann könnten wir im JIRA-Ticket angeben, dass die Genehmigung von einem von mehreren leitenden Ingenieuren erforderlich ist. Rechts.

Jeff: Es macht mehr Sinn, dass ein Ingenieur die Arbeit eines anderen Ingenieurs genehmigt, weil sie den Kontext haben. Rechts. Sie müssen nicht herumsitzen und auf Operationen warten. Das Auditstück wird beantwortet, weil wir einen klaren Workflow haben, der in JIRA definiert ist und dokumentiert wird, wenn jemand genehmigt, wie jemand es verlangt. Und wir haben eine Automatisierung, die diesen Befehl abruft und diesen Befehl wörtlich im Terminal ausführt. Rechts.

Jeff: Sie müssen sich keine Sorgen machen, dass ich mich vertippe. Sie müssen sich keine Sorgen machen, dass ich das falsche Ticket ergattere. Das verlängerte die Bearbeitungszeit für diese Tickets um etwa das Zehnfache. Rechts. Entwickler sind entsperrt. Mein Team ist nicht damit beschäftigt. Und alles, was es wirklich brauchte, war eine ein- oder zweiwöchige Investition, um die Automatisierung und die erforderlichen Berechtigungen zu entwickeln, um ihnen den Zugriff darauf zu ermöglichen.

Jeff: Jetzt sind wir komplett davon entfernt. Und die Entwicklung ist tatsächlich in der Lage, einige dieser Funktionen an untergeordnete Teile der Organisation auszulagern. Sie haben es an die Kundenbetreuung weitergeleitet. Es ist wie jetzt, wenn die Kundenbetreuung weiß, dass dieser Datensatz für was auch immer aktualisiert werden muss, sie brauchen keine Entwicklung. Sie können ihr Standardskript einreichen, das wir für diese Funktion genehmigt haben. Und sie können es durch genau den gleichen Arbeitsablauf führen wie die Entwicklung. Es ist wirklich rundum ein Segen.

Jeff: Und dann erlaubt es uns, die Arbeit in der gesamten Organisation immer weiter nach unten zu schieben. Denn während wir das tun, wird die Arbeit billiger und billiger, weil ich einen schicken, teuren Entwickler haben könnte, der das betreibt. Rechts. Oder ich kann einen Kundenbetreuer beauftragen, der direkt mit dem Kunden zusammenarbeitet, es selbst ausführen, während er mit einem Kunden telefoniert, der ein Problem behebt.

Jeff: Automatisierung ist meiner Meinung nach der Schlüssel zu jeder Organisation. Und das letzte, was ich dazu sagen möchte, ist, dass es Ihnen auch erlaubt, Know-how zu exportieren. Rechts. Jetzt bin ich vielleicht die einzige Person, die weiß, wie das geht, wenn ich eine Reihe von Befehlen auf der Befehlszeile ausführen musste. Aber wenn ich das in die Automatisierung setze, kann ich das jedem geben. Und die Leute wissen, was das Endergebnis ist, aber sie müssen nicht alle Zwischenschritte kennen. Ich habe meinen Wert verzehnfacht, indem ich es an die Organisation weitergab und mein Fachwissen nahm und es in etwas exportierbares kodifizierte.

Drew: Sie haben über die Automatisierung von Aufgaben gesprochen, die häufig vorkommen. Gibt es ein Argument dafür, auch Aufgaben zu automatisieren, die so selten vorkommen, dass ein Entwickler ziemlich lange braucht, um wieder auf dem Laufenden zu bleiben, wie es funktionieren sollte? Weil alle vergessen sind. Das ist so lange her. Es ist ein Jahr her, vielleicht hat es noch niemand gemacht. Gibt es ein Argument dafür, auch solche Dinge zu automatisieren?

Jeff: Das ist ein harter Balanceakt. Rechts. Und ich sage immer, nehmen Sie es von Fall zu Fall. Und der Grund, warum ich das sage, ist, dass eines der Mantras in DevOps lautet, wenn etwas schmerzhaft ist, tun Sie es öfter. Rechts. Denn je öfter Sie es tun, desto mehr Muskelgedächtnis wird es und Sie können diese Knicke trainieren und ausbügeln.

Jeff: Das Problem, das wir bei der Automatisierung sehr seltener Aufgaben sehen, ist, dass sich die Landschaft der Umgebung zwischen den Ausführungen dieser Automatisierung tendenziell ändert. Rechts. Am Ende macht Ihr Code bestimmte Annahmen über die Umgebung und diese Annahmen sind nicht mehr gültig. Die Automatisierung bricht also sowieso zusammen.

Drew: Und dann hast du zwei Probleme.

Jeff: Richtig. Rechts. Exakt. Exakt. Und du denkst: „Habe ich es falsch eingegeben? Oder ist das? Nein, das Ding ist tatsächlich kaputt.“ Damit-

Jeff: Tippfehler oder nein, das Ding ist tatsächlich kaputt. Wenn es also darum geht, seltene Aufgaben zu automatisieren, gehen wir wirklich von Fall zu Fall vor, um zu verstehen, was das Risiko ist, wenn dies nicht funktioniert, richtig. Wenn wir es falsch machen, sind wir in einem schlechten Zustand oder haben wir diese Aufgabe nur nicht erledigt? Wenn Sie also sicherstellen können, dass dies ordnungsgemäß fehlschlägt und keine negativen Auswirkungen hat, dann lohnt es sich, es zu automatisieren. Denn dann hat man zumindest einen Rahmen des Verständnisses dessen, was vor sich gehen sollte, denn zumindest wird jemand in der Lage sein, den Code zu lesen und zu verstehen, in Ordnung, genau das haben wir getan. Und ich verstehe nicht, warum dies nicht mehr funktioniert, aber ich habe ein klares Verständnis dafür, was zumindest zur Entwurfszeit passieren sollte, als dies geschrieben wurde.

Jeff: Aber wenn Sie jemals in einer Situation sind, in der ein Fehler zu Datenänderungen oder ähnlichem führen könnte, gehe ich normalerweise auf Nummer sicher und behalte es nur manuell, denn wenn ich ein Automatisierungsskript habe, wenn ich ein Confluence-Dokument finde das ist drei Jahre alt und sagt, führe dieses Skript aus. Ich habe in der Regel hundertprozentiges Vertrauen in dieses Skript und führe es aus. Rechts. Wenn es sich dagegen um eine Reihe manueller Schritte handelt, die vor vier Jahren dokumentiert wurden, werde ich sagen, dass ich hier eine Überprüfung durchführen muss. Rechts? Lassen Sie mich das ein wenig durchgehen und mit ein paar Leuten sprechen. Und manchmal, wenn wir Prozesse entwerfen, lohnt es sich, diesen Denkprozess zu forcieren, richtig? Und Sie müssen über die menschliche Komponente nachdenken und wie sie sich verhalten werden. Und manchmal lohnt es sich, den Prozess etwas umständlicher zu gestalten, um die Leute zum Nachdenken zu zwingen, sollte ich das jetzt tun?

Drew: Gibt es andere Möglichkeiten, um zu identifizieren, was automatisiert werden sollte, indem Sie Ihre Systeme überwachen und Dinge messen? Ich meine, ich denke an DevOps und ich denke an Dashboards als eines der Dinge, nette Diagramme. Und ich bin mir sicher, dass diese Dashboards viel mehr zu bieten haben, als nur hübsch auszusehen, aber es ist immer schön, hübsch aussehende Dashboards zu haben. Gibt es Möglichkeiten, zu messen, was ein System vorhat, um Ihnen zu helfen, solche Entscheidungen zu treffen?

Jeff: Absolut. Und diese Art geht in den Metrikteil von Kameras über, richtig, was sind die Dinge, die wir in unseren Systemen verfolgen, um zu wissen, dass sie effizient arbeiten? Und eine der häufigsten Fallstricke von Metriken ist, dass wir nach Fehlern suchen, anstatt den Erfolg zu überprüfen. Und das sind zwei sehr unterschiedliche Praktiken, richtig? Es könnte also etwas durch das System fließen und nicht unbedingt einen Fehler verursachen, aber nicht unbedingt den gesamten Prozess so durchlaufen, wie es sollte. Wenn wir also eine Nachricht in einer Nachrichtenwarteschlange ablegen, sollte es eine entsprechende Metrik geben, die besagt: „Und diese Nachricht wurde abgerufen und verarbeitet“, richtig? Wenn nicht, richtig, hast du schnell ein Ungleichgewicht und das System funktioniert nicht so, wie es sollte. Ich denke, wir können Metriken verwenden, um auch verschiedene Dinge zu verstehen, die automatisiert werden sollten, wenn wir in diese schlechten Zustände geraten.

Jeff: Richtig? Denn oft ist es ein sehr einfacher Schritt, der getan werden muss, um die Dinge zu bereinigen, richtig? Für Leute, die schon eine Weile im Einsatz sind, richtig, der Speicherplatzalarm, jeder weiß davon. Oh, wir sind voll mit Discs. Oh, wir haben vergessen, dass Monatsende ist und die Abrechnung lief und die Abrechnung immer die Protokolle füllt. Und dann verbraucht das VAR-Protokoll den gesamten Speicherplatz, sodass wir eine Protokollrotation ausführen müssen. Rechts? Sie könnten dafür um drei Uhr morgens geweckt werden, wenn Sie das bevorzugen. Aber wenn wir irgendwie wissen, dass das das Verhalten ist, sollten unsere Metriken uns einen Hinweis darauf geben können. Und wir können den Befehl zum Rotieren des Protokolls einfach automatisieren, richtig? Oh, wir haben diesen Schwellenwert erreicht, führen Sie den Befehl zum Rotieren des Protokolls aus. Mal sehen, ob die Warnung gelöscht wird. Wenn ja, fahren Sie mit dem Leben fort. Wenn nicht, wecken wir vielleicht jemanden auf, richtig.

Jeff: Sie sehen das auch viel häufiger bei der Infrastrukturautomatisierung, genau dort, wo es heißt: „Hey, unsere Anfragen pro Sekunde erreichen unser theoretisches Maximum. Vielleicht müssen wir den Cluster skalieren. Vielleicht müssen wir dem Load-Balancer-Pool drei oder vier Knoten hinzufügen.“ Und wir können das tun, ohne dass jemand notwendigerweise eingreifen muss. Wir können uns einfach diese Metriken ansehen und diese Maßnahmen ergreifen und dann diese Infrastruktur beauftragen, sobald sie unter einen bestimmten Schwellenwert fällt, aber Sie müssen diese Metriken haben und Sie müssen diese Hooks in Ihrer Überwachungsumgebung haben, um dies tun zu können. Und hier kommt der gesamte Metrikteil der Konversation ins Spiel.

Jeff: Außerdem ist es auch gut, diese Informationen mit anderen Leuten teilen zu können, denn sobald Sie Daten haben, können Sie anfangen, über Dinge in einer gemeinsamen Realität zu sprechen, richtig, denn beschäftigt ist ein allgemeiner Begriff, aber 5.200 Anfragen pro Sekunde sind etwas viel konkreter, über den wir alle nachdenken können. Und ich denke so oft, wenn wir Gespräche über Kapazität oder irgendetwas führen, verwenden wir diese handgewellten Begriffe, obwohl wir uns stattdessen ein Dashboard ansehen und sehr spezifische Werte angeben und sicherstellen könnten, dass jeder Zugriff auf diese Dashboards hat, das Sie sind nicht hinter einer Operationswand versteckt, zu der nur wir aus unbekannten Gründen Zugang haben.

Drew: So while sort of monitoring and using metrics as a decision-making tool for the businesses is one aspect of it, it sounds like the primary aspect is having the system monitor itself, perhaps, and to respond maybe with some of these automations as the system as a whole gives itself feedback on onto what's happening.

Jeff: Absolutely. Feedback loops are a key part of any real system design, right, and understanding the state of the system at any one time. So while it's easy in the world where everything is working fine, the minute something goes bad, those sorts of dashboards and metrics are invaluable to have, and you'll quickly be able to identify things that you have not instrumented appropriately. Rechts. So one of the things that we always talk about in incident management is what questions did you have for the system that couldn't be answered, right. So what is it, or you're like, “Oh man, if we only knew how many queries per second were going on right now.” Rechts.

Jeff: Well, okay. How do we get that for next time? How do we make sure that that's radiated somewhere? And a lot of times it's hard when you're thinking green field to sit down and think of all the data that you might want at any one time. But when you have an incident, it becomes readily apparent what data you wish you had. So it's important to sort of leverage those incidents and failures and get a better understanding of information that's missing so that you can improve your incident management process and your metrics and dashboarding.

Drew: One of the problems we sometimes face in development is that teammate members, individual team members hold a lot of knowledge about how a system works and if they leave the company or if they're out sick or on vacation, that knowledge isn't accessible to the rest of the team. It seems like the sort of DevOps approach to things is good at capturing a lot of that operational knowledge and building it into systems. So that sort of scenario where an individual has got all the information in their head that doesn't happen so much. Ist das eine faire Einschätzung?

Jeff: It is. I think we've probably, I think as an industry we might have overstated its efficacy. And the only reason I say that is when our systems are getting so complicated, right? Gone are the days where someone has the entire system in their head and can understand it from beginning to end. Typically, there's two insidious parts of it. One, people typically focus on one specific area and someone doesn't have the whole picture, but what's even more insidious is that we think we understand how the system works. Rechts. And it's not until an incident happens that the mental model that we have of the system and the reality of the system come into conflict. And we realize that there's a divergence, right? So I think it's important that we continuously share knowledge in whatever form is efficient for folks, whether it be lunch and learns, documentation, I don't know, presentations, anything like that to sort of share and radiate that knowledge.

Jeff: But we also have to prepare and we have to prepare and define a reality where people may not completely understand how the system works. Rechts. And the reason I think it's important that we acknowledge that is because you can make a lot of bad decisions thinking you know how the system behaves and being 100% wrong. Rechts. So having the wherewithal to understand, okay, we think this is how the system works. We should take an extra second to verify that somehow. Rechts. I think that's super important in these complicated environments in these sprawling complex microservice environments. Whereas it can be very, it's easy to be cavalier if you think, oh yeah, this is definitely how it works. And I'm going to go ahead and shut the service down because everything's going to be fine. And then everything topples over. So just even being aware of the idea that, you know what, we may not know a hundred percent how this thing works.

Jeff: So let's take that into account with every decision that we make. I think that's key. And I think it's important for management to understand the reality of that as well because for management, it's easy for us to sit down and say, “Why didn't we know exactly how this thing was going to fail?” And it's like, because it's complicated, right, because there's 500 touch points, right, where these things are interacting. And if you change one of them, it changes the entire communication pattern. So it's hard and it's not getting any easier because we're getting excited about things like microservices. We're getting excited about things like Kubernetes. We're giving people more autonomy and these are just creating more and more complicated interfaces into these systems that we're managing. And it's becoming harder and harder for anyone to truly understand them in their entirety.

Drew: We've talked a lot about a professional context, big organizations and small organizations too. But I know many of us work on smaller side projects or maybe we volunteer on projects and maybe you're helping out someone in the community or a church or those sorts of things. Can a DevOps approach benefit those smaller projects or is it just really best left to big organizations to implement?

Jeff: I think DevOps can absolutely benefit those smaller projects. And specifically, because I think sort of some of the benefits that we've talked about get amplified in those smaller projects. Rechts? So exporting of expertise with automation is a big one, right? If I am… Take your church example, I think is a great one, right? If I can build a bunch of automated tests suites to verify that a change to some HTML doesn't break the entire website, right, I can export that expertise so that I can give it to a content creator who has no technical knowledge whatsoever. Rechts. They're a theologian or whatever, and they just want to update a new Bible verse or something, right. But I can export that expertise so that they know that I know when I make this content change, I'm supposed to run this build button.

Jeff: And if it's green, then I'm okay. And if it's red, then I know I screwed something up. Rechts. So you could be doing any manner of testing in there that is extremely complicated. Rechts. It might even be something as simple as like, hey, there's a new version of this plugin. And when you deploy, it's going to break this thing. Rechts. So it has nothing to do with the content, but it's at least a red mark for this content creator to say “Oh, something bad happened. I shouldn't continue. Rechts. Let me get Drew on the phone and see what's going on.” Rechts. And Drew can say, “Oh right. This plugin is upgraded, but it's not compatible with our current version of WordPress or whatever.” Rechts. So that's the sort of value that we can add with some of these DevOps practices, even in a small context, I would say specifically around automation and specifically around some of the cultural aspects too.

Jeff: Right? So I've been impressed with the number of organizations that are not technical that are using get to make changes to everything. Rechts. And they don't really know what they're doing. They just know, well, this is what we do. This is the culture. And I add this really detailed commit message here. And then I push it. They are no better than us developers. They know three get commands, but it's the ones they use over and over and over again. But it's been embedded culturally and that's how things are done. So everyone sort of rallies around that and the people that are technical can take that pattern.

Jeff: … around that and the people that are technical can take that pattern and leverage it into more beneficial things that might even be behind the scenes that they don't necessarily see. So I think there's some value, definitely. It's a matter of how deep you want to go, even with the operations piece, right? Like being able to recreate a WordPress environment locally very easily, with something like Docker. They may not understand the technology or anything, but if they run Docker Compose Up or whatever, and suddenly they're working on their local environment, that's hugely beneficial for them and they don't really need to understand all the stuff behind it. In that case, it's worthwhile, because again, you're exporting that expertise.

Drew: We mentioned right at the beginning, sort of putting off as much sort of DevOps as possible. You mentioned using tools like Heroku. And I guess that sort of approach would really apply here on getting started with, with a small project. What sort things can platforms like Heroku offer? I mean, obviously, I know you're not a Heroku expert or representative or anything, but those sorts of platforms, what sort of tools are they offering that would help in this context?

Jeff: So for one, they're basically taking that operational context for you and they're really boiling it down into a handful of knobs and levers, right? So I think what it offers is one, it offers a very clear set of what we call the yellow brick road path, where it's like, “If you go this route, all of this stuff is going to be handled for you and it's going to make your life easier. If you want to go another route, you can, but then you got to solve for all this stuff yourself.” So following the yellow brick road route helps because one, they're probably identifying a bunch of things that you hadn't even thought of. So if you're using their database container or technology, guess what? You're going to get a bunch of their metrics for free. You're going to get a lot of their alerting for free. You didn't do anything. You didn't think anything. It's just when you need it, it's there. And it's like, “Oh wow, that's super are helpful.”

Jeff: Two, when it comes to performance sizing and flexibility, this becomes very easy to sort of manage because the goal is, you're a startup that's going to become wildly successful. You're going to have hockey stick growth. And the last thing you necessarily really want to be doing is figuring out how to optimize your code for performance, while at the same time delivering new features. So maybe you spend your way out of it. You say, “Well, we're going to go up to the next tier. I could optimize my query code, but it's much more efficient for me to be spending time building this next feature that's going to bring in this new batch of users, so let's just go up to the next tier,” and you click button and you move on.

Jeff: So being able to sort of spend your way out of certain problems, I think it's hugely beneficial because tech debt gets a bad rap, but tech debt is no different than any debt. It's the trade off of acquiring something now and dealing with the pain later. And that's a strategic decision that you have to make in every organization. So unchecked tech debt is bad, right? But tech debt generally, I think, is a business choice and Heroku and platforms like that enable you to make that choice when it comes to infrastructure and performance.

Drew: You've written a book, Operations, Anti-Patterns, DevOps Solutions, for Manning. I can tell it's packed with years of hard-earned experience. The knowledge sort of just leaps out from the page. And I can tell it's been a real labor of love. It's packed full of information. Who's your sort of intended audience for that book? Is it mostly those who are already working in DevOps, or is it got a broader-

Jeff: It's got a broader… So one of the motivations for the book was that there were plenty of books for people that we're already doing DevOps. You know what I mean? So we were kind of talking to ourselves and high-fiving each other, like, “Yeah, we're so advanced. Awesome.” But what I really wanted to write the book for were people that were sort of stuck in these organizations. I don't want to use the term stuck. That's unfair, but are in these organizations that maybe aren't adopting DevOps practices or aren't at the forefront of technology, or aren't necessarily cavalier about blowing up the way they do work today, and changing things.

Jeff: Ich wollte es ihnen schreiben, hauptsächlich Einzelpersonen und mittleren Managern, um zu sagen: „Sie müssen kein CTO sein, um diese Art von inkrementellen Änderungen vornehmen zu können, und Sie müssen dies nicht haben Whole-Sale-Revolution, um einige der Vorteile von DevOps nutzen zu können.“ Es war also wirklich eine Art Liebesbrief an sie, wenn sie sagten: „Hey, du kannst das in Stücken machen. Sie können dies selbst tun. Und es gibt all diese Dinge, von denen Sie vielleicht nicht glauben, dass sie mit DevOps zu tun haben, weil Sie es als Tools und Kubernetes betrachten.“ Nicht jede Organisation … Wenn Sie für diesen Staat New York wären, wie die Landesregierung, würden Sie Kubernetes nicht einfach über Nacht implementieren. Rechts? Aber Sie können implementieren, wie Teams miteinander sprechen, wie sie zusammenarbeiten, wie wir die Probleme des anderen verstehen und wie wir diese Probleme durch Automatisierung lösen können. Das sind Dinge, die in Ihrem Einflussbereich liegen und Ihren Alltag verbessern können.

Jeff: Es war also wirklich ein Brief an diese Leute, aber ich denke, es sind genug Daten und Informationen für Leute in einer DevOps-Organisation enthalten, um daraus etwas zu entnehmen und zu sagen: „Hey, das ist immer noch nützlich für uns. ” Und ich denke, viele Leute erkennen schnell, wenn sie das Buch lesen, dass sie nicht in einer DevOps-Organisation sind, sie haben nur einen Jobtitelwechsel. Und das passiert ziemlich oft. Sie sagen also: „Hey, wir sind jetzt DevOps-Ingenieure, aber wir führen diese Art von Praktiken nicht durch, über die in diesem Buch gesprochen wird, und wie kommen wir dorthin?“

Drew: Es hört sich so an, als wäre Ihr Buch eines davon, aber gibt es andere Ressourcen, an die sich Leute wenden könnten, die mit DevOps anfangen möchten? Gibt es gute Orte, um dieses Zeug zu lernen?

Jeff: Ja. Ich denke, DevOps für Dummies von Emily Freeman ist ein großartiger Ausgangspunkt. Es macht wirklich einen großartigen Job, einige der Kernkonzepte und Ideen zu sortieren und darzulegen, und was wir anstreben. Das wäre also ein guter Anfang, nur um sich einen Überblick über das Land zu verschaffen. Ich denke, das Phoenix Project ist offensichtlich eine weitere großartige Quelle von Gene Kim. Und das ist großartig, das schafft die Voraussetzungen für die Arten von Problemen, die nicht in einer DevOps-Umgebung auftreten können. Und es macht einen großartigen Job, diese Muster und Persönlichkeiten hervorzuheben, die wir in allen Arten von Organisationen immer wieder sehen. Ich denke, es macht einen großartigen Job, diese hervorzuheben. Und wenn Sie dieses Buch lesen, werden Sie am Ende die Seiten anschreien und sagen: „Ja, ja. Dies. Dies." Also, das ist ein weiterer großartiger Ort.

Jeff: Und von dort aus tauchen Sie in eines der DevOps-Handbücher ein. Ich werde mich selbst in den Hintern treten, weil ich das gesagt habe, aber das Google SRE-Handbuch war ein weiterer großartiger Ort, um nachzusehen. Verstehen Sie, dass Sie nicht Google sind, also haben Sie nicht das Gefühl, dass Sie alles umsetzen müssen, aber ich denke, dass viele ihrer Ideen und Strategien für jede Organisation sinnvoll sind und großartige Orte sind, an denen Sie Dinge umsetzen können sagen: „Okay, wir werden unsere Betriebsumgebung ein wenig effizienter gestalten.“ Und das wird, denke ich, besonders hervorstechend für Entwickler sein, die eine operative Rolle spielen, weil es sich auf eine Art programmatischen Ansatz zur Lösung einiger dieser Probleme konzentriert.

Drew: Ich habe also alles über DevOps gelernt. Was hast du in letzter Zeit gelernt, Jeff?

Jeff: Kubernetes, Mann. Ja. Kubernetes war für uns eine echte Art von Lese- und Wissensquelle. Also versuchen wir gerade, das bei Centro zu implementieren, um Entwicklern mehr Möglichkeiten zu geben. Wir wollen noch einen Schritt weiter gehen, wo wir jetzt sind. Wir haben viel Automatisierung implementiert, aber im Moment ist mein Team, wenn es um das Onboarding eines neuen Dienstes geht, immer noch ziemlich stark damit beschäftigt, je nach Art des Dienstes. Und wir wollen nicht in dieser Branche tätig sein. Wir möchten, dass Entwickler in der Lage sind, eine Idee vom Konzept über den Code bis zur Bereitstellung umzusetzen, und zwar dort, wo das operative Fachwissen im System kodifiziert ist. Wenn Sie sich also durch das System bewegen, führt Sie das System. Wir glauben also, dass Kubernetes ein Tool ist, das uns dabei helfen wird.

Jeff: Es ist einfach unglaublich kompliziert. Und es ist ein großes Stück zum Abbeißen. Also herausfinden, wie Bereitstellungen aussehen? Wie nutzen wir diese Operatoren innerhalb von Kubernetes? Wie sieht CICD in dieser neuen Welt aus? Es wurde also viel gelesen, aber in diesem Bereich lernt man ständig dazu, oder? Es spielt keine Rolle, wie lange Sie schon dabei sind, wie lange Sie es schon tun, Sie sind irgendwo auf diesem Gebiet ein Idiot. Es ist also nur etwas, woran man sich anpasst

Drew: Nun, Hut ab, wie gesagt, selbst nach all den Jahren, obwohl ich irgendwie verstehe, wo es im Stack sitzt, habe ich immer noch keine Ahnung, was Kubernetes tut.

Jeff: Mir geht es manchmal ähnlich. Es fühlt sich an, als würde es ein bisschen von allem tun, oder? Es ist das DNS des 21. Jahrhunderts.

Drew: Wenn Sie, der Zuhörer, mehr von Jeff hören möchten, finden Sie ihn auf Twitter, wo er dunkel und nerdig ist, und finden Sie sein Buch und Links zu früheren Präsentationen und Blog-Beiträgen auf seiner Website attainabledevops.com. Danke, dass du heute dabei bist, Jeff. Gab es Abschiedsworte?

Jeff: Lernen Sie einfach weiter, gehen Sie einfach raus, lernen Sie weiter und sprechen Sie mit Ihren Kollegen. Reden reden reden. Je mehr Sie mit den Menschen sprechen können, mit denen Sie zusammenarbeiten, desto besser verstehen Sie sie, desto mehr Empathie entwickeln Sie für sie, und wenn es jemanden in der Organisation gibt, den Sie hassen, stellen Sie sicher, dass Sie zuerst mit ihm sprechen.