Laissez au moins une inondation, mais 1C devrait fonctionner! Négocier avec les entreprises au sujet de DR

Imaginez : vous entretenez l'infrastructure informatique d'un grand centre commercial. Il commence à pleuvoir en ville. Des jets de pluie traversent le toit et l'eau remplit les locaux commerciaux jusqu'aux chevilles. Nous espérons que votre salle de serveurs ne se trouve pas au sous-sol, sinon les problèmes ne pourront être évités.  

L’histoire décrite n’est pas un fantasme, mais une description collective de quelques événements de 2020. Dans les grandes entreprises, un plan de reprise après sinistre (DRP) est toujours à portée de main dans ce cas. Dans les entreprises, cette responsabilité incombe aux spécialistes de la continuité des activités. Mais dans les petites et moyennes entreprises, la résolution de ces problèmes incombe aux services informatiques. Vous devez comprendre vous-même la logique métier, comprendre ce qui peut échouer et où, proposer une protection et la mettre en œuvre. 

C'est formidable si un spécialiste informatique peut négocier avec l'entreprise et discuter du besoin de protection. Mais j’ai vu plus d’une fois comment une entreprise lésinait sur une solution de reprise après sinistre (DR) parce qu’elle la considérait comme redondante. Lorsqu'un accident survenait, une longue reprise menaçait de perdre et l'entreprise n'était pas prête. Vous pouvez répéter autant que vous le souhaitez : « Je vous l'avais bien dit », mais le service informatique devra quand même rétablir les services.

En tant qu'architecte, je vais vous expliquer comment éviter cette situation. Dans la première partie de l'article, je montrerai le travail préparatoire : comment aborder trois questions avec le client pour le choix des outils de sécurité : 

• Que protégeons-nous ?
• De quoi protégeons-nous ?
• Dans quelle mesure protégeons-nous ? 

Dans la deuxième partie, nous parlerons des options pour répondre à la question : comment se défendre. Je donnerai des exemples de cas montrant comment différents clients construisent leur protection.

Ce que nous protégeons : identifier les fonctions commerciales critiques 

Il est préférable de commencer à se préparer en discutant du plan d’action post-urgence avec le client professionnel. La principale difficulté ici est de trouver un langage commun. Le client ne se soucie généralement pas du fonctionnement de la solution informatique. Il se soucie de savoir si le service peut remplir des fonctions commerciales et rapporter de l'argent. Par exemple : si le site fonctionne, mais que le système de paiement est en panne, il n'y a aucun revenu des clients et les « extrémistes » sont toujours des informaticiens. 

Un professionnel de l'informatique peut avoir des difficultés dans de telles négociations pour plusieurs raisons :

• Le service informatique ne comprend pas bien le rôle du système d’information en entreprise. Par exemple, s'il n'existe pas de description disponible des processus commerciaux ou d'un modèle commercial transparent. 
• L'ensemble du processus ne dépend pas du service informatique. Par exemple, lorsqu'une partie du travail est effectuée par des sous-traitants et que les informaticiens n'ont pas d'influence directe sur eux.

Je structurerais la conversation comme ceci : 

1. Nous expliquons aux entreprises que les accidents arrivent à tout le monde et que la guérison prend du temps. Le mieux est de démontrer les situations, comment cela se produit et quelles sont les conséquences possibles.
2. Nous montrons que tout ne dépend pas du service informatique, mais vous êtes prêt à contribuer avec un plan d'action dans votre domaine de responsabilité.
3. Nous demandons au client professionnel de répondre : si l’apocalypse se produit, quel processus doit être restauré en premier ? Qui y participe et comment ? 

   Une réponse simple est par exemple exigée de la part de l'entreprise : le centre d'appels doit continuer à enregistrer les candidatures 24h/7 et XNUMXj/XNUMX.

4. Nous demandons à un ou deux utilisateurs du système de décrire ce processus en détail. 
   Il est préférable de faire appel à un analyste pour vous aider si votre entreprise en possède un.

   Pour commencer, la description peut ressembler à ceci : le centre d'appels reçoit les demandes par téléphone, par courrier et via les messages du site Internet. Ensuite, il les saisit dans 1C via l'interface Web, et la production les récupère ainsi.

5. Nous examinons ensuite quelles solutions matérielles et logicielles prennent en charge le processus. Pour une protection complète, nous prenons en compte trois niveaux : 
   • applications et systèmes au sein du site (niveau logiciel),   
   • le site lui-même où fonctionnent les systèmes (niveau infrastructure), 
   • réseau (ils l'oublient souvent).

6. Nous découvrons les points de défaillance possibles : les nœuds du système dont dépendent les performances du service. Nous notons séparément les nœuds pris en charge par d'autres sociétés : opérateurs télécoms, hébergeurs, centres de données, etc. Grâce à cela, vous pouvez revenir vers le client professionnel pour l'étape suivante.

Ce contre quoi nous nous protégeons : les risques

Ensuite, nous découvrons auprès du client professionnel les risques contre lesquels nous nous protégeons en premier. Tous les risques peuvent être divisés en deux groupes : 

• perte de temps due à une interruption du service ;
• perte de données due à des impacts physiques, à des facteurs humains, etc.

Les entreprises ont peur de perdre du temps et des données – tout cela entraîne une perte d’argent. Encore une fois, nous posons des questions pour chaque groupe à risque : 

• Pour ce processus, pouvons-nous estimer combien coûte la perte de données et la perte de temps en argent ? 
• Quelles données ne pouvons-nous pas perdre ? 
• Où ne pouvons-nous pas autoriser les temps d’arrêt ? 
• Quels événements sont les plus probables et les plus menaçants pour nous ?

Après discussion, nous comprendrons comment prioriser les points de défaillance. 

Combien nous protégeons : RPO et RTO 

Lorsque les points critiques de défaillance sont clairs, nous calculons les indicateurs RTO et RPO. 

Je me souviens que RTO (objectif de temps de récupération) — il s'agit du délai autorisé à partir du moment de l'accident jusqu'au rétablissement complet du service. En langage commercial, il s’agit d’un temps d’arrêt acceptable. Si nous savons combien d’argent le processus a rapporté, nous pouvons calculer les pertes de chaque minute d’arrêt et calculer la perte acceptable. 

RPO (objectif de point de récupération) — point de récupération de données valide. Il détermine le temps pendant lequel nous pouvons perdre des données. D’un point de vue commercial, la perte de données peut par exemple entraîner des amendes. Ces pertes peuvent également être converties en argent. 

Le temps de récupération doit être calculé pour l'utilisateur final : combien de temps pourra-t-il se connecter au système. Nous additionnons donc d’abord le temps de récupération de tous les maillons de la chaîne. Une erreur est souvent commise ici : ils retirent le RTO du fournisseur du SLA et oublient les conditions restantes.

Regardons un exemple spécifique. L'utilisateur se connecte à 1C, le système s'ouvre avec une erreur de base de données. Il contacte l'administrateur système. La base de données se trouve dans le cloud, l'administrateur système signale le problème au fournisseur de services. Disons que toutes les communications prennent 15 minutes. Dans le cloud, une base de données de cette taille sera restaurée à partir d'une sauvegarde en une heure, le RTO côté fournisseur de services est donc d'une heure. Mais ce n'est pas le délai ultime : pour l'utilisateur, 15 minutes ont été ajoutées pour détecter le problème. 
 
Ensuite, l'administrateur système doit vérifier que la base de données est correcte, la connecter à 1C et démarrer les services. Cela nécessite encore une heure, ce qui signifie que le RTO du côté de l’administrateur est déjà de 2 heures et 15 minutes. L'utilisateur a besoin de 15 minutes supplémentaires : connectez-vous, vérifiez que les transactions nécessaires sont apparues. 2 heures 30 minutes est la durée totale de récupération du service dans cet exemple.

Ces calculs montreront à l'entreprise de quels facteurs externes dépend la période de récupération. Par exemple, si le bureau est inondé, vous devez d’abord trouver la fuite et la réparer. Cela prendra du temps, qui ne dépend pas de l'informatique.  

Comment nous protégeons : choisir des outils pour différents risques

Après avoir discuté de tous les points, le client comprend déjà le coût d’un accident pour l’entreprise. Vous pouvez désormais choisir les outils et discuter du budget. À l'aide d'exemples de cas clients, je vais vous montrer quels outils nous proposons pour différentes tâches. 

Commençons par le premier groupe de risques : les pertes dues aux interruptions de service. Les solutions à ce problème devraient fournir un bon RTO.

1. Héberger l'application dans le cloud 

   Pour commencer, vous pouvez simplement passer au cloud - le fournisseur a déjà réfléchi aux problèmes de haute disponibilité. Les hôtes de virtualisation sont assemblés dans un cluster, l'alimentation et le réseau sont réservés, les données sont stockées sur des systèmes de stockage tolérants aux pannes et le fournisseur de services est financièrement responsable des temps d'arrêt.

   Par exemple, vous pouvez héberger une machine virtuelle avec une base de données dans le cloud. L'application se connectera à la base de données en externe via un canal établi ou depuis le même cloud. Si des problèmes surviennent avec l'un des serveurs du cluster, la VM redémarrera sur le serveur voisin en moins de 2 minutes. Après cela, le SGBD y démarrera et dans quelques minutes, la base de données deviendra disponible.

   RTO: mesuré en minutes. Ces conditions peuvent être précisées dans l'accord avec le fournisseur.
   coût de: Nous calculons le coût des ressources cloud pour votre application. 
   De quoi cela ne vous protégera pas: des pannes massives sur le site du fournisseur, par exemple dues à des accidents au niveau de la ville.

2. Clusteriser l'application  

   Si vous souhaitez améliorer le RTO, vous pouvez renforcer l'option précédente et placer immédiatement une application en cluster dans le cloud.

   Vous pouvez implémenter un cluster en mode actif-passif ou actif-actif. Nous créons plusieurs VM en fonction des exigences du fournisseur. Pour une plus grande fiabilité, nous les répartissons sur différents serveurs et systèmes de stockage. Si le serveur contenant l'une des bases de données tombe en panne, le nœud de sauvegarde prend en charge la charge en quelques secondes.

   RTO: Mesuré en secondes.
   coût de: légèrement plus cher qu'un cloud classique, des ressources supplémentaires seront nécessaires pour le clustering.
   De quoi cela ne vous protégera pas: Cela ne protège toujours pas contre les pannes massives sur site. Mais les perturbations locales ne dureront pas aussi longtemps.

   De la pratique: L'entreprise de vente au détail disposait de plusieurs systèmes d'information et sites Internet. Toutes les bases de données étaient situées localement dans les bureaux de l'entreprise. Aucun DR n'a été envisagé jusqu'à ce que le bureau soit laissé sans électricité plusieurs fois de suite. Les clients étaient mécontents des pannes du site Web. 
    
   Le problème de disponibilité du service a été résolu après le passage au cloud. De plus, nous avons réussi à optimiser la charge sur les bases de données en équilibrant le trafic entre les nœuds.

3. Passez à un cloud à l’épreuve des catastrophes

   Si vous devez vous assurer que même une catastrophe naturelle sur le site principal n'interfère pas avec votre travail, vous pouvez choisir un cloud résistant aux catastrophes. Dans cette option, le fournisseur répartit le cluster de virtualisation sur 2 centres de données. Une réplication synchrone constante se produit entre les centres de données, une à une. Les canaux entre les centres de données sont réservés et empruntent des itinéraires différents, un tel cluster n'a donc pas peur des problèmes de réseau. 

   RTO: tend vers 0.
   coût de: L'option cloud la plus chère. 
   De quoi cela ne vous protégera pas: Cela n'aidera pas contre la corruption des données, ni contre le facteur humain, il est donc recommandé de faire des sauvegardes en même temps. 

   De la pratique: L'un de nos clients a développé un plan complet de reprise après sinistre. Voici la stratégie qu'il a choisie : 

   • Un cloud tolérant aux catastrophes protège l'application des pannes au niveau de l'infrastructure. 
   • La sauvegarde à deux niveaux offre une protection en cas d'erreur humaine. Il existe deux types de sauvegardes : « à froid » et « à chaud ». Une sauvegarde « à froid » est dans un état désactivé et prend du temps à déployer. Une sauvegarde « à chaud » est déjà prête à l’emploi et est restaurée plus rapidement. Il est stocké sur un système de stockage spécialement dédié. La troisième copie est enregistrée sur bande et stockée dans une autre pièce. 

   Une fois par semaine, le client teste la protection et vérifie la fonctionnalité de toutes les sauvegardes, y compris celles sur bande. Chaque année, l'entreprise teste l'ensemble du cloud résistant aux catastrophes. 

4. Organiser la réplication vers un autre site 

   Autre option pour éviter les problèmes globaux sur le site principal : proposer la géo-réservation. En d’autres termes, créez des machines virtuelles de sauvegarde sur un site dans une autre ville. Des solutions spéciales pour DR sont adaptées à cela : dans notre entreprise, nous utilisons VMware vCloud Availability (vCAV). Avec son aide, vous pouvez configurer la protection entre plusieurs sites de fournisseurs cloud ou restaurer vers le cloud à partir d'un site sur site. J'ai déjà parlé plus en détail du schéma de travail avec vCAV ici. 

   RPO et RTO: à partir de 5 minutes. 

   coût de: plus chère que la première option, mais moins chère que la réplication matérielle dans un cloud à l'épreuve des sinistres. Le prix comprend le coût d'une licence vCAV, les frais d'administration, le coût des ressources cloud et les ressources de réserve selon le modèle PAYG (10 % du coût des ressources de travail pour les VM éteintes).

   De la pratique: Le client conservait 6 machines virtuelles avec différentes bases de données dans notre cloud à Moscou. Au début, la protection était assurée par sauvegarde : certaines des copies de sauvegarde étaient stockées dans le cloud à Moscou et d'autres sur notre site de Saint-Pétersbourg. Au fil du temps, la taille des bases de données a augmenté et la restauration à partir d'une sauvegarde a commencé à prendre plus de temps. 
    
   La réplication basée sur VMware vCloud Availability a été ajoutée aux sauvegardes. Les répliques de machines virtuelles sont stockées sur un site de sauvegarde à Saint-Pétersbourg et sont mises à jour toutes les 5 minutes. En cas de panne sur le site principal, les employés basculent indépendamment vers une réplique de la machine virtuelle à Saint-Pétersbourg et continuent de travailler avec elle. 

Toutes les solutions envisagées offrent une haute disponibilité, mais ne protègent pas contre la perte de données due à un virus ransomware ou à une erreur accidentelle d’un employé. Dans ce cas, nous aurons besoin de sauvegardes qui fourniront le RPO requis.

5. N'oubliez pas la sauvegarde

Tout le monde sait que vous devez effectuer des sauvegardes, même si vous disposez de la solution anti-catastrophe la plus cool. Je vais donc vous rappeler brièvement quelques points.

À proprement parler, la sauvegarde n’est pas une reprise après sinistre. Et c'est pourquoi: 

• C'est long. Si les données sont mesurées en téraoctets, la récupération prendra plus d'une heure. Vous devez restaurer, attribuer un réseau, vérifier qu'il s'allume, voir que les données sont en ordre. Vous ne pouvez donc fournir un bon RTO que s’il y a peu de données. 
• Les données peuvent ne pas être restaurées du premier coup et vous devez prévoir du temps pour répéter l'action. Par exemple, il arrive parfois que nous ne sachions pas exactement quand les données ont été perdues. Disons que la perte a été constatée à 15.00h15.00 et que des copies sont faites toutes les heures. A partir de 14h00, nous examinons tous les points de récupération : 13h00, XNUMXhXNUMX et ainsi de suite. Si le système est important, nous essayons de minimiser l'âge du point de récupération. Mais si la nouvelle sauvegarde ne contenait pas les données nécessaires, passons au point suivant : c'est du temps supplémentaire. 

Dans ce cas, le planning de sauvegarde peut fournir les RPO. Pour les sauvegardes, il est important de prévoir une géo-réservation en cas de problème avec le site principal. Il est recommandé de stocker certaines copies de sauvegarde séparément.

Le plan final de reprise après sinistre doit contenir au moins 2 outils :  

• Une des options 1 à 4, qui protégera les systèmes contre les pannes et les chutes.
• Sauvegarde pour protéger les données contre la perte. 

Il vaut également la peine de prévoir un canal de communication de secours en cas de panne du principal fournisseur d'accès Internet. Et voilà ! — La RD au salaire minimum est déjà prête. 

Source: habr.com