5 grundlegende Unterschiede zwischen DevOps und SRE, die Sie kennen sollten
Veröffentlicht: 2021-02-22Die Welt der Informationstechnologie und Softwareentwicklung verbindet DevOps oft mit SRE, um ein und dasselbe zu bedeuten. Es gibt jedoch große Unterschiede zwischen den beiden. Während Site Reliability Engineering (SRE) in den letzten Jahren an Bedeutung gewonnen hat, gibt es DevOps schon viel länger (noch bevor es den Begriff DevOps gab).
Einfach ausgedrückt: DevOps und SRE sind beides Praktiken, die eingeführt wurden, um Software schneller bereitzustellen. Der einzige Unterschied zwischen den beiden liegt in ihren Ansätzen; DevOps konzentriert sich darauf, den Lebenszyklus der Softwareentwicklung zu verkürzen, und SRE konzentriert sich auf die Beseitigung von Systemschwächen, um den gleichen Zweck zu erreichen.
In diesem Artikel werden wir uns die grundlegenden Unterschiede zwischen DevOps und SRE ansehen. Bevor wir das tun, beginnen wir damit, zu verstehen, was DevOps und SRE sind.
Inhaltsverzeichnis
Was ist DevOps?
Mit den Worten von Gene Kim, Autor von The DevOps Handbook und The Phoenix Project,
„DevOps ist [die] Reihe kultureller Normen und Technologiepraktiken, die den schnellen Fluss geplanter Arbeiten unter anderem von der Entwicklung über Tests bis hin zum Betrieb [ermöglichen] und gleichzeitig erstklassige Zuverlässigkeit, Betrieb und Sicherheit gewährleisten. Bei DevOps geht es nicht darum, was Sie tun, sondern was Ihre Ergebnisse sind.“
Daher konzentriert sich DevOps hauptsächlich darauf, die kulturellen Praktiken innerhalb einer Organisation zu transformieren, um den Software Development Lifecycle (SDLC) zu beschleunigen. Es ist nicht auf eine Person, Gruppe oder Position ausgerichtet. DevOps zielt darauf ab, die Zusammenarbeit zwischen den IT-Betriebs- und Softwareentwicklungsteams zu stärken.
Was es tut und wie es es tut, ist nicht wichtig; Nur das Ergebnis des Prozesses wird anerkannt.
DevOps verwendet eine Reihe von Prinzipien, um den Kontakt eines Softwareentwicklungsteams mit Produktionssystemen zu intensivieren, und ermöglicht es dem IT-Betriebsteam, Diskrepanzen effizienter an das Entwicklungsteam zu eskalieren. Tatsächlich spielt SRE eine entscheidende Rolle in einer DevOps-Organisation, indem es proaktives Testen, Geschwindigkeit, Beobachtbarkeit ermöglicht und die Servicezuverlässigkeit verbessert. DevOps ermutigt jede DevOps-zentrierte Organisation, gemäß den in ihrem Modell CALMS beschriebenen kulturellen Prinzipien zu operieren.
Was ist SRE?
SRE, kurz für Site Reliability Engineering, ist ein Begriff, der von Googles Senior VP Ben Treynor geprägt wurde, der für die Überwachung des technischen Betriebs verantwortlich ist.
Drew Farnsworth (von Green Lane Design) erklärt: „Ich stelle mir SRE im Allgemeinen gerne als ein System vor, in dem die Entwicklung den Betrieb steuert. Dies ist ein System, bei dem die Umgebung auf die grundlegendsten Komponenten des IT-Stacks heruntergebrochen und mit den in die Hardware integrierten Best Practices eingeführt wird.“
Im Wesentlichen hat das SRE-Team mit Fachkenntnissen in der Softwareentwicklung die Aufgabe, Probleme in der Systemproduktion zu lösen und gleichzeitig ein Gleichgewicht zwischen Liefergeschwindigkeit und Systemzuverlässigkeit aufrechtzuerhalten. Auf diese Weise bringt der SRE-Ansatz Softwareentwicklungspersonal in Betriebsrollen zusammen, um strukturierte Engineering-Praktiken anzuwenden, um die Richtlinien einer Organisation aufrechtzuerhalten.
Sie stellen sicher, dass Systeme jederzeit verfügbar sind und effizient laufen, damit Softwareteams technische Dienste entwickeln können, um die Zuverlässigkeit des Systems zu erhöhen. Es liegt in der Verantwortung von SREs, potenzielle Schwachstellen zu identifizieren, bevor sie sich zu einem größeren Problem ausweiten.
DevOps vs. SRE: Die wichtigsten Unterschiede zwischen DevOps und SRE
In der Praxis sollten DevOps und SRE als komplementäre Disziplinen betrachtet werden, wobei sich SREs als Teil einer DevOps-zentrierten Struktur darauf konzentrieren, die Zuverlässigkeit ihrer technischen Dienste zu verbessern. Im Wesentlichen gibt es also kein DevOps versus SRE.
Daher untersuchen wir in diesem Abschnitt die grundlegenden Unterschiede zwischen DevOps und SRE.
Veränderung umsetzen
Damit Aktualisierungen häufig erfolgen und Benutzer Zugriff auf neuere und relevantere Technologien haben, beabsichtigen sowohl DevOps als auch SRE, schnell voranzukommen. DevOps geht jedoch schrittweise und mit Vorsicht voran, während SRE die Kosten eines Versäumnisses berücksichtigt, schneller voranzukommen.
Beide implementieren Automatisierung und verwenden Tools, um diesen Zweck zu erreichen.
Ausfälle als normal betrachten
DevOps ist enorm darin, Fehler zu akzeptieren und sie als Lernunterdrückung zu betrachten. Aus diesem Grund fördert es eine tadellose Kultur, indem es akzeptiert, dass Fehler ein Teil des Prozesses sind, und sich nicht darauf konzentriert, Systeme zu 100 % fehlertolerant zu machen. Ein Beispiel dafür ist Netflix mit seiner Simian Army.
SRE hingegen unterstützt eine tadellose Obduktion. Der Zweck dahinter ist, die Fehlerursache zu identifizieren, Verantwortlichkeiten zuzuweisen und daran zu arbeiten, ähnliche Fehler in Zukunft zu vermeiden. Wie viele Ausfälle ein System erleiden kann, ist im Fehlerbudget enthalten. Die SLI-, SLO- und SLA-Metriken bestimmen dies, um die Produktionskosten zu senken. Grundsätzlich wendet SRE proaktive Überwachungs- und Alarmierungspraktiken an, um einen potenziellen Ausfall abzuwenden.
Lernen Sie Softwareentwicklungskurse online von den besten Universitäten der Welt. Verdienen Sie Executive PG-Programme, Advanced Certificate-Programme oder Master-Programme, um Ihre Karriere zu beschleunigen.
Automatisierung vs. Innovation
DevOps legt größten Wert auf Automatisierung. In einer auf DevOps ausgerichteten Umgebung bedeutet dies, dass Systeme so weit wie möglich automatisiert werden, was zu langweiligen Releases führt. Nachdem ein Entwickler den Code festgeschrieben hat, müssen die meisten der folgenden Aktivitäten, wenn nicht alle, automatisiert werden.
Daher ist der Grund für DevOps, CI/CD zu verfolgen, die Entwicklung hochwertiger Systeme mit höherer Geschwindigkeit.
Die Gründe für SRE, CI/CD zu verfolgen, sind andere, sie zielen darauf ab, die Ausfallkosten zu reduzieren. Alle allgemeinen, allgemeinen oder sich wiederholenden Aufgaben im Betrieb wie Bereitstellung und Backups werden als weniger beachtenswert angesehen. Daher planen SREs eine bestimmte Zeitspanne ein, um operative Mühsal zu vermeiden. Dies geschieht, damit sie attraktiveren Aufgaben wie der Ausführung oder Innovation neuer Technologien oder architekturbezogenen Aktivitäten nachgehen können.
Checkout: DevOps-Projekte für Einsteiger
Organisatorische Silos aufbrechen
Entwickler und Betreiber geraten in Konflikt, wenn es um den Bereitstellungsprozess geht. Während Entwickler davon profitieren würden, dass Funktionen bereitgestellt werden, sobald sie codiert sind, konzentrieren sich Betriebsmitarbeiter darauf, Systeme verfügbar zu machen, was den Bereitstellungsprozess behindert.
Sowohl DevOps als auch SRE unterscheiden sich darin, wie sie die Silos in einer Organisation beseitigen.
Wie im DevOps-Handbuch erläutert, geht DevOps dieses Problem an, indem es Praktiken wie den Betrieb in kleineren Batches und eine bessere Verwaltung von Konfigurationen einbezieht.
SREs zielen nicht nur darauf ab, den Fluss zwischen den Teams zu optimieren, sondern unterstützen auch die Systeme in der Produktion. Sie tun dies, indem sie sich als Berater in die Teams integrieren und die Entwickler unterstützen, indem sie die Verantwortung für den Betrieb von Systemen teilen. So brechen SREs Silos in einer Organisation auf.
Messung einer erfolgreichen Implementierung
Bei DevOps-Metriken dreht sich alles um die Geschwindigkeit des Betriebs; Dazu gehört, wie oft Bereitstellungen stattfinden, wie viel Zeit dafür benötigt wird und wie häufig sie auf Probleme stoßen.
Laut dem Bericht von Puppet und DORA aus dem Jahr 2017 hängt die Messung einer erfolgreichen Implementierung in DevOps von Folgendem ab:
- die Häufigkeit, mit der Bereitstellungen stattfinden
- die Zeitdauer zwischen einem Code-Commit und seiner Bereitstellung
- die Häufigkeit, mit der Bereitstellungen fehlschlagen
- die Zeit, die für die Wiederherstellung nach einem Bereitstellungsfehler benötigt wird
Diese Rückkopplungsschleifen werden eingerichtet, um DevOps dabei zu helfen, die Systemqualität zu verbessern und gleichzeitig eine Änderung beim Experimentieren zu erleichtern.
SRE hingegen arbeitet daran, Systeme zu verbessern und dabei deren Zuverlässigkeit im Auge zu behalten. Es berücksichtigt die folgenden Schlüsselmetriken, um eine erfolgreiche Implementierung zu bestimmen:
- Service-Level-Ziel (SLO)
- Service-Level-Indikator (SLI)
- Service Level Agreement (SLA)
Die oben genannten Metriken sind Indikatoren für die Zuverlässigkeit eines Systems. Diese Metriken bestimmen im Voraus, ob eine Änderungsfreigabe die Produktion erreicht oder nicht.
In SRE sind diese Metriken für Geschwindigkeit und Qualität praktisch, wenn Sie ein Fehlerbudget erstellen und die Zuverlässigkeit von Systemen verbessern, anstatt an neuen Funktionen zu arbeiten.
Lesen Sie: Gehalt als DevOps-Ingenieur in Indien
Fazit
Google hatte ein eBook darüber veröffentlicht, wie sie Site Reliability Engineering in ihren Produktionssystemen implementieren, in dem Treynor SRE wie folgt erklärte:
„SRE ist das, was passiert, wenn Sie einen Softwareingenieur bitten, ein Betriebsteam zu entwerfen.“
Wenn es darum geht, wie unterschiedlich DevOps und SRE sind, müssen Sie sich nur daran erinnern, dass SRE eher von Entwicklern als von einem Betriebsteam vorangetrieben wird. Sowohl die Wartung als auch die Überwachung unterliegen größtenteils der Kontrolle der Entwickler. Das unterscheidet die beiden Disziplinen vor allem.
Wenn Sie mehr über große DevOps und Full-Stack-Entwicklung erfahren möchten, schauen Sie sich das Executive PG-Programm in Softwareentwicklung von upGrad & IIIT-B an – Spezialisierung auf Full-Stack-Entwicklung , das für Berufstätige konzipiert ist und mehr als 500 Stunden strenge Schulungen bietet. Über 9 Projekte und Aufgaben, IIIT-B-Alumni-Status, praktische praktische Abschlussprojekte und Arbeitsunterstützung bei Top-Unternehmen.
