Vom SysAdmin zum SRE

Vom SysAdmin zum SRE

Lesezeit: 8 Minuten

Wer bin ich?

Mein Name ist Benjamin Dassow und ich arbeite im Bremer Büro der CLOUDETEER als SRE. Ich habe die letzten Jahre im Datacenter Bereich gearbeitet und dabei so ziemlich alle Aspekte hiervon mitbekommen. Auch das Arbeiten in der Cloud war nichts neues für mich. Genau hier wollte ich mich intensiver mit beschäftigen, denn ich sehe in der Cloud die Zukunft der IT.
2019 begann dann ein neuer Lebensabschnitt für mich: Die Arbeit als SRE bei CLOUDETEER.

Was ist ein SRE?

Genau diese Frage hatte ich mir auch gestellt, bevor ich bei der CLOUDETEER angefangen habe. Auf meine Nachfrage kam „Google!“ als Antwort.
Jetzt denkt sich bestimmt jeder „Ja klar, soweit wäre ich auch gekommen“. Dies war aber nicht die Aufforderung zum Benutzen der gleichnamigen Suchmaschine, sondern die Nennung von Google als Firma.

Google prägte als erstes den Begriff des SRE und definiert ihn wie folgt:

SRE is what you get when you treat operations as if it’s a software problem. Our mission is to protect, provide for, and progress the software and systems behind all of Google’s public services — Google Search, Ads, Gmail, Android, YouTube, and App Engine, to name just a few — with an ever-watchful eye on their availability, latency, performance, and capacity. (https://landing.google.com/sre/)

Eine andere gute Quelle ist die Definition des SRE aus der Sicht von Atlassian
Link: https://www.atlassian.com/incident-management/devops/sre

Natürlich kann diese Beschreibung noch viel tiefer definiert und teilweise schon philosophisch diskutiert werden. In diesem Eintrag möchte ich aber meine Gedanken zum Thema SRE als ehemaliger SysAdmin schildern.

Alles wie immer, nur mit neuem Namen

So dachte ich zum Anfang auch, doch da lag ich falsch, wie ich schnell feststellen musste. Klar, SREs decken den Großteil der Aufgaben eines althergebrachten Systemadministrators mit ab.
Zum Beispiel:

  • Systemmonitoring
  • Backup Management
  • Ticketbearbeitung
  • Systeminstallation
  • Und vieles mehr

Ich fragte mich, wo dann der Unterschied zwischen SRE und Sys-Admin ist.
Der für mich größte Unterschied ist die Anwendung von Techniken und Methoden aus der Softwareentwicklung auf die Bereitstellung, Pflege und das Management von Infrastruktur.

Scrum, Sprint-Planing, Pipeline… wer aus der Entwicklung kommt für den ist sofort klar, was hier gemeint ist. Als jemand, der seine Zeit damit verbracht hat, Hardware einzubauen, Betriebssysteme zu installieren und Netzwerke zu konfigurieren klang das alles erst einmal wie Böhmische Dörfer.

Agiles Arbeiten im Datacenter-Betrieb. Meine Erfahrungen waren hier großteilig, dass bei wöchentlichen Meetings oft die Antwort kam „Lieferung der Hardware dauert noch 2 Monate“. Damit war das Thema meist erledigt.

Glücklicherweise bietet hier die Cloud flexiblere Möglichkeiten für die Bereitstellung der benötigten Ressourcen. Ein neuer Server für die Entwickler? Kein Problem, kurz im Portal herumgeklickt oder das vorbereitete Skript angeworfen und schon ging es los.
Meist wurde dadurch eine VM hochgezogen, welche einen Agent zur Softwareverteilung bekommen hat und so mit den notwendigen Anwendungen betankt wurde.
Besser als früher, aber wirklich agil war das auch nicht.

Infrastructure as Code oder „Wie ich mich neu verliebt habe“

Codifizierung von Infrastrukturen. Das war etwas, was für mich bisher aus der Erstellung von Skripten, welche Nacheinander ausgeführt wurden, bestanden hat. Das kann wunderbar funktionieren, sofern man sich auf einen Cloudanbieter beschränkt.

Was ist aber, wenn man, wie CLOUDETEER, als Multi-Cloud Betreiber unterwegs ist?
In unserem Fall heißt die Lösung Terraform von Hashi Corp ( https://www.terraform.io/ ).
Terraform fasst die API-Schnittstellen der großen Cloudanbieter in einer einheitlichen, codifizierbaren Form zusammen. Die notwendigen Anpassungen pro Cloudprovider reduzieren sich so auf ein Minimum.
Bis hierhin werden sich viele Denke „Ja und? Es wird einfach ein anderes Skript ausgeführt als vorher.“

Als Antwort möchte ich ein Lied einer Norddeutschen HipHop-Band zitieren: Jain

Grundlegend stimmt es. Aber SREs gehen noch einen Schritt weiter.
Durch die Verbindung von Softwareentwicklung mit dem klassischen Systembetrieb halten auch neue Techniken Einzug.
So codifizieren wir unsere Infrastruktur komplett in Terraform und gießen diese dann wiederum in Pipelines, welche z.B. in Azure DevOps ( https://azure.microsoft.com/en-us/services/devops/ ) als Mittel der Wahl, ausgeführt werden.

Durch die Nutzung von Repositories zur Speicherung des Codes ist eine feinmaschigere Nachverfolgung von Änderungen möglich als früher. Pull Request auf den Code erlauben das Review durch andere Kollegen. So kommt man in den Genuss die auftretenden Fragen beantworten zu dürfen und teilt auch direkt sein Wissen mit den Kollegen. Durch die Nutzung von Pipeline Systemen wiederum lassen sich Genehmigungsverfahren einstellen, bevor eine Änderung in der Infrastruktur wirklich ausgerollt wird.
Klingt schon anders als die Skripte auf dem eigenen Computer oder maximal im Netzlaufwerk zu speichern, oder?

Fehler als Wege des Erfolges akzeptieren

Das Bestehen einer Fehlerkultur sollte nicht nur in Bezug auf SREs bestehen, sondern in jeder Art von Unternehmen entwickelt werden.
Im Hinblick auf SRE nimmt eine funktionierende Fehlerkultur aber eine ganz andere Stellung ein.

Fehler gehören dazu und sind wichtig!

Eine funktionierende Fehlerkultur ist Teil des Selbstbildes eines SRE. Von Fehlern lernt man mehr, als wenn alles reibungslos läuft.
Bei CLOUDETEER hat sich daher das Motto „FAIL FAST, LEARN QUICK“ etabliert.
Von Fehlern muss gelernt werden, „How to NOT do something“. Außerdem kann jeder Fehler als Möglichkeit gesehen werden, die eigenen Prozesse auf Wirksamkeit zu überprüfen.

Als Beispiel kann man hier Netflix aufführen. Netflix fährt Test zur Verfügbarkeit seiner Umgebung gegen seine Produktivumgebung über welche die meisten von uns wohl All-Abendlich unsere Gier nach Serien und Filmen stillen. Klingt verrückt, oder? Der Grundgedanke hierbei ist denkbar einfach: Wenn der Ausfalltest gegen die Produktivumgebung zu erfolgreich ist, fällt der Fernsehabend bei den Kunden ins Wasser. Aus diesen Fehlern lernt man dann deutlich.

Jedes Team muss seinen Weg definieren

Auch wenn man viel von den großen wie Google, AWS, Netflix und anderen lernen kann. Am Ende muss jedes Team und jede Organisation für sich entscheiden wie sie SRE für sich definiert.

  • Fokussiert man sich auf eine Architektur, die Möglichst belastbar ist?
  • Eine die möglichst Ausfallsicher ist?
  • Welchem Wert wird die Lösung von Alarmen zugewiesen oder wird bei einem Problem einfach neu deployed?

Hier gibt es aus meiner Sicht keine allgemeingültige Regel. Es muss ein Konsens im Team gefunden werden, hinter dem alle stehen und den alle gemeinsam mittragen.

Zusammengefasst

Was bedeutet es für mich ein SRE zu sein?
Eine Frage, die ich auch heute noch nicht leicht zu beantworten weiß. Für mich bedeutete der Wechsel zum SRE eine klare Änderung in meinem „Mindset“. Ich musste meine Sichtweise deutlich mehr in die Richtung Softwareentwicklung lenken als bisher, mehr in „Infrastructure-as-Code“ denken als in Hardware Racks.

Früher hatte ich „nur“ geskriptet, nun musste ich mich mit dem Thema Programmiersprachen auseinandersetzen, um den Workflow zu verstehen.
Den Schritt zum SRE bereue ich nicht. Ich habe hier die Möglichkeit meine Erfahrung aus der klassischen Infrastruktur mit den Kollegen zu teilen, die eher aus der Programmierung kommen. Gleichzeitig kann ich mein eigenes Wissen auf neue Themenbereiche erweitern.

Meine Kollegen und Vorgesetzten von der CLOUDETEER haben mich hierbei stark unterstützt. Hatte ich Fragen, so waren Sie jederzeit ansprechbar. Wollte ich mal etwas ausprobieren, so war auch das kein Problem. Habe ich einen Fehler gemacht, so wurde nicht über den Fehler gesprochen, sondern darüber, was wir aus diesem lernen können.

Ich freue mich, dabei zu sein und bin gespannt auf meinen weiteren Weg als SRE bei der CLOUDETEER!