DevOps-orientierte Ingenieure sind in der Schnittmenge aus IT Operations und Softwareentwicklung angesiedelt: Sie wissen ziemlich genau, was für die Wartung der IT-Infrastruktur erforderlich ist, und sind gleichzeitig in der Lage, Code zu schreiben und neue Services bereitzustellen. DevOps-orientierte Teams erstellen Services nicht nur, sondern warten sie auch. Eine DevOps-Struktur zwingt Teams dazu, Verantwortung für ihre Anwendungen und Infrastruktur zu übernehmen, und erlaubt den Entwicklern nicht, der IT Code ohne jede weitere Verantwortlichkeit einfach vor die Füße zu kippen.
Im Lebenslauf eines Ingenieurs mit Schwerpunkt DevOps finden sich in der Regel gleichzeitig ein breites Spektrum an Know-how sowie spezialisiertes Fachwissen in einem oder zwei Bereichen. Zu den wichtigsten Aufgaben und Verantwortlichkeiten eines DevOps-Teams gehören:
- Für effektive Kommunikation sorgen
- Transparenz über die gesamte CI/CD-Pipeline verbessern
- Ständig dazulernen
Das Streben nach ständiger Verbesserung ist ein Kernaspekt einer effizienten DevOps-Organisation. Jede Person in einer DevOps-orientierten Organisation sollte sich stark darauf konzentrieren, schnell neue Funktionen und Services zu entwickeln, ohne dabei Abstriche bei der Zuverlässigkeit oder Kundenerfahrung zu machen.
Im Folgenden sehen wir uns einige Kernprinzipien von DevOps an und untersuchen, wie sich die Beziehungen zwischen Entwicklern und IT verbessern lassen und wie DevOps helfen kann, den Geschäftswert schnell zu steigern.
Entwicklung und ITOps finden zusammen
In einem Engineering- und IT-Unternehmen ohne abgeschottete Silostrukturen entstehen bessere Ideen und die Produktivität steigt. Bei DevOps werden die Dinge tatsächlich aus einem anderen Blickwinkel betrachtet. Es ist eine Möglichkeit, die Zusammenarbeit und Transparenz zwischen Softwareentwicklung und IT Operations zu verbessern, was zu mehr Transparenz für Business-Teams und letztlich zu mehr Umsatz führt.
Durch kürzere Feedbackschleifen und eine verbesserte Kommunikation zwischen IT und Entwicklung könnt ihr schnell beobachtbare Systeme aufbauen, die echten Kundennutzen bringen.
Bei DevOps gibt es nicht „den einen Weg“. Es gibt weder das eine Tool noch den einen Prozess, der für jedes Team geeignet ist. Im Kern geht es bei DevOps einfach darum, die Arbeitsweise eurer Teams innerhalb des gesamten Lebenszyklus der Softwareentwicklung und des Incident Management-Prozesses zu verbessern. DevOps ist systemunabhängig – es spielt also keine Rolle, ob ihr mit AWS, GCP oder einer lokalen IT-Infrastruktur arbeitet bzw. Backend- oder Frontend-Ingenieur seid. DevOps ist von der Anwendungsbereitstellung bis hin zur Produktionsunterstützung wichtig, da es agile Methoden mit praktischen IT-Prinzipien kombiniert.
DevOps hat Vorteile durch agile und schlanke Softwareentwicklungsgrundsätze sowie zentrale IT Service- und IT Operations-Verfahren. Indem ihr im Wesentlichen euer Bereitstellungsteam zum IT-Team und das IT-Team zu eurem Entwicklungsteam macht, werden folgende Aufgaben einfacher:
- Finden von Problemen in Produktionssystemen
- Schnellerer Aufbau von Services
Durch die verbesserte Zusammenarbeit und Transparenz kann euer DevOps-Team von Produktentwicklung bis hin zu Operations eigentlich jede Rolle ausfüllen.
Im Folgenden sehen wir uns einige der wesentlichen DevOps-Grundsätze an, die für jedes Team gelten.
DevOps-Konzepte und -Strukturen
Wenn Teams die Interaktion zwischen Menschen, Prozessen und Technologien verbessern, verbessert sich auch DevOps. Durch die Implementierung von Scrum und Agile in den Entwicklungsprozess sowie die kontinuierliche Verbesserung der Kommunikation und Workflow-Transparenz wächst und verändert sich DevOps weiter. Seit den Anfängen von DevOps als Konzept sind bereits Änderungen an der Struktur von DevOps-Praktiken erkennbar.
Die spezifischen DevOps-Merkmale variieren zwar von Unternehmen zu Unternehmen, doch die DevOps-Grundprinzipien bleiben dieselben. Im Folgenden stellen wir die wichtigsten Konzepte vor, die ihr bei eurer eigenen DevOps-Transformation beachten solltet:
Mehr Einblick
Wenn Entwickler Bereitschaftsdienst und mehr IT-Aufgaben übernehmen, erhalten sie mehr Einblick in Produktionssysteme. IT Operations-Experten bekommen im Gegenzug mehr Einblick in die Staging-Umgebung und den Softwareentwicklungsprozess.
Wenn Mitarbeiter der beiden Bereiche in das jeweils andere Fachgebiet einbezogen werden, haben in Summe mehr Personen Einblick in größere Teile des Systems. Bei Problemen ist das Team dann insgesamt besser in der Lage, das Problem zu erkennen und den Vorfall zu beheben. Und wenn Entwickler mehr darüber wissen, wie Produktionssysteme zusammenarbeiten, können sie besseren Code schreiben, was dann zu einer schnelleren Bereitstellung zuverlässiger Services führt.
Zusammenarbeit
Zusammenarbeit ist ein Schlüsselelement von DevOps. Mit folgenden Fragen könnt ihr den Grad eurer Zusammenarbeit bewerten:
- Wie kommuniziert man am besten bei der Produktentwicklung und während des gesamten Softwarebereitstellungszyklus?
- Wie kann man IT-Experten und Entwicklern helfen, in Echtzeit zusammenzuarbeiten und Probleme schneller zu identifizieren?
Während der gesamten Softwareentwicklung bis hin zur Incident Response sollte auf effektive Zusammenarbeit gesetzt werden. Ein Team, das effektiv kommuniziert, wird gleich von Anfang an proaktiv bessere Anwendungen und Infrastrukturen entwickeln. Dies macht dann im Bedarfsfall eine schnelle Incident Response noch einfacher.
Verantwortlichkeit
Wenn man mehr Verantwortung für die Entwicklung und Wartung der angebotenen Services hat, übernimmt man auch die Verantwortung für die Uptime und Zuverlässigkeit dieser Services. Bei DevOps übernehmen Entwickler auch Aufgaben im Bereitschaftsdienst für Anwendungs- bzw. Infrastrukturnotfälle.
Da sie die Verantwortung für ihr eigenen Services tragen und in der Lage sind, eventuelle Probleme zu beheben, müssen Softwareentwickler Bereitschaftsdienst übernehmen, besseren Code schreiben und zuverlässigere Services bereitstellen. Durch mehr Verantwortlichkeit beginnen Entwickler, die Produktentwicklung, Qualitätssicherung und Testing-Durchläufe ernster zu nehmen, was im Endeffekt die Qualität der Prozesse und Geschäftsentscheidungen erhöht.
Automatisierung
Bei DevOps liegt der Schwerpunkt stark auf der Automatisierung von Aufgaben und Workflows, um die Effizienz von Menschen und Prozessen zu verbessern. Zuerst definiert ihr Problembereiche und Engpässe in eurem Entwicklungslebenszyklus und anschließend sucht ihr Möglichkeiten zur Automatisierung von Prozessen, um eure Entwicklungs- und IT-Teams zu entlasten.
Bei sinnvoller Automatisierung hat das DevOps-Team mehr Zeit für die Entwicklung neuer Funktionen und Services. Automatisierung sollte im Entwicklungs- und Release Management-Prozess überall dort eingesetzt werden, wo sie Mitarbeiter entlastet. So kann sich das Team auf die Wertschöpfung durch neue Produktentwicklungen konzentrieren.
Transparenz
Mit mehr Zusammenarbeit und mehr Einblick in alle Aspekte des Softwareentwicklungszyklus werdet ihr automatisch transparentere Workflows aufbauen. Und wenn euer Team ganz leicht feststellen kann, was in der Produktion und während der Entwicklung passiert, dann kann es mehr Probleme schon vor ihrem Auftreten erkennen.
Aufgrund der Transparenz wissen IT Operations und Entwicklung, an welchem Punkt der Pipeline sich Projekte befinden, und verstehen dadurch die Anforderungen ihrer Kollegen besser. In Kombination mit einer besseren Zusammenarbeit ermöglicht die Transparenz Teams, schnell zu reagieren.
Kontinuierliche Verbesserung der Teamdynamik
Wie in jeder Branche oder jedem Beruf kommt es auch bei DevOps auf eine effiziente Teamdynamik an. Die bereits oben in diesem Blog besprochenen Grundsätze sind ein integraler Bestandteil beim Aufbau eines Teams, das schnell zuverlässige Services entwickelt. Wenn ihr den Fortschritt und die Effizienz eures Teams anhand von Metriken für die Entwicklungsgeschwindigkeit und das Incident Management überwacht, könnt ihr die Effektivität eurer Engineering- und IT-Prozesse kontinuierlich verbessern. Bei DevOps ist Teamwork gefragt: Jeder muss ein Teamplayer sein, wenn es um Bereitschaftsdienst und Code-Verantwortlichkeit geht.
Gängige DevOps-Rollen und -Verantwortlichkeiten
Nachdem wir nun viele der gängigen DevOps-Grundsätze kennengelernt haben, können wir uns ansehen, wie sich diese in den DevOps-Rollen und -Verantwortlichkeiten niederschlagen. Wir werden jetzt einige allgemeine DevOps-Aufgaben durchgehen und jeweils beleuchten, wie Engineering- und IT-Teams davon profitieren.
Planen, Testen und Entwickeln von Anwendungen und Infrastruktur
Das gesamte DevOps-Team ist für die Planung, das Testen und die Entwicklung von Anwendungen und Infrastruktur zuständig. Wenn die Verantwortung für die Entwicklungs- und Release-Pipeline geteilt wird, steigert dies die Zuverlässigkeit der Services. Teil eines DevOps-Teams zu sein, heißt nicht, dass man zu einem reinen Team aus „DevOps-Ingenieuren“ gehört, sondern, dass ein DevOps-orientiertes Unternehmen die Verantwortlichkeit für die Entwicklung, das Testen und das Veröffentlichen von Anwendungen über die gesamte Engineering- und IT-Organisation verteilt.
Pflegen der CI/CD-Pipelines
Teil eines DevOps-Teams zu sein, bedeutet, dass ihr für den Aufbau einer CI/CD-Pipeline und die Optimierung von Prozessen, Mitarbeitern und Tools verantwortlich seid. DevOps-orientierte Ingenieure finden immer wieder Möglichkeiten, die Pipeline zu verbessern – von den Mitarbeitern bis hin zu den Prozessen.
Das Team beginnt früher im Entwicklungszyklus mit Testing- und Qualitätssicherungsaufgaben, damit das Team kontinuierlich testen kann, ohne die Geschwindigkeit einzuschränken.
Implementieren von Automatisierung
Die Implementierung von Automatisierung fällt eindeutig in den Aufgabenbereich von DevOps-Teams. Jeder, vom Datenteam bis zum Frontend-Team, ist dafür verantwortlich, Aufgaben zu automatisieren und die Effizienz von Engineering und IT zu verbessern. Durch die kontinuierliche Automatisierung alltäglicher Aufgaben könnt ihr euch stärker auf die strategische Entwicklung und die Steigerung des Business Value konzentrieren.
Bereitschaft, Incident Response und Incident Management
Aufgrund der gemeinsamen Verantwortlichkeit und Code-Verantwortung müssen DevOps-Teams Aufgaben bei Bereitschaftsdienst und Incident Management übernehmen. Doch, je mehr Zeit das DevOps-Team mit der Reaktion auf Incidents in der Produktion verbringt, desto mehr lernt es über seine Systeme. Dies führt dazu, dass die Entwickler mit der Zeit dann Code schreiben, der besser in ihre Anwendungen und die Infrastruktur passt, was wiederum zu weniger Incidents führt.
Zudem haben IT-Teams dadurch mehr Einfluss auf den Entwicklungszyklus und können die Zuverlässigkeit der bereitgestellten Services proaktiv verbessern.
Monitoring
Last, but not least, sind DevOps-Teams auch für die Implementierung zuverlässiger Monitoring-Lösungen verantwortlich. Das Unternehmen muss Daten sammeln und wissen, wie es diese Daten in Handlungen verwandeln kann. Das DevOps-Team (also jeder) ist dafür verantwortlich, blinde Flecken in seinen Anwendungen und seiner Infrastruktur aufzudecken und dann Möglichkeiten für das Monitoring dieser Services zu finden.
Monitoring ist nur ein kleiner Schritt beim Aufbau von Systemen mit einem hohen Maß an Observability, doch es ist ein wichtiger Anfang für die Erstellung zuverlässiger Systeme.
Für Transparenz sorgen, Zusammenarbeit verbessern
Die DevOps-Rollen und -Verantwortlichkeiten sind sehr breit angelegt, basieren jedoch auf der Kombination der speziellen Skillsets der einzelnen Teammitglieder. Eine DevOps-Kultur führt zu gemeinsamer Verantwortung, Übernahme von Bereitschaftsdienst und Verantwortlichkeit für den zugrundeliegenden Service eines Teams. Da die Mitarbeiter mehr Einblick in die erstellten Produktionssysteme haben, schreiben Entwickler eher Code, der besser zu den Parametern des Systems passt. Außerdem kann das IT-Team die Entwickler besser anleiten und während des gesamten Entwicklungszyklus Tests durchführen, um zuverlässigere Releases zu gewährleisten.
Was ist Splunk?
Dieser Beitrag spiegelt nicht zwingend die Position, Strategie oder Meinung von Splunk wider.
