Kritikalitätsklassifizierung von Informationssystemen

"Die Alfa-Bank ist so zuverlässig wie ein Panzer,

und die Gamma-Bank ist so zuverlässig wie eine Bank!"



Victor Pelevin, "Zahlen"

Wenn der Ausdruck "Bankensystem" in Gesprächen vorkommt, zeichnet die Phantasie ein äußerst zuverlässiges System, das auf den teuersten Geräten basiert, auf allen möglichen Ebenen gruppiert und durch zugängliche und unzugängliche Schutzmittel von der Außenwelt abgeschirmt ist. In der Tat existieren solche Systeme. Aber ...







Wenn Sie sich die offenen Stellen von Entwicklern in der Bank ansehen, dann ist es durchaus möglich, dort die Anforderungen an das Wissen von Cassandra, MongoDB und anderen Plattformen zu erkennen, die in keiner Weise zu Gedanken über eine 100% ige Verfügbarkeit anregen. Und DBMS wie Oracle oder Microsoft SQL Server werden irgendwo auf einem Cluster teurer Server installiert, die mit den zuverlässigsten und leistungsstärksten Arrays verbunden sind, und irgendwo auf einer regulären virtuellen Maschine in einer Farm von Anfang an.



Die Gründe liegen auf der Hand - redundante Lösungen sind teuer. Aber wie kann man einen Kompromiss zwischen den Kosten der Plattform und ihrer Zuverlässigkeit finden?



Es war einmal, als es im Unternehmen nur wenige Informationssysteme gab, die Infrastruktur für jedes System war ein Kunstwerk. Mit der Zeit gab es mehr Systeme, die Unterstützung mehrerer hundert verschiedener Hardware- und Softwarekonfigurationen wurde teuer, und die Infrastrukturabteilungen wurden standardisiert. Beispielsweise könnte eine Reihe von RDBMS-Infrastrukturlösungen, die Anwendungen verwenden können, folgendermaßen aussehen:

• Hi-End-Klassenserver mit Hi-End-Klassen-Festplattenarrays und synchroner Replikation;
• Midrange-Server mit Midrange-Festplatten-Arrays und synchroner Replikation;
• Server der Midrange-Klasse mit Midrange-Festplatten-Arrays und asynchroner Replikation;
• Commodity-Server mit Midrange-Disk-Arrays ohne Replikation.

Wie wählen Sie nun eine Konfiguration für eine bestimmte Datenbank aus, die zu einer bestimmten Anwendung gehört?



Sie können eine Liste der "wichtigsten Anwendungen erstellen, die um jeden Preis funktionieren müssen". Dies wirft zwei Probleme auf:



Die Hardwarekonfiguration für die verbleibenden Anwendungen hängt vom "Gewicht" des Systembesitzers ab. Infolgedessen funktioniert ein Teil des elektronischen Krankenstands mit den teuersten Geräten, da dies die beliebteste Idee des Hauptbuchhalters ist, mit dem sich niemand streiten möchte. Dies ist eine unvernünftige Geldverschwendung.



Einige Anwendungen werden möglicherweise nicht in die "wichtigste" Liste aufgenommen, da sie nicht berücksichtigt wurden. Zum Beispiel erinnert sich jeder an die Verarbeitung von Bankkarten, aber niemand erinnert sich daran, Kunden auf "schwarzen Listen" zu überprüfen, die bei jedem Vorgang funktionieren sollten. Infolgedessen wird der Ausfall eines solchen Systems zu einer unangenehmen Überraschung und führt zu ernsthaften Problemen.



Es gibt eine formale Methode, mit der Sie die richtige Wahl treffen und schützen können, was geschützt werden muss, ohne zu viel für das zu bezahlen, wofür Sie nicht zu viel bezahlen können.



Zunächst wird eine Klassifizierung der Anwendungen nach dem Grad der Kritikalität eingeführt. In der Regel sind diese Ebenen vier. Sie können zum Beispiel so genannt werden:

• Platin;
• Gold;
• Silber;
• Bronze.

Oder so:

• Missionskritisch;
• Geschäftskritisch;
• Geschäftsbetrieb;
• Office-Produktivität.

Diese vier Ebenen passen perfekt in 4 verschiedene Infrastrukturkonfigurationen. Sie müssen nur noch jede Anwendung nach Bedarf klassifizieren.



Bei der Bewertung sind zwei Regeln zu beachten:



Das System wird vom Unternehmen und nicht von der IT-Abteilung bewertet, die es bedient. Die Kritikalität sollte nicht davon abhängen, wie lange oder mühsam das System zu warten ist. Das einzige Kriterium sind die Verluste, die dem Unternehmen durch Systemausfälle entstehen.



Der Wortlaut der Fragen, aus denen sich die Bewertung zusammensetzt, sollte die Möglichkeit bieten, die Antworten zu überprüfen. Natürlich basieren die Kriterien immer noch auf Expertenurteilen, aber der Experte kann zumindest erklären, warum er gerade eine solche Bewertung abgegeben hat.



Was bestimmt den Grad der Kritikalität?

• . , , , .
• SLA (service level agreement). , – , .
• . , , .

In der Weltpraxis hat sich so etwas entwickelt:







Dies bedeutet nicht, dass in Ihrem Unternehmen die Verteilung der Systeme nach Klassen genau gleich sein sollte. Wenn jedoch mehr als 15% der Betriebssysteme in die kritische Klasse der Mission eingestuft werden, ist dies auf jeden Fall ein Grund, ernsthaft nachzudenken.



Auf die Frage "Wie viel wird dieses oder jenes System benötigt" antwortet jeder Eigentümer mit "sehr". Daher muss eine andere Frage gestellt werden: Was passiert, wenn das System stoppt? Die Kritikalitätsklasse des Systems hängt von der Schwere der Folgen des Herunterfahrens des Systems und der Geschwindigkeit ihres Auftretens ab.



Schauen wir uns einige Bankensysteme an.



Das Abwicklungssystem bietet (Überraschung!) Abrechnungen zwischen Mandanten - juristischen Personen. Wenn ein großer Firmenkunde plötzlich nicht mehr in der Lage ist, eine Zahlung an eine Gegenpartei zu leisten, verliert die Bank einen sehr erheblichen Betrag, sodass das Abwicklungssystem zweifellos in die höchste Klasse der Kritikalität fällt.



Nehmen wir die Kartenverarbeitung. Wenn ein oder zwei Kunden nicht mit Karte bezahlen können, sind die Verluste der Bank gering, aber ein derart massiver Denial-of-Service ist an sich nicht akzeptabel.



Nehmen wir nun ein System, das Einlagen verwaltet. Wenn dieses System stoppt, sind die Verluste der Bank wieder gering und der Denial-of-Service nicht so massiv wie bei der Verarbeitung. Aber brauchen wir ein Zeitungs-Editorial mit der Überschrift "Die Bank weigert sich, Einlagen auszugeben"? Die Frage ist rhetorisch.



Nehmen wir zum Schluss das Hauptbuch. Wenn ihr plötzlich etwas passiert, werden die Kunden nichts bemerken, da dieses System überhaupt nicht am Kundenservice teilnimmt. Es lohnt sich jedoch, die Lieferung der Bilanz zu verzögern, da die Sanktionen der Zentralbank nicht lange auf sich warten lassen.



Die negativen Folgen von Systemausfällen lassen sich also in vier Klassen einteilen:

• Wirtschaftlich (direkte Verluste);
• Kunde (Denial of Service);
• Reputation (negative Reaktionen in den Medien);
• Rechtlich (von Warnungen und Geldstrafen bis hin zu Klagen und Lizenzentzug).

Für jede Konsequenzklasse sollten Schweregradkriterien formuliert und Werte von 0 bis 4 zugewiesen werden. Beispielsweise könnte eine Tabelle folgendermaßen aussehen:





Natürlich sind alle Zahlen willkürlich, alle Berechnungsmethoden basieren ausschließlich auf Expertenmeinungen, und der Diskussionsspielraum darüber, was als "regionale Medien" zu betrachten ist und wie negative Artikel in populären Blogs zu behandeln sind, ist wirklich unbegrenzt. Aber in einem großen Unternehmen wird es sicherlich sowohl eine Rechtsabteilung als auch einen PR-Dienst geben, der bereitwillig eine kompetente Meinung äußert.



Der nächste Schritt besteht darin, die Zeitintervalle auszuwählen, in denen die Verluste geschätzt werden. Zum Beispiel Stunde, 4 Stunden, 8 Stunden, 24 Stunden. Diese Intervalle sind willkürlich und haben nichts mit SLAs für die zu bewertenden Systeme zu tun. Obwohl es in Zukunft richtig wäre, typische SLA genau an diese Intervalle zu binden.



Jetzt füllt der Besitzer jedes Systems eine Matrix von 16 Zellen aus. Die Zahlen in der folgenden Tabelle sind als Beispiele angegeben. Grundsätzlich ist nur wichtig, dass die Schätzung der Folgen für ein längeres Intervall nicht geringer sein kann als die Schätzung für ein kürzeres Intervall.





Es sind noch drei Schritte übrig, um das Endergebnis aus dieser Matrix zu erhalten.

Schritt eins - Wählen Sie für jedes Zeitintervall die maximale Schätzung aus:





Schritt zwei: Wir übersetzen die erhaltenen Schätzungen unter Verwendung der Matrix in die Kritikalitätsklassen:





Für dieses System erhalten wir folgende Schätzungen:





Und schließlich wählen wir aus allen erhaltenen Schätzungen die maximale aus - in diesem Fall sollte das zu bewertende System als geschäftskritisch eingestuft werden.



Nachdem wir diese Schätzungen erhalten haben, können wir vernünftigerweise die eine oder andere Infrastrukturlösung für jedes System auswählen.



Es gibt noch einige Nuancen, ohne die die beschriebene Methodik unvollständig wäre.



Wenn das System die Funktionsfähigkeit eines anderen Systems sicherstellt, kann seine Kritikalitätsklasse nicht niedriger sein als die Klasse des abhängigen Systems. Zum Beispiel hat Active Directory überhaupt nichts mit Geschäft zu tun. Wenn es jedoch plötzlich ansteigt, sind die Konsequenzen für viele Geschäftsanwendungen am schlimmsten, und daher gehört AD definitiv zur kritischen Klasse der Mission.



Verluste aufgrund von Systemausfällen können nicht geringer sein als Verluste, die durch die Unterbrechung des von diesem System bereitgestellten Geschäftsprozesses entstehen. Angesichts dieser Regel ist es sehr interessant, das E-Mail-System des Unternehmens zu bewerten, da sich plötzlich herausstellt, dass der Austausch kritischer Informationen damit verbunden ist.



Wenn ein Unternehmen mehrere Blöcke auf demselben System verwendet und die Schätzungen dieser Blöcke für das System unterschiedlich sind, sollte die maximale Schätzung verwendet werden. Darüber hinaus können auch die Bewertungskriterien unterschiedlich sein. So kann beispielsweise die Einschätzung der Unmöglichkeit, einen Kunden zu bedienen, sehr unterschiedlich sein, je nachdem, um welche Art von Kunden es sich handelt - ein gewöhnlicher "Physiker", ein VIP oder ein großer Firmenkunde.



Beschriften Sie Ihre Systeme - und Ihre Infrastruktur ist möglicherweise so zuverlässig wie nötig, aber nicht teurer als sie sein kann!