Vue d’ensemble
Cette série fournit un exemple illustrant comment une organisation peut concevoir une stratégie de récupération d’urgence pour une plateforme de données d’entreprise Azure.
- Cette série d’articles complète les conseils fournis par le Framework d’adoption du cloud de Microsoft, le Framework Azure Well-Architected et la gestion de la continuité d’activité.
Azure fournit un large éventail d’options de résilience pouvant assurer la continuité du service en cas de sinistre. Mais il se peut que des niveaux de service plus élevés introduisent de la complexité et des coûts plus élevés. Le compromis entre coût, résilience et complexité est le facteur de prise de décision clé pour la plupart des clients en matière de récupération d'urgence.
Bien que des défaillances de point occasionnelles se produisent sur la plateforme Azure, les centres de données Azure de Microsoft et les services Azure ont plusieurs couches de redondance intégrées. Toute défaillance est normalement limitée dans l’étendue et est généralement corrigée en quelques heures. Historiquement, il est beaucoup plus probable qu’un service clé comme la gestion des identités rencontre un problème de service plutôt qu’une région Azure entière en mode hors connexion.
Il convient également de reconnaître que les cyberattaques, en particulier les rançongiciels, constituent désormais une menace tangible pour tout écosystème de données moderne, et peuvent entraîner une panne de la plateforme de données. Bien que cela soit hors de portée pour cette série, il est conseillé aux clients d’implémenter des contrôles contre de telles attaques dans le cadre de la conception de la sécurité et de la résilience de toute plateforme de données.
- Les conseils de Microsoft sur la protection contre les ransomwares sont disponibles dans le document Azure Cloud Fundamentals.
Étendue
Cette série d’articles aborde les sujets suivants :
- Récupération de service d’une plateforme de données Azure suite à un sinistre physique pour un personnage illustrant le client. Cet exemple de client est :
- Une organisation de taille moyenne avec une fonction de support opérationnelle définie, à la suite d’une méthodologie de gestion des services basée sur ITIL (Information Technology Infrastructure Library).
- Non cloud natif, avec son entreprise principale, services partagés tels que la gestion des accès et des authentifications et la gestion des incidents restants en local.
- Sur le parcours de la migration cloud vers Azure, activée par l’automatisation.
- La plateforme de données Azure a implémenté les conceptions suivantes au sein de la location Azure du client :
- Zone d’atterrissage d’entreprise : base de la plateforme, notamment la mise en réseau, la surveillance, la sécurité, et ainsi de suite.
- Plateforme d’analytique Azure : fournit les composants de données qui prennent en charge les différentes solutions et produits de données fournis par le service.
- Les processus décrits dans cet article seront exécutés par une ressource technique Azure plutôt qu’un expert spécialisé en matière d’objet Azure (PME). Par conséquent, les ressources doivent avoir le niveau de connaissances/compétences suivant :
- Principes fondamentaux d’Azure : connaissance opérationnelle d’Azure, de ses services principaux et de ses composants de données.
- Connaissance pratique d’Azure. Possibilité de naviguer dans le contrôle de code source et d’exécuter des déploiements de pipeline.
- Ces processus décrits dans cet article couvrent les opérations de basculement de service, du serveur principal à la région secondaire.
Hors propos
Les éléments suivants sont présumés hors de portée pour cette série d’articles :
- Processus de secours, de la région secondaire à la région primaire.
- Toutes les applications, composants ou systèmes autres qu’Azure : cela inclut, mais n’est pas limité à des fournisseurs de cloud locaux, à d’autres fournisseurs de cloud, à des services web tiers, et ainsi de suite.
- Récupération de tous les services en amont, tels que les réseaux locaux, les passerelles, les services partagés d’entreprise et d’autres, quelles que soient les dépendances de ces services.
- Récupération de tous les services en aval, tels que les systèmes opérationnels locaux, les systèmes de création de rapports tiers, la modélisation des données ou les applications de science des données, et d’autres, quelles que soient les dépendances de ces services.
- Scénarios de perte de données, y compris la récupération à partir d’un ransomware ou d’incidents de sécurité des données similaires
- Stratégies de sauvegarde de données et plans de restauration des données
- Établissement de la cause racine d’un événement de récupération d’urgence.
- Pour les incidents liés aux services/composants Azure, Microsoft publie une « analyse des causes profondes » au sein de la page Web Statut - Historique.
Hypothèses principales
Les principales hypothèses pour cet exemple de récupération d’urgence sont les suivantes :
- L’organisation suit une méthodologie de gestion de service basée sur ITIL pour la prise en charge opérationnelle de la plateforme de données Azure.
- L’organisation dispose d’un processus de récupération d’urgence existant dans le cadre de son infrastructure de restauration de service pour les ressources informatiques.
- L’infrastructure en tant que code (IaC) a été utilisée pour déployer la plateforme de données Azure activée par un service d’automatisation, tel qu’Azure DevOps ou similaire.
- Chaque solution hébergée par la plateforme de données Azure a effectué une évaluation d’impact métier ou similaire, fournissant des exigences de service claires pour l’objectif de point de récupération (RPO), l’objectif de temps de récupération (RTO) et le temps moyen de récupération (MTTR).
Étapes suivantes
Maintenant que vous avez découvert le scénario d’ensemble, vous pouvez en apprendre davantage sur l’architecture conçue pour le cas d’usage.