Ermittlung der minimalen Lebensfähigkeit – mit Constellation Energy

Unter „Minimum Viability“ versteht man die geringste Menge an unverzichtbaren Ressourcen – Mitarbeiter, Prozesse und Technologie –, die erforderlich ist, um den Geschäftsbetrieb während einer schwerwiegenden Störung aufrechtzuerhalten. 

Dies erfordert Entscheidungen auf Führungsebene, funktionsübergreifende Abstimmung und die Priorisierung von Ergebnissen, wodurch es sich eher um eine strategische Unternehmensdisziplin als um eine rein technische Aufgabe handelt. 

Da Ausfälle oft wochenlang andauern, bietet die „Minimum Viability“ den schnellsten Weg, um die Wiederaufnahme wesentlicher Betriebsabläufe zu unterstützen und finanzielle sowie rufschädigende Auswirkungen zu minimieren. 

Durch eine funktionsübergreifende Analyse von Abhängigkeiten, Arbeitsabläufen und Identitätsdiensten werden häufig kritische Systeme aufgedeckt, die zuvor übersehen wurden. 

Die Mindestbetriebsfähigkeit liegt in der gemeinsamen Verantwortung der Bereiche IT, Sicherheit, Betrieb, Risk, Finanzen und der Geschäftsleitung. 

Sehen Sie sichhierdas Video mit dem zeitgestempelten Transkript an

Hallo und herzlich willkommen zu dieser Folge des SHIFT-Podcasts.

Hier geht es darum, die minimale Funktionsfähigkeit (Minimum Viability) zu etablieren und sie zum wertvollsten
Faktor für Ihr Unternehmen zu machen.

Hallo zusammen, ich bin Vidya Shankaran, Field CTO bei Commvault, und heute sind bei mir Ha
Hoang, CIO bei Commvault Technologies, sowie Jay, CIO bei Constellation Energy.

Vielen Dank, dass ihr heute hier bei uns seid.

Vielen Dank für die Einladung.

Vielen Dank für die Einladung.

Selbstverständlich.

Wenn wir über die minimale Betriebsfähigkeit sprechen, liegt die durchschnittliche Ausfallzeit, die branchenweit verzeichnet
wird, laut optimistischen Branchenstatistiken bei 24 Tagen.

Für die meisten Unternehmen ist das jedoch eine unhaltbar lange Zeit.

Es geht nicht nur darum, sondern auch um die finanziellen Auswirkungen auf den Umsatz, die sich daraus für Unternehmen ergeben können –
ganz zu schweigen vom Reputationsschaden, den das Unternehmen während der 24 Tage der

Ausfallzeit erleidet.

Daher definiert die Branche heute die Mindestbetriebsfähigkeit als ein Mindestmaß an Fähigkeiten, das
die Mitarbeiter, die Prozesse und natürlich die Technologieumgebung umfasst, die zusammen ein

ein funktionsfähiges Unternehmen ausmachen.

Und das Erreichen dieser Mindestbetriebsfähigkeit wird zum entscheidenden Faktor dafür, ob das Unternehmen
nach einem Cyberangriff überleben und florieren kann.

Da die „Minimum Viability“ (MV) heute das Thema unserer Diskussion ist, freue ich mich, dass Ha.

und Jay bei uns sind.

Meine erste Frage an Ha lautet: Wie würdest du „Minimum Viability“
definieren, jenseits der in der Branche wahrscheinlich verbreiteten Fehlvorstellung, dass es sich dabei lediglich um eine IT-Checkliste handelt?

Wie lässt sich das mit einer Führungsmentalität umsetzen?

Für mich geht es bei der „Minimum Viability“ weniger um den Tech-Stack als vielmehr um Klarheit bei den Entscheidungen.

Es geht also um die Frage: Was ist der kleinste Satz an Fähigkeiten, den wir benötigen, um das Geschäft
am Laufen zu halten, während alles andere ausfällt, richtig?

Es ist also eine Denkweise, die Disziplin erfordert – nämlich Ergebnisse und nicht nur
die Infrastruktur in den Vordergrund zu stellen, richtig?

Ich denke also, wenn man diese Perspektive einnimmt, wird die Recovery-Planung zu einem Führungsgespräch
über Kompromisse und ist nicht nur eine technische Übung, oder?

Und das trägt auch dazu bei, eine gemeinsame Verantwortung für die Geschäftsbereiche, das Risk-Management und
, ähm, die IT hinweg aufzubauen.

Das leuchtet vollkommen ein.

Nun, da wir das Vergnügen haben, dass Sie heute hier bei uns sind, Jay: Was bedeutet „Minimum
Viability“ für ein Unternehmen mit kritischer Infrastruktur wie Constellation Energy, bei dem

Ausfallzeiten definitiv keine Option sind?

Nun, ich denke, ich würde mich da wohl ein wenig dem anschließen, worüber Sie gesprochen haben.

Es ist der ultimative Mannschaftssport.

Stimmt’s?

Ich meine, es ist keine reine IT-Diskussion.

Es ist keine Diskussion mit einzelnen Geschäftsbereichen.

Es ist keine Diskussion mit der Sicherheitsabteilung oder der IT-Abteilung.

Es ist wirklich eine Diskussion mit allen.

Denn genau das bedeutet „Minimal Viable Company“ doch eigentlich, oder?

Was bedeutet es für mich, mein Kerngeschäft weiterzuführen?

Stimmt’s?

Und wie sieht das aus?

Für mich ist die wichtigste Botschaft daher, dass es sich um eine Teamleistung handelt, denn es ist keine individuelle

Keine einzelne Gruppe kann das alleine schaffen.

Das finde ich toll.

Und ich muss euch beide das fragen.

Ich würde wohl zuerst Ha das Wort erteilen.

Gab es irgendwelche Fallstricke oder Überraschungen, die euch beim Erstellen der
Liste der minimal notwendigen kritischen Ressourcen unvorbereitet getroffen haben?

Ja, auf jeden Fall.

Es gab einige.

Einige der grundlegenden Systeme oder Anwendungen,

, von denen wir dachten, sie seien sozusagen ein Muss, waren definitiv nicht dabei, oder?

Oder sie haben es nicht auf unsere Liste geschafft.

Und dann denke ich, dass gerade Systeme wie die Identitätsverwaltung, die meiner Meinung nach eher nachträglich berücksichtigt wurden
, dabei eine ziemlich entscheidende Rolle spielen.

Und manchmal, ähm, konzentrieren wir uns hauptsächlich auf das, was der Kunde sieht, nämlich die
Anwendungen, oder?

Aber wenn man darüber nachdenkt, ob es sich um einen Jump-Service handelt, ob es um Identitätsmanagement geht oder ob
es einfach nur grundlegende, miteinander verknüpfte Systeme sind,

dann sind das meiner Meinung nach die entscheidenden.

Das finde ich toll.

Ich möchte noch hinzufügen, dass das Ganze dich voll und ganz beschäftigt.

Und wenn dir jemand sagt, dass das nicht so ist, dann erfindet er das einfach.

Das hat doch noch niemand zuvor gemacht, oder?

Es ist das erste Mal, dass wir wirklich darüber nachgedacht haben – wir haben zwar schon immer über
Viable Products“ gesprochen, aber nicht über „Minimal Viable Company“.

Ich denke, das Wichtigste für mich ist, dass wir eine sehr traditionelle Sicht auf die Welt hatten, bei der es Apps mit hohem, mittlerem und niedrigem Geschäftswert gab
.

Und wir sagten: „Na ja, das ist einfach.

Wir werden einfach die Apps mit hohem geschäftlichem Wert wiederherstellen und fertig.“

Was wir gelernt haben, war, dass eine ganze Reihe dieser Apps mit geringem geschäftlichem Wert wahrscheinlich dazu beigetragen hat
, die App mit hohem geschäftlichem Wert zu unterstützen oder ihr etwas zu liefern.

Dieses Denken in scheinbar sehr absoluten Kategorien funktioniert also nicht, wenn es um
ein „Minimal Viable Company“ geht, oder?

Denn man spricht von einem System, nicht von einzelnen Anwendungen.

Und das war für uns der größte Durchbruch.

Und ich würde wetten, dass das für viele Leute gilt.

Ich finde, das ist eine fantastische

Formulierung, die er da gerade verwendet hat: Es geht nicht um ein „Minimum Viable Product“, sondern um ein „Minimum
Viable Business“ oder ein „Minimum Viable Company“.

Das bringt mich zum nächsten Punkt.

Inwieweit haben Sie bei all diesen Maßnahmen mit Ihrem CISO zusammengearbeitet,
insbesondere bei der Festlegung einiger dieser kritischen Vermögenswerte und der Frage, wer für die Entscheidungen zur Recovery zuständig ist

Entscheidungen?

Ja, Sie haben die kritischen Ressourcen genannt, aber wer hilft dann dabei?

bei der Priorisierung der Recovery-Maßnahmen?

Ja.

Mann, wie ich schon sagte, es ist zwar ein Mannschaftssport, aber man braucht auch einen Schiedsrichter.

Ich denke also, in vielerlei Hinsicht fungieren der CIO und der CSO in diesem Fall tatsächlich ein bisschen wie ein Schiedsrichter
, denn als wir mit den Tabletop-Übungen begannen, hatten wir einen großartigen Partner, der

uns bei WWT unterstützt und uns wirklich dabei geholfen hat, das Ganze zu
durchdenken und sowohl den technischen Prozess als auch die

ich würde sagen, die verfahrenstechnischen Abläufe durchzugehen, denn am Ende hat man gelernt, dass jeder das Gefühl hat
, sein Bereich sei der wichtigste.

Ich denke also, das Wichtigste, worauf sich der CIO und der CISO konzentrieren sollten, ist, wie man
diese Rolle als Richter und Geschworener einnimmt, aber auch, wie man sicherstellt, dass man sich auf – du hast es erwähnt –

einige wirklich zentrale, grundlegende Technologien – Identität, Netzwerk – im Blick zu behalten, richtig?

Ohne diese funktioniert nichts.

Es geht also auch darum, den Menschen zu helfen,

dieses Puzzleteil zu verstehen.

So stelle ich mir ihre Rolle vor, oder?

Das finde ich toll.

Zurück zu dir, Ha.

Um noch einmal auf Jays Punkt zurückzukommen, dass es sich hierbei um eine Teamleistung handelt: Bist du bei der Erstellung des Business Case auf irgendwelche
Herausforderungen gestoßen, als du ihn wahrscheinlich dem Finanzteam

, dem Risk-Team und dem Compliance-Team vorgelegt hast?

Und was waren einige der Vorurteile, die in diesen

Geschäftsbereichen bereits eingeschlichen hatten und die du ausräumen musstest, bevor du den Anwendungsfall rund
um die minimale Machbarkeit verkaufen konntest?

Um diese Teams an einen Tisch zu bringen, musste der Ansatz zum „Minimum Viability“ natürlich anders gestaltet werden
, oder?

Sie musste in geschäftlichen Begriffen erfolgen und nicht in der Fachsprache von Backup and Recovery, oder?

Im Finanzbereich geht es beispielsweise darum, die Kontinuität der Einnahmen zu sichern.

Für die Risikoteams geht es darum, das Risiko zu begrenzen.

Und für die Betriebsteams geht es vor allem darum, die Kunden zufrieden zu stellen.

Und ich denke, wenn sich die Teams und die Funktionsbereiche in der Strategie der „Minimum
Viability“ wiedererkennen, entsteht erst echte Abstimmung.

Was Missverständnisse angeht, ist meiner Meinung nach das größte Missverständnis, dass „Minimum
Viability“ gleichbedeutend mit minimalem Aufwand ist.

Als ob es darum ginge, Standards zu senken oder sich mit einer teilweisen Recovery zufrieden zu geben.

Das ist ein guter Punkt.

In Wirklichkeit ist es genau das Gegenteil, oder?

Ähm, es geht wirklich um Disziplin und darum, sich auf das zu konzentrieren, was tatsächlich Kontinuität und
Widerstandsfähigkeit fördert, wenn jede Minute zählt, oder?

Und dann ist meiner Meinung nach das andere Missverständnis, dass es sich um eine reine Technologieangelegenheit handelt, oder?

Vorstände und CIOs wie wir erwarten also eine Checkliste oder ein Architekturdiagramm, aber in
Wirklichkeit geht es um eine Diskussion über die Geschäftsstrategie, oder?

Darüber, wie Unternehmen unter Druck tatsächlich Werte priorisieren, was sie schützen wollen und
warum.

Mir gefällt dieser Slogan, den du gerade genannt hast: „Wie man unter Druck geschäftlichen Wert
priorisiert“.

Ich würde das wahrscheinlich…

sie fett formatieren, markieren und bis zum Überdruss betonen, denn genau darin liegt der entscheidende Kern der
MVC-Definition.

Das bringt mich zum nächsten Punkt.

Wir haben über Strategie gesprochen.

Wir haben darüber gesprochen, dass es sich um eine Teamleistung handelt.

Aber was sind die wichtigsten KPIs?

Wie lässt sich das überhaupt quantifizieren und messen?

Das sind doch nicht gerade die typischen, greifbaren Kennzahlen, oder?

Oder übersehe ich da etwas?

Sind es der RPO und der RPTO, an denen man sich orientiert?

Was wären die Maßeinheiten für den Erfolg auf Basis von MVC?

Ich denke, ich werde vielleicht zunächst weniger auf die Kennzahlen eingehen, und dann kommen wir vielleicht auf die Kennzahlen zu sprechen.

Aber für mich geht es darum, sicherzustellen, dass man das System nicht nur in einer Krise nutzt.

Ich denke, es ist ein weit verbreitetes Missverständnis, einfach nur dazusitzen und zu sagen: „Wir werden das üben und
wir werden das hier haben.“

Wir haben

unsere gesamten Backups and Recoverys auf Commvault umgestellt, weil wir wollten, dass die Mitarbeiter das System täglich
nutzen.

Wir wollten also sicherstellen, dass sie wussten, wie man das System nutzt, wie es funktioniert und
wie man alle Details beherrscht, denn, wissen Sie, wir sprechen ja davon, unter Druck zu stehen,

oder?

Das ist nicht der richtige Zeitpunkt, um etwas Neues auszuprobieren.

Das ist also einer der Punkte.

Und ich möchte noch auf den letzten Punkt eingehen, über den du gesprochen hast – es ging wieder um DR,
richtig?

Ich glaube, ein weiteres weit verbreitetes Missverständnis ist, dass wir bereits über DR verfügen.

Wozu brauche ich das?

Stimmt’s?

Ich meine, ich habe es doch schon.

Und ich glaube,

wenn man noch einmal über DR nachdenkt, ist das doch irgendwie eine veraltete Denkweise, oder?

Es hat – mangels eines besseren Begriffs – so eine Art „Loch-im-Boden“-Denkweise, oder?

Was passiert, wenn mir diese eine Sache fehlt?

Nun, ich glaube nicht, dass irgendeine unserer Welten in weniger als fünf anderen Clouds oder fünf anderen
Welten existiert.

Deshalb glaube ich wirklich, dass es erstens darum geht, die Denkweise zu ändern, und zweitens darum, die Abläufe so anzupassen
, dass man nicht erst in einer Krise handelt.

So sehe ich das jedenfalls.

Das finde ich toll.

Da stimme ich voll und ganz zu.

Ja, natürlich betrachten wir quantitative und qualitative Kennzahlen,
also Indikatoren.

Und technisch gesehen misst ja jeder RPO und RTO sowie
den Prozentsatz der einwandfreien Backup-Daten und so weiter.

Aber ich denke, worauf ich mich ebenfalls konzentriere und was ich im Auge behalte, ist, wie schnell wir unter Druck fundierte
Entscheidungen treffen können, oder?

Denn meiner Meinung nach geht es bei der Readiness nicht nur darum, wie schnell wir Daten wiederherstellen können, sondern auch darum
, wie schnell wir den Daten und dem System, das wir wiederherstellen, vertrauen können.

Inwieweit läuft das also letztendlich auf die Operationalisierung von Tests hinaus?

Alles.

Eine ganze Menge.

Ja.

Ich meine, darauf läuft es doch immer hinaus, oder?

Vorbereitung, Übung.

Schau mal, in unserer Welt üben wir viel.

Wir üben alles, was wir tun.

Denn man will sichergehen, dass man es dann, wenn es wirklich darauf ankommt oder man unter Druck steht,
auch umsetzen kann.

Und ich denke, hier ist es nicht anders.

Vielleicht ist die gute Nachricht – oder auch die schlechte Nachricht –, dass wir alle in letzter Zeit viele Gelegenheiten hatten, das
zu üben, oder?

Ob es nun Cloud-Ausfälle waren oder Anbieter, die so etwas tun, oder?

Wir hatten Gelegenheiten, das zu üben.

Und das ist der andere Punkt, den ich ansprechen möchte: Man muss diese Gelegenheiten nutzen und sagen:
Habt keine Angst davor, ein System einzusetzen, das ihr habt, oder?

Man hat ein System aufgebaut, also nutzt man dieses System.

Wie nutze ich es

, um schneller wieder einsatzfähig zu sein?

Wie nutze ich es für die Recovery einer bestimmten Cloud oder bei einem aktuellen
Vorfall, oder?

Ich denke, es geht darum, nach vorne zu schauen und es zu nutzen, anstatt es beiseite zu schieben und zu denken:
„Oh, muss ich mich wirklich um die Notfallwiederherstellung kümmern?

So nach dem Motto: „Muss ich das wirklich tun?“

Diese Denkweise haben wir alle.

Man darf es nicht einfach einrichten und dann vergessen.

Genau, genau.

Es ist einfach da, also nutzt es.

Ja, und das ist definitiv etwas, woran Organisationen weiterarbeiten müssen.

Das ist keine

einmalige Übung, die man einfach abhaken kann.

Es ist ein lebendiger Prozess, den man kontinuierlich verbessern muss.

Und seien wir ehrlich: Es wächst auch ständig weiter, oder?

Die Datenmenge und alles andere nehmen nicht ab.

Wahrscheinlich ist das Produkt, das man eingeführt hat – und das gilt wohl für jeden –, nur ein Bruchteil dessen, was
man heute hat.

Das verändert die Situation grundlegend, oder?

Genau.

Das bringt mich zur nächsten, entscheidenden Frage, die schwieriger zu beantworten war.

War es die technische Umsetzung oder der kulturelle Wandel?

Ich würde sagen, der kulturelle Wandel und die kulturelle Veränderung, ohne Frage.

Die technische Arbeit ist komplex, aber lösbar.

Man kann sie automatisieren und sich durch Tests hindurcharbeiten.

Am schwierigsten ist jedoch der Umdenkprozess – weg von der Vorstellung, dass Recovery eine Aufgabe der IT ist, hin
zur Erkenntnis, dass Resilienz tatsächlich eine gemeinsame

unternehmensweite Kompetenz ist.

Ja.

Ja.

Da stimme ich zu.

Ich würde sagen, der technische Teil ist einfach, weil ich ein großartiges technisches Team habe und sie
es einfach wirklich einfach aussehen lässt.

Aber ich glaube schon, dass sich die technischen Probleme lösen lassen, oder?

Es sind Einsen und Nullen, und wir können das alles herausfinden.

Das Problem ist, dass diese Diskussion immer so lief: „Hey, IT, macht euren Job und sagt uns Bescheid, wenn
ihr fertig seid“, oder?

So läuft das Gespräch heute aber nicht mehr.

Und das ist für mich die größte Veränderung: Man muss jetzt alle Führungskräfte des Unternehmens in
einem Raum versammeln und sagen: „Hey, wir müssen ein Gespräch über Recovery führen.“

Und es geht nicht mehr nur darum: „Hey, sagt uns Bescheid, wenn ihr fertig seid, IT.“

Und genau das ist der kulturelle Wandel.

Da stimme ich voll und ganz zu.

Ich denke, die Frage nach der Zukunftsfähigkeit zwingt uns zu etwas unangenehmen Gesprächen über
Prioritäten, oder?

Was muss wirklich in den ersten 24 Stunden geschehen und was kann warten?

Und genau da, denke ich,

wir von Führungskräften im Wesentlichen verlangen, in Echtzeit Kompromisse einzugehen – und das sind
die schwierigen Gespräche.

Ja.

Nein, das leuchtet vollkommen ein.

Und gerade zu Ihrem Punkt: Wenn man jede Führungskraft fragen würde, würde sie
antworten: „Mein AppStack ist wichtig.“

Alles ist wichtig.

Ich bin am wichtigsten.

Ja, absolut.

Nachdem ich also

den Prozess des Aufbaus Ihres MVC miterlebt und durchlaufen haben – und natürlich ist es
, wie wir gerade besprochen haben, ein fortlaufender Prozess.

Aber was sind die wichtigsten Erkenntnisse, die „Erfahrungen“, die du unbedingt mit deinen Kollegen teilen möchtest
, damit sie nicht auf dieselben Herausforderungen stoßen, wenn sie

beim Aufbau ihres MVC?

Ich würde sagen: Übe die Recovery, als wäre es Spieltag, oder?

Denn in einer Krise kann man keine Widerstandsfähigkeit aufbauen.

Sie entsteht durch die Übungen, die man vorher macht.

Perfekt.

Ich denke, für mich – und du hast es schon ein paar Mal erwähnt, und ich kann es gar nicht genug betonen –
ist die grundlegende Kernschicht entscheidend.

Ich glaube, traditionell denken wir einfach nicht daran, dass grundlegende Dinge wie
Active Directory, das Netzwerk und all diese Dinge mittlerweile stärker

als je zuvor.

Und ich denke, das ist die größte Veränderung, die man wirklich berücksichtigen und umsetzen muss

und verstehen muss: Wie sieht es aus, wenn ich meine zentrale Authentifizierung wiederherstellen muss, bevor
meine Mitarbeiter überhaupt mit der Arbeit beginnen können?

Und genau das vergessen wir immer.

Ohne das können die IT-Mitarbeiter keine Arbeit erledigen.

Und ich denke, das ist die ultimative „Schlachtnarbe“.

Und ehrlich gesagt denke ich, dass dies eines der Dinge ist, die Commvault besser kann als alle anderen – nämlich
diese Recovery-Prozesse auf Active Directory-Forest-Ebene, die so entscheidend sind und eines der

wichtigsten Unterscheidungsmerkmale für uns bei der Produktauswahl sind.

Ich danke Ihnen.

Danke, dass Sie uns diesen Einblick gewährt haben.

Und bevor ich euch beide gehen lasse: Was sind die kurzen, aber wirkungsvollen Schlussworte
, die ihr uns mit auf den Weg geben würdet?

Meine Güte, ich glaube, das habe ich gerade erst gesagt.

Trainiert Recovery so, als wäre es Spieltag.

Perfekt.

Das gefällt mir.

Für mich ist es ein Mannschaftssport.

Und man kann das nicht einfach dem IT-Team überlassen und sagen: „Hey, sagt mir Bescheid, wenn es fertig ist.“

Das ist ein Mannschaftssport, bei dem alle im Raum an der Diskussion teilnehmen müssen.

Perfekt.

Vielen Dank, dass Sie heute bei uns sind und Ihre Erkenntnisse mit uns teilen.

Das war sehr wertvoll.

Und an alle unsere Zuschauer, die virtuell dabei sind: Wenn Sie sich eingehender mit
dem Konzept der „Minimum Viability“ befassen möchten, werfen Sie bitte einen Blick auf unseren GigaOm-Analystenbericht, der

in dem näher auf das Konzept der minimalen Funktionsfähigkeit eingegangen wird und das auf Commvault.com verfügbar ist.

Ich danke Ihnen.