Vom Entwickler zum SRE

Vom Entwickler zum SRE

Lesezeit: 5 Minuten

Vorwort

Mein Kollege Benjamin Dassow hat bereits ein ähnlichen Blogpost, mit dem Titel “Vom SysAdmin zum SRE", verfasst. Dieser gab mir zum Anlass einmal selber diesen kurzen Blogpost zu verfassen um das Thema aus meiner Sicht zu behandeln.

Wer bin ich?

Mein Name ist Yannick Kubica und ich bin einer der Bremer CLOUDETEERs. Angefangen habe ich meinen Werdegang als Fachinformatiker für Anwendungsentwicklung. Seit 2013 habe ich als Webentwickler gearbeitet und im letzten Jahr vor CLOUDETEER war ich im Bereich SAP Process Integration/Orchestration unterwegs.

Das produktive Arbeiten in der Cloud war für mich etwas ganz Neues. Meine vorherigen Erfahrungen waren nur mit On-Premise-Systemen und den damit oft langsamen Bereitstellungen von neuen Systemen/Umgebungen.

Als ich die Möglichkeit bekommen habe, bei der CLOUDETEER als SRE zu beginnen, sah ich meine Chance tiefer in das Thema Infrastruktur einzutauschen. Ohne Groß zu zögern habe ich die Chance ergriffen und bin nun ein Teil der CLOUDETEER-Erfolgsstory.

Was ist ein SRE?

Site Reliability Engineering - Ein Begriff der von Google geprägt wurde. Deswegen verweise ich hier auch gerne auf Googles Seite dazu: https://landing.google.com/sre/ Atlassian hat ebenfalls eine sehr gute Definition zu dem Thema, mehr dazu hier.

Mir war dieser Begriff zuvor gar nicht bekannt.
Wenn man es vereinfachem möchte, dann ist ein SRE die Kombination eines Systemadministrators und eines Softwareentwicklers. Durch die Erfahrungen in beiden Bereichen kann man sicherstellen, dass komplexe Systeme reibungslos funktionieren und hoch verfügbar sind.

alt text

Im nächsten Abschnitt gehe ich auf die Themen ein, die für mich als ehemaliger Softwareentwickler neu sind und zum Teil auch zur Definition des SREs gehören.

Was ist neu für mich?

Als klassischer Softwareentwickler kam ein neuer Themenbereich auf mich zu: Infrastruktur. Klar deckt ein SRE einige Themen ab, mit denen ich bereits Erfahrungen gesammelt hatte, darunter u.a. Ticketbearbeitung oder Systeminstallationen. Dass ein SRE diverse Methoden aus der, mir bekannten, Softwareentwicklung nutzt um die Bereitstellung, Pflege und Orchestrierung von Infrastruktur durchzuführen, begeisterte mich unglaublich.

Themen wie Containerisierung mit z.B. Docker waren mir nicht grundsätzlich fremd, da wir diese Themen bei meinem alten Arbeitgeber aber nicht eingesetzt haben, konnte ich diese nie richtig im produktiven Betrieb greifen. Als ich dann noch Kubernetes lernte, war ich vollkommen begeistert und sah erst die ganzen Möglichkeiten.

Alles zu Automatisieren. Wenn es geht, dann tatsächlich alles. Dies ist, wie auch Google sagt, dass ultimative Ziel eines SREs. Dem Kunden am Ende möglichst einfach neue Lösungen bereitzustellen macht uns das Leben einfacher und den Kunden glückerlicher.

Fehler als Normal zu betrachten und daraus zu lernen. Neue Änderungen zu implementieren die Fehler minimieren oder deren Auswirkungen auf ein Minimum beschränken.

Messen was möglich ist und aus diesen Messwerten brauchbare Metriken für den Kunden und uns zu erstellen. Basierend auf diesen Metriken werden dann wieder neue Aufgaben zur Verbesserung der Gesamtsituation erschlossen.

Wie unterscheidet sich die Arbeit?

Ich schreibe immer noch eine Menge Code. Nur einfach nicht mehr die klassische Software, sondern Skripte - Bash, Powershell und Python sind meine neuen besten Freunde.

Der große Selling-Point sind die Problemstellungen, vor denen ich täglich stehe. Als Entwickler hat man immer das Ziel vor Augen etwas zum Laufen zu bekommen. In der Arbeit als SRE habe ich täglich dieses Erfolgsgefühl, da immer wieder neue Fehler auftreten, die ich beheben kann.
Im Anschluss daran eine Automation zu entwickeln, damit diese Fehler nicht wieder auftreten, gehört in die Stellenbeschreibung. Es ist nun einmal das Ziel eines SREs eine “Reliable”-Umgebung bereitzustellen.

Einheitliche Software-Deployments mittels CI/CD zu erschaffen, nicht nur Nutznießer von diesen zu sein, sondern diese aktiv zu entwickeln und anzupassen.

Herausforderungen

Jeder Kunde bringt seine eigene Architektur mit, die uns immer wieder vor neue Herausforderungen stellen. Es gibt quasi nie eine “one fits all”-Lösung. Das macht aber auch den Charme aus, auf den Kunden zugeschnittene Lösungen zu erarbeiten.

Eine weitere Herausforderung für mich ist das Thema Netzwerk-Architektur. In meiner bisherigen Laufbahn nur ein kleiner Randbegleiter ist es nun ein täglicher Begleiter. Ein ganz neues Themengebiet welches sich aufgetan hat und, je nach Kunde, auch sehr schwierig zu durchblicken ist.

Lernen und noch mehr Lernen. In unserer Branche und auch speziell als Softwareentwickler darf man nie aufhören zu lernen. Als SRE ist man noch mehr dazu gezwungen sich mit den aktuellen Themen auseinander zu setzen, da das Spektrum nun ein viel Größeres ist.

Zusammengefassung

War der Wechsel zum SRE für mich der richtige Schritt? Definitiv!

Ich nutze nach wie vor die Methoden der Softwareentwicklung, die ich die letzten Jahre verinnerlicht habe, nur eben in einem anderen Kontext. Dass ich nun meine Erfahrungen im Bereich der Infrastruktur machen kann und die beiden Welten für mich verschmelzen sind ein klares Verkaufsargument.

Mein Team bei der CLOUDETEER besteht aus ehemaligen Systemadministratoren und Entwicklern. So können wir unsere Erfahrungen optimal zusammenfließen lassen, um die besten Lösungen für unsere Kunden zu erarbeiten.

Es ist ein schönes Gefühl zu wissen, dass alle jederzeit bereit sind Fragen zu beantworten oder ihre Erfahrungen in gewissen Bereichen mitzuteilen.

Ich bin froh diesen Schritt gegangen zu sein und die Chance bekommen zu haben, ein Teil der noch jungen CLOUDETEER-Geschichte zu werden.