Classification de criticité des systèmes d'information

"Alfa-bank est aussi fiable qu'un tank,

et Gamma-bank est aussi fiable qu'une banque!"



Victor Pelevin, "Numbers"

Lorsque l'expression «système bancaire» apparaît dans les conversations, l'imagination dessine un système ultra-fiable construit sur les équipements les plus coûteux, regroupés à tous les niveaux possibles et isolés du monde extérieur par des moyens de protection accessibles et inaccessibles. En effet, de tels systèmes existent. Mais ...







Si vous regardez les postes vacants de développeurs dans la banque, alors il est tout à fait possible d'y voir parmi les exigences de connaissance de Cassandra, MongoDB et d'autres plates-formes, qui n'inspirent en aucun cas des réflexions sur une disponibilité à 100%. Et des SGBD tels qu'Oracle ou Microsoft SQL Server sont installés quelque part sur un cluster de serveurs coûteux connectés aux baies les plus fiables et les plus performantes, et quelque part sur une machine virtuelle ordinaire dans une batterie de serveurs à partir du produit même.



Les raisons sont évidentes: les solutions redondantes coûtent cher. Mais comment trouver un compromis entre le coût de la plateforme et sa fiabilité?



Il était une fois, quand il y avait peu de systèmes d'information dans l'entreprise, l'infrastructure de chaque système était une œuvre d'art. Au fil du temps, il y a eu plus de systèmes, il est devenu coûteux de prendre en charge plusieurs centaines de configurations matérielles et logicielles différentes, et les services d'infrastructure sont arrivés à la normalisation. Par exemple, un ensemble de solutions d'infrastructure SGBDR que les applications peuvent utiliser peut ressembler à ceci:

• serveurs haut de gamme avec baies de disques haut de gamme et réplication synchrone;
• serveurs de milieu de gamme avec baies de disques de milieu de gamme et réplication synchrone;
• serveurs de classe milieu de gamme avec baies de disques milieu de gamme et réplication asynchrone;
• serveurs standard avec baies de disques de milieu de gamme sans réplication.

Maintenant, comment choisir une configuration pour une base de données spécifique appartenant à une application spécifique?



Vous pouvez faire une liste des «applications les plus importantes qui doivent fonctionner à tout prix». Cela pose deux problèmes:



La configuration matérielle des applications restantes dépend du "poids" du propriétaire du système. En conséquence, certains services de congés maladie électroniques fonctionnent sur l'équipement le plus cher, car c'est l'idée préférée du chef comptable, avec qui personne ne veut se disputer. C'est un gaspillage d'argent déraisonnable.



Certaines applications peuvent ne pas être incluses dans la liste «les plus importantes» car elles n'ont pas été prises en compte. Par exemple, tout le monde se souvient du traitement des cartes bancaires, mais personne ne se souvient de la vérification des clients sur des «listes noires», qui devraient fonctionner à chaque opération. En conséquence, l'échec d'un tel système devient une surprise désagréable et conduit à de graves problèmes.



Il existe une méthodologie formelle qui vous permet de faire le bon choix et de protéger ce qui doit être protégé sans payer trop cher ce que vous ne pouvez pas payer trop cher.



Dans un premier temps, une classification des applications selon le niveau de criticité est introduite. En règle générale, il existe quatre de ces niveaux. Ils peuvent être appelés, par exemple, comme ceci:

• Platine;
• Or;
• Argent;
• Bronze.

Ou comme ça:

• Mission critique;
• Business critique;
• Entreprise opérationnelle;
• Productivité de bureau.

Ces quatre niveaux s'intègrent parfaitement dans 4 configurations d'infrastructure différentes. La seule chose à faire est de classer chaque application selon les besoins.



Lors de l'évaluation, il est important de respecter deux règles:



Le système est évalué par l'entreprise et non par le service informatique qui la dessert. La criticité ne doit pas être déterminée par la durée ou la main-d’œuvre nécessaire à la maintenance du système. Le seul critère est les pertes que l'entreprise subira du fait des temps d'arrêt du système.



Le libellé des questions constituant l'évaluation devrait prévoir la possibilité de vérifier les réponses. Bien sûr, les critères sont toujours basés sur le jugement d'expert, mais l'expert, au moins, peut expliquer pourquoi il a donné une telle évaluation.



Qu'est-ce qui détermine le niveau de criticité?

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

Dans la pratique mondiale, quelque chose de ce genre s'est développé:







cela ne signifie pas que dans votre entreprise, la répartition des systèmes par classes devrait être exactement la même. Mais dans tous les cas, si plus de 15% des systèmes d'exploitation entraient dans la classe Mission critique, c'est une raison de réfléchir sérieusement.



A la question "combien est-ce que tel ou tel système a besoin", tout propriétaire répondra "très". Par conséquent, une autre question doit être posée: que se passe-t-il si le système s'arrête? La classe de criticité du système dépend de la gravité des conséquences de l'arrêt du système et de la vitesse de leur occurrence.



Jetons un coup d'œil à plusieurs systèmes bancaires.



Le système de règlement fournit (surprise!) Des règlements entre clients - entités juridiques. Si soudainement une grande entreprise cliente est incapable d'effectuer un paiement à une contrepartie, la banque perdra un montant très important, de sorte que le système de règlement tombera sans aucun doute dans la classe de criticité la plus élevée.



Prenons le traitement des cartes. Si cent ou deux clients ne peuvent pas payer par carte, les pertes de la banque seront minimes, mais un déni de service aussi massif est inacceptable en soi.



Prenons maintenant un système qui maintient les dépôts. Si ce système s'arrête, les pertes de la banque seront à nouveau faibles et le déni de service ne sera pas aussi massif que dans le cas du traitement. Mais avons-nous besoin d'un éditorial de journal avec le titre «La banque refuse d'émettre des dépôts»? La question est rhétorique.



Enfin, prenons le grand livre général. Si soudainement quelque chose lui arrive, les clients ne remarqueront rien, car ce système ne participe pas du tout au service client. Mais il vaut la peine de retarder la remise du bilan, car les sanctions de la Banque centrale ne tarderont pas à venir.



Ainsi, les conséquences négatives des temps d'arrêt du système peuvent être divisées en 4 classes:

• Économique (pertes directes);
• Client (déni de service);
• Réputation (réactions négatives dans les médias);
• Juridique (des avertissements et amendes aux poursuites et révocation de licence).

Pour chaque classe de conséquences, des critères de gravité doivent être formulés et attribués des scores de 0 à 4. Par exemple, un tableau peut ressembler à ceci:





Bien sûr, tous les chiffres sont arbitraires, toutes les méthodes de calcul sont basées uniquement sur le jugement d'experts, et la portée du débat sur ce qu'il faut considérer comme «média régional» et comment traiter les articles négatifs dans les blogs populaires est vraiment illimitée. Mais dans une grande entreprise, il y aura certainement à la fois un service juridique et un service de relations publiques qui exprimeront volontiers une opinion compétente.



L'étape suivante consiste à choisir les intervalles de temps dans lesquels nous évaluerons les pertes. Par exemple, heure, 4 heures, 8 heures, 24 heures. Ces intervalles sont arbitraires et n'ont rien à voir avec les SLA des systèmes évalués. Bien qu'à l'avenir, il serait correct de lier exactement le SLA typique à ces intervalles.



Maintenant, le propriétaire de chaque système remplit une matrice de 16 cellules. Les nombres dans le tableau ci-dessous sont donnés à titre d'exemple. La seule chose fondamentalement importante est que l'estimation des conséquences pour un intervalle plus long ne peut pas être inférieure à l'estimation pour un intervalle plus court.





Il reste trois étapes pour obtenir le score final à partir de cette matrice.

Première étape - pour chaque intervalle de temps, sélectionnez l'estimation maximale:





Deuxième étape: nous traduisons les estimations obtenues dans les classes de criticité à l'aide de la matrice:





Pour ce système, nous obtenons les estimations suivantes:





Et, enfin, parmi toutes les estimations obtenues, nous choisissons la plus élevée - dans ce cas, le système évalué doit être classé comme critique pour l'entreprise.



Ayant reçu ces estimations, nous pouvons raisonnablement choisir l'une ou l'autre solution d'infrastructure pour chaque système.



Il reste plusieurs nuances sans lesquelles la méthodologie décrite serait incomplète.



Si le système garantit l'opérabilité d'un autre système, sa classe de criticité ne peut pas être inférieure à la classe du système dépendant. Par exemple, Active Directory n'a rien à voir avec les affaires. Mais si elle augmente soudainement, les conséquences pour de nombreuses applications métier seront les plus désastreuses, et donc AD appartient définitivement à la classe critique de mission.



Les pertes subies à la suite d'un temps d'arrêt du système ne peuvent pas être inférieures aux pertes encourues en interrompant le processus métier fourni par ce système. À la lumière de cette règle, il est très intéressant d'évaluer le système de messagerie de l'entreprise, car il s'avère soudain que l'échange d'informations critiques y est lié.



Si une entreprise utilise plusieurs blocs sur le même système et que les estimations de ces blocs pour le système diffèrent, l'estimation maximale doit être utilisée. De plus, même les critères d'évaluation peuvent être différents. Ainsi, par exemple, l'évaluation de l'impossibilité de servir un client peut être très différente selon le type de client - un "physicien" ordinaire, un VIP ou une grande entreprise cliente.



Étiquetez vos systèmes - et que votre infrastructure soit aussi fiable qu'elle le devrait, mais pas plus chère qu'elle ne peut l'être!