DevOps

menu icon

DevOps

DevOps beschleunigt die Lieferung von qualitativ hochwertigerer Software, indem es die Arbeit von Teams in der Softwareentwicklung und im IT-Betrieb kombiniert und automatisiert.

Was ist DevOps?

DevOps beschreibt – per definitionem –sowohl einen Softwareentwicklungsprozess als auch einen Kulturwandel im Unternehmen, der die Lieferung qualitativ hochwertigerer Software beschleunigt, indem die Arbeit von Teams in der Softwareentwicklung und im IT-Betrieb kombiniert und automatisiert wird – also von zwei Gruppen, die traditionell getrennt voneinander oder in Silos gearbeitet haben.

In der Praxis gehen die besten DevOps-Prozesse und -Kulturen jedoch über die Entwicklung und den Betrieb hinaus und beziehen den Input aller an der Anwendung beteiligten Akteure – d. h. einschließlich Plattform- und Infrastruktur-Engineering, Sicherheit, Compliance, Governance, Risikomanagement, Geschäftsbereiche, Endanwender und Kunden – in den Lebenszyklus der Softwareentwicklung ein.

DevOps stellt den aktuellen Stand der Evolution der Software-Lieferungszyklen in den letzten 20+ Jahren dar: von riesigen anwendungsweiten Code-Releases im Abstand von einigen Monaten oder sogar Jahren, zu iterativen kleineren Feature- oder Funktions-Updates, die täglich oder sogar mehrmals täglich veröffentlicht werden.

Letztlich geht es bei DevOps darum, die ständig steigenden Anforderungen der Software-Anwender an häufige, innovative neue Funktionen und ununterbrochene Leistung und Verfügbarkeit zu erfüllen.

Wie wir bei DevOps angelangt sind

Bis kurz vor 2000 wurde die meiste Software nach der Wasserfall-Methode entwickelt und aktualisiert, d. h. nach einem linearen Ansatz für groß angelegte Entwicklungsprojekte. Teams in der Softwareentwicklung verbrachten normalerweise Monate damit, große Mengen an neuem Code zu entwickeln, der den Großteil oder die gesamte Anwendung betraf. Da die Änderungen so umfangreich waren, verbrachten sie mehrere weitere Monate damit, diesen neuen Code in die Codebasis zu integrieren.

Als nächstes verbrachten die Teams für Qualitätssicherung (QA), Sicherheit und Betrieb weitere Monate damit, den Code zu testen. Das Ergebnis war eine Zeitspanne von Monaten oder sogar Jahren zwischen Software-Releases, und dazu noch oft mehrere umfangreiche Patches oder Bug-Fixes zwischen Releases. Und dieser „Big Bang"-Ansatz, d. h. der Ansatz für die „urknallartige" Lieferung von Features, war oft von komplexen und riskanten Implementierungsplänen geprägt, von einem schwer zu terminierenden Ineinandergreifen von vorgelagerten und nachgelagerten Systemen, und der „großen Hoffnung" der IT, dass die Geschäftsanforderungen in den Monaten vor dem „Go Live" in der Produktion sich hoffentlich nicht drastisch geändert hatten.

Um die Entwicklung zu beschleunigen und die Qualität zu verbessern, begannen Entwicklungsteams damit, agile Softwareentwicklungsmethoden einzusetzen, die eher iterativ als linear sind und sich auf kleinere, häufigere Aktualisierungen der Codebasis der Anwendung konzentrieren. Die wichtigsten dieser Methoden sind CI/CD, d. h. Continuous Integration (Kontinuierliche Integration) und Continuous Delivery (Kontinuierliche Lieferung). Im Rahmen von CI/CD werden kleinere Teile des neuen Codes alle ein bis zwei Wochen in die Codebasis eingebunden und dann automatisch integriert, getestet und für die Bereitstellung in der Produktionsumgebung vorbereitet. Agile Softwareentwicklung entwickelte den „Big Bang"-Ansatz zu einem Ansatz weiter, der aus einer Reihe von „kleineren Explosionen" bestand und so das vorhandene Gesamtrisiko in kleinere Stücke aufspaltete.

Je effektiver diese agilen Entwicklungspraktiken die Softwareentwicklung und -lieferung beschleunigten, desto mehr zeigten sie deutlich, dass die betrieblichen Aspekte der IT – nämlich Systembereitstellung, Konfiguration, Abnahmeprüfung, Management, Überwachung – nach wie vor in Silos organisiert waren und so zum nächsten Engpass im Lebenszyklus der Softwarelieferung wurden.

DevOps hat also seinen Ursprung in der agilen Softwareentwicklung. Es fügte neue Prozesse und Tools hinzu, die die kontinuierliche Iteration und Automatisierung von CI/CD auf den Rest des Lebenszyklus der Softwarelieferung ausweiteten. Und es schuf eine enge Zusammenarbeit zwischen der Entwicklung und dem IT-Betrieb in jedem Schritt des Prozesses.

Wie DevOps funktioniert: Der DevOps-Lebenszyklus

Diagramm mit dem Pfad des DevOps-Lebenszyklus

Abbildung 1: Der DevOps-Lebenszyklus

Der DevOps-Lebenszyklus (manchmal auch als „Continuous Delivery Pipeline"/Pipeline für kontinuierliche Lieferung bezeichnet, wenn er linear dargestellt wird) ist eine Reihe von iterativen, automatisierten Entwicklungsprozessen oder Workflows, die im Rahmen eines größeren, automatisierten und iterativen Entwicklungszyklus ausgeführt werden, der wiederum die schnelle Lieferung von qualitativ hochwertiger Software optimieren soll. Der Name und die Anzahl der Workflows können sich unterscheiden, je nachdem, wen Sie fragen, aber in der Regel geht es im Wesentlichen um die folgenden 6 Workflows:

  • Planung (oder Ideenfindung). In diesem Arbeitsablauf skizzieren die Teams neue Features und Funktionalitäten für das nächste Release, wobei sie sich auf priorisiertes Endbenutzer-Feedback und Fallstudien sowie auf Inputs von allen internen Stakeholdern stützen. Das Ziel in der Planungsphase besteht darin, den Geschäftswert des Produkts zu maximieren, indem ein Backlog, eine Liste von noch zu schaffenden Features erstellt wird, die bei der Lieferung ein gewünschtes Ergebnis erzeugen, das Wert für das Unternehmen hat.
  • Entwicklung. Dies ist der Programmierschritt, in dem Entwickler neue und erweiterte Funktionen testen, codieren und erstellen, die auf Benutzergeschichten und im Backlog erfassten Arbeitselementen basieren. Eine Kombination von Verfahren wie z. B. unter anderem Test-driven Development (TDD, d. h. testgesteuerte Entwicklung), Pair Programming (d. h. Paarprogrammierung) und Peer-Code-Reviews (d. h. Überprüfung des Codes durch einen anderen Programmierer) ist dabei häufig anzutreffen. Entwickler verwenden oft ihre lokalen Workstations, um den „inneren Loop" des Schreibens und des Testens von Code auszuführen, bevor sie den Code an die Continuous Delivery Pipeline weitergeben.
  • Integration (oder Erstellung bzw. Continuous Integration und Continuous Delivery [CI/CD]). Wie bereits erwähnt, wird in diesem Workflow der neue Code in die bestehende Codebasis integriert, dann getestet und in eine ausführbare Datei für die Bereitstellung verpackt. Zu den typischen Aktivitäten im Bereich der Automatisierung gehören das Zusammenführen von Codeänderungen in einer „Master"-Kopie, das Auschecken dieses Codes aus einem Quellcode-Repository und das Automatisieren der Kompilierung, des Komponententests und der Verpackung in einer ausführbaren Datei. Die Best Practice besteht darin, das Arbeitsprodukt der CI-Phase in einem binären Repository für die nächste Phase zu speichern.
  • Bereitstellung (in der Regel als Continuous Deployment/Kontinuierliche Bereitstellung bezeichnet). In diesem Schritt wird das Laufzeit-Arbeitsprodukt (aus der Integration) in einer Laufzeitumgebung bereitgestellt – dies ist in der Regel eine Entwicklungsumgebung, in der Laufzeittests für Qualität, Compliance und Sicherheit ausgeführt werden. Wenn Fehler oder Defekte gefunden werden, haben Entwickler eine Chance, Probleme zu identifizieren und zu beheben, bevor Endbenutzer sie sehen. In der Regel gibt es Umgebungen für die Entwicklung, den Test und die Produktion, wobei jede Umgebung zunehmend „strengere" Quality Gates/Qualitätsstandards erfordert. Ein bewährtes Verfahren für die Bereitstellung in einer Produktionsumgebung ist in der Regel die Bereitstellung zunächst für eine Untergruppe von Endbenutzern und dann schließlich für alle Benutzer, sobald die notwendige Stabilität hergestellt ist.
  • Betrieb. Wenn der Tag, an dem Funktionen, die in einer Produktionsumgebung bereitgestellt werden, als „Tag 1" bezeichnet wird,dann werden, nachdem die Funktionen in der Produktion laufen, „Tag 2"-Abläufe ausgeführt. Das Monitoring der Leistung, des Verhaltens und der Verfügbarkeit von Funktionen stellt sicher, dass die Funktionen den Endnutzern Mehrwert bieten können. Der Bereich IT-Betrieb stellt sicher, dass Funktionen reibungslos laufen und dass keine Unterbrechungen in den Services vorhanden sind – indem er sicherstellt, dass Netzwerk, Speicher, Plattform, Rechenleistung und Sicherheitsstatus alle „gesund" sind! Wenn ein Problem auftritt, stellt der IT-Betrieb sicher, dass Vorfälle erkannt, das richtige Personal alarmiert, Probleme identifiziert und Korrekturen vorgenommen werden.
  • Lernen (manchmal auch Continuous Feedback/Kontinuierliches Feedback genannt). Dies ist das Sammeln von Feedback von Endanwendern und Kunden zu Features, Funktionalität, Leistung und Geschäftswert, um dieses Feedback in die Planung von Verbesserungen und Features für die nächste Version einfließen zu lassen. Dies umfasst außerdem all das, was der IT-Betrieb selbst aus seinen Aktivitäten gelernt hat, sowie die Elemente, die sich noch im Backlog befinden und die es Entwicklern ermöglichen könnten, proaktiv Vorfälle zu vermeiden, die sich bereits ereignet haben, aber in der Zukunft noch einmal passieren könnten. An genau diesem Punkt findet der erneute Übergang zur Planungsphase statt: „Der Kreis schließt sich" und wir beginnen den „Prozess der kontinuierlichen Verbesserung".

Zwischen diesen Workflows laufen drei weitere wichtige kontinuierliche Workflows ab:

Kontinuierliches Testen: Klassische DevOps-Lebenszyklen umfassen eine diskrete „Test"-Phase, die zwischen den Schritten der Integration und der Bereitstellung stattfindet. DevOps ist jedoch nun so weit entwickelt, dass bestimmte Elemente des Testens bereits während der Planung (verhaltensgesteuerte Entwicklung), Entwicklung (Komponententests, Vertragstests), Integration (statische Codescans, CVE-Scans, Linting), Bereitstellung (Rauchtests, Penetrationstests, Konfigurationstests), Operationen (Chaos-Tests, Konformitätsprüfung) und Lernen (A/B-Tests) durchgeführt werden können. Testen ist ein sehr effektives Werkzeug zur Identifizierung von Risiken und Schwachstellen und bietet der IT die Möglichkeit, Risiken entweder zu akzeptieren, zu mindern oder zu beseitigen.

Sicherheit: Während Wasserfall-Methoden und agile Implementierungen Sicherheitsworkflows erst im Nachhinein nach Lieferung oder Implementierung „anhängen", ist es das Ziel von DevOps, Sicherheit von Anfang an zu integrieren (d. h. bereits während der Planung) – also zu einem Zeitpunkt, zu dem es am einfachsten und billigsten ist, Sicherheitsfragen zu berücksichtigen – und an diesem Thema kontinuierlich über den gesamten Rest des Entwicklungszyklus hinweg zu arbeiten. Dieser Ansatz für die Sicherheit wird als „Shift-Left" (wörtlich „nach links verschieben") bezeichnet (was einfacher zu verstehen ist, wenn Sie sich Abbildung 1 ansehen). Einige Unternehmen hatten mit diesem Ansatz weniger Erfolg als andere, was zur Entstehung von DevSecOps führte (siehe unten).

Compliance. Die Einhaltung von regulatorischen Vorschriften (Governance und Risiko) wird idealerweise ebenfalls frühzeitig und während des gesamten Entwicklungslebenszyklus berücksichtigt. Regulierte Branchen sind oft verpflichtet, ein bestimmtes Maß an Beobachtbarkeit, Nachvollziehbarkeit und Zugriff darauf zu gewährleisten, wie Funktionen in ihrer Laufzeitumgebung innerhalb der betrieblichen Abläufe bereitgestellt und verwaltet werden. Dies erfordert Planung, Entwicklung, Testen und Durchsetzung von Richtlinien in der Pipeline für die kontinuierliche Lieferung und in der Laufzeitumgebung. Die Überprüfbarkeit von Compliance-Maßnahmen ist äußerst wichtig, um die Einhaltung von Compliance-Vorschriften gegenüber externen Prüfern beweisen zu können.

DevOps-Kultur

Es ist allgemein anerkannt, dass DevOps-Methoden nicht ohne ein Bekenntnis zur DevOps-Kultur funktionieren können, die sich als ein völlig anderer organisatorischer und technischer Ansatz zur Softwareentwicklung zusammenfassen lässt.

Auf organisatorischer Ebene erfordert DevOps kontinuierliche Kommunikation, Zusammenarbeit und gemeinsame Verantwortung aller an der Lieferung von Software Beteiligten (was natürlich die Teams in Softwareentwicklung und IT-Betrieb sind, aber auch Teams in den Bereichen Sicherheit, Compliance, Governance, Risiko und in den Geschäftsbereichen), um schnell und kontinuierlich innovativ zu sein und von Anfang an Qualität zu einem integralen Bestandteil der Software zu machen.

In den meisten Fällen ist der beste Weg, dies zu erreichen, diese Silos aufzubrechen und sie in funktionsübergreifende, autonome DevOps-Teams umzuorganisieren, die von Anfang bis Ende – d. h. von der Planungs- bis zur Feedbackphase – an Codeprojekten arbeiten können, ohne an andere Teams übergeben oder auf Genehmigungen von anderen Teams warten zu müssen. Im Kontext der agilen Entwicklung sind gemeinsame Verantwortlichkeit und Zusammenarbeit die Grundlage für einen gemeinsamen Produktfokus, der zu einem Ergebnis führt, das Wert hat.

Auf der technischen Ebene erfordert DevOps ein Bekenntnis zur Automatisierung, die Projekte innerhalb und zwischen Workflows vorantreibt, sowie zu Feedback und Ergebnismessungen, die es den Teams ermöglichen, Zyklen kontinuierlich zu beschleunigen und Softwarequalität und -leistung zu verbessern.

DevOps-Tools: Erstellen einer DevOps-Toolchain

Die Anforderungen von DevOps und der DevOps-Kultur erfordern den Einsatz von Werkzeugen, die asynchrone Zusammenarbeit unterstützen, DevOps-Workflows nahtlos integrieren und den gesamten DevOps-Lebenszyklus so weit wie möglich automatisieren. Zu den Kategorien von DevOps-Tools gehören:

  • Projektmanagement-Tools –Tools, die es Teams ermöglichen, ein Backlog mit Benutzergeschichten (d. h. Anforderungen) zu erstellen, die Codierungsprojekte bilden, diese in kleinere Aufgaben aufzuteilen und die Aufgaben bis zur Fertigstellung zu verfolgen. Viele unterstützen agile Projektmanagement-Praktiken wie Scrum, Lean und Kanban, die Entwickler in DevOps einbringen. Beliebte Open-Source-Optionen sind GitHub Issues und Jira.
  • Kollaborative Quellcode-Repositories – versionsgesteuerte Codierungsumgebungen, die es mehreren Entwicklern ermöglichen, auf derselben Codebasis zu arbeiten. Code-Repositories sollten mit CI/CD-, Test- und Sicherheits-Tools integriert werden, so dass, wenn der Code in das Repository festgeschrieben wird, automatisch zum nächsten Schritt übergegangen werden kann. Open-Source-Code-Repositories umfassen GitHub und GitLab.
  • CI/CD-Pipelines – Tools zur Automatisierung des Check-outs von Code sowie der Erstellung, des Testens und der Bereitstellung. Jenkins ist das beliebteste Open-Source-Tool in dieser Kategorie; viele Alternativen, die in der Vergangenheit Open-Source waren, wie z. B. CircleCI, sind heute nur noch in kommerziellen Versionen verfügbar. Im Bereich der Continuous Deployment (CD)-Tools bewegt sich Spinnaker zwischen den Code-Schichten Anwendung und Infrastruktur. ArgoCD ist eine weitere beliebte Open-Source-Wahl für Kubernetes-native CI/CD.
  • Testautomatisierungs-Frameworks – dazu gehören Software-Tools, Bibliotheken und Best Practices für die Automatisierung von Komponenten-, Vertrags-, Funktions-, Leistungs-, Benutzerfreundlichkeits-, Penetrations- und Sicherheitstests. Die besten dieser Tools unterstützen mehrere Sprachen; einige nutzen künstliche Intelligenz (KI), um Tests in Reaktion auf Codeänderungen automatisch neu zu konfigurieren. Die verfügbare Palette an Test-Tools und -Frameworks ist groß! Zu den beliebten Open-Source-Testautomatisierungs-Frameworks gehören Selenium, Appium, Katalon, Robot Framework und Serenity (früher bekannt unter dem Namen Thucydides bekannt).
  • Konfigurationsmanagement (Infrastruktur als Code)-Tools – diese Tools ermöglichen DevOps-Ingenieuren die Konfiguration und Bereitstellung vollständig versionierter und vollständig dokumentierter Infrastruktur durch Ausführen eines Scripts. Zu den Open-Source-Optionen gehören Ansible (Red Hat), Chef, Puppet und Terraform. Kubernetes übernimmt die gleiche Funktion für containerisierte Anwendungen (siehe „DevOps und Cloud-native Entwicklung" weiter unten).
  • Monitoring-Tools – diese Tools helfen DevOps-Teams bei der Identifizierung und Behebung von Systemproblemen; sie sammeln und analysieren außerdem Daten in Echtzeit, um aufzuzeigen, wie sich Codeänderungen auf die Anwendungsleistung auswirken. Zu den Open-Source-Monitoring-Tools gehören Datadog, Nagios, Prometheus und Splunk.
  • Tools für kontinuierliches Feedback – Tools, die Feedback von Benutzern sammeln, entweder durch Heatmapping (Aufzeichnen von Benutzeraktionen auf dem Bildschirm), Umfragen oder Self-Service-Ticketing.

DevOps und Cloud-native Entwicklung

Cloud-Nativ ist ein Ansatz für die Erstellung von Anwendungen, die grundlegende Cloud-Computing-Technologien nutzen. Das Ziel von Cloud-Nativ ist es, eine konsistente und optimale Anwendungsentwicklung, -bereitstellung, -verwaltung und -leistung in öffentlichen, privaten und Multi-Cloud-Umgebungen zu ermöglichen.

Heute werden Cloud-native Anwendungen in der Regel:

  • Unter Verwendung von Microservices erstellt – dies sind lose miteinander verknüpfte, unabhängig voneinander einsetzbare Komponenten, die über einen eigenen, in sich geschlossenen Stack verfügen und über REST-APIs, Event-Streaming oder Message Broker miteinander kommunizieren.
  • In Containern bereitgestellt – d. h. in ausführbaren Codeeinheiten, die alle Code-, Laufzeiten- und Betriebssystemabhängigkeiten enthalten, die für die Ausführung der Anwendung erforderlich sind. (Für die meisten Unternehmen ist „Container" gleichbedeutend mit Docker-Containern, aber es gibt auch andere Containertypen.)
  • Mit Kubernetes (bei entsprechender Skalierung) betrieben, einer Open-Source-Container-Orchestrierungsplattform für die Planung und Automatisierung der Bereitstellung, Verwaltung und Skalierung von containerisierten Anwendungen.

In vielerlei Hinsicht sind Cloud-native Entwicklung und DevOps wie füreinander geschaffen.

Zum Beispiel eignet sich die Entwicklung und Aktualisierung von Microservices – das heißt, die iterative Lieferung von kleinen Codeeinheiten zu einer kleinen Codebasis – perfekt für die schnellen Release- und Management-Zyklen von DevOps. Und es wäre schwierig, die Komplexität einer Microservices-Architektur ohne DevOps-Bereitstellung und -Betrieb zu bewältigen. Eine aktuelle IBM-Umfrage von Entwicklern und IT-Managern stellte fest, dass 78 % der derzeitigen Nutzer von Microservices erwarten, die Zeit, das Geld und den Aufwand, die sie in diese Architektur investiert haben, in der Zukunft zu erhöhen, und 56 % der Nicht-Nutzer sagten, sie würden Microservices wahrscheinlich innerhalb der nächsten zwei Jahre einführen. Verwenden Sie das folgende interaktive Tool, um mehr zu den von den Umfrageteilnehmern genannten spezifischen Vorteilen und Herausforderungen von Microservices zu erfahren:

(Quelle: „Microservices im Unternehmen 2021: Echte Vorteile, die die Herausforderungen wert sind" [Microservices in the enterprise 2021: Real benefits, worth the challenges].)

Durch die Paketierung und dauerhafte Festlegung aller Betriebssystemabhängigkeiten ermöglichen Container schnelle CI/CD- und Bereitstellungszyklen, da die gesamte Integration, das Testen und die Bereitstellung in der gleichen Umgebung stattfinden. Und die Kubernetes-Orchestrierung führt die gleichen kontinuierlichen Konfigurationsaufgaben für containerisierte Anwendungen aus, wie sie Ansible, Puppet und Chef für nicht containerisierte Anwendungen ausführen.

Die meisten führenden Cloud-Computing-Anbieter – einschließlich AWS, Google, Microsoft Azure und IBM Cloud – bieten eine Art von verwalteter DevOps-Pipeline-Lösung.

Was ist DevSecOps?

DevSecOps ist ein DevOps, das Sicherheit während des gesamten DevOps-Lebenszyklus kontinuierlich integriert und automatisiert – von Anfang bis Ende, von der Planungs- bis zur Feedbackphase und wieder zurück zur Planungsphase.

Man kann es auch so ausdrücken: DevSecOps ist das, was DevOps von Anfang hätte sein sollen. Zwei der ersten großen (und eine Zeit lang unüberwindbaren) Herausforderungen bei der Einführung von DevOps waren jedoch die Integration von Sicherheitsexpertise in funktionsübergreifende Teams (ein kulturelles Problem) und die Implementierung von Sicherheitsautomatisierung in den DevOps-Lebenszyklus (ein technisches Problem). Sicherheit wurde als das „Team der Neinsager" und als teurer Engpass in vielen DevOps-Verfahren wahrgenommen.

DevSecOps entstand daher als ein gezielter Versuch, Sicherheit zu integrieren und zu automatisieren, so wie es ursprünglich beabsichtigt war. In DevSecOps ist die Sicherheit ein „Bürger erster Klasse" und Stakeholder auf gleicher Stufe wie Entwicklung und Betrieb und bringt das Element Sicherheit mit einem Produktfokus in den Entwicklungsprozess ein.

Sehen Sie sich das Video „Was ist DevSecOps?" an, um mehr über DevSecOps-Prinzipien, Vorteile und Anwendungsfälle zu erfahren:

DevOps and Site Reliability Engineering (SRE)

Site Reliability Engineering (SRE) nutzt Software-Engineering-Techniken zur Automatisierung von Aufgaben im IT-Betrieb – z. B. Produktionssystemmanagement, Änderungsmanagement, Reaktion bei Sicherheitsvorfällen oder sogar bei Notfällen – die andernfalls manuell von Systemadministratoren ausgeführt werden müssten. SRE zielt darauf ab, den klassischen Systemadministrator zu einem Ingenieur zu machen.

Das ultimative Ziel von SRE ist ähnlich dem Ziel von DevOps, aber spezifischer: SRE zielt darauf ab, den Wunsch eines Unternehmens nach schneller Anwendungsentwicklung mit der Notwendigkeit in Einklang zu bringen, das in Service Level Agreements (SLAs) mit Kunden und Endnutzern festgelegte Leistungs- und Verfügbarkeitsniveau zu erfüllen.

Site Reliability Engineers erreichen diese Balance, indem sie ein akzeptables Niveau für das durch Anwendungen verursachte Betriebsrisiko bestimmen – auch „Fehler-Budget" genannt – und indem sie Abläufe automatisieren, um dieses Leistungsniveau zu erreichen.

In einem funktionsübergreifenden DevOps-Team kann SRE als Brücke zwischen Entwicklung und Betrieb dienen, indem es die Metriken und die Automatisierung zur Verfügung stellt, die das Team benötigt, um Code-Änderungen und neue Features so schnell wie möglich durch die DevOps-Pipeline zu pushen, ohne aber die Bedingungen der SLAs des Unternehmens zu „verletzen".

Mehr zum Thema Site Reliability Engineering erfahren

DevOps und IBM Cloud

DevOps erfordert die Zusammenarbeit zwischen Stakeholdern in Geschäft, Entwicklung und IT-Betrieb, um zuverlässige Software zu liefern und zu betreiben. Unternehmen, die DevOps-Tools und -Verfahren verwenden, während sie ihre Kultur transformieren, schaffen eine leistungsstarke Grundlage für die digitale Transformation und für die Modernisierung ihrer Anwendungen, während die Notwendigkeit für Automatisierung im gesamten Geschäfts- und IT-Betrieb immer weiter zunimmt.

Ein Schritt in Richtung auf mehr Automatisierung sollte mit kleinen, messbar erfolgreichen Projekten beginnen, die Sie dann skalieren und für andere Prozesse und in anderen Teilen Ihrer Organisation optimieren können.

Bei der Arbeit mit IBM haben Sie Zugriff auf KI-basierte Automatisierungsfunktionen, einschließlich vorgefertigter Workflows, um jeden IT-Service-Prozess intelligenter zu machen und Teams zu entlasten, damit sie sich auf die wichtigsten IT-Probleme konzentrieren und die Innovation beschleunigen können.

Machen Sie den nächsten Schritt:

Beginnen Sie noch heute mit einem IBM Cloud-Konto.

IBM Cloud Pak for Watson AIOps nutzt maschinelles Lernen und natürliches Sprachverständnis, um strukturierte und unstrukturierte Daten in Ihrer gesamten Toolchain für den IT-Betrieb in Echtzeit miteinander zu korrelieren, um verborgene Einblicke zu gewinnen und Ursachen schneller zu identifizieren. Watson AIOps macht mehrere Dashboards überflüssig und speist Erkenntnisse und Empfehlungen direkt in die Workflows Ihres Teams ein, um die Lösung von Vorfällen zu beschleunigen.

Informationen zum Autor

Andrea C. Crawford ist ein Distinguished Engineer bei IBM mit Know-How sowohl im klassischen als auch modernen DevOps. Ihre Leidenschaft ist es, Kunden bei der Transformation der Anwendungsbereitstellung durch Modernisierung in den Bereichen Mitarbeiter, Prozesse und Tools zu helfen. In ihrer Freizeit genießt Andrea Aktivitäten wie Gartenarbeit und Motorradfahren.

https://twitter.com/acmthinks (Link führt zu einer Webseite außerhalb von IBM.)

https://medium.com/@acmThinks (Link führt zu einer Webseite außerhalb von IBM.)