DevOps – Kann das überhaupt skalieren?
Das DevOps-Betriebs- und -Entwicklungsmodell bietet viele Vorteile hinsichtlich der langfristigen Entwicklung und des (fachlichen) Betriebs von qualitativ hochwertiger Software. In einem Umfeld, in dem nicht nur eine Software durch ein Team entwickelt und betreut wird, stellt sich aber die Frage, wie DevOps skaliert werden kann. Insbesondere spielen hierbei die kognitive Last der einzelnen Mitglieder sowie die verfügbaren Personalressourcen eine entscheidende Rolle.
In diesem Beitrag sollen daher die Herausforderungen sowie Lösungsansätze für die Skalierung des DevOps-Modells aus Entwicklersicht dargestellt werden. Der Fokus liegt hierbei auf der Automatisierung von Regelaufgaben sowie Modellen für eine teamübergreifende Zusammenarbeit in Betrieb und Entwicklung. Ziel der diskutierten Maßnahmen ist es, langfristig Betrieb und Weiterentwicklung in einem ausgewogenen Maß parallel ausführen zu können.
DevOps und Skalierung: Unser DevOps-Verständnis
Um die Limitationen der vorgestellten Ansätze zur Skalierung von DevOps in einem Multiprojektumfeld mit mehreren Teams zu verstehen, müssen zunächst sowohl das Umfeld als auch die gewählte Herangehensweise an das DevOps-Modell dargestellt werden.
In der klassischen Darstellung des DevOps-Workflows nach Pease befinden sich Dev und Ops, also Entwicklung und Betrieb einer Software, in einem dauerhaften und sich wiederholenden Zyklus (s. Abb.) [1].
In der Realität gibt es mit dieser zwar sehr anschaulichen Darstellung allerdings einige Probleme. Innerhalb eines Entwicklungszyklus sind die einzelnen Phasen keineswegs klar voneinander getrennt. So finden im Verlauf eines Produktinkrements die Entwicklung ("Code"), das Bauen der Software ("Build") und das Testing ("Test") für mehrere unterschiedliche Features gleichzeitig statt. Dies hat vorwiegend den Grund, dass es meist nicht sinnvoll ist, alle Entwickler am selben Feature arbeiten zu lassen, da dies die Effizienz mindert. Zusätzlich finden diese Phasen auch innerhalb eines Features im besten Fall teilweise parallel statt, um Zeit zu sparen. So können beispielsweise automatisierte Tests in einer CI/CD-Pipeline laufen, während ein neuer Codestand entwickelt wird.
Neben der zuvor genannten Parallelität der einzelnen Phasen innerhalb eines Entwicklungszyklus gibt es mit der klassischen Darstellung des DevOps-Workflows noch ein viel größeres Problem. Diese einfache Darstellung vermittelt den Eindruck, dass während der Entwicklung keine Notwendigkeit des Betriebs besteht. Sobald allerdings eine Software in einer produktiven Umgebung veröffentlicht wurde, muss sie auch fachlich wie technisch betrieben werden.
Es ist hierbei also nicht möglich, eine Software, die potenziell hunderttausende Nutzer hat, einfach sich selbst zu überlassen, während die nächste Version entwickelt wird. Der fachliche wie technische Betrieb muss daher ab Produktivgang bis zum Ende der Lebenszeit der Software gewährleistet werden. Ein weiterer Schwachpunkt der klassischen DevOps-Darstellung besteht in der Weise, wie neue Anforderungen in die Planung des neuen Inkrements aufgenommen werden. Gemäß dieser Darstellung können neue Anforderungen nur aus dem Betriebsanteil kommen. In der üblichen (Weiter-)Entwicklung einer Software können zwar auch Anforderungen wie beispielsweise Verbesserungen in der Stabilität aus dem Betrieb kommen, die meisten Anforderungen kommen aber "von außerhalb" über Stakeholder in die Planungsphase. Diese Erkenntnisse aus der Praxis lassen sich in einer realitätsnäheren Darstellung abbilden (s. Abb. 2).
Mit Hilfe dieses grundsätzlichen DevOps-Workflows kann man unser Verständnis von DevOps weiterhin einfach mit dem Satz "You built it, you run it." zusammenfassen. Dies bedeutet für uns, dass wir als Team eine Ende-zu-Ende-Verantwortung (von Entwicklung über Betrieb bis hin zur Einstellung) unserer Services haben. Wenn es zu einem Fehler in einem unserer Services kommt, sind wir dafür verantwortlich, diesen zu beheben. Über dieses grundsätzliche DevOps-Verständnis hinaus sind wir der Ansicht, dass wir zu jeder Zeit Änderungen in unsere Produktionsumgebung einspielen können müssen. Bei aktiv in der Entwicklung befindlichen Services versuchen wir daher mehrmals täglich, mindestens aber nach Abschluss eines neuen Features, dieses in unsere Produktionsumgebung einzuspielen. Das ermöglicht uns nicht nur, neue Features so schnell wie möglich zur Verfügung zu stellen, sondern auch Sicherheitslücken sehr schnell zu schließen.
DevOps und Unternehmenskultur: Umfeld
Als zweiter wichtiger Aspekt ist die Unternehmenskultur zu betrachten. In der DB Systel GmbH – dem IT- und Digitalisierungspartner der Deutschen Bahn (DB) – existieren größtenteils selbstorganisierte Teams. Diese Teams werden in der Regel nicht pro Projekt neu zusammengesetzt, sondern bestehen über Projektgrenzen hinweg. Hierdurch werden Reibungsverluste durch immer neue Forming-, Storming- und Normingphasen der Teams vermieden [2].
Als höhere Form der Organisation werden Teams in Einheiten und diese wiederum in Cluster eingeteilt. Einheiten sollen dabei Teams von gleichartigen Tätigkeiten entlasten und ermöglichen damit eine Fokussierung ihrer zugehörigen Teams auf ihr Kerngeschäft. Cluster gruppieren hingegen Einheiten und geben vor allem eine strategische Ausrichtung vor.
Durch diesen strukturellen Rahmen der DB Systel ergibt sich eine vergleichsweise flache Hierarchie. Dies bietet vielen Teams ein hohes Maß an Freiheiten bei gleichzeitiger Erfüllung strategischer und organisatorischer Vorgaben. Mit den gewährten Freiheiten geht für die Teams auch ein hohes Maß an Verantwortung einher.
Innerhalb des zuvor beschriebenen Unternehmensumfelds bildete sich zunächst ein Team namens doService, welches sich zum Ziel gesetzt hat, wiederverwendbare Services nach dem API-First-Ansatz für die Deutsche Bahn zu entwickeln. Ein Service stellt dabei eine Software mit abgeschlossener Funktionalität, die über eine API angesprochen werden kann, dar. Alle Services werden nach dem API-First-Ansatz entwickelt, bei dem zunächst eine Schnittstelle (API) für die jeweilige Fachdomäne erstellt wird. Hierbei wird zunächst die Fachdomäne des jeweiligen Service durchdrungen und danach eine API-Spezifikation erstellt. Diese Spezifikation ist dann der Ausgangspunkt sowohl für alle Entwicklungen innerhalb des Service als auch für eine Kommunikation mit den Konsumenten.
Die Entwicklung wiederverwendbarer Services steht dabei im Kontrast zu den Individualentwicklungen der einzelnen Geschäftsfelder der Deutschen Bahn. Durch Abstraktion und Wiederverwendbarkeit soll eine Skalierbarkeit der einzelnen Services erreicht werden. Nach der Entwicklung erster Services in verschiedenen Fachdomänen stellte sich schnell heraus, dass ein einzelnes Team nicht den gesamten Bedarf an Services abdecken konnte. Durch diese Erkenntnis gab es zunächst eine Teilung und Personalaufstockung des ursprünglichen Teams in zwei neue eng zusammenarbeitende Teams. Da der Bedarf an wiederverwendbaren Services auch durch zwei Teams nicht gedeckt werden konnte, wurden im Laufe der Zeit insgesamt fünf Teams im doService-Umfeld gegründet.
In einem dieser Teams, in dem ich Mitglied bin, entwickeln und betreiben wir Services in den Bereichen Geodaten, Reisendeninformation, Vertrieb, Verbund (Fahrzeugbereitstellung), Plattformlösungen für die Deutsche Bahn sowie Fahrzeugdiagnose & -sensorik. In diesen unterschiedlichen Fachdomänen haben wir aktuell 13 Services in unserer Produktivumgebung. Diese reichen in der Komplexität von ein paar tausend Zeilen Code bis hin zu zehntausenden Zeilen Code.
Technisch bauen unsere Services auf Spring Boot auf und sind für den Betrieb in Kubernetes ausgelegt. Um einen Service in Kubernetes bereitzustellen, nutzen wir eine DB-weite Standard CI/CD-Pipeline auf Basis von GitLab CI, welche wiederum Helm verwendet. Innerhalb dieser CI/CD-Pipeline finden neben unseren automatisierten Tests (JUnit, Cucumber und Karate) auch Security- und Codeanalysen (u. a. mittels Trivy) statt. Alle in der Produktionsumgebung befindlichen Services werden aktiv durch Prometheus in Verbindung mit Grafana sowie Icinga überwacht. Teil dieser Überwachung sind Alarme, wenn bestimmte fachliche wie technische Schwellwerte über- beziehungsweise unterschritten werden.
DevOps skalieren: Herausforderungen
Durch die schnelle horizontale Skalierung von einem auf fünf Teams sowie die Entwicklung vieler Services gleichzeitig ergeben sich Herausforderungen für die Entwicklung und den Betrieb in unserem Umfeld. Zum einen sind wir – wie auch unsere Schwesterteams – mit vielen unterschiedlichen fachlichen Themengebieten und Projekten gleichzeitig beschäftigt. Allein bei uns im Team bedienen wir sechs komplett unterschiedliche Fachdomänen (s. DevOps und Unternehmenskultur: Umfeld). Jede dieser einzelnen Fachdomänen hat einen solchen Umfang, dass ein gesamtes Arbeitsleben hineininvestiert werden kann, ohne alle Details zu kennen.
Dies erzeugt vor allem im Betrieb, aber auch in der Weiterentwicklung unserer Services eine hohe kognitive/ mentale Last bei den Mitgliedern im Team. Diese Last ist primär dadurch bedingt, dass die Teammitglieder viel Wissen aus jedem fachlichen Kontext benötigen und zudem häufig diesen Kontext wechseln müssen. Jeder dieser Wechsel ist hierbei sowohl mit einem Zeitverlust durch das erneute Hineindenken in den jeweiligen Kontext als auch mit einer Erhöhung der kognitiven/ mentalen Last verbunden. Dies führt zu einer zeitlichen Erhöhung der Betriebsaufwände unserer Services über das notwendige Maß hinaus.
Zudem steigt mit jedem neuen Service, der in die Produktionsumgebung veröffentlicht wird, der betriebliche Anteil weiter. Die naheliegendste Lösung wäre hier, weitere Teams, welche sich auf jeweils eine Fachdomäne spezialisieren, zu gründen. Eine nahezu unbegrenzte horizontale Skalierung von Teams ist aber bereits auf Grund eines Mangels an qualifiziertem Personal nicht möglich. Darüber hinaus ergeben sich durch eine solche Form der Skalierung neue Herausforderungen, zum Beispiel in der Koordination bei domänenübergreifenden Themen und Themen einer Domäne, die zu groß für ein einzelnes Team sind. Aus diesen Gründen stellt sich die Frage: "DevOps – Kann das überhaupt skalieren?"
Lösungsansätze zur Skalierung von DevOps
Um die zuvor genannten Herausforderungen zu bewältigen und sinnvolle Maßnahmen abzuleiten, müssen zunächst die zwei Ebenen von DevOps betrachtet werden. Zum einen besteht DevOps aus einem technischen Teil. Zum anderen aus einem fachlichen. Für den fachlichen DevOps-Teil benötigt es tiefgreifende Kenntnisse über die fachliche Domäne des jeweiligen Service. Dies lässt sich unseren Erfahrungen nach nicht gut skalieren. Für den technischen Teil konnten wir allerdings auf verschiedenen Ebenen Maßnahmen zur Verbesserung ergreifen.
1. DevOps und automatisierte Software-Tests
Auf der individuellen Teamebene wurden zunächst die automatisierten Tests (Unit-, Komponenten- und Integrationstests) erweitert. Hierfür wurde neben JUnit auch Cucumber vor allem für Integrationstests eingeführt. Das Besondere an Cucumber ist dabei, dass Testfälle in einer natürlichsprachlichen Version abstrahiert geschrieben werden können. Dies vereinfacht das Testen von Verhalten unserer Services an der API. Zudem kann die natürlichsprachliche Version der Tests auch genutzt werden, um mit Partnern und Kunden das gewünschte Verhalten des Service durchzusprechen, bevor es implementiert wird. Hierdurch kann Cucumber auch das Test Driven Development (TDD) unterstützen.
2. Automatische Aktualisierung von Dependencies
Eine weitere Maßnahme auf der Teamebene, die auf guten und automatisierten Tests aufbaut, ist die automatische Aktualisierung unserer Dependencies (Serviceabhängigkeiten). Durch den Renovate Bot können wir einfach unsere Dependencies auf dem aktuellen Stand halten. Dies sorgt zum einen dafür, dass unsere Services seltener und vergleichsweise kurz von externen Sicherheitsschwachstellen betroffen sind. Zum anderen ist die Migration von einer Dependency-Version auf die nächste meist deutlich einfacher und damit weniger aufwändig als ein großer Versionssprung.
Dies liegt vor allem daran, dass man zum Zeitpunkt der Aktualisierung bei einem großen Versionssprung häufig mehrere Änderungen, die den eigenen Code brechen, behandeln muss. Um kein dauerhaftes Grundrauschen durch automatisierte Dependency-Updates zu erzeugen, haben wir uns dafür entschieden, diese einmal wöchentlich in unsere Services einzuspielen. Dies reicht unseren Erfahrungen nach aus, um auf einem aktuellen Stand zu bleiben. Im Bedarfsfall – zum Beispiel bei einer kritischen Sicherheitsschwachstelle in den Dependencies – können wir über den gleichen Mechanismus Aktualisierung mit einem Klick anstoßen.
3. DevOps stabilisieren durch resiliente Services
Zusätzlich zu den vorherigen Maßnahmen konzipieren und entwickeln wir unsere Services so resilient wie möglich. Dies bedeutet, dass all unsere Services sowohl mit dem Ausfall von benötigten Umsystemen als auch Infrastrukturkomponenten (beispielsweise Datenbanken) umgehen können müssen. Dies wird unter anderem durch wiederholte Anfragen an Umsysteme sowie die Bereitstellung einer verminderten Funktionalität erzielt, falls notwendige Systeme dauerhaft nicht verfügbar sind. Zudem werden unsere Services selbst aktiv durch sogenannte Health-Checks von außen überwacht. Wenn diese Health-Checks über eine definierte Zeit nicht funktionieren, erhalten wir eine aktive Benachrichtigung hierzu.
Unsere Services werden resilient gestaltet und aktiv überwacht um "selbstheilende Services" zu entwickeln.
Ziel dieser Maßnahmen ist es, "selbstheilende Services" zu entwickeln. Diese Art von Services kann mit verschiedenen Formen von Fehlern umgehen und sich im schlimmsten Fall durch einen Neustart versuchen, selbst aus einem Fehlerfall zu befreien. Dadurch werden die Ausfallzeit sowie die Anzahl der betroffenen Nutzer reduziert. Zudem führt nicht jede temporäre Einschränkung in der Systemlandschaft dazu, dass ein Teammitglied sich um diese Störung kümmern muss.
Dies schafft personelle Kapazitäten im Team für Aufgaben abseits des Betriebs. Voraussetzung für "selbstheilende Services" ist der Einsatz von skalierfähigen Technologien wie Containern in Kubernetes sowie der Aufbau einer gewissen Redundanz. Nur so ist es ohne große Auswirkungen möglich, dass sich Services selbstständig neu starten können, ohne zu einem Ausfall zu führen. Besonders bei kritischen Infrastrukturkomponenten ist die Redundanz entscheidend, da hier ein Ausfall die größten Auswirkungen hat.
4. DevOps und Redundanz der Infrastruktur
Aus diesem Grund haben wir bei solchen Infrastrukturkomponenten immer mindestens zwei Replika gleichzeitig in Betrieb. Diese Replika werden zusätzlich in verschiedenen Verfügbarkeitszonen (Availability Zones in AWS) bereitgestellt. Dies erhöht grundsätzlich die Verfügbarkeit und ermöglicht es uns, zusätzlich Aktualisierungen der Komponenten (z. B. Update der Datenbankversion) ohne Ausfallzeit im laufenden Betrieb vorzunehmen.
5. Reduktion des Technologie-Stacks
Neben der Verbesserung der Resilienz unserer Services ist auch die Reduzierung des Technologie-Stacks ein wichtiger Baustein für die Skalierung von DevOps auf der Teamebene. Natürlich ist es sinnvoll, neue Technologien und Frameworks auszuprobieren. Eine heterogene Systemlandschaft, bei der jeder Service einen anderen Technologie-Stack oder sogar eine andere Programmiersprache besitzt, führt allerdings zu einem erhöhten Betriebsaufwand, da sie mit einer erhöhten Einarbeitungszeit in den jeweiligen Service verbunden ist.
Durch die Reduzierung des Technologie-Stacks und die damit einhergehende Homogenisierung der Systemlandschaft können diese Mehraufwände reduziert werden. Hierbei ist eine Abwägung zwischen Einheitlichkeit der einzelnen Services und speziellen Anforderungen essenziell. Denn nicht bei jedem Service ist es sinnvoll, den Technologie-Stack zu reduzieren und sich somit übermäßig bei der Entwicklung einzuschränken.
6. Reduktion des fachlichen Kontextes
Neben einer Reduktion des Technologie-Stacks ist es aus betrieblicher Sicht auch nützlich, die unterschiedlichen fachlichen Kontexte zu reduzieren. Jeder fachliche Kontext bringt seine eigenen Herausforderungen mit sich. Besonders in der Kombination unterschiedlicher fachlicher Kontexte entstehen im Betrieb Reibungsverluste. Diese Reibungsverluste ergeben sich hauptsächlich durch den Wechsel von einem Kontext in den anderen. Eine Möglichkeit, die fachlichen Kontexte zu reduzieren, findet sich in der Abgabe einzelner Services.
In der Vergangenheit haben wir bereits Services an Teams abgegeben, zu deren Portfolio sie besser passen. Hierdurch werden diese Services nun von Teams betrieben und weiterentwickelt, deren Fokus auf der jeweiligen Fachdomäne liegt. Zusätzlich haben wir kaum genutzte Services mit einer entsprechenden Vorankündigung an die Konsumenten eingestellt. Beide Maßnahmen zusammen haben es ermöglicht, uns auf eine geringere Anzahl fachlicher Domänen zu beschränken und unsere Services innerhalb dieser Domänen weiter auszubauen.
7. DevOps und Handlungsanweisungen
Eine weitere Maßnahme auf Teamebene abseits der Automatisierung und Fokussierung wurde in Form von ausführbaren Anleitungen und Checklisten umgesetzt. Im Regelbetrieb lassen sich nicht alle Aufgaben (voll-)automatisieren. Für solche Aufgaben ist es wichtig, klare und vor allem direkt ausführbare Schritt-für-Schritt-Anleitungen zu erstellen.
Diese Anleitungen ermöglichen es, manuelle Tätigkeiten schnell und einfach zu erledigen. Wichtig beim Erstellen und Pflegen solcher Anleitungen und Checklisten ist es, dass jedes Mitglied in unserem Team diese versteht. Diese Anleitungen und Checklisten sind besonders sinnvoll, wenn zusätzlich eine Rolle für den täglichen Betrieb existiert.
8. DevOps und Tagdienst
Dieser im Team rollierende Tagdienst – bei uns "Chewie" genannt – ist hierbei für den Betrieb unserer Services am jeweiligen Tag zuständig. Der Tagdienst ist somit die erste Anlaufstelle bei Problemen in unseren Services. Hierfür ist die Kapazität der jeweiligen Person in unserer Sprintplanung abgezogen, sodass ein Freiraum für die Bearbeitung von kritischen Fehlerfällen existiert. Kommt es im Regelfall nicht zu Problemen in unseren Services, arbeitet der Tagdienst wie jedes andere Teammitglied normale Sprintaufgaben ab.
9. DevOps standardisieren
Zusätzlich zu der Teamebene haben wir zusammen mit unseren Schwesterteams aus dem doService-Umfeld Maßnahmen zur Verbesserung der Entwicklung und des Betriebs erarbeitet. Hier lag der Fokus zunächst auf der Identifizierung gemeinsam wartbarer Projekte und Libraries.
Unter anderem wurden in diesem Prozess Softwarekomponenten (Libraries) für ein gleichartiges Logging, Monitoring und Sammeln von Telemetriedaten ausgelagert. Dazu wurden Libraries für ein einheitliches HTTP-, MQTT-, Kafka- und Exception-Handling für unsere Java-Services erstellt. Diese Libraries ermöglichen es uns, neue Services mit einer gewissen Grundfunktionalität schnell und einfach zu erstellen. Dies wird zusätzlich durch ein gemeinsam gepflegtes Spring-Boot-Startprojekt vereinfacht.
Darüber hinaus haben wir unsere CD/CI-Pipeline, welche bereits auf einer Standardlösung innerhalb der Deutschen Bahn beruht, gemeinsam erweitert, sodass sie für unsere Anwendungsfälle einsetzbar wird. Zusätzlich haben wir auf der doService-Ebene Zeit in eine gemeinsame Monitoring-Infrastruktur auf Basis von Icinga und Grafana investiert.
10. Maintainer-Ansatz in DevOps
Um alle gemeinsam entwickelten Lösungen auch langfristig aktuell zu halten, haben wir uns für einen Maintainer-Ansatz, ähnlich dem von OpenSource-Projekten, entschieden. Hierbei haben sich Maintainer der einzelnen Libraries aus den fünf Teams zu deren Pflege bereiterklärt. Diese Maintainer, die durch die Teams mandatiert wurden, tragen die Verantwortung für die Libraries. Dies bedeutet, dass sie einen gewissen Anteil ihrer Arbeitszeit abseits von Projekten an den Libraries arbeiten sollen, um diese aktuell zu halten und zu verbessern. Neben den Maintainern, die sich in einem virtuellen Team organisieren, ist es jedem Mitglied des doService-Umfelds freigestellt, Änderungen an den Libraries vorzunehmen. Diese müssen allerdings durch einen Maintainer, der die Stabilität der Library sicherstellt, freigegeben werden.
11. DevOps und Wissensaustausch
Zusätzlich zur gemeinsamen Pflege von Libraries wurde im doService-Umfeld ein regelmäßiger Austausch zu Betriebsthemen ins Leben gerufen. Dieser soll dazu dienen, Betriebserfahrungen im ähnlichen Umfeld zu diskutieren und voneinander zu lernen.
Bei abgeschlosseneren Themengebieten sowie Themen, die über mehrere doService-Teams koordiniert werden müssen, wurden virtuelle Thementeams aus Freiwilligen gegründet. Diese virtuellen Teams bearbeiten das jeweilige übergreifende Thema und sorgen somit unter anderem für die Gestaltung einheitlicher APIs in verteilten Systemen. Ein aktuelles Beispiel findet sich in der Verbesserung des Zugbereitstellungsprozesses. Hier wird zunächst eine übergreifende API für mehrere Services, welche in unterschiedlichen Teams entwickelt werden, erstellt.
12. DevOps-Betrieb stetig verbessern
Auch auf Einheitenebene wurden Maßnahmen zur Verbesserung der Entwicklung des Betriebs abgeleitet. Diese dienen vorwiegend der Förderung der Aufmerksamkeit des Themas DevOps.
Alle Maßnahmen dienen einer konzeptionellen Ebene, die auf den Austausch von Erfahrungen abzielt.
So wurde auf Einheitenebene ein Austauschformat zu verschiedenen DevOps-Themen organisiert. Bei diesem Austausch ist es im Sinne der Beteiligung sehr sinnvoll, konkrete Themen als Ausgangspunkt zu wählen. So kann beispielsweise ein Team innerhalb der Einheit eine konkrete Lösung für eine Herausforderung im Betrieb vorstellen. Ein komplett offener Austausch verläuft hingegen zu unstrukturiert ab, was mittelfristig die Beteiligungsquote sinken lässt. Zudem wurde eine DevOps-Videoreihe produziert, um über konkrete Erkenntnisse zu berichten. Weiterhin wurde eine DevOps-Community auf der Ebene der Einheit für einen Austausch ins Leben gerufen.
Alle Maßnahmen der Einheit dienen somit einer konzeptionellen Ebene, die auf den Austausch von Erfahrungen abzielt. Über diese konzeptionelle Ebene hinaus gestalteten sich weitere Maßnahmen schwierig, da die einzelnen Teams innerhalb der Einheit in sehr unterschiedlichen Umfeldern arbeiten. Einfache und einheitliche Lösungen sind somit sehr schwer umzusetzen.
Fazit: So kann DevOps skalieren!
Zu Beginn unserer Reise stand die Frage "DevOps – Kann das überhaupt skalieren?" Diese lässt sich je nach Betrachtung mit "Ja" oder "Nein" beantworten.
DevOps und Fachlichkeit
Betrachtet man zunächst die fachliche Seite von DevOps, so ist eine Skalierung für einen fachlichen Betrieb sehr schwer bis fast unmöglich, da dieser ein sehr großes Wissen sowie eine breite Wissensverteilung voraussetzt. Im fachlichen Teil von DevOps ist daher eine Fokussierung auf wenige Fachdomänen essenziell. Bei einer Erweiterung des Service-Portfolios sind Fachdomänen, die eine Ähnlichkeit zu bereits im Portfolio befindlichen Services haben, komplett neuen Domänen vorzuziehen. Dies hilft bei der zuvor beschriebenen Fokussierung und erleichtert sowohl die Entwicklung als auch den langfristigen Betrieb der neuen Services.
Skalierbarkeit von DevOps und Technik
Im technisch geprägten Teil von DevOps kann die Frage der Skalierbarkeit mit einem "Ja" beantwortet werden. Um diese Skalierung über ein einzelnes Team hinaus zu erreichen, braucht es einzelne Personen, die die Verantwortung für gemeinsame Projekte und Libraries übernehmen. Diese Personen müssen sowohl die Kompetenz als auch den Willen haben, die gemeinsamen Libraries dauerhaft zu pflegen. Zudem muss ein klares Mandat für übergreifende Tätigkeiten aus den jeweiligen Teams erteilt werden. Dies minimiert Zeitverluste durch häufige Abstimmungen in den Teams. Neben diesen Maintainern muss es aber auch für alle anderen Mitglieder der Teams möglich sein, gemeinsame Projekte und Libraries zu pflegen. Erfahrungsgemäß hält sich die Beteiligung hier aber zurück, da abseits der Maintainer nicht immer das benötigte Verantwortungsbewusstsein oder das entsprechende Wissen vorhanden ist.
Freiräume für DevOps-Maintainer
Damit unser Konstrukt übergreifender Projekte und Libraries funktioniert, müssen Freiräume für die Maintainer existieren. Ohne diese Freiräume kann keine Arbeitszeit für Verbesserungen im laufenden Betrieb eingesetzt werden. Hierbei zahlen sich zuvor getätigte Investitionen in die Automatisierung von Regelaufgaben (z. B. Dependency-Updates) aus, da diese für zusätzliche Freiräume sorgen. Im besten Fall entsteht hierdurch eine positive Rückkopplungsschleife, in welcher investierte Zeit zu mehr Freiräumen führt. Natürlich ist dies nicht unbegrenzt möglich.
Für eine dauerhafte Nutzung des DevOps-Modells benötigt es immer Personen mit der richtigen Einstellung.
Reduktion der Komplexität
Eine weitere wichtige Stellschraube findet sich in einer Reduktion der Komplexität. Nach Möglichkeit sollten so wenig unterschiedliche technische Lösungen wie möglich eingesetzt werden, da die Vielzahl die kognitive/ mentale Last jedes Teammitglieds erhöht. Einen Weg, dies zu erreichen, können Standardlösungen darstellen. Für gleichartige Probleme sollte eine standardisierte Lösung der Entwicklung verschiedener sehr ähnlicher Lösungen vorgezogen werden. Gibt es bereits viele unterschiedliche Lösungen für das gleiche Problem, sollten diese konsolidiert werden. Eine Konsolidierung bedarf dabei in der Regel auch einer Abstraktion der Lösung. In diesem Rahmen sollten konstruktive Lösungen gefunden werden.
Das Argument "Das ist historisch so gewachsen." ist hier unbedingt außen vor zu lassen. Wichtiger ist es, die Gemeinsamkeiten unterschiedlicher Lösungen herauszuarbeiten und zusammenzufassen. Hierfür sind Austausch und Recherche von zentraler Bedeutung.
Neben der Einführung von Standardlösungen lohnen sich alle Anstrengungen, einen Service im Betrieb stabiler und zuverlässiger zu machen, mittel- bis langfristig. Je weniger manuelle Intervention im Betrieb notwendig ist, desto mehr Kapazität bleibt für die Entwicklung neuer Features. Ziel sollte es im DevOps daher immer sein, die betrieblichen Aufwände so weit wie möglich zu reduzieren.
Neben allen technischen Optimierungen sollte immer die personelle Ebene beachtet werden. Für eine dauerhafte Nutzung des DevOps-Modells benötigt es immer Personen mit der richtigen Einstellung. Nur diese Personen werden die Verantwortung für die stetige Verbesserung sowohl im Betrieb als auch in der Weiterentwicklung langfristig übernehmen.
- Pease, J. (2017). DevOps Part 1: It’s More Than Teams
- Tuckman, B. W. (1965). Developmental sequence in small groups. Psychological Bulletin, 63(6), pp. 384–399.
Neuen Kommentar schreiben