Was ist der Unterschied zwischen SRE und DevOps?
In diesem Essay haben wir versucht zu zeigen, warum die folgenden Antworten auf die Fragen angemessen sind: Was sollten Sie zwischen SRE und DevOps wählen? Ist SRE nur auf Cloud-Umgebungen anwendbar? Was genau ist die Funktion des DevOps-Teams? Sind SRE und DevOps miteinander kompatibel? Benötigt SRE Codierung? Ist es eine gute Idee, eine Karriere im Bereich DevOps anzustreben? Die Antworten auf all diese Fragen finden Sie auf dieser Seite.
Wenn es um Softwareentwicklung, -veröffentlichung und -produktion geht, können Unternehmen entweder SRE oder DevOps wählen. Eine umfassende Analyse der Unterschiede und Ähnlichkeiten zwischen diesen beiden Methoden kann Unternehmen jedoch bei der Auswahl der am besten geeigneten Strategie helfen.
Was ist „DevOps“?
Entwicklung und Betrieb werden in der Praxis zusammengeführt, die als „DevOps“ bezeichnet wird. Der Zweck von DevOps besteht darin, sicherzustellen, dass dasselbe Team, das für die Entwicklung verantwortlich ist, auch für die Wartung des Codes in der Produktion verantwortlich ist.
Die Möglichkeit, Anwendungsupgrades vor der Bereitstellung von Software zu bewerten, wird durch kontinuierliche Bereitstellung für Entwickler ermöglicht. Neben kontinuierlicher Bereitstellung umfasst DevOps die Softwareentwicklung, die Veröffentlichung neuer Versionen, das Testen und Integrieren dieser neuen Versionen, das Konfigurationsmanagement und die Echtzeitüberwachung.
Was ist SRE?
Site Reliability Engineering ist das, was wir meinen, wenn wir SRE sagen. Software Reliability Engineering (SRE) ist eine Partnerschaft zwischen Softwareentwicklung und Systembetrieb. Eines der Ziele von SRE besteht darin, Probleme zu erkennen und vorbeugende Maßnahmen dagegen zu ergreifen, die zu Ausfallzeiten führen könnten.
Was genau ist SRE im Vergleich zu DevOps?
System Reliability Engineering ist eine Verschmelzung von Systembetrieb und Softwareentwicklung.
Software Reliability Engineering (SRE) befasst sich mit Aspekten der Softwareentwicklung wie Geschwindigkeit, Qualität, Design, Agilität und Innovation. Darüber hinaus ist SRE für betriebliche Anforderungen wie Wartbarkeit, Verfügbarkeit, Wartungsfreundlichkeit und Leistung verantwortlich.
Was ist der Unterschied zwischen SRE und DevOps im Vergleich
SRE vs. DevOps – ein organisatorischer Vergleich
In den meisten Unternehmen arbeiten viele Abteilungen an demselben Produkt. Das Produkt kann jedoch nur dann erfolgreich sein, wenn diese Abteilungen zusammenarbeiten.
Die Unterschiede, die zwischen den Teammitgliedern auftreten können, können mithilfe von DevOps gelöst werden, das alle unter einem gemeinsamen Ziel näher zusammenbringt. Der Zweck der DevOps-Methodik besteht darin, eine effiziente Ressourcenverwaltung in allen Abteilungen einer Organisation zu ermöglichen.
Die SREs hingegen greifen die Silos nicht direkt an, sondern ermutigen alle zur Diskussion. Aus diesem Grund wird die Verantwortung für ein Produkt gleichmäßig auf alle Mitarbeiter der Organisation verteilt, die daran arbeiten.
SRE vs. DevOps: Testfehler
Wenn Software nicht ständig getestet wird, wissen Unternehmen, dass sie irgendwann kaputt gehen wird. DevOps verwendet automatisierte Tests, um Probleme zu entdecken und Risiken zu minimieren. DevOps stellt durch diese Vorgehensweise sicher, dass die Teams nicht dieselben Fehler machen.
Fehler werden von SREs mithilfe von zwei verschiedenen Ansätzen untersucht, nämlich Service-Level-Indikatoren und Service-Level-Zielen. SLOs stellen den Erfolgsprozentsatz von SLIs dar, der die Anzahl der Fehler quantifiziert, die pro Anfrage im Laufe der Zeit auftreten.
Messung des Fortschritts zwischen SRE und DevOps
Die Effektivität von DevOps wird anhand dieser vier Kennzahlen bewertet. Zu diesen Faktoren gehören die Anzahl der Bereitstellungen, die Zeit, die zur Wiederherstellung des Dienstes benötigt wird, die Zeit, die zur Vorbereitung auf Änderungen benötigt wird, und der Prozentsatz erfolgreicher Änderungen.
SREs überwachen den Fortschritt anhand von vier Signalen: Verkehr, Latenz, Sättigung und Fehler. Bei der Messung müssen Entwickler die bestehenden Standards berücksichtigen, die jeder Statistik entsprechen.
Teamorganisation in Bezug auf SRE vs. DevOps.
Site Reliability Engineers mit Erfahrung in der Softwareentwicklung und im Betrieb bilden das Rückgrat von SRE-Teams.
Innerhalb eines DevOps-Teams können viele verschiedene Rollen besetzt werden. Einige Beispiele für diese Rollen sind Qualitätsanalysten, Softwareentwickler, Release-Manager, Systemadministratoren, Produktbesitzer und System Reliability Engineers.
SRE versus DevOps: Tools
Container, Microservices, kontinuierliche Integration und Bereitstellung, Infrastruktur als Code, Belastbarkeitstests und Überwachungssysteme sind einige der Technologien, die DevOps und SREs gemeinsam haben. Zu den weiteren Tools gehören Belastbarkeitstests.
SRE versus DevOps: Fokus
Das Hauptziel von SRE ist die Entwicklung von Anwendungen, die sowohl sehr zuverlässig als auch sehr skalierbar sind. Daher konzentrieren sich die Aufgaben eines SRE hauptsächlich darauf, die Zuverlässigkeit der Anwendung sicherzustellen und aufrechtzuerhalten, anstatt häufige Änderungen vorzunehmen.
DevOps hingegen befasst sich hauptsächlich mit der Erstellung von Produktionsumgebungen, in denen Entwickler mehr Kontrolle haben. Das Ziel von DevOps ist die Implementierung von CI/CD-Pipelines in allen Phasen des Produkts, um eine agile Entwicklung zu ermöglichen.
SRE vs. DevOps: Unterschiede in der Art und Weise, wie Änderungen implementiert werden
Anstatt umfangreiche Updates auf einmal für die Softwareanwendung zu veröffentlichen, nimmt DevOps im Laufe der Zeit inkrementelle Anpassungen am Produkt vor. Wenn dies getan wird, gibt es weniger Probleme in DevOps-Apps und sie verfügen über ein besseres Überprüfungsmanagement.
SREs machen Änderungen schnell und oft rückgängig, um sicherzustellen, dass das Produkt fehlerfrei ist. SREs bewerten Updates mithilfe von Canary Releases, bevor sie Änderungen in die Produktion einbringen. Darüber hinaus muss der SRE ein Gleichgewicht zwischen Zuverlässigkeit und Häufigkeit der Updates finden.
Automatisierung ist ein wichtiger Unterschied zwischen SRE und DevOps.
SRE zielt darauf ab, langweilige Aufgaben loszuwerden, indem ermittelt wird, welche Aktivitäten mehr als fünfzig Prozent der Zeit eines Ingenieurs in Anspruch nehmen, und diese Aktivitäten dann eliminiert werden. Darüber hinaus sind SREs dafür verantwortlich, bestimmte Codes für eine Vielzahl von Prozessen vorzubereiten und diese Codes dann einem Playbook hinzuzufügen.
Die automatisierten Strategien von DevOps ermöglichen die Erstellung von Feedbackschleifen zwischen den Entwicklungs- und Betriebsteams. Der Zweck der von DevOps eingesetzten Automatisierung besteht darin, den Prozess der Einführung inkrementeller Änderungen an bereits laufenden Anwendungen zu beschleunigen.
Welche Vorteile bietet die Verwendung von SRE?
Google hat das SRE-Modell mit der Absicht entwickelt, es Entwicklern zu erleichtern, sich auf die Geschwindigkeit zu konzentrieren, mit der neue Funktionen hinzugefügt werden, und auf den Einfallsreichtum dieser Funktionen, während sich Systembetreiber gleichzeitig auf die Aufrechterhaltung von Konsistenz und Stabilität konzentrieren können.
Das Konzept lässt sich an jede Organisation anpassen, und in den letzten Jahren gab es ein spürbar steigendes Interesse an seiner Verwendung. Die Unternehmen, die das SRE-Modell implementiert haben, haben faszinierende Anekdoten mit vielen Gemeinsamkeiten zu erzählen, die sich um die Vorteile von SRE drehen und darum, wie sie diese Praktiken in einen greifbaren und positiven Einfluss auf ihr Geschäft umgesetzt haben.
Aus der Sicht eines Entwicklungsteams sind die Vorteile von SRE von Anfang an deutlich erkennbar. In der Vergangenheit lag der Hauptfokus von Entwicklungsteams auf der Anwendungsentwicklung und der Fähigkeit, so schnell wie möglich neue Funktionen bereitzustellen.
Offensichtlich ist sich eine moderne und erfahrene Gruppe bewusst, dass dies nur ein Bestandteil der Gleichung ist. Unter anderem trägt die Aufwendung von Zeit und Aufwand für die Entwicklung von Testtechniken, Prozessen für kontinuierliche Integration und Bereitstellung sowie Cloud-Automatisierung zur Gesundheit eines Softwaresystems bei.
Der Ansatz des Software Reliability Engineering (SRE) liefert Teams Prinzipien der Softwareentwicklung, die auf ihre IT-Abläufe angewendet werden können. Dies hilft Teams, die Messlatte für operative Exzellenz höher zu legen. Dank dieser Prinzipien können sie Verbesserungen in verschiedenen Bereichen erzielen, darunter Kapazität, Leistung, Verfügbarkeit und Latenz. SRE-Praktiken sind eine Disziplin, die sich darauf konzentriert, den Prozess des Betriebs und der Wartung von Softwarelösungen zu verkürzen und letztendlich zu vereinfachen.
Diese Praktiken können eine Vielzahl von Facetten umfassen, die über den gesamten Softwarelebenszyklus hinweg vorhanden sind. Anstatt Änderungen an ihrer Softwarelösung zu vermeiden, verlagert ein Team, das SRE-Praktiken erfolgreich einführt, seine betriebliche Arbeitslast auf die alltäglichen Entwicklungsaufgaben und berücksichtigt die technischen Komplexitäten, die mit Skalierung und neuen Funktionen einhergehen. Diese Verlagerung erfolgt aufgrund der Entscheidung des Teams, Änderungen an seiner Softwarelösung nicht zu vermeiden. Einheitliche technische Vision und Koordination zwischen den verschiedenen Teams
Der Ansatz des Software Reliability Engineering (SRE) verleiht dem Unternehmen eine kohärente technische Vision, wenn er auf verschiedene Softwareentwicklungsteams angewendet wird. Diese einheitliche technische Vision fördert die Zusammenarbeit, den Informationsaustausch und eine einheitliche Sprache zwischen verschiedenen Teams. Im Gegensatz zur Einführung einer neuen Softwarebibliothek oder eines Bereitstellungstools liegt die effektive Einführung von SRE nicht nur in der Verantwortung des Softwareentwicklungsteams. Das Unternehmen und andere Stakeholder, die nicht technisch orientiert sind, haben erheblichen Einfluss auf die Fähigkeit, eine Kultur zu ermöglichen und zu pflegen, in der die SRE-Einstellung gedeihen kann. Mit einem Gespräch zwischen allen Stakeholdern darüber, was Zuverlässigkeit für das Unternehmen bedeutet, ist es wichtig, eine Kultur zu etablieren, in der sich die Entwicklungsteams psychologisch sicher fühlen, zu scheitern, und aus ihren Fehlern lernen können.
Ein Gespräch zwischen geschäftlichen und technischen Stakeholdern ist die einzige Möglichkeit, die notwendige Abstimmung herzustellen, um die verschiedenen Servicelevel zu definieren, ein Kernkonzept von SRE, und den Aufwand und die geschäftlichen Auswirkungen zu verstehen, die mit jedem Level verbunden sind. Für das SRE-Servicelevel entscheidende Konzepte Im Folgenden sind die wichtigsten SRE-Servicelevel-Konzepte aufgeführt: Service Level Indicators (SLIs) sind eine oder mehrere quantitative Zuverlässigkeitsmesswerte der Softwarelösung aus der Sicht Ihrer Kunden.
In einem webbasierten System sind die HTTP-Statuscodes und die gesamte End-to-End-Latenz einige nützliche Beispiele. Service Level Objectives (oft SLOs genannt) sind ein oder mehrere Ziele, die ein bestimmter SLI innerhalb einer vorgegebenen Zeitspanne erreichen muss. Im Kontext einer Weblösung kann dies bedeuten, jeden Monat maximal 1 % HTTP 5xx (Serverfehler) anzustreben oder täglich für jede HTTP-Anforderung eine Latenz von weniger als 200 Millisekunden zu erreichen.
Um die Zuverlässigkeit zu berechnen, teilen Sie die Anzahl der erfolgreichen Aktionen (d. h., wie oft es ordnungsgemäß funktioniert hat) durch die Gesamtzahl der Aktionen. So erhalten Sie den Zuverlässigkeitswert. Das Maß an Unzuverlässigkeit, das die verschiedenen Beteiligten bereit sind zu ertragen, wird als Fehlerbudget bezeichnet. Kurz gesagt kann dies ermittelt werden, indem der Zuverlässigkeitswert von 100 % des Gesamtwerts abgezogen wird.
Die SRE-Servicelevel-Konzepte und die damit verbundenen Zuverlässigkeits- und Fehlerbudgetwerte sind äußerst hilfreich, um diese gemeinsame Sprache in der gesamten Organisation zu etablieren. Dadurch entsteht ein gemeinsames Verständnis zwischen Unternehmen, Entwicklern und SRE-Ingenieuren hinsichtlich der Definition von Erwartungen und Verantwortlichkeiten. Auch wenn sie leicht zu verstehen sind, sind die SRE-Servicelevel-Konzepte und die damit verbundenen Zuverlässigkeits- und Fehlerbudgetwerte von Vorteil. Ebenso wichtig ist, dass die Festlegung eines Ziels von 100 % Zuverlässigkeit sowohl romantisch als auch falsch ist, da dies das Team an Innovationen hindert, das Team daran hindert, aus seinen Fehlern zu lernen, und die Geschwindigkeit verlangsamt, mit der neue Funktionen veröffentlicht werden.
Das Unternehmen selbst als Quelle der Wertschöpfung
Das SRE-Paradigma führte zu einer grundlegenden Veränderung der Denkweise von Führungskräften in Unternehmen über die operativen Aufgaben und Praktiken der Softwareentwicklung. In der Vergangenheit hielten die Geschäftspartner nur die Entwicklung neuer Softwareentwicklungsfunktionen für lohnenswert. Andererseits wurden zugrunde liegende IT-Operationen und andere Aktivitäten als lästige Ausgaben betrachtet. Aufgeklärte Organisationsführer in der modernen Softwareentwicklung von heute wissen, dass man der Entwicklung und Feinabstimmung eines großartigen Motors mehr Wert beimessen muss, wenn man ihn in ein altes, rostiges Chassis stecken will.
Sie sind sich dieser Tatsache bewusst, weil man der Entwicklung eines großartigen Motors mehr Wert beimessen muss. Daher ist es notwendig, die gesamte Softwarelösung in den verschiedenen Phasen ihres Lebenszyklus zu berücksichtigen und ihr einen angemessenen Wert zuzuweisen. Dieser Wert wurde besser verstanden, nachdem man eine SRE-Perspektive und den damit verbundenen Kulturwandel und die damit verbundenen Vorteile eingenommen hatte. Beispielsweise hat die Skalierbarkeit der Anwendung, um unerwarteten Verkehrsanforderungen zu besonderen Anlässen (wie dem Black Friday) gerecht zu werden, weniger mit der Geschäftslogik der Anwendung zu tun als vielmehr damit, wie Systemvorgänge gehandhabt und verwaltet werden. Skalierbarkeit ist die Fähigkeit einer Softwarelösung, unerwarteten Verkehrsanforderungen gerecht zu werden.
Andere Beispiele, wie die Optimierung der Cloud-Kosten oder angemessene Backup- und Notfallwiederherstellungsstrategien, die gleichzeitig Kosten und Risiken senken und die operative Exzellenz steigern, haben bewiesen, dass der Betrieb ein wichtiges Wertschöpfungszentrum ist (und als solches behandelt werden sollte). Weitere Beispiele:
Site Reliability Engineers sind für die kontinuierliche Förderung struktureller Verbesserungen verantwortlich und verfügen über eine seltene Mischung schwer zu findender Talente: ein umfassendes Verständnis der Technologie und einen Fokus auf die Bedürfnisse der Kunden. Daher ist der Versuch, Kosten für ein SRE-Team zu sparen, indem man die Anzahl der Mitarbeiter reduziert oder die Arbeit auslagert, oft eine schlechte Entscheidung. Es ist wichtig, sich darüber im Klaren zu sein, dass nur einige Softwarelösungen ein spezialisiertes SRE-Team oder spezielle SRE-Aufgaben erfordern.
Auch bei Google ist die Teilnahme an SRE-Teams freiwillig. Wenn der Umfang der Lösung oder die Reifephase des Projekts dieses Maß an Unterstützung nicht erfordert, kann die Arbeit, die für SRE geleistet werden muss, vom Entwicklungsteam übernommen und vorangetrieben werden. Trotzdem ist es wichtig, im Hinterkopf zu behalten, dass die SRE-Haltung und -Praktiken weiterhin umgesetzt und diese Kultur gepflegt werden muss.
Zusammenfassung
SRE und DevOps sind dieselben Dinge, nur aus unterschiedlichen Perspektiven betrachtet.
SRE (Site Reliability Engineering) und DevOps (Development Operations) sind Tools, die Unternehmen nutzen können, um die Kommunikation zwischen ihren Softwareentwicklungs- und Betriebsteams zu verbessern. Unternehmen sollten jedoch den Einsatz von DevOps in Betracht ziehen, wenn sie den Prozess der Markteinführung ihres Produkts beschleunigen und Upgrades während der laufenden Produktion integrieren möchten. Unternehmen hingegen, die eine Jobautomatisierung im großen Maßstab wünschen, müssen SREs als Lösung nutzen.
Versuchen Sie Prometteur Solutions, wenn Sie jemanden mit Fachwissen in DevOps oder Site Reliability Engineering einstellen müssen.
Prometteur Solutions ermöglicht es Unternehmen, vorab geprüfte Ingenieure in Silicon-Valley-Qualität in nur drei bis fünf Werktagen einzustellen. Aus einem Pool von insgesamt 2 Millionen Entwicklern.
FAQs
Was ist „DevOps“?
Entwicklung und Betrieb werden in der Praxis zusammengeführt, was als „DevOps“ bezeichnet wird.
Was ist SRE?
Site Reliability Engineering ist das, was wir meinen, wenn wir SRE sagen. Software Reliability Engineering (SRE) ist eine Partnerschaft zwischen Softwareentwicklung und Systembetrieb.
- Benötigt SRE Codierung?
Ja, Codierung ist für SREs erforderlich. Ingenieure, die auf Site Reliability spezialisiert sind, arbeiten daran, Wege zu finden, Systeme zuverlässiger zu machen. Um dieses Ziel zu erreichen, ist es gelegentlich erforderlich, in den Quellcode eines Systems einzudringen, das Problem zu identifizieren und häufig einen Patch für die Codebasis bereitzustellen.
- Ist ein Job in DevOps eine kluge Wahl?
In den letzten fünf Jahren ist die Nachfrage nach DevOps um 40 bis 50 Prozent gestiegen.
- Welche Programmiersprache ist ideal für den Einsatz in DevOps-Umgebungen?
Python ist aufgrund der großen Anzahl von Bibliotheksmodulen, die typische Aufgaben ausführen können, die beliebteste Sprache für DevOps. Die für die Programmierung verwendeten Sprachen bilden das Herzstück des Entwicklungsprozesses für DevOps-Systeme. Daher müssen Personen, die im DevOps-Bereich arbeiten, die entsprechenden Programmiersprachen kennen, die in diesen Systemtypen verwendet werden können.
