Zum Glück ist das Site Reliability Engineering, das intern bei Google entwickelt wurde und erst seit kurzem Eingang in die breitere Community findet, ziemlich genau definiert. Was jedoch nicht ist, sind Weboperationen (oder "Systemadministration" - als Beispiel für die mangelnde Klarheit verwenden Sie beide in Ihrer Frage). Es ist schwierig, die Unterschiede zwischen zwei Dingen zu diskutieren, wenn Sie nicht ganz sicher sind, was einer von ihnen ist.
Aber ich bin ein abenteuerlustiger Kerl, also werde ich es versuchen.
In sehr traditionellen Läden sind Entwickler und Systemadministratoren sehr voneinander getrennt. Die Entwickler erstellen eine App und betrachten ihren Job als abgeschlossen, sobald der Code festgeschrieben wurde. Die Sysadmins nehmen die Build-Artefakte (bei einer interpretierten Sprache möglicherweise nur den Code) und stellen sie auf Produktionsservern bereit. Es ist die Aufgabe der Systemadministratoren, die Anwendung reibungslos laufen zu lassen und im Allgemeinen die Produktionsumgebung zu verwalten. Leistungsprobleme treten jedoch häufig aufgrund von Architekturproblemen in der App auf. Die Sysadmins haben keine Programmierkenntnisse, um zu wissen, was die App tut, und die Entwickler wissen nicht, wie sich die App in der Produktionstopologie mit dem Produktionsdatenverkehr verhält. Daher ist niemand für die Lösung des Problems allein gerüstet.
Darüber hinaus werden die Entwickler in der Regel danach beurteilt, wie schnell sie neue Funktionen erstellen können, während die Systemadministratoren danach beurteilt werden, wie selten die App in der Produktion unterbrochen wird. Da Veränderungen eine der Hauptursachen für Brüche sind, geraten die beiden Abteilungen in Konflikt miteinander - eine alte Rivalität, die das Geschäft und die beteiligten Personen verletzt.
Irgendwann ärgerten sich einige entwicklerorientierte Unternehmen so sehr, dass sie anfingen, "NoOps" zu üben - sie beseitigten ihre Betriebsabteilungen und die damit verbundenen wahrgenommenen Straßensperren. In der Realität bedeutete dies, dass Entwickler Betriebsfunktionen übernahmen, aber ihre alten Titel behielten.
In einer Diskussion um NoOps definierte John Allspaw, damals Vice President of Technical Operations bei Etsy und Herausgeber des angesehenen Web Operations-Buches , die Rollen bei Etsy folgendermaßen:
Etsy Operations ist verantwortlich für:
- Reaktion auf Ausfälle, Bereitschaftsdienst
- Schwellenwert für Warnsysteme, Design
- Architekturdesign und Überprüfung
- Erstellen einer Messwertsammlung
- Anwendungskonfiguration
- Aufbau / Verwaltung der Infrastruktur
Etsy Development ist verantwortlich für:
- Reaktion auf Ausfälle, Bereitschaftsdienst
- Schwellenwert für Warnsysteme, Design
- Architekturdesign und Überprüfung
- Erstellen einer Messwertsammlung
- Anwendungskonfiguration
- Versand von öffentlich zugänglichen Codes
Keine dieser Listen ist umfassend, ich bin mir sicher, dass ich dort etwas vermisse. Während Etsy Ops produktionsbezogene Anwendungsänderungen vorgenommen hat, gibt es nur wenige, aber echte (und manchmal recht tiefe). Während Etsy Dev Änderungen am Koch vornimmt, gibt es nur wenige, aber echte. Wenn es so viele Überschneidungen bei den Zuständigkeiten gibt, warum ist das anders? Fachwissen und Hintergrund. Nicht viele Entwickler haben tiefes Wissen darüber, wie langsamer TCP-Start funktioniert, aber Ops. Nicht viele Ops haben umfassende Kenntnisse über Sortier- oder Relevanzalgorithmen, aber Dev. Ops hat jahrelange Erfahrung in der schnellen Vorhersage der Ressourcennutzung mit akzeptabler Genauigkeit, Dev nicht. Dev kennt möglicherweise nicht die Vor- und Nachteile der Verteilung der Workload-Optionen auf alle Ebenen 1 bis 7, möglicherweise erst bei 7, was Ops tut. Entity-Relationship-Modellierung ist für einen Entwickler möglicherweise eine Selbstverständlichkeit, nicht jedoch für ops. Am Ende finden beide Lösungen für verschiedene Formen von byzantinischen Versagensszenarien und Resilienzmustern auf allen Ebenen und Ebenen.
In seiner Welt hatten Entwickler und Operationsingenieure sehr ähnliche Fähigkeiten und Verantwortlichkeiten auf hoher Ebene. wo sie sich unterschieden, war in ihrer Sachkenntnis. Ihre unterschiedlichen Fachgebiete ermutigten sie, zusammenzuarbeiten, um Probleme zu lösen, und ihre gemeinsamen Grundkenntnisse gaben ihnen eine Sprache, in der sie dies tun konnten.
Dies ist im Allgemeinen die Definition von Weboperationen, auf die ich in den meisten Fällen gelange. Also werden wir damit weitermachen.
Was ist Site Reliability Engineering?
Das Google SRE-Buch wird mit einer Definition von SRE ... und dann einer weiteren ... geöffnet. Anschließend wird in einem Kapitel die Rolle und ein ganzes Buch mit den Einzelheiten definiert. Selbst wenn es in einer Organisation entwickelt wird, scheint es schwierig zu sein, den Job auf eine einzige vereinbarte Definition zu reduzieren.
Zunächst müssen wir auf das Jahr 2003 zurückblicken, als Ben Traynor zu Google stieß und das erste Team für Site Reliability Engineering gründete. Denken Sie daran, dass wir uns vor einigen Absätzen in den frühen 2010er Jahren befanden. Aber im Jahr 2003 war die Branche immer noch ziemlich auf die Kluft zwischen Systemadministrator und Entwickler fixiert. Als Ben sagt, dass SRE das wäre, was passieren würde, wenn ein Softwareentwickler ein Betriebsteam aufbauen würde, ist dies eine viel radikalere Verschmelzung der beiden Welten, als es jetzt scheint.
Die Definition im Vorwort hebt jedes der drei Wörter einzeln hervor:
- Ingenieurwesen - Nutzung von Konzepten der Informatik und des Ingenieurwesens zur Lösung von Problemen
- Zuverlässigkeit - ein Fokus darauf, Systeme skalierbarer, zuverlässiger und effizienter zu machen
- Service - die spätere Entwicklung von "Site", wobei hervorgehoben wird, dass SREs für vernetzte Services verantwortlich sind
Das Einführungskapitel listet die Grundsätze des Site Reliability Engineering wie folgt auf:
- Sicherstellung einer dauerhaften Fokussierung auf das Engineering - Ergreifen vorbeugender Maßnahmen, um häufige Seiten und andere "Mühen" zu vermeiden
- Behalten Sie die maximale Änderungsgeschwindigkeit bei, ohne den SLO eines Dienstes zu verletzen - ein Thema, das leicht mehrere Hundert Wörter beantworten kann, das jedoch grob als Hilfe für Entwickler beim Vornehmen von Änderungen zusammengefasst wird, sofern sie nicht zu viele Probleme verursachen
- Überwachung - Automatische Warnungen, wenn etwas schief geht
- Notfallhilfe - Reparieren von Dingen, wenn sie kaputt sind
- Änderungsmanagement
- Kapazitätsplanung
- Bereitstellung
- Effizienz und Leistung - zu gewährleisten , dass ein Dienst führt zu einem erwarteten Niveau - Engpässen verletzt Benutzer, aber überschüssige Kapazität kostet Geld
Site Reliability Engineering würde ich als eine spezialisierte Untermenge moderner Web-Operationen einstufen. Eine SRE-Organisation konzentriert sich in hohem Maße auf die Automatisierung aller Vorgänge, was nur in relativ großen Unternehmen wirtschaftlich ist. Ideen wie Fehlerbudgets können nur funktionieren, wenn Ihr Service viele, viele Anfragen hat, da Sie sonst an Granularität verlieren (bei einem kleineren Service kann ein bestimmter Fehler 0 bis 20% Ihrer Anfragen betreffen, abhängig von der Minute). Verwandte Bereiche wie Sicherheit fehlen in der SRE-Definition, da Unternehmen, die groß genug sind, um echte SRE-Teams zu haben, dedizierte Teams für Sicherheit haben.
Bei dem von Google definierten SRE-Programm handelt es sich um Web-Ops, die für die spezifischen Anforderungen von Google entwickelt wurden und an anderer Stelle nicht unbedingt anwendbar sind.
Site Reliability Engineering hat jedoch in letzter Zeit eine breitere Verwendung in der Industrie gefunden. Meine aktuelle Berufsbezeichnung ist eine SRE, obwohl ich in einem viel kleineren Unternehmen arbeite und meine Berufsbezeichnung ziemlich gut mit der Etsy-Web-Ops-Definition von John Allspaw für 2012 übereinstimmt. Meine Theorie ist, dass wir Titel als Abkürzung für die Entwicklung eines einzelnen Feldes durchgearbeitet haben:
- Wir haben als Sysadmins angefangen .
- Dann , als Web - Sites mehr ein „Ding“ wurden, Job - Angebote gestartet beziehen Web Betriebsingenieure sysadmins zu unterscheiden , die in der Bahn von denen spezialisiert , die auch allgemeines Büro IT abgewickelt.
- Dann sollte DevOps diejenigen herausfiltern, die mit der Programmierung vertraut waren, um die Arbeitsbelastung ihrer Weboperationen zu verringern.
- Da DevOps jedoch durch das Fehlen einer klaren Definition verwirrt wurde , haben wir Site Reliability Engineering eingeführt, um anzugeben, dass wir nach Mitarbeitern suchen, die Produktionsservices auf Abruf unterstützen.
Was ist der Unterschied zwischen einem Sysadmin und einem SRE? Das Jahr, in dem sie ihren Titel erhalten haben. Was ist der Unterschied zwischen herkömmlichem Betrieb und Standortzuverlässigkeitstechnik? SRE ist lediglich die derzeitige Inkarnation von Operationen, bei denen neue Tools (Hallo, Container!) Verwendet werden. Da vernetzte Programme immer umfangreicher und wichtiger werden, muss der Fokus verstärkt auf Praktiken gelegt werden, mit denen ein Ingenieur mehr tun kann .