Vom Code zur Cloud: Aufbau von Ausfallsicherheit entlang der gesamten DevOps-Pipeline

DevOps verwaltet Code, Pipelines, Automatisierung und Metadaten. Sind diese Ressourcen nicht verfügbar, kommen die Bereitstellungspipelineszum Stillstand, was sich auf den Geschäftsbetrieb auswirkt. 

Versehentliche Löschungen, Handlungen von Insidern, Fehlkonfigurationen, API-Einschränkungen, Ransomware und Cloud-Ausfälle betreffen selbst etablierte Unternehmen. 

Häufig fehlen ihnen Funktionen zur langfristigen Aufbewahrung, zum Schutz von Metadaten, zur plattformübergreifenden Wiederherstellung sowie Sicherheitskontrollen auf Unternehmensebene. 

Indem wir dazu beitragen, einen einheitlichen, cloud-nativen Schutz mit granularer Recovery, cloudübergreifenden Wiederherstellungen, RBAC, Nachvollziehbarkeit und skalierbarem Speicher bereitzustellen. 

Ausfälle verzögern Produktveröffentlichungen, beeinträchtigen die Produktivität, erhöhen das Compliance-Risiko und schaden dem Ruf – daher ist die Ausfallsicherheit von DevOps unerlässlich. 

Sehen Sie sichhierdas Video mit dem zeitgestempelten Transkript an

…

Hallo zusammen, willkommen zu unserer Sitzung „Vom Code zur Cloud“ – Aufbau von Ausfallsicherheit entlang der
„DevOps-Pipeline“.

Ich bin Aashray Agur, Senior Product Manager bei Commvault.

Ich bin nun bereits im dritten Jahr bei Commvault.

Ich arbeite von Bangalore in Indien aus.

Was meine Rolle betrifft, so arbeite ich im SaaS-Apps-Team und bin direkt für Salesforce- und
Verantwortlich für DevOps-Lösungen.

Einfach ausgedrückt: Ich bin dafür zuständig, die Bedürfnisse der Kunden zu verstehen und
sinnvolle Softwarelösungen in diesem Bereich zu entwickeln.

Unser heutiger Referent und Gast ist Anilkumar von Oikocredit.

Bevor ich ihm das Wort übergebe, möchte ich kurz etwas über Oikocredit sagen.

Oikocredit ist einer der weltweit größten Social-Impact-Investoren und Genossenschaften.

Das Unternehmen fördert eine nachhaltige Entwicklung durch Investitionen in finanzielle Inklusion,
Landwirtschaft und erneuerbare Energien.

Der Hauptsitz befindet sich in den Niederlanden.

Und Anil ist Cloud-Ingenieur bei

Oikocredit.

Hallo, Anil.

Es wäre toll, wenn du ein wenig über deine Rolle erzählen könntest und wo du tätig bist. Ja,
Natürlich.

Ja, zunächst einmal: Ähm, ich bin Anil.

Ich arbeite als Cloud-Ingenieur bei Oikocredit und bin daher in den Niederlanden tätig.

Mein Schwerpunkt liegt also auf der Implementierung, der Unterstützung bei der Konzeption und der Wartung der cloudbasierten
Infrastruktur.

Am meisten Spaß macht mir der Automatisierungsprozess, damit die Abläufe schneller vonstattengehen.

Kurz gesagt: Ich sorge dafür, dass unsere Cloud-Umgebung reibungslos, sicher und effizient läuft.

Hier ist die Tagesordnung für die Sitzung.

Wir beginnen mit den zunehmenden Risiken in DevOps-Umgebungen und gehen dann kurz darauf ein
darüber, warum Ausfallsicherheit wichtig ist und wo die Grenzen einiger bestehender Lösungen liegen.

Anschließend gehen wir zur Demonstration über.

In den letzten Jahren haben wir beobachtet, wie einige der renommiertesten Unternehmen der
Technologiebranche

mit unerwarteten Problemen in ihren DevOps-Umgebungen konfrontiert wurden.

So verlor beispielsweise eine führende Kollaborationsplattform über 100 GitHub-Repositorys.

Bei einem globalen Cloud-Anbieter führte ein Konfigurationsfehler zu einem regionenweiten
DevOps-Ausfall.

Ebenso wurden bei einem führenden Automobilhersteller wichtige Pipelines gelöscht.

Dies waren keine Einzelfälle oder Sicherheitslücken.

Sie übertreffen sogar gut ausgestattete, hochentwickelte Unternehmen.

Der entscheidende Punkt ist: Diese Liste ist keineswegs vollständig.

Wenn man sich diese Situationen ansieht, hätte das jeder Organisation passieren können.

Wir müssen uns also bewusst machen, dass die Risiken in unseren DevOps-Tools zunehmen.

Fragen wir doch mal jemanden, der sich in diesem Bereich auskennt: Anil, du verwaltest schon seit geraumer Zeit DevOps-Umgebungen
.

Wenn du solche Vorfälle branchenweit beobachtest, wie interpretierst du sie?

Und stellst du fest, dass sich Unternehmen zunehmend bewusst werden, wie wichtig der Schutz ihrer DevOps-Umgebungen
ist?

Ja, das ist eine sehr gute Frage.

Vor einigen Jahren wurde DevOps noch hauptsächlich als Arbeitsablauf für Entwickler betrachtet.

Heute hat es sich jedoch zu etwas viel Größerem entwickelt.

Es gilt als Teil der geschäftskritischen Infrastruktur.

Alle konzentrieren sich also vor allem darauf, dass die Produktionssysteme laufen, aber die Systeme, die
Die Erstellung und Bereitstellung dieser Anwendungen – also die DevOps-Umgebung – sind ebenfalls von entscheidender Bedeutung.

Daher wächst weltweit das Bewusstsein,

diese Ebene zu schützen – nicht nur vor externen Bedrohungen, sondern auch vor versehentlichen Änderungen,
Handlungen von Insidern oder sogar Plattformausfälle.

Es ist großartig zu sehen, dass Resilienz von Anfang an in DevOps integriert wird,
anstatt erst später hinzugefügt zu werden.

Das ist ein ausgezeichneter Punkt.

Lassen Sie uns etwas näher darauf eingehen,

Warum Resilienz eigentlich so wichtig ist.

Bevor wir über Resilienz sprechen, lassen Sie uns einen Schritt zurücktreten und klären, was DevOps ist.
was das eigentlich bedeutet.

Wie du bereits gesagt hast: Früher, als es in der Softwareentwicklung noch nur zwei Teams gab
gab – wobei das eine den Code schrieb und die Hauptaufgabe des zweiten Teams, des Betriebsteams, darin bestand,

dafür zuständig war, den Betrieb dieser Systeme sicherzustellen.

Inzwischen hat DevOps

die Art und Weise, wie die Softwareentwicklung abläuft, grundlegend verändert.

Es gibt nicht mehr zwei Mannschaften.

Heute läuft alles in einem kontinuierlichen Kreislauf ab.

Man beginnt zum Beispiel zunächst mit einem Plan.

In der Planungsphase überlegt man sich, welche Features implementiert werden sollen und welche neuen Lösungen entwickelt werden müssen
und so weiter.

Dafür kann man zum Beispiel eine Lösung wie Jira nutzen.

Sobald die Planung abgeschlossen ist, schreibt man den Code.

Diesen Code speichert man in einem Repository und hinterlegt ihn an einem Ort wie

GitHub oder GitLab hinterlegt.

Sobald der Code geschrieben ist, packst du ihn ein und stellst einen Build als Artefakt bereit.

Anschließend prüfen Sie, ob alles in Ordnung ist, stellen Ihre Lösung bereit und überwachen sie danach.

Sobald du mit der Überwachung beginnst, ergeben sich neue Anforderungen.

Dann fangen Sie wieder mit der Planung an.

Sie sehen, das ist wie eine Endlosschleife.

Sprechen Sie mit jemandem, der bereits im Bereich der Softwareentwicklung tätig war.

Jeder würde zustimmen, dass sich das endlos so fortsetzen würde.

Außerdem, Anil, warum glaubst du, dass DevOps für die Arbeitsweise
warum ist dies für moderne Unternehmen heute so wichtig geworden, insbesondere wenn es um Agilität und Innovation geht?

Ja, ich glaube, es geht weniger um ein einzelnes Unternehmen als vielmehr darum, wie sich die Softwarebereitstellung insgesamt verändert hat
.

Heutzutage dreht sich bei allen alles um Geschwindigkeit und Zusammenarbeit.

DevOps bringt Entwicklung und sogar

Sicherheit, damit Ideen schnell und zuverlässig vom Konzept in die Produktion gelangen können.

Es geht also nicht mehr nur um Effizienz.

Äh, die DevOps-Umgebung enthält mittlerweile die wichtigsten Elemente wie Quellcode, Pipeline, äh
, Geschäftslogik – im Grunde ebenfalls das geistige Eigentum des Unternehmens und die zukünftige

Die Roadmap des Unternehmens.

DevOps hat zudem an strategischer Bedeutung gewonnen.

Es geht nun darum, dass Unternehmen innovativ bleiben, widerstandsfähig bleiben und auch ihren Wettbewerbsvorteil bewahren.

Genau.

Die Fähigkeit, schnell zu handeln, Prozesse zu automatisieren und teamübergreifend zusammenzuarbeiten, ist zweifellos zu einem Wettbewerbsvorteil geworden.
geworden.

Aber ich denke auch, dass aufgrund dieser Vernetzung – dieser enormen Vernetzung – ein
Problem an einer Stelle

Kettenreaktionen auslösen.

Wenn man zum Beispiel seinen Code verliert, hat das Auswirkungen auf alles, was darauf aufbaut.

Sie wissen ja, dass es diese Risiken gibt.

Schauen wir uns nun an, welche Risiken heute bestehen.

Wir haben bereits auf unserer ersten Folie einige Beispiele gesehen, was manche dieser Unternehmen
Das habt ihr doch auch erlebt, oder?

Ich versuche nur, diese zu benennen.

Bei einem Ransomware-Angriff könnten Ihre Repos also wahrscheinlich verschlüsselt werden.

Bei böswilligen Insidern könnte ein Angreifer Ihre Konfigurationen löschen.

Im Falle eines menschlichen Fehlers kann es beispielsweise so aussehen, dass Sie und unsere Softwareentwickler eine
Eine Reihe von Tools von Drittanbietern integrieren.

Wenn bei der Integration etwas schiefgeht, wird Ihr gesamtes System beschädigt.

Die Risiken sind also vorhanden, und wir haben sie im Griff.

Außerdem, Anil, was passiert Ihrer Meinung nach, wenn diese DevOps-Pipelines auch
nur kurzzeitig unterbrochen werden?

Ähm, das ist eine interessante Frage.

Unsere DevOps-Pipeline ist im Grunde das System, das sicherstellt, dass Features und Updates für
unsere internen Anwendungen reibungslos und sicher gemäß unseren

Richtlinien bereitgestellt werden.

Es geht also nicht nur darum, Code zu veröffentlichen.

Sie sorgt dafür, dass alles reibungslos abläuft – das Testen, die Integration und die Veröffentlichung von Änderungen
ohne Verzögerungen.

Wenn der Prozess also schon durch etwas Geringes gestört wird, würde das mehrere unserer
Teams gleichzeitig ausbremsen.

Ähm, und die Auswirkungen sind nicht nur technischer Natur.

Unsere Teammitglieder müssen sich darauf verlassen können, dass bisher alles wie erwartet funktioniert.

Ähm, es geht vor allem darum, das Problem zu beheben und die Dinge wieder zum Laufen zu bringen.

Also das Projekt.

Verliert nicht den Schwung.

Verstanden.

Verstanden.

Ich habe versucht, die unmittelbaren Risiken zu erfassen.

Zum Beispiel: Wie du gesagt hast, kommt es bei Verlusten zu Verzögerungen bei der Bereitstellung.

Wenn man einen Beispieltest verwendet, leidet die Produktqualität darunter.

Und heutzutage enthält der Code dein geistiges Eigentum.

Heutzutage ist Code so etwas wie das Herzstück Ihrer Daten.

Wenn man davon Gebrauch macht, geht man Risiken im Zusammenhang mit geistigem Eigentum ein.

Ähm

Abgesehen von der technischen Seite: Welche geschäftlichen Auswirkungen hätte es für Sie, wenn beispielsweise DevOps-Daten
im Zusammenhang mit unseren Unternehmensdaten nicht mehr verfügbar wären?

Ja, in diesem Fall, äh, wenn DevOps-Daten auch nur für Stunden oder Tage nicht mehr verfügbar wären, wäre die
die größte, äh, Auswirkung des Fortschritts.

Wenn also das System, das die Softwarebereitstellung unterstützt, ausfällt, verlangsamt dies Updates und
Verbesserungen, auf die sich das Team verlässt.

Deshalb sind Ausfallsicherheit und Recovery keine Option.

Sie sind von Anfang an in den Prozess eingebunden.

Es geht vielmehr darum, sicherzustellen, dass Kontinuität Teil des Designs ist.

Selbst wenn also etwas schiefgeht, können wir uns schnell davon erholen und den Betrieb weiter vorantreiben.

Ich meine, ich hätte es nicht besser ausdrücken können, um das, was du gesagt hast, noch zu ergänzen.

Äh, es geht nicht nur um die…

Es geht nicht nur um die Datenverlustrate, sondern auch um Produktivitätsverluste.

Möglicherweise kämen auch Reputationsverluste hinzu.

Wenn man in regulierten Branchen tätig ist, hätte man es mit zahlreichen Compliance-Lücken zu tun.

Deshalb muss Resilienz von Anfang an in DevOps integriert sein, und ich stimme der Aussage zu:
Man kann davon einfach nicht genug bekommen, das ist alles.

Okay, wir haben festgestellt, dass wir in DevOps Resilienz brauchen.

Lassen Sie uns nun ein wenig darüber sprechen, welche Lösungen es heute auf dem Markt gibt und welche Einschränkungen solche Tools mit sich bringen
bringen.

Was die auf dem Markt verfügbaren Lösungen angeht: Was ich als Produktmanager
Was mir aufgefallen ist, ist, dass manche auf native Tools zurückgreifen, den sogenannten Papierkorb.

Manche versuchen es mit Skripten, mit benutzerdefinierten Skripten, um Backups zu erstellen, und dann gibt es
Es gibt noch Einzellösungen.

Aber

Diese weisen einige gravierende Einschränkungen auf.

Bevor ich als Produktmanager zu Wort komme, möchte ich Sie als Kunden fragen: Warum glauben Sie, dass
Warum setzen manche Teams immer noch auf diese systemeigenen Funktionen oder Skripte?

Warum gibt es diese Lösungen bei uns nicht?

Das ist eine sehr gute Frage.

Ja, ich kann aus eigener Erfahrung sprechen.

Wir haben also zunächst die in die Plattform integrierten Funktionen und weitere auf
auf dem Markt verfügbare Tools genutzt.

Und diese Optionen decken nun ja nicht gerade die umfangreichen Möglichkeiten ab, die wir suchen.

Sie decken zwar die Grundlagen ab, sind aber sehr wartungsintensiv.

Aber wenn man genauer hinschaut, haben sie oft, ähm, kürzere Aufbewahrungsfristen und erfassen
Nicht alles, was wichtig ist, wie Pipelines, Boards und Metadaten.

Verstanden.

Das war tatsächlich auch meine Erfahrung, als ich mich mit einer Reihe von Leuten unterhalten habe.

Ähm, Papierkörbe decken nicht unbedingt alles ab.

Selbst Skripte decken so etwas wie Metadaten nicht vollständig ab.

Eines der größten Warnsignale, die man beobachten kann – nehmen wir einmal an, man verwendet Skripte –, wäre
die Sicherheit.

Auch Ihre Backups verbleiben in derselben Umgebung.

Und das ist ein ernstzunehmendes Warnsignal.

Ähm, wenn die Produktion ausfällt, fällt auch Ihr Backup aus.

Man kann also kein Backup erstellen

In derselben Umgebung.

Und dann gibt es noch das Problem der Nachvollziehbarkeit.

Wenn man Skripte verwendet, sieht man nicht, was gesichert ist und was gerade gesichert wird.

Und schließlich, äh, die Unternehmensgröße.

Zwar gibt es Skripte und Einzellösungen, die die drei oben genannten Aspekte abdecken,
Aber sie haben Schwierigkeiten, wenn es um Skalierbarkeit geht.

Ähm, wahrscheinlich kommen sie mit Hunderten von Repos zurecht, aber wenn man zu Tausenden von Repos
oder Terabyte an Daten übergeht,

geraten ins Straucheln und scheitern an den API-Beschränkungen.

Und das ist der Grund, warum sowohl Skripte als auch – wie man so sagt – Punktlösungen die Anforderungen auf Unternehmensebene nicht
bewältigen können.

Und genau diese Lücke ist der Grund, warum es Commvault überhaupt gibt: um diese Lücken zu schließen.

Bevor ich nun meine eigene Lösung vorstelle und erkläre, warum sie gut ist, möchte ich Anil als

unserem Kunden: Was war für dich der wichtigste Grund, dich überhaupt
sich für die Commvault-Lösung zu entscheiden?

Ja, ich würde sagen, der ausschlaggebende Grund war Einfachheit und Konsistenz.

Früher mussten wir uns mit verschiedenen Tools und Richtlinien für jede Umgebung herumschlagen, was
was die Datensicherung komplexer und schwieriger zu verwalten machte.

Mit Commvault-Backup für DevOps

Nun verfügen wir über einen einheitlichen Ansatz und eine zentrale Stelle, an der wir Daten aus allen DevOps-Bereichen einsehen, sichern und wiederherstellen können.

Und ja, diese Konsistenz hat auch unsere Sicherheit gestärkt.

Ähm, ja, Zugriffskontrollen und Aufbewahrungsrichtlinien werden überall auf die gleiche Weise angewendet, was
reduziert zudem Risiken und hilft uns, die Compliance-Vorgaben einzuhalten, ohne zusätzlichen Aufwand zu verursachen.

Großartig, da stimme ich zu.

Tatsächlich ist eines der ersten Dinge, die ich von unseren Kunden höre, die zentrale Übersicht an einem einzigen
Ein Ort, an dem man alle seine Workloads schützen kann.

Abgesehen von den Punkten, die Sie hervorgehoben haben, möchte ich kurz auf zwei
auf einige sehr wichtige Punkte eingehen, da sie mit meiner vorherigen Folie zusammenhängen.

Wir haben über die Skalierbarkeit gesprochen und darüber, dass viele Lösungen auf dem Markt große Setups nicht bewältigen können.

Das liegt an den API-Ratenbeschränkungen.

Jede dieser Plattformen – Azure DevOps, GitHub, GitHub – schränkt ein, wie
wie oft Backups durchgeführt werden können, und damit meine ich, wie oft oder wie viele API-Aufrufe man nutzen darf.

Sobald Sie diese Grenzwerte erreichen, werden Ihre Aufträge langsamer ausgeführt oder schlagen fehl.

Und das umgehen wir durch eine automatische Token-Rotation.

So laufen Backups parallel, ohne jemals die Ratenbeschränkungen zu erreichen.

Wir können mehrere Token verwenden und diese nahtlos abwechseln.

Außerdem verteilen wir unsere Workloads intelligent, sodass auch groß angelegte Umgebungen ohne Eingriffe reibungslos weiterlaufen
.

Und der nächste Punkt, auf den ich eingehen möchte, ist die plattformübergreifende Wiederherstellung.

Wie bereits erwähnt, kann es zu Dienstausfällen kommen.

Auch große Anbieter können ausfallen.

Wenn das passiert, kannst du als Abhilfe deine Berichte von Azure
DevOps von GitHub zu GitLab und in jeder beliebigen Kombination auf diese Weise verschieben –

sind Sie wirklich ausfallsicher, und Ihre Arbeit kommt nicht zum Stillstand.

Abgesehen davon verfügen wir über all diese Standardfunktionen, wie zum Beispiel detaillierte
Audit-Protokolle, regelbasierte Zugriffskontrolle und so weiter.

An dieser Stelle möchte ich die Gelegenheit nutzen, um anzukündigen, dass wir in
Wir werden in Kürze die Unterstützung für Jira einführen.

Ab Dezember starten wir unser Early-Access-Programm.

Mit Jira sind wir in die nächste Phase unserer Entwicklung im Bereich DevOps eingetreten, und wir freuen uns riesig
auf unseren Jira-Support.

Kommen wir nun zum nächsten Teil unserer Präsentation, der Produktdemo.

Das ist unsere Commvault Cloud Console.

Dies ist die zentrale Benutzeroberfläche, über die Sie praktisch alle Ihre
Workloads schützen können.

Dies ist die Startseite unseres DevOps-Tools.

Ich werde meine Demo in zwei Abschnitte unterteilen.

Im ersten Abschnitt werde ich auf die Übersichtsseite eingehen und erläutern, wie Sie Ihre App einbinden können.

Im zweiten Abschnitt werde ich mich auf die Wiederherstellung konzentrieren.

Die Übersichtsseite bietet Ihnen eine

Einen Überblick darüber, welche Anwendungen Sie nutzen und wie groß diese sind.

Da wir Jira beispielsweise noch nicht konfiguriert haben, wird Jira hier nicht angezeigt.

Aber unabhängig davon, was konfiguriert wurde – die Größe der Backups und die Anzahl der geschützten Repos –

So erhalten Sie einen Überblick darüber, wie viele Backups bereits durchgeführt wurden und für wie viele Instanzen noch keine Backups vorliegen
erstellt wurden.

Sie erhalten also eine Zustandsüberprüfung.

Kommen wir nun kurz dazu, wie man eine App integriert.

Das sind alle Apps, die wir konfiguriert haben.

Äh, die Zusammenfassung davon finden Sie auf dieser, äh, Übersichtsseite.

Lassen Sie uns nun eine App einbinden.

Klicken Sie auf „➡️ DevOps-App hinzufügen“.

Äh, das sind alle vier Anwendungen, die wir unterstützen.

Der Einrichtungsablauf ist bei all diesen Plattformen ziemlich ähnlich.

Klickt auf „Weiter“.

Der Name der App kann also, ähm, alles Mögliche sein, was

damit Sie die App leicht identifizieren können – es kann ein Name aus Ihrem Azure DevOps sein oder alles, was für Sie Sinn ergibt.

Es gibt zwei Möglichkeiten, die App einzurichten.

Wenn Sie die Express-Konfiguration verwenden, stellt Commvault die App bereit.

Sie können auch Ihre eigene benutzerdefinierte Konfiguration verwenden.

Das bedeutet, dass Sie Ihre eigene App einbinden und diese auch mit der Express-Konfiguration nutzen können.

Das Hinzufügen dauert weniger als eine Minute.

Schauen wir uns einmal an, wie das funktioniert.

Genau.

Wir haben Kontakt zu dieser Organisation aufgenommen.

Kommen wir nun zu „Access Node“.

Im Wesentlichen müssen Sie Ihre Speicherregion auswählen.

Wir sind praktisch überall vertreten.

Nehmen wir an, Sie haben Ihren Sitz in den USA – dann wird Ihnen die Speicherregion „USA“ angezeigt, ebenso in Europa und
in Asien.

Diese wird automatisch angezeigt.

Legen Sie die Region fest.

Und erstellen Sie dann den Tarif.

Unter „Plan“ können Sie im Wesentlichen

Wählen Sie aus, wie oft Sie ein Backup erstellen möchten.

Ähm, wir bieten bereits Speicherpakete an, und du kannst auch die Aufbewahrungsdauer festlegen.

Wir bieten also eine unbegrenzte Aufbewahrungsdauer an.

Sie können mindestens einmal täglich Backups erstellen.

Und schließlich der Inhalt.

Das sind also alle Dienste, die wir schützen.

Wenn du nicht möchtest, dass bestimmte Dienste geschützt werden, kannst du die entsprechende Auswahl aufheben.

Was Projekte betrifft: Wenn Sie „Alle Projekte“ auswählen, werden alle neuen
Projekte oder Repos, die täglich erstellt werden, werden von uns gescannt und gesichert.

Wenn Sie beispielsweise nur bestimmte Workloads schützen oder deren Auswahl aufheben möchten, können Sie dies hier auswählen
.

Da der Speicherplatz in der Lizenz enthalten ist, empfiehlt es sich, alle Projekte auszuwählen.

Klicken Sie auf „➡ Absenden“.

Genau.

Ihre Instanz wurde erstellt.

Nun möchte ich noch einmal auf einen der Punkte eingehen, den ich in meinem Vortrag immer wieder betont habe,
nämlich die Skalierbarkeit.

Warum viele Lösungen auf dem Markt nicht skalierbar sind.

Es geht um die Unterstützung mehrerer Token.

Heute haben wir bereits eine App hinzugefügt,

die Ihnen ein Token zur Verfügung stellt.

Fügen wir nun weitere hinzu.

Das waren Anmeldeinformationen, die ich bereits erstellt habe.

Wenn Sie weitere möchten, klicken Sie hier auf „+“.

Das funktioniert so: Angenommen, du stößt mit einer App an die API-Ratenbegrenzung – dann wechsle
Wir wechseln automatisch zur zweiten und anschließend zur dritten.

Auf diese Weise könnt ihr so viele Apps wie möglich hinzufügen.

Außerdem, äh, wann immer du an die API-Ratenbegrenzung stößt, wechseln wir, und dann haben wir das hier.

So gehen wir bei der Skalierung vor.

Damit sind wir mit dem Onboarding-Teil der Demo fertig.

Schauen wir uns nun den Abschnitt zur Wiederherstellung an.

Kommen wir zurück zur Organisation.

Das sind alle Backups, die durchgeführt wurden.

Sie sehen diesen Zeitstempel.

Sie können zu einem beliebigen Datum springen und auf „Wiederherstellen“ klicken.

Das ist die Organisation.

Sie können auf die Organisation klicken.

Das sind alle Projekte.

Die Hierarchie lautet also: Organisation, Projekte und Repos.

Wie du siehst, gibt es hier Hunderte von Projekten.

Sie können jedes der Projekte aufrufen und sich ansehen, welche Repos dort vorhanden sind.

Das sind alle vorhandenen Repos.

Angenommen, Sie möchten nun eine Wiederherstellung durchführen.

Klicken Sie auf die Schaltfläche „Wiederherstellen“.

Richtig.

Nun bieten wir noch mehr Detailgenauigkeit.

Nehmen wir zum Beispiel an, Sie möchten nur Artefakte wiederherstellen.

Dann können Sie die Auswahl einfach aufheben.

Oder Sie möchten lediglich Repos wiederherstellen.

Sie können andere Dienste abwählen.

So gewährleisten wir eine präzise Steuerung.

Und ebenso liegt eine Wiederherstellung vor Ort nahe.

Wir bieten jedoch auch die Wiederherstellung an einem anderen Ort und sogar auf einer Festplatte an.

Dies dient Ihrer Notfallbereitschaft.

Schauen wir uns nun die „Out-of-Place“-Wiederherstellung an.

Ich habe doch auch über einen wichtigen Faktor gesprochen, oder?

Nehmen wir an, auch Ihre Plattformen können ausfallen.

In diesem Fall möchten Sie Ihre Berichte vielleicht auf andere Plattformen verlagern.

Zum Beispiel auf Azure DevOps oder GitHub.

Und das unterstützen wir.

Sie könnten zum Beispiel eine der im Setup konfigurierten Apps auswählen.

Und so läuft es ab.

Sehen Sie, Sie klicken auf „Senden“.

Äh, diese Berichte würden nahtlos in Ihre App wiederhergestellt werden.

GitHub und warum – Damit sind wir am Ende angelangt.

Um die gesamte Diskussion abzuschließen: Was haben wir gesehen?

Sehen wir der Realität ins Auge: Cybervorfälle sind keine Theorie.

Wir haben gesehen, dass Unternehmen fast täglich davon betroffen sind. Die Risiken liegen also ganz klar auf der Hand: Die
Die Lücke zwischen den nativen Tools und den selbst erstellten Skripten ist groß, und Punktlösungen

kommen mit der Skalierbarkeit nicht zurecht.

Sich auf sie zu verlassen, gefährdet also Ihre Cyber-Resilienz.

Und wir haben auch die Risiken erörtert.

Sie haben Produktivitätsverluste, Reputationsschäden, den Verlust des Kundenvertrauens und
andere mögliche Risiken berücksichtigt.

Die Lösung: Sie benötigen eine Lösung der Enterprise-Klasse wie Commvault, um diese
Risiken anzugehen und bereit zu sein.

Abschließend möchte ich noch den Unternehmen,

, die gerade erst damit beginnen, über den Schutz ihrer DevOps-Umgebungen nachzudenken: Welchen Rat
Würden Sie ihnen das geben?

Ja, ich würde damit beginnen, DevOps-Daten wie alle anderen geschäftskritischen Daten zu behandeln.

Ein weiteres weit verbreitetes Missverständnis ist, dass die nativen Tools oder Schnellskripte ausreichen – doch
Diese decken möglicherweise nur die grundlegende Recovery-Phase ab.

Sie sind nicht auf langfristige Sicherheit, Skalierbarkeit oder gar Compliance ausgelegt.

Der zweite Punkt, auf den ich eingehen möchte: Streben Sie nach Einfachheit.

Je fragmentierter die Sicherheitsstrategie ist, desto schwieriger wird es, Konsistenz und Sicherheit zu gewährleisten
.

Ähm, wir sollten also einen einheitlichen Ansatz verfolgen, der auf Transparenz, Automatisierung und sogar strengen
Zugriffskontrollen nachverfolgen.

Das macht im täglichen IT-Betrieb einen großen Unterschied.

Ein ausgezeichneter Ratschlag.

Vielen Dank für Ihre Einblicke.

Bevor wir uns verabschieden: Nutzen Sie diese QR-Codes, um unsere DevOps-Lösungsübersicht herunterzuladen und sich für unseren Cyber-Resilience-Workshop anzumelden
, das Cyber-Readiness-Assessment durchzuführen und mehr

mehr über unsere Early-Access-Programme zu erfahren.

Ich danke Ihnen.