DevOps und Site Reliability Engineering (SRE) werden häufig zur Beschreibung ähnlicher Ansätze zur nahtlosen Integration von Softwareentwicklung und -betrieb verwendet. Allerdings werden diese Begriffe sehr oft falsch verstanden und umgesetzt. Dieser Artikel erläutert den Ursprung und die Grundprinzipien von DevOps, beschreibt, wie Site Reliability Engineering damit im Zusammenhang steht und wie die entstehende Disziplin Platform Engineering die Realisierung der Kerngedanken von DevOps werden könnte. DevOps – Ursprung und Prinzipien Der Begriff DevOps hat in den letzten 10 Jahren einen ungebrochenen Aufwärtstrend zu verzeichnen und bleibt auch 2024 relevant. Die grundlegenden Prinzipien von DevOps wurden bereits mehrfach und ausführlich erklärt, daher soll hier nicht erneut auf jeden Einzelaspekt im Detail eingegangen werden. Um jedoch Unterschiede von DevOps zu anderen Konzepten zu verdeutlichen, hier eine kurze Rekapitulation der Definition und des ursprünglichen Ziels von DevOps. Um 2007 entstand DevOps aus dem Bedürfnis, die Zusammenarbeit zwischen den Entwickler:innen (Development) und den IT-Betriebsteams (Operations) zu verbessern, um Unternehmen eine schnellere und effizientere Bereitstellung von Software für den Kunden zu ermöglichen. DevOps hat sich seitdem zu einer beliebten Alternative zu den isolierten Arbeitsweisen von Entwicklungs- und Betriebsteams der Vergangenheit entwickelt. Die Methodik verfolgt einen kollaborativen, multidisziplinären Ansatz, der die Softwareentwicklung beschleunigt und die Gesamteffizienz steigert. Dieser Ansatz basiert auf bestimmten Praktiken und einer Kultur, die sich auf die folgenden 5 Säulen stützen: Abbau von organisatorischen Silos Scheitern als normal akzeptieren Schrittweises Einführen von Änderungen Einsatz von Werkzeugen und Automatisierung Messbarkeit Trotz der vielversprechenden Aussichten sind diese Konzepte zu abstrakt, um sie unmittelbar im Unternehmen praktisch umzusetzen. SRE – Relation zu und Umsetzung von DevOps Hier setzt Site Reliability Engineering (SRE) an. Die Rolle des Site Reliability Engineers wurde erstmals 2003 intern von Google eingeführt, um die komplexen Systeme, mit denen das Unternehmen seine Dienste ausgeliefert hat, zu verwalten und zu betreiben. Die Entstehung von SRE geht auf die Notwendigkeit zurück, eine bessere Balance zwischen Innovation und Zuverlässigkeit zu finden. Während die Entwicklung des SRE-Ansatzes lange Zeit parallel zur DevOps-Bewegung gelaufen ist, stellt die Rolle des Site Reliability Engineers eine konkrete Implementierung des DevOps-Konzepts dar. Technisch ausgedrückt: class SRE implements DevOps SRE setzt die 5 Grundpfeiler von DevOps wie folgt um: 1. Abbau von organisatorischen Silos SRE fördert den Abbau von organisatorischen Silos durch eine enge Zusammenarbeit und das Teilen von Verantwortlichkeiten über traditionelle Rollengrenzen hinweg. Development und Operations verwenden dieselben Metriken, Tools und Prozesse und legen Wert auf gute Kommunikation. Dieser Ansatz fördert ein Umfeld, in dem Wissen und Erfahrungen frei zwischen den Teams getauscht werden können. 2. Scheitern als normal akzeptieren SRE sieht Scheitern als einen natürlichen Bestandteil des Innovationsprozesses an und fördert eine Kultur, in der aus Fehlern gelernt wird, ohne Schuld zuzuweisen. SREs erwarten und planen Systemausfälle ein, z. B. über Error Budgets und halten nach Ausfällen Postmortem-Meetings ab, um herauszufinden, welche Teilsysteme oder Abläufe verbessert werden sollten, um künftige Ausfälle zu verhindern oder den Schaden zu begrenzen. 3. Schrittweises Einführen von Änderungen Durch kleinere, aber häufigere Deployments und die Nutzung von Feature Flags ermöglicht SRE die schrittweise Einführung von Änderungen in der Produktionsumgebung. Dieser Ansatz minimiert das Risiko neuer Releases und bietet die Flexibilität, schnell auf potenzielle Probleme zu reagieren, indem Änderungen leicht rückgängig gemacht werden können. 4. Einsatz von Werkzeugen und Automatisierung SRE setzt stark auf den Einsatz von Werkzeugen und Automatisierung, um manuelle Aufgaben zu reduzieren und Prozesse zu standardisieren. Menschen sind im Gegensatz zu Maschinen schlecht darin, repetitive, monotone Aufgaben abzuarbeiten – die Aufmerksamkeit lässt nach, Fehler schleichen sich ein. Daher kommen Konzepte wie Infrastruktur als Code zum Einsatz, die konsistente und reproduzierbare Umgebungen ermöglichen, ergänzt durch die Automatisierung von Deployments und Tests. 5. Messbarkeit Messbarkeit in SRE basiert auf dem Erfassen relevanter Metriken, um den Erfolg von Maßnahmen zu quantifizieren und Verbesserungen zu bestätigen. Service Level Objectives (SLOs) legen die erwartete Serviceverfügbarkeit fest, während Error Budgets den Spielraum für Experimente und Fehler definieren. Diese klare Ausrichtung auf Metriken unterstützt die kontinuierliche Überwachung und Verbesserung der Servicequalität, um proaktiv die Benutzerzufriedenheit zu gewährleisten. Unternehmen müssen sich folglich nicht zwischen SRE und DevOps entscheiden; beide Konzepte bedingen und ergänzen einander. Obwohl DevOps ursprünglich als revolutionäre Denkweise und Philosophie eingeführt wurde, hat sich der Begriff im Laufe der Zeit zu einer eigenständigen Rolle entwickelt. Dabei ist der Job-Titel „DevOps Engineer“ ein Oxymoron, dessen Einführung nicht automatisch alle Herausforderungen löst – es geht vielmehr um die Förderung einer Kultur sowie Praktiken, die zu effizienteren Arbeitsabläufen führen. Trotz der zunehmenden Popularität des Begriffs „DevOps“ in der Bezeichnung von Stellenangeboten ist es essentiell, den Fokus auf die Verbesserung der organisatorischen Strukturen zu legen. DevOps Anti-Patterns Unternehmen scheitern oft bei dem Vorhaben, DevOps zu realisieren, indem beispielsweise neue Tools, Prozesse und Technologien eingeführt oder Teamstrukturen geändert werden, die grundlegenden Probleme aber bestehen bleiben oder sich nur geringfügig verschieben. Im Folgenden drei Beispielszenarien, wie DevOps Implementierung üblicherweise nicht funktioniert: System-Administrator mit neuem Namen Dieses Anti-Pattern ist leider sehr verbreitet; die klassische Rolle des System-Administrators bekommt hierbei einfach eine andere Bezeichnung, führt aber dieselben Tätigkeiten wie zuvor aus, ohne dass ein wirklicher kultureller oder organisatorischer Wandel stattgefunden hat. Das DevOps-Team-Silo Neben Dev- und Ops-Teams wird ein zusätzliches DevOps-Team neu gegründet, mit dem häufigen Effekt, dass ein weiteres Silo entsteht und so Entwicklung und Betrieb noch weiter voneinander trennt. Das sollte nur eine temporäre Lösung sein, um spezifische Projekte durchzuführen, wie das Refaktorieren von CI/CD Pipelines. Betrieb wird nicht mehr benötigt Hier übernehmen die Entwicklungsteams zusätzliche Betriebsaufgaben, meistens in sehr kleinen Organisationen wie Startups oder aufgrund von Kosteneinsparungen und unter der Annahme, dass ein dediziertes Betriebsteam in der Cloud nicht mehr gebraucht wird. Dieser Ansatz skaliert allerdings nicht, wenn die Komplexität der Infrastruktur zunimmt und Entwickler:innen sich dadurch nicht mehr auf ihre wichtigste Aufgabe konzentrieren können: Neue Features für den Kunden zu entwickeln. Der Versuch, DevOps-Methoden zu etablieren, kann also auf verschiedenste Weisen fehlschlagen. Zudem hat nicht jedes Unternehmen die Kapazitäten, um alle Praktiken genauso umzusetzen, wie sie bei Tech-Riesen wie Google betrieben werden. Wie könnte also ein praktikabler Lösungsansatz aussehen, um die angestrebten Verbesserungen zu erreichen? Erste Schritte in Richtung Praktisches DevOps Zwar befindet sich jedes Unternehmen auf dem Weg zur Implementierung von DevOps in einem anderen Stadium, dennoch sind hier einige konkrete, umsetzbare Maßnahmen. Man kann diese Ansätze als erste Schritte in Richtung eines kulturellen, prozessualen, organisatorischen und technischen Wandels nutzen, um letztendlich eine bessere Leistung im Software Delivery Process zu erreichen. Kulturell Sie können Ihrer Organisation helfen, eine gesunde Kultur zu fördern, indem Sie Lernen als Schlüsselaktivität zur Verbesserung und als Investition betrachten. Konkret bedeutet das: Lassen Sie Scheitern zu. Wenn Misserfolge bestraft werden, wird nichts Neues ausprobiert und die Entwicklung blockiert. Schaffen Sie eine Kultur der Innovation, indem Sie Mitarbeitende kalkulierte Risiken eingehen und kontrollierte Experimente durchführen lassen. Auch Ausfälle sind Lernchancen und sollten als Möglichkeit verstanden werden, um herauszufinden, wie Prozesse und Systeme verbessert werden können. Führen Sie Postmortems ohne Schuldzuweisungen durch. Durch die Beseitigung von Schuldzuweisungen beseitigen Sie Ängste, und durch die Beseitigung von Ängsten ermöglichen Sie den Teams, Probleme aufzudecken und sie effektiver zu lösen. Technisch Der Software-Bereitstellungsprozess sollte so automatisch wie möglich ablaufen. CI/CD-Pipelines implementieren hier wichtige Aspekte wie Tests, Wiederholbarkeit und die Möglichkeit, sich von fehlerhaften Deployments zu erholen. Um Ihrem Team zu helfen, einen höheren Durchsatz mittels CI/CD zu erreichen, könnte ein erster Ansatz so aussehen: Listen Sie alle Schritte auf, die notwendig sind, um Code von der lokalen Entwicklungsumgebung in Produktion zu bringen. Diese Schritte können so heruntergeschrieben werden, als ob Sie sie manuell ausführen. „Ich würde Tests folgendermaßen durchführen. Dann würde ich die Ergebnisse überprüfen. Dann würden wir den Branch mergen. Danach wird der Code kompiliert.“ usw. Welche dieser Schritte lassen sich automatisieren? Code-Reviews können nicht automatisiert werden, aber die Durchführung von Tests oder die Provisionierung der Infrastruktur schon. Welche Skripte oder Tools können Sie einsetzen, um diese Schritte zu automatisieren? Sie könnten zum Beispiel eine Liste aller Befehle erstellen, die Sie ausführen müssen, um Ihre Codebasis auf dem jeweiligen Hosting-/IaaS-Dienst in Betrieb zu nehmen. Das wäre ein möglicher Arbeitsablauf, der in einem Skript festgehalten werden kann. Letztendlich besteht das Ziel von CI/CD darin, sicherzustellen, dass Software-Releases mit geringem Risiko während der normalen Geschäftszeiten durchgeführt werden. Um Verbesserungen objektiv messbar zu machen, sollten die richtigen Metriken herangezogen werden. Die DORA-Forschungsgruppe hat die folgenden vier Metriken identifiziert, die am aussagekräftigsten für die Fähigkeit zur kontinuierlichen Bereitstellung sind: Deployment-Frequenz: Wie oft wird eine neue Version ausgerollt? Vorlaufzeit für Änderungen: Wie lange dauert es, bis angeforderte Änderungen erfolgreich in Betrieb genommen werden können? Mittlere Wiederherstellungszeit (MTTR): Wie lange dauert es, bis der Service nach einem Fehler oder Ausfall wiederhergestellt ist? Misserfolgsrate bei Änderungen: Wie oft führen Änderungen zu Fehlern, Ausfällen oder erfordern zusätzliche Korrekturen, bevor sie erfolgreich durchgeführt werden können? Beginnen Sie also damit, diese Kennzahlen zu messen, wenn Sie es nicht schon tun. Prozessual Die Ergebnisse des jährlich durchgeführten State of DevOps Reports der DORA-Gruppe haben einen eindeutigen Zusammenhang zwischen der Qualität der Dokumentation und der Fähigkeit eines Unternehmens festgestellt, seine Leistungs- und Rentabilitätsziele zu erreichen. Dokumentation ist ebenfalls hochtechnische Arbeit im Softwareentwicklungsprozess, und diese Ergebnisse zeigen, wie sehr sich diese Arbeit auszahlt. Die Dokumentation kritischer Systeme und Anwendungsfälle ist Teil des Abbaus von Silos und stellt einen praktischen Wissensaustausch dar. Erstellen Sie klare Richtlinien für die Dokumentationspflege. Teammitglieder sollten wissen, wie sie Aktualisierungen vornehmen und veraltete Inhalte entfernen können, damit die Dokumentationsqualität auch bei Systemänderungen beibehalten wird. Dokumentation als Teil des Softwareentwicklungsprozesses einbeziehen. Wie das Testen ist auch die Erstellung und Pflege der Dokumentation ein wesentlicher Bestandteil eines leistungsstarken Softwareentwicklungsprozesses. Erkennen Sie die Dokumentationsarbeit bei Leistungsbeurteilungen und Beförderungen an. Die Dokumentation ist ebenfalls ein essenzieller Bestandteil der Software, und sollte als solcher anerkannt werden, um die Qualität zu verbessern. Organisatorisch Die folgende Grafik veranschaulicht zwei Modelle, die DevOps- und SRE-Rollen in agilen Produktteams organisieren, um eine effektive Zusammenarbeit, schnelle Feedbackschleifen und kontinuierliche Verbesserungen zu fördern. In einem nach DevOps-Prinzipien organisierten agilen Produktteam sind alle wichtigen Rollen und Qualifikationen vertreten, von der Softwareentwicklung über den Betrieb und das Testen bis hin zum Produktmanagement. Dieses dezentrale Setup fördert eine engmaschige Zusammenarbeit, schnelle Feedbackschleifen und eine ständige Verbesserung der Arbeitsprozesse. Auf der anderen Seite hat ein separates SRE-Team die Rolle des „Enablers“. Es unterstützt mehrere Produktteams, indem es deren Betriebslast übernimmt und gleichzeitig die allgemeine Systemzuverlässigkeit sicherstellt. Darüber hinaus kann das SRE-Team durch seine beratende Funktion dabei helfen, DevOps-Prinzipien in der gesamten Organisation zu etablieren und zu verankern, indem es Best Practices teilt und die Teams bei der Bewältigung betrieblicher Herausforderungen unterstützt. Fangen Sie klein an und wählen Sie eine relativ simple Komponente mit wenig Abhängigkeiten als Pilotprojekt, um DevOps-Implementierung in Produktion zu erproben. Messen Sie dabei regelmäßig die erwähnten Kennzahlen, identifizieren Sie Verbesserungspotenziale und nehmen Sie schrittweise Änderungen vor, um die Leistung kontinuierlich zu steigern. Platform Engineering als Ablösung des DevOps-Paradigmas Platform Engineering ist eine weitere aktuelle Entwicklung, die die Prinzipien von DevOps aufgreift und dabei bewusst darauf verzichtet, die spezialisierten Rollen in Entwicklung und im Betrieb zu vereinen oder zu ersetzen. Stattdessen zielt dieser Ansatz darauf ab, die individuellen Stärken und Fähigkeiten jedes Teams anzuerkennen und die jeweiligen Kernkompetenzen optimal zu nutzen. Dies wird durch eine klare Trennung der Zuständigkeiten und die Nutzung von Internal Developer Platforms (IDP) als Abstraktionsschicht zwischen Produktteams und der genutzten Infrastruktur erreicht. Die IDP dient dabei als zentrales Element, das den gesamten Lebenszyklus einer Anwendung abdeckt und Entwickler:innen erlaubt, effizient zu arbeiten, ohne sich mit der Komplexität der Infrastruktur bis ins Detail auseinandersetzen zu müssen. Die IDP abstrahiert Kernkomponenten wie Infrastruktur-Orchestrierung durch Kubernetes, Umgebungsmanagement und CI/CD und stellt diese als Self-Service-Lösungen bereit. Dies reduziert die kognitive Last für Entwicklerteams und ermöglicht eine schnellere Umsetzung von Projekten, ohne dass das Platform Team zum Flaschenhals wird. Es gibt einige interessante Projekte wie KusionStack, Radius, Crossplane, KubeVela, Humanitec und AWS Proton, die auf die Entwicklung einer IDP abzielen und die Unterscheidung sowie Aufteilung von Verantwortlichkeiten zwischen Entwicklung und Betrieb implementieren. Platform Engineering schafft einen Rahmen, in dem Entwickler als interne Kunden behandelt werden und gleichzeitig zur kontinuierlichen Verbesserung der Plattform beitragen können, um eine Kultur der Zusammenarbeit und Innovation zu fördern. Es stellt eine natürliche Evolution des DevOps-Paradigmas dar, indem es die Verantwortung und Autonomie jedes Teams stärkt und so einen effizienteren, flexibleren Entwicklungsprozess ermöglicht. Ausblick: Wie können Unternehmen von der richtigen Anwendung von DevOps-Methoden profitieren? Platform Engineering stellt keinen Ersatz für DevOps dar, noch zielt es darauf ab, Teams erneut in isolierte Silos zu separieren. Vielmehr geht es darum, den Fokus zurück auf die Kernkompetenzen der Teams zu lenken und in diesen Bereichen den größtmöglichen Mehrwert zu schaffen. Die Essenz von DevOps – die Förderung von Kommunikation und Zusammenarbeit zwischen Entwicklung und Betrieb – bleibt zum Vorteil des Unternehmens und letztendlich des Kunden unverändert relevant. Die vorgestellte schrittweise Adoption von DevOps, angepasst an die spezifischen Bedürfnisse eines Unternehmens, ist essentiell für die Verbesserung der Leistungsfähigkeit. Dabei sollte Platform Engineering als Chance gesehen werden, nicht als ein weiteres Buzzword. Aus unserer Erfahrung heraus bietet Platform Engineering eine hervorragende Möglichkeit, die Konzepte DevOps und Site Reliability Engineering harmonisch zu vereinen und somit nicht nur die interne Zusammenarbeit zu verbessern, sondern auch ein optimales Produkt- und Serviceangebot für Kunden zu gestalten. Wir werden uns in einem bald erscheinenden Blog-Artikel noch detaillierter mit der Umsetzung und den Vorzügen von Platform Engineering beschäftigen.
Die PKV Beitragserhöhungen 2022 für das kommende Jahr werden aller PKV Beitragserhöhungen 2022 Unterschiede Neugeschäft und Bestand weiter » Der Beitrag PKV Beitragserhöhungen 2022 Unterschiede Neugeschäft und Bestand erschien zuerst auf Arbeitskreis
zum Artikel gehenWas macht eigentlich ein DevOps Engineer bei AIM? Wir haben uns mal umgehört und unseren Kollegen Frederic befragt. Frederic unterstützt das AIM-Team bereits seit Sommer 2021 an unserem Standort in Hannover. Was sind deine Aufgaben? Da wir bei AIM unseren
zum Artikel gehenHome Case studies Henkel’s DevOps triumph – a boost of agility, clear focus and team engagement Henkel embarked on a journey to enhance quality and engagement across the
zum Artikel gehenCase Studies IoT solution for airport self-boarding SITA, the world’s leading specialist in air transport communication and information technology, decided to develop an intelligent cloud platform to support
zum Artikel gehenEs gibt eine Menge Hörbuch-Anbieter. Wer genau hinsieht, bemerkt einige Unterschiede. So kannst du dir bei Audible ein kostenloses Hörbuch pro Monat holen, während du bei Bookbeat eine bestimmte Hörzeit... Weiterlesen Der Beitrag Hörbuch-Angebot Podimo e