Basierend auf einer Chat-Diskussion
In letzter Zeit kam es zu regelrechten Auseinandersetzungen um die Definition von DevOps und SRE.
Trotz der Tatsache, dass die Diskussionen zu diesem Thema mich, mich eingeschlossen, in vielerlei Hinsicht bereits nervös gemacht haben, habe ich beschlossen, meine Meinung zu diesem Thema vor Gericht der Habra-Gemeinschaft zu bringen. Interessierte sind herzlich willkommen bei cat. Und lass alles von vorne beginnen!
Vorgeschichte
In der Antike lebte also ein Team aus Softwareentwicklern und Serveradministratoren getrennt. Der erste schrieb erfolgreich den Code, der zweite richtete mit verschiedenen warmen, liebevollen Worten an den ersten die Server ein, kam regelmäßig zu den Entwicklern und erhielt als Antwort eine umfassende Antwort: „Auf meinem Rechner funktioniert alles.“ Das Unternehmen wartete auf die Software, alles war untätig, es ging immer wieder kaputt, alle waren nervös. Vor allem derjenige, der für diesen ganzen Schlamassel bezahlt hat. Glorreiche Lampenära. Nun, Sie wissen bereits, woher DevOps kommt.
Die Geburt von DevOps-Praktiken
Dann kamen ernsthafte Leute und sagten: Das ist keine Branche, so kann man nicht arbeiten. Und sie brachten Lebenszyklusmodelle ein. Hier ist zum Beispiel das V-Modell.
Was sehen wir also? Ein Unternehmen kommt mit einem Konzept, Architekten entwerfen Lösungen, Entwickler schreiben Code und dann scheitert es. Irgendwie testet jemand das Produkt, jemand liefert es irgendwie an den Endverbraucher, und irgendwo am Ausgang dieses Wundermodells sitzt ein einsamer Geschäftskunde und wartet am Meer auf das versprochene Wetter. Wir kamen zu dem Schluss, dass wir Methoden brauchen, die es uns ermöglichen, diesen Prozess zu etablieren. Und wir beschlossen, Praktiken zu schaffen, die diese umsetzen würden.
Ein lyrischer Exkurs zum Thema, was Praxis ist
Mit Übung meine ich eine Kombination aus Technologie und Disziplin. Ein Beispiel ist die Praxis, Infrastruktur mithilfe von Terraform-Code zu beschreiben. Disziplin ist die Art und Weise, wie man Infrastruktur mit Code beschreibt, sie findet im Kopf des Entwicklers statt und Technologie ist die Terraform selbst.
Und sie beschlossen, sie DevOps-Praktiken zu nennen – ich glaube, sie meinten von der Entwicklung bis zum Betrieb. Wir haben uns verschiedene clevere Dinge ausgedacht – CI/CD-Praktiken, Praktiken nach dem IaC-Prinzip, Tausende davon. Und los geht's, Entwickler schreiben Code, DevOps-Ingenieure wandeln die Beschreibung des Systems in Form von Code in funktionierende Systeme um (ja, der Code ist leider nur eine Beschreibung, aber nicht die Verkörperung des Systems), die Auslieferung geht weiter, und so weiter. Die Administratoren von gestern, die neue Praktiken beherrschten, ließen sich stolz zu DevOps-Ingenieuren umschulen, und von da an ging alles weiter. Und es wurde Abend, und es wurde Morgen ... Entschuldigung, nicht von da an.
Es ist nicht wieder alles gut, Gott sei Dank
Sobald sich alles beruhigte und verschiedene schlaue „Methodologen“ begannen, dicke Bücher über DevOps-Praktiken zu schreiben, kam es in aller Stille zu Streitigkeiten darüber, wer der berüchtigte DevOps-Ingenieur war und dass DevOps eine Produktionskultur ist, und es kam erneut zu Unzufriedenheit. Plötzlich stellte sich heraus, dass die Softwarebereitstellung eine absolut nicht triviale Aufgabe ist. Jede Entwicklungsinfrastruktur hat ihren eigenen Stack, irgendwo muss man ihn zusammenbauen, irgendwo muss man die Umgebung bereitstellen, hier braucht man Tomcat, hier braucht man eine raffinierte und komplizierte Möglichkeit, es zu starten – im Allgemeinen klopft einem der Kopf. Und seltsamerweise stellte sich heraus, dass das Problem vor allem in der Organisation von Prozessen lag – diese Lieferfunktion begann wie ein Engpass Prozesse zu blockieren. Darüber hinaus hat niemand Operationen abgesagt. Im V-Modell ist es zwar nicht sichtbar, rechts befindet sich aber dennoch der gesamte Lebenszyklus. Daher ist es notwendig, die Infrastruktur irgendwie aufrechtzuerhalten, die Überwachung zu überwachen, Vorfälle zu beheben und sich auch um die Lieferung zu kümmern. Diese. Ich saß mit einem Bein sowohl in der Entwicklung als auch im Betrieb – und plötzlich hieß es „Development & Operations“. Und dann war da noch der allgemeine Hype um Microservices. Und mit ihnen begann sich die Entwicklung von lokalen Maschinen in die Cloud zu verlagern. Versuchen Sie, etwas lokal zu debuggen. Wenn es Dutzende und Hunderte von Mikrodiensten gibt, wird die ständige Bereitstellung zum Überlebensmittel. Für ein „kleines, bescheidenes Unternehmen“ war das in Ordnung, aber trotzdem? Was ist mit Google?
SRE von Google
Google kam, aß die größten Kakteen und entschied: Wir brauchen das nicht, wir brauchen Zuverlässigkeit. Und Zuverlässigkeit muss gemanagt werden. Und ich habe beschlossen, dass wir Spezialisten brauchen, die für Zuverlässigkeit sorgen. Ich nannte sie SR-Ingenieure und sagte, das war's für Sie, machen Sie es gut wie immer. Hier ist SLI, hier ist SLO, hier ist Überwachung. Und er steckte seine Nase in Operationen. Und er nannte seinen „zuverlässigen DevOps“ SRE. Alles scheint in Ordnung zu sein, aber es gibt einen schmutzigen Hack, den sich Google leisten könnte: Stellen Sie für die Position der SR-Ingenieure Leute ein, die qualifizierte Entwickler sind, ein paar Hausaufgaben gemacht haben und die Funktionsweise funktionierender Systeme verstehen. Darüber hinaus hat Google selbst Probleme mit der Einstellung solcher Leute – vor allem, weil es hier mit sich selbst konkurriert – es ist notwendig, jemandem die Geschäftslogik zu beschreiben. Die Lieferung wurde Release-Ingenieuren zugewiesen, SR – Ingenieure verwalten die Zuverlässigkeit (natürlich nicht direkt, sondern durch Einflussnahme auf die Infrastruktur, Änderung der Architektur, Verfolgung von Änderungen und Indikatoren, Umgang mit Vorfällen). Schön, dass du das kannst . Aber was ist, wenn Sie kein Google sind, die Zuverlässigkeit aber trotzdem ein Problem darstellt?
Entwicklung von DevOps-Ideen
Gerade dann kam Docker, das aus lxc hervorging, und dann verschiedene Orchestrierungssysteme wie Docker Swarm und Kubernetes, und DevOps-Ingenieure atmeten aus – die Vereinheitlichung der Praktiken vereinfachte die Bereitstellung. Es vereinfachte es so weit, dass es sogar möglich wurde, die Bereitstellung an Entwickler auszulagern – was ist „deployment.yaml“. Containerisierung löst das Problem. Und die Reife von CI/CD-Systemen ist bereits auf dem Niveau des Schreibens einer Datei und los geht’s – die Entwickler können sich selbst darum kümmern. Und dann fangen wir an, darüber zu reden, wie wir unser eigenes SRE machen können, mit ... oder zumindest mit jemandem.
SRE ist nicht bei Google
Nun gut, wir haben die Lieferung geliefert, es scheint, wir können aufatmen und zu den guten alten Zeiten zurückkehren, als Administratoren zusahen, wie der Prozessor belastet wurde, die Systeme abgestimmt und in aller Ruhe etwas Unverständliches aus Tassen schlürften ... Stopp. Das ist nicht der Grund, warum wir alles angefangen haben (was schade ist!). Plötzlich stellt sich heraus, dass wir im Google-Ansatz problemlos hervorragende Praktiken übernehmen können – es ist nicht die Prozessorlast, die wichtig ist, und nicht, wie oft wir dort die Festplatten wechseln oder die Kosten in der Cloud optimieren, aber die Geschäftskennzahlen sind dieselben berüchtigten SLx. Und niemand hat ihnen das Infrastrukturmanagement entzogen, und sie müssen Vorfälle lösen, regelmäßig im Dienst sein und im Allgemeinen den Überblick über die Geschäftsprozesse behalten. Und Leute, fangt nach und nach an, auf einem guten Niveau zu programmieren, Google wartet bereits auf euch.
Zusammenfassen. Plötzlich, aber Sie sind schon müde vom Lesen und können es kaum erwarten, dem Autor einen Kommentar zum Artikel zu schreiben. DevOps als Bereitstellungspraxis war schon immer und wird es auch sein. Und es führt nirgendwo hin. SRE als eine Reihe betrieblicher Praktiken macht genau diese Umsetzung erfolgreich.
Source: habr.com