SRE: Die grösste Lüge seit Kanban?!

Site Reliability Engineering: Die größte „Lüge“ seit Kanban

 

 

Zugegeben ein bisschen provokant ist der Blog schon, doch die Diskussionen führe ich derzeit einfach sehr häufig….

 

Was hat sich zugetragen:

 

In letzter Zeit wird viel darüber diskutiert, wie Site Reliability Engineers zu DevOps Engineers passen, (es gibt zwar viele DevOps Engineers Ausschreibungen, doch wunder ich mich stets, denn es gibt immer noch keine einheitliche Definition dieses Job Titels) mit ihnen konkurrieren oder was auch immer sie mit DevOps machen.  In der nächsten Woche werde ich einen Vortrag zum Thema “Site Reliability Engineers vs. DevOps” halten, und zur gleichen Zeit sehe ich Moderatoren, die Folien von Velocity und Value Stream Mapping in Verbindung mit Site Reliability Engineering zur Umsetzung von DevOps twittern. Und je mehr ich darüber nachdenke und sehe, was die Leute tun, desto mehr “Sorgen” bekomme ich.

 

 

Die große Lüge

 

Nur damit die Leichtgläubigen nicht gleich ihre Mistgabeln in die Hand nehmen, ich habe nichts gegen Site Reliability Engineers und ich habe nichts gegen Kanban.  Im Gegenteil, dieses anzuwenden und zu unterrichten macht mir Freude. Der Grund, warum ich Kanban eine “große Lüge” nenne, ist, dass es noch mehr fachliche Ausrichtung erfordert Kanban richtig anzuwenden um den größtmöglichen Nutzen daraus zu ziehen.  Es sieht jedoch so aus, als wäre es nichts Neues, dass zahlreiche Teams da draußen sagen: “Sie machen Kanban” und damit meinen, dass sie nichts machen, sondern nur die Kanban-Ansicht in JIRA aktiviert haben, damit sie es bequem haben.  Sie haben keine Vorhersehbarkeit, sie bewirken keinen WIP, sie identifizieren keine Engpässe – sie haben nur eine sichtbare Tafel und das war’s. Aus meiner Erfahrung heraus glaube ich fest daran, dass die meisten Teams, die “Kanban” anwenden, in Wirklichkeit gar nichts tun.  In diesem Blog gibt es Artikel darüber, wie ich meine Teams, denen ich Agilität näher brachte, dazu bewog, zuerst Scrum zu machen, wenn sie Kanban nutzen wollten, um die nötige fachliche Ausrichtung zu entwickeln. Und ich bin nicht der einzige “Freak”, der so denkt. Ein Freund von mir hat seinem Managementteam vor ein paar Wochen genau das Gleiche gesagt, was mir das wieder ins Gedächtnis gerufen und mich zu diesem Artikel angeregt hat.

 

 

Denn ich erlebe das Gleiche bei den SREs (Site Reliability Engineers).  Das ist nicht überraschend – es gab und gibt eine Menge “DevOps-Washing” von bestehenden Operations-Teams.  Benenne dein Betriebs-Team in DevOps um, fertig. Wenigstens war DevOps in der Lage zu sagen: “Es ist eine Methodik, keine Stellenbeschreibung oder ein Gruppenname”,  – deshalb heißt das Team meines Freundes bei der Arbeit auch “Engineering Operations” und nicht “DevOps”. Ich hatte eine Diskussion mit einem anderen Teamleiter und das Ergebnis war: “Site Reliability Engineers – ja, das ist ein Team wie dein eigenes Operation Team, vom Organigramm aus gesehen sieht es genauso aus….”  Site Reliability Engineers zu beschäftigen, kann also – und tut es in zahlreichen Unternehmen auch – bedeuten, nichts Neues zu machen. Du nennst dein bestehendes Operation Team einfach Site Reliability Engineers und denkst – das war’s. 😉

 

 

Eine kurze, persönliche Geschichtsstunde – in einem meiner früheren Jobs vor DevOps@pontine leitete ich ein Engineering Team – ein Betriebsteam.  

Dort lernten wir “agilen” Admins uns richtig kennen, denn 2 meiner Kollegen waren beide Operation Engineers in diesem Team! Wir hatten kluge Leute und machten den Betrieb richtig gut.  

 

Wir hatten Automatisierung, Monitoring, und sogar “Definition of done”-Standards für neue Services. Man muss nicht allzu sehr Flunkern, um dieses Team einfach als Site Reliability Engineers zu bezeichnen und Feierabend zu machen. Meinen schlimmsten Feinden würde ich diesen Job jedoch nicht wünschen. Es war brutal, den Betrieb für nur 4-5 Entwicklerteams zu machen, und das mit gleichzeitiger Unterstützung der ganzen Firma, einigen gemeinsamen Zielen und so weiter. Unsere Lebensqualität war gelinde gesagt eingeschränkt, wir wurden nicht befähigt und egal, wie sehr wir uns bemühten, der Erfolg blieb uns immer verwehrt. Als wir dann ein Team gründeten, das DevOps-Denken verwendete, war der Unterschied wie Tag und Nacht, und wir begannen, unsere Arbeit als Operation Engineers zu genießen.  Ich würde es ungern sehen, wenn sich jemand vormacht, er bekäme das Beste aus diesen Prinzipien, was ein DevOps/”echter” Site Reliability Engineers-Ansatz zu bieten hat, während er es immer noch so macht, wie wir es gemacht haben.

 

 

Ein Freund von mir, der bei einer heimischen Softwarefirma arbeitet, hat mir erzählt, dass sie alle QA-Mitarbeiter in SWET (Software-Engineer In Test) umbenennen, unabhängig davon, ob sie programmieren können oder nicht und alle Mitarbeiter*innen im Betrieb sind SREs. Man könnte wohlwollend sein und sagen, dass sie sich nach vorne bewegen und vorhaben, das mit Umschulungen oder Ähnlichem zu untermauern, jedoch… werden sie das tun?

Wahrscheinlich nicht, denn es ist nur eine Umbenennung in den angesagten neuen Begriff, ohne eine Änderung, die den Technikern hilft in ihrem Job erfolgreicher zu sein!

 

 

Site Reliability Engineers sind keine “Implementierung von DevOps“, wenn du sie nur als Bezeichnung für ein aufgemotztes Operation-Team verwendest.  Richtig verstanden, kann es eine Umsetzung eines der drei Teile von DevOps sein: Infrastructure As Code, Continuous Integration/Deployment und Site Reliability Engineering. Das Reliability Engineering beginnt jedoch nicht mit dem Deployment in die Produktion, sondern erfordert, wie bei DevOps üblich, die Zusammenarbeit von Dev- und Operation-Teams und zwar sowohl im Entwicklungszyklus als auch in der Produktion, um richtig zu funktionieren.  Das muss nicht unbedingt ein anderes Team sein.  Wenn das Team nicht beschlossen hat, ob es den Betrieb für eine bestimmte Anwendung übernimmt, wenn es nicht 50 % seiner Zeit damit verbringen darf die Arbeit zu reduzieren und wenn du die Site Reliability Engineers nicht so bezahlst wie die Entwicklungsingenieure – dann ist es kein Site Reliability Engineering und du bist ein „Gauner“, wenn du es Site Reliability Engineering nennst. Wenn du die DevOps-Prinzipien nicht beachtest, bekommst du nur dein altes Operationsteam mit seinen alten Problemen zurück.

 

 

Deshalb ist Site Reliability Engineering eine große Lüget – denn sie ermöglicht es den Leuten zu behaupten, dass sie etwas tun, das ihrem Unternehmen zum Erfolg verhelfen könnte und ihren Dev- und Operation Engineers eine bessere Karriere und ein besseres Leben zu ermöglichen – es jedoch nicht wirklich durchführen. 

Ja, es hat schon früher große Täuschungen gegeben, weshalb ich Kanban als weiteres Beispiel anführe – doch selbst wenn der neue Verbrecher dem alten ziemlich ähnlich ist, hängt man sein Bild trotzdem die Lobby des Unternehemens.

 

 

Ehrlich gesagt trägt jeder der Site Reliability Engineering propagiert, ohne einen Warnhinweis anzubringen, zum Problem bei.

“Nun, jedoch wird es in Kapitel 20 des zweiten Buches erwähnt”, sagte jemand als Antwort auf meine Diskussion, die ich mit einem Kollegen zu diesem Thema führte. In meinen Augen eine kritische Antwort, denn:

Wenn etwas das du verkaufst, zutiefst missverstanden wird, ist es deine Verantwortung die Probleme offen anzusprechen.

 

 

Die kleinen Probleme

 

Nun gibt es berechtigte Probleme mit dem “echten Site Reliability Engineers”-Modell, zumindest mit der Art und Weise, wie es normalerweise beschrieben wird.  In den Google-Büchern wird es einerseits als Praxis der Engineers beschrieben und andererseits als “ein Team, das so arbeitet”.  Selbst unter denjenigen, die sich nicht mit dem klassischen Site Reliability Engineers-Betrieb befassen, wird allgemein davon ausgegangen, dass es sich bei den Site Reliability Engineers um eine Berufsbezeichnung für ein Team innerhalb des Produktionsbetriebs handelt.

 

Hier gibt es ein Problem: das Problem der Spezialisierung.  Wenn du den Maßstab von Google anlegst, dann musst du dich spezialisieren und ein separates Operation-Team ist sinnvoll.  Jedoch bist du nicht der Maßstab von Google.  Wenn du weniger als 100 Engineers hast, machst du meiner Meinung nach einen Fehler, wenn du ein separates Operation Team hast. Deine Produktteams müssen sich um ihre Produkte kümmern. Zweitens: Ich will mir die netten Google-Ingenieure da draußen nicht zum Feind machen, doch hast du die Erfahrung gemacht, dass sich Google Services schnell weiterentwickeln und besser werden, sobald sie zum Release bereitstehen?  Das ist nicht meine.  Hast du in letzter Zeit Google Hangouts verwendet, ohne dass es mit Fluchen und anschließendem Wechsel zu Zoom oder Teams endete?

Diese Art von Spezialisierung hat immer noch ihre Schattenseiten, denn sie behindert die Feedbackschleifen die dich besser werden lassen (der Zweite Weg von DevOps). Ist “Site Reliability Engineers” einfach nur Google-Jargon für “nachhaltig”?

Der Reiz des Modells und der Grund, warum Google so stark darauf ausgerichtet ist, liegt in Kubernetes selbst. k8s ist sehr komplex, was die Leute ein wenig zu dem alten Priester-im-Heiligtum-Modell zurückbringt: “Jemand wartet die Infrastruktur, du schreibst die App und lässt sie dann von ihm deployen”, doch jetzt gibt es einige Standards (wie das Deployment als Container), die das wieder in Ordnung bringen. Wenn du jedoch glaubst, dass Zuverlässigkeit und Beobachtbarkeit die Hauptverantwortung eines Operation-Teams sind das nicht an der Entwicklung der Anwendung beteiligt ist, dann hast du entweder tiefgreifende Unternehmensstandards, die ein nahtloses Ineinandergreifen des einen mit dem anderen ermöglichen, oder man macht sich was vor….-unter uns: –>90 % machen sich etwas vor.

 

 

 

Site Reliability Engineering als “separates neumodisches Operation-Team” mag für manche funktionieren, du musst jedoch realistisch sein was die Probleme und Kompromisse angeht die du eingehen willst.  Überlege dir, ob Produktteams ihr Produkt unterstützen, vielleicht mit Hilfe eines Plattformteams, das Tools erbringt und eines Enabling/Consulting/Center of Excellence-Teams, das fachlichen Rat geben kann? 

DevOps hat uns gezeigt, wie sehr das Modell “von Dev zu Ops über die Mauer werfen” unserer Branche geschadet hat.  Der Wechsel von der Entwicklung zu den Site Reliability Engineering, macht das nicht besser, sondern ist gefühlt ein Rückschritt. Um Site Reliability Engineering “richtig” zu machen, um das zu kompensieren, braucht es wie bei Kanban mehr fachliche Ausrichtung, nicht weniger – da sollte jeder realistisch sein, ob in der eigenen Organisation das Google-Niveau an fachlicher Ausrichtung besteht 😊

Ich für meinen Teil werde auf die Umsetzung achten und in meinen Kursen genau das Lehren. Die Prinzipien und Praktiken sind vorhanden und gut verstanden. Diese richtig angewendet, sind ein absoluter Garant für guten Service.

Doch wie so oft und bei fast allen mir bekannten IT – Frameworks und Methoden, mangelt es zu oft an der Umsetzung und Implementierung.

Und nein, DevOps ist kein Framework, es ist eine Bewegung!

 

Wie ist Deine Meinung zu dem Thema…übertriebe ich, oder kommt Dir diese Art der Diskussion bekannt vor?

 

 

LG Euer Sven