Basierend auf der Diskussion im Chat
In letzter Zeit entbrennen echte Kämpfe darüber, wie die Begriffe DevOps und SRE definiert werden sollen.
Obwohl ich bereits viel über dieses Thema gehört habe, wollte ich meine Sichtweise der Habr-Community präsentieren. Interessierte sind herzlich eingeladen, weiterzulesen. Möge alles neu beginnen!
Hintergrund
In alten Zeiten lebte ein Team von Softwareentwicklern getrennt von den Serveradministratoren. Die Ersten schrieben fleißig Code, während die Letzteren, ausgestattet mit liebevollen Worten, die Server einrichteten und gelegentlich zu den Entwicklern gingen, um das altbekannte 'Auf meinem Rechner funktioniert alles' zu hören. Das Geschäft wartete auf Software, alles stand still, brach manchmal zusammen, und alle waren nervös. Besonders derjenige, der für das ganze Durcheinander bezahlte. Eine glorreiche, nostalgische Ära. Aber das wissen Sie sicher, woher DevOps kommt.
Die Geburt von DevOps-Praktiken
Dann kamen ernsthafte Herren und sagten - das ist keine Branche, so kann man nicht arbeiten. Und sie brachten Lebenszyklusmodelle mit. Hier zum Beispiel das V-Modell.
Was sehen wir also? Unternehmen entwickeln Konzepte, Architekten gestalten Lösungen, Entwickler schreiben Code, und dann folgt oft das Chaos. Jemand testet das Produkt auf die eine oder andere Art, jemand anders bringt es zum Endbenutzer, und irgendwo am Ende dieses Wunderprozesses sitzt ein einsamer Geschäftskunde und wartet auf die versprochene Verbesserung. Wir sind zu dem Schluss gekommen, dass Methoden benötigt werden, um diesen Prozess zu optimieren. Daher haben wir Praktiken entwickelt, die diese Ziele umsetzen.
Ein lyrischer Einschub zur Frage, was eine Praxis ist.
Unter Praxis verstehe ich die Verbindung von Technologie und Disziplin. Ein Beispiel wäre die Praxis der Infrastrukturgestaltung mit Code in Terraform. Die Disziplin bezeichnet, wie man die Infrastruktur mit Code beschreibt; sie existiert im Kopf des Entwicklers, während die Technologie selbst Terraform ist.
Sie beschlossen, diese Praktiken als DevOps zu bezeichnen – ich nehme an, sie dachten dabei an den Übergang von der Entwicklung zu den Betrieb. Es wurden verschiedene komplexe Konzepte erfunden – CI/CD-Praktiken, Praktiken basierend auf dem IaC-Prinzip, und viele mehr. Und los ging's: Entwickler schreiben Code, DevOps-Engenieure transformieren Systembeschreibungen in funktionierende Systeme (ja, Code ist leider lediglich eine Beschreibung, aber keineswegs die Umsetzung des Systems), die Bereitstellung läuft, und so weiter. Die ehemaligen Administratoren, die sich mit den neuen Praktiken vertraut gemacht hatten, haben sich stolz in DevOps-Ingenieure umgeschult, und alles nahm seinen Lauf. Und es war Abend, und es war Morgen… Entschuldigung, das kommt nicht von dort.
Alles ist wieder nicht in Ordnung.
Sobald alles sich beruhigt hatte, begannen verschiedene schlaue "Methodologen" dicke Bücher über DevOps-Praktiken zu schreiben, und die Diskussion darüber, was ein "DevOps-Ingenieur" wirklich ist und dass DevOps eine Produktionskultur ist, kriselte erneut. Plötzlich stellte sich heraus, dass die Softwarelieferung eine absolut nicht triviale Aufgabe ist. Jede Entwicklungsinfrastruktur hat ihren eigenen Stack: An manchen Stellen muss zusammengebaut, an anderen die Umgebung aufgesetzt werden, hier wird Tomcat benötigt, dort ein ausgeklügelter Startmodus – kurz gesagt, es ist verwirrend. Und seltsamerweise lag das Hauptproblem in der Organisation der Prozesse; dieser Lieferprozess, wie ein Flaschenhals, blockierte alles andere. Außerdem blieb die Betriebsführung (Operations) nicht aus. Diese wird in der V-Modell-Darstellung nicht sichtbar, obwohl dort der gesamte Lebenszyklus zu finden ist. Letztendlich muss man die Infrastruktur unterstützen, das Monitoring im Blick behalten, Incidents managen und sich auch um die Lieferung kümmern. Das heißt, man sitzt sowohl in der Entwicklung als auch im Betrieb – und plötzlich wurde daraus Development & Operations. Und dann kam noch der große Hype um Microservices. Mit ihnen begann auch die Entwicklung, von lokalen Maschinen in die Cloud zu wechseln – probiere mal, etwas lokal zu debuggen, wenn es Dutzende oder Hunderte von Microservices gibt, da wird die kontinuierliche Lieferung zum Überlebensmittel. Für eine "kleine bescheidene Firma" mag das noch machbar sein, aber was ist mit größeren Unternehmen? Und Google?
SRE von Google
Google kam, fraß die größten Kakteen und entschied – wir brauchen das nicht, wir brauchen Zuverlässigkeit. Und Zuverlässigkeit muss gemanagt werden. Also kam die Idee – wir brauchen Fachleute, die die Zuverlässigkeit verwalten. Er nannte sie SR-Ingenieure und sagte, hier ist alles, macht es so wie gewohnt, gut. Hier ist euer SLI, hier ist euer SLO, hier ist das Monitoring. Und er zeigte mit dem Finger auf die Betriebsabläufe. So nannte er sein 'verlässliches DevOps' SRE. An sich klingt das gut, aber es gibt einen schmutzigen Hack, den sich Google leisten konnte – bei den SR-Ingenieuren Leute einzustellen, die Entwicklerqualifikationen hatten und sich noch etwas mit dem Betrieb funktionierender Systeme auskannten. Und Google hatte selbst Schwierigkeiten mit der Einstellung solcher Leute – hauptsächlich, weil er in diesem Bereich mit sich selbst konkurriert – schließlich muss auch jemand die Geschäftslogik beschreiben. Die Auslieferung wurde auf Release-Ingenieure verteilt, die SR-Ingenieure managen die Zuverlässigkeit (naturgemäß nicht direkt, sondern durch Einflussnahme auf die Infrastruktur, Änderung der Architektur, Verfolgung von Änderungen und Kennzahlen, sowie die Bearbeitung von Vorfällen). Schön gemacht, man kann . Was ist zu tun, wenn Sie nicht Google sind, aber Zuverlässigkeit dennoch ein Anliegen ist?
Entwicklung von DevOps-Ideen
Hier kommt Docker ins Spiel, das aus LXC hervorgegangen ist, gefolgt von verschiedenen Orchestrierungssystemen wie Docker Swarm und Kubernetes. DevOps-Ingenieure atmeten auf – die Vereinheitlichung der Praktiken erleichterte die Bereitstellung. So sehr, dass es sogar möglich wurde, die Bereitstellung den Entwicklern zu überlassen – was ist schon ein deployment.yaml? Die Containerisierung löst das Problem. Und die Reife der CI/CD-Systeme ist mittlerweile so weit fortgeschritten, dass es genügt, eine Datei zu erstellen, und schon läuft alles – die Entwickler kommen alleine zurecht. Und hier beginnen wir zu diskutieren, wie wir unser eigenes SRE erstellen können, mit… ja, mit irgendwem.
SRE kommt nicht von Google.
Nun gut, die Lieferung haben wir abgegeben, scheinbar können wir durchatmen und zu den guten alten Zeiten zurückkehren, als Admins die CPU-Auslastung überwachten, Systeme optimierten und in Ruhe aus Tassen etwas Unbestimmtes schlürften… Halt. Dafür haben wir das alles nicht angefangen (schade!). Plötzlich zeigt sich, dass wir in der Herangehensweise von Google viele ausgezeichnete Praktiken übernehmen können – es geht nicht um die Auslastung der Prozessoren, und nicht darum, wie oft wir die Festplatten wechseln oder die Kosten im Cloud optimieren, sondern um Geschäftskennzahlen – all die berühmten SLx. Und die Verwaltung der Infrastruktur bleibt davon unberührt, Vorfälle müssen gelöst werden, und man muss regelmäßig präsent sein und überhaupt mit den Geschäftsprozessen vertraut sein. Jungs, fangt an, langsam auf einem vernünftigen Niveau zu programmieren, Google wartet bereits auf euch.
Zusammenfassend. Plötzlich, aber ihr seid schon müde zu lesen, und könnt es kaum erwarten, dem Autor einen Kommentar zu schreiben. DevOps als Lieferpraxis war, ist und wird immer sein. Und wird nicht verschwinden. SRE als Satz von Betriebspraktiken macht diese Lieferung erfolgreich.
Quelle: habr.com
