Procédures opérationnelles pour les charges de travail stratégiques sur Azure

Les opérations fiables et efficaces doivent être basées sur les principes de l’automatisation dans la mesure du possible et de la configuration en tant que code. Cette approche nécessite un investissement d’ingénierie substantiel dans les processus DevOps. Les pipelines automatisés sont utilisés pour déployer des artefacts de code d’application et d’infrastructure. Les avantages de cette approche incluent des résultats opérationnels cohérents et précis avec des procédures opérationnelles manuelles minimales.

Ce domaine de conception explore comment implémenter des procédures opérationnelles efficaces et cohérentes.

Important

Cet article fait partie de la série de charges de travail stratégiques Azure Well-Architected Framework . Si vous n’êtes pas familiarisé avec cette série, nous vous recommandons de commencer par Qu’est-ce qu’une charge de travail stratégique ?.

Processus DevOps

DevOps combine les processus de développement et opérationnels et les équipes en une seule fonction d’ingénierie. Il englobe l’ensemble du cycle de vie de l’application et utilise l’automatisation et les outils DevOps pour effectuer les opérations de déploiement de manière rapide, efficace et fiable. Les processus DevOps prennent en charge et soutiennent l’intégration continue et la livraison continue (CI/CD) tout en favorisant une culture d’amélioration continue.

L’équipe DevOps pour une application stratégique doit être responsable des tâches suivantes :

• Création et gestion des ressources d’application et d’infrastructure via l’automatisation CI/CD.
• Surveillance et observabilité des applications.
• Contrôle d’accès en fonction du rôle (RBAC) Azure et gestion des identités pour les composants d’application.
• Gestion réseau des composants d’application.
• Gestion des coûts pour les ressources d’application.

DevSecOps étend le modèle DevOps en intégrant la surveillance de la sécurité, les audits d’application et l’assurance qualité avec le développement et les opérations tout au long du cycle de vie de l’application. Les équipes DevOps sont nécessaires pour les scénarios hautement réglementés et sensibles à la sécurité afin de garantir que la sécurité est incorporée tout au long du cycle de vie du développement plutôt qu’à une phase de mise en production ou à une porte spécifique.

Considérations en matière de conception

• Processus de mise en production et de mise à jour. Évitez les processus manuels pour toute modification des composants d’application ou de l’infrastructure sous-jacente. Les processus manuels peuvent entraîner des résultats incohérents.

• Dépendances sur les équipes informatiques centrales. Les processus DevOps peuvent être difficiles à appliquer lorsqu’il existe des dépendances matérielles sur des fonctions centralisées, car ces dépendances empêchent les opérations de bout en bout.

• Gestion des identités et des accès. Les équipes DevOps peuvent envisager des rôles RBAC Azure granulaires pour diverses fonctions techniques, comme AppDataOps pour la gestion de base de données. Appliquez un modèle de confiance zéro sur des rôles DevOps.

Recommandations de conception

• Définissez les paramètres de configuration et les mises à jour en tant que code. Appliquez la gestion des modifications par le biais du code pour activer des processus de mise en production et de mise à jour cohérents, y compris des tâches telles que la rotation des clés ou des secrets et la gestion des autorisations. Utilisez des processus de mise à jour gérés par pipeline, comme des exécutions de pipeline planifiées, plutôt que des mécanismes de mise à jour automatique intégrés.

• N’utilisez pas de processus centraux ou de pipelines d’approvisionnement pour l’instanciation ou la gestion des ressources d’application. Cela introduit des dépendances d’application externes et des vecteurs de risque supplémentaires, comme ceux associés à des scénarios de voisins bruyants.

  Si vous devez utiliser des processus d’approvisionnement centralisés, assurez-vous que les exigences de disponibilité des dépendances sont entièrement alignées sur les exigences stratégiques. Les équipes centrales doivent fournir de la transparence afin d’obtenir une opérationnalisation holistique de l’application de bout en bout.

• Consacrez une partie de la capacité d’ingénierie à chaque sprint à l’amélioration fondamentale de la plateforme et au renforcement de la fiabilité. Nous vous recommandons d’allouer 20 à 40 % de la capacité à ces améliorations.

• Développez des critères d’ingénierie communs, des architectures de référence et des bibliothèques alignées sur les principes de conception de base. Appliquez une configuration de base cohérente pour la fiabilité, la sécurité et les opérations via une approche basée sur des stratégies qui utilise Azure Policy.

  Vous pouvez également utiliser les critères d’ingénierie courants et les artefacts associés, comme les stratégies Azure et les ressources Terraform pour des modèles de conception courants, sur d’autres charges de travail au sein de l’écosystème d’application plus large de votre organization.

• Appliquez un modèle de confiance zéro dans des environnements d’application critiques. Utilisez des technologies telles que Microsoft Entra Privileged Identity Management pour vous assurer que les opérations sont cohérentes et se produisent uniquement par le biais de processus CI/CD ou de procédures opérationnelles automatisées.

  Les membres de l’équipe ne doivent pas avoir d’accès en écriture permanent à un environnement. Vous souhaiterez peut-être faire des exceptions dans les environnements de développement pour faciliter les tests et le débogage.

• Définissez des processus d’urgence pour l’accès juste-à-temps aux environnements de production. Assurez-vous que des comptes d’interruption existent en cas de problèmes sérieux avec le fournisseur d’authentification.

• Envisagez d’utiliser AIOps pour améliorer continuellement les procédures opérationnelles et les déclencheurs.

Opérations d’application

La conception de l’application et les recommandations de plateforme influencent les procédures opérationnelles. Il existe également des fonctionnalités opérationnelles fournies par différents services Azure, en particulier pour la haute disponibilité et la récupération.

Considérations en matière de conception

• Opérations intégrées des services Azure. Les services Azure fournissent des fonctionnalités de plateforme intégrées (activées par défaut) et configurables, comme la redondance zonale et la géoréplication. La fiabilité d’une application dépend de ces opérations. Certaines fonctionnalités configurables entraînent un coût supplémentaire, comme la configuration de déploiement en plusieurs écritures pour Azure Cosmos DB. Évitez de créer des solutions personnalisées, sauf si vous en avez absolument besoin.

• Accès opérationnel et temps d’exécution. La plupart des opérations requises sont exposées et accessibles via l’API Azure Resource Manager ou l’Portail Azure. Toutefois, certaines opérations nécessitent l’aide des ingénieurs du support technique. Par exemple, une restauration à partir d’une sauvegarde périodique d’une base de données Azure Cosmos DB ou la récupération d’une ressource supprimée ne peut être effectuée que par support Azure ingénieurs via un cas de support. Cette dépendance peut affecter le temps d’arrêt de l’application. Pour les ressources sans état, nous vous recommandons de redéployer au lieu d’attendre que les ingénieurs du support technique essaient de récupérer les ressources supprimées.

• Application de stratégie. Azure Policy fournit une infrastructure pour l’application et l’audit des bases de référence de sécurité et de fiabilité afin de garantir la conformité aux critères d’ingénierie courants pour les applications stratégiques. Plus spécifiquement, Azure Policy constitue une partie clé du plan de contrôle Azure Resource Manager, en complétant RBAC en limitant les actions que les utilisateurs autorisés peuvent effectuer. Vous pouvez utiliser Azure Policy pour appliquer des conventions de sécurité et de fiabilité vitales entre les services de plateforme.

• Modification et suppression de ressources. Vous pouvez verrouiller les ressources Azure pour empêcher leur modification ou leur suppression. Toutefois, les verrous introduisent une surcharge de gestion dans les pipelines de déploiement. Pour la plupart des ressources, nous recommandons un processus RBAC robuste avec des restrictions strictes plutôt que des verrous de ressources.

Recommandations de conception

• Automatiser les procédures de basculement. Pour un modèle actif/actif, utilisez un modèle d’intégrité et des opérations de mise à l’échelle automatisées pour vous assurer qu’aucune intervention de basculement n’est requise. Pour un modèle actif/passif, assurez-vous que les procédures de basculement sont automatisées ou au moins codifiées dans les pipelines.

• Hiérarchiser l’utilisation de la mise à l’échelle automatique native Azure pour les services qui la prennent en charge. Pour les services qui ne prennent pas en charge la mise à l’échelle automatique native, utilisez des processus opérationnels automatisés pour mettre à l’échelle les services. Utilisez des unités de mise à l’échelle avec plusieurs services pour atteindre la scalabilité.

• Utilisez des fonctionnalités natives de plateforme pour la sauvegarde et la restauration, en veillant à ce qu’elles soient alignées sur vos exigences en matière de RTO/RPO et de rétention des données. Définissez une stratégie de conservation des sauvegardes à long terme en fonction des besoins.

• Utilisez des fonctionnalités intégrées pour la gestion et le renouvellement des certificats SSL, comme celles fournies par Azure Front Door.

• Pour les équipes externes, établissez un processus de récupération pour les ressources qui nécessitent de l’aide. Par exemple, si la plateforme de données est incorrectement modifiée ou supprimée, les méthodes de récupération doivent être bien comprises et un processus de récupération doit être en place. De même, établissez des procédures pour gérer les images conteneur désaffectées dans le Registre.

• Pratiquez des opérations de récupération à l’avance, sur des ressources et des données hors production, dans le cadre des préparations standard de la continuité d’activité.

• Identifiez les alertes critiques et définissez des audiences et des systèmes cibles. Définissez des canaux clairs pour atteindre les parties prenantes appropriées. Envoyez uniquement des alertes exploitables pour éviter le bruit blanc et empêcher les parties prenantes opérationnelles d’ignorer les alertes et de manquer des informations importantes. Implémentez l’amélioration continue pour optimiser les alertes et supprimer le bruit blanc observé.

• Appliquez une gouvernance et des Azure Policy pilotées par les stratégies pour garantir l’utilisation appropriée des fonctionnalités opérationnelles et une base de référence de configuration fiable pour tous les services d’application.

• Évitez l’utilisation de verrous de ressources sur des ressources régionales éphémères. Au lieu de cela, appuyez-vous sur l’utilisation appropriée des pipelines RBAC et CI/CD pour contrôler les mises à jour opérationnelles. Vous pouvez appliquer des verrous de ressources pour empêcher la suppression de ressources globales à longue durée de vie.

Gestion des mises à jour

La conception stratégique approuve fortement le principe des ressources d’application éphémères sans état. Si vous appliquez ce principe, vous pouvez généralement effectuer une mise à jour à l’aide d’un nouveau déploiement et de pipelines de livraison standard.

Considérations en matière de conception

• Alignement avec les feuilles de route Azure. Alignez votre charge de travail sur les feuilles de route Azure afin que les ressources de plateforme et les dépendances d’exécution soient mises à jour régulièrement.

• Détection automatique des mises à jour. Configurez des processus pour surveiller et détecter automatiquement les mises à jour. Utilisez des outils tels que GitHub Dependabot.

• Test et validation. Testez et validez les nouvelles versions des packages, des composants et des dépendances dans un contexte de production avant toute mise en production. Les nouvelles versions peuvent contenir des modifications cassants.

• Dépendances d’exécution. Traitez les dépendances du runtime comme vous le feriez pour toute autre modification apportée à l’application. Les versions antérieures peuvent introduire des failles de sécurité et avoir un effet négatif sur les performances. Surveillez l’environnement d’exécution de l’application et tenez-le à jour.

• Hygiène des composants et entretien ménager. Désaffectez ou supprimez les ressources qui ne sont pas utilisées. Par exemple, surveillez les registres de conteneurs et supprimez les anciennes versions d’images que vous n’utilisez pas.

Recommandations de conception

• Surveillez ces ressources et tenez-les à jour :

  • Plateforme d’hébergement d’applications. Par exemple, vous devez mettre à jour régulièrement la version de Kubernetes dans Azure Kubernetes Service (AKS), d’autant plus que la prise en charge des versions antérieures n’est pas maintenue. Vous devez également mettre à jour les composants qui s’exécutent sur Kubernetes, comme cert-manager et azure Key Vault CSI, et les aligner sur la version de Kubernetes dans AKS.
  • Bibliothèques externes et kits SDK (.NET, Java, Python).
  • Fournisseurs Terraform.

• Évitez les modifications opérationnelles manuelles pour mettre à jour les composants. Envisagez l’utilisation de modifications manuelles uniquement dans les situations d’urgence. Vérifiez que vous disposez d’un processus de rapprochement des modifications manuelles dans le référentiel source afin d’éviter la dérive et la récurrence des problèmes.

• Établissez une procédure automatisée pour supprimer les anciennes versions d’images de Azure Container Registry.

Gestion des secrets

Les expirations de clé, de secret et de certificat sont une cause courante de panne de l’application. La gestion des secrets pour une application stratégique doit fournir la sécurité nécessaire et offrir un niveau de disponibilité approprié pour s’aligner sur vos exigences de fiabilité maximale. Vous devez effectuer régulièrement une rotation des clés, des secrets et des certificats à l’aide d’un service managé ou dans le cadre de la gestion des mises à jour, et appliquer des processus pour les modifications de code et de configuration.

De nombreux services Azure prennent en charge l’authentification Microsoft Entra au lieu de s’appuyer sur des chaînes/clés de connexion. L’utilisation de Microsoft Entra ID réduit considérablement la surcharge opérationnelle. Si vous utilisez une solution de gestion des secrets, elle doit s’intégrer à d’autres services, prendre en charge la redondance zonale et régionale et fournir une intégration avec l’ID Microsoft Entra pour l’authentification et l’autorisation. Key Vault fournit ces fonctionnalités.

Considérations en matière de conception

Il existe trois approches courantes de la gestion des secrets. Chaque approche lit les secrets du magasin de secrets et les injecte dans l’application à un moment différent.

• Récupération au moment du déploiement. L’avantage de cette approche est que la solution de gestion des secrets doit être disponible uniquement au moment du déploiement, car il n’y a pas de dépendances directes après ce délai. Par exemple, l’injection de secrets en tant que variables d’environnement dans un déploiement Kubernetes ou dans un secret Kubernetes.

  Seul le principal du service de déploiement doit être en mesure d’accéder aux secrets, ce qui simplifie les autorisations RBAC au sein du système de gestion des secrets.

  Toutefois, cette approche présente des inconvénients. Il introduit la complexité RBAC dans les outils DevOps en ce qui concerne le contrôle de l’accès au principal de service et dans l’application en ce qui concerne la protection des secrets récupérés. En outre, les avantages en matière de sécurité de la solution de gestion des secrets ne sont pas appliqués, car cette approche s’appuie uniquement sur le contrôle d’accès dans la plateforme d’application.

  Pour implémenter des mises à jour ou une rotation des secrets, vous devez effectuer un redéploiement complet.

• Récupération au démarrage de l’application. Dans cette approche, les secrets sont récupérés et injectés au démarrage de l’application. L’avantage est que vous pouvez facilement mettre à jour ou faire pivoter les secrets. Vous n’avez pas besoin de stocker les secrets sur la plateforme d’application. Un redémarrage de l’application est nécessaire pour extraire la valeur la plus récente.

  Les choix de stockage courants incluent le fournisseur Azure Key Vault pour le pilote CSI du magasin de secrets et akv2k8s. Une solution Azure native, Key Vault paramètres d’application référencés, est également disponible.

  L’inconvénient de cette approche est qu’elle crée une dépendance d’exécution sur la solution de gestion des secrets. Si la solution de gestion des secrets rencontre une panne, les composants d’application déjà en cours d’exécution peuvent continuer à traiter les demandes. Toute opération de redémarrage ou de scale-out entraînerait probablement un échec.

• Récupération du runtime. La récupération des secrets au moment de l’exécution à partir de l’application elle-même est l’approche la plus sécurisée, car même la plateforme d’application n’a jamais accès aux secrets. L’application doit s’authentifier auprès du système de gestion des secrets.

  Toutefois, pour cette approche, les composants d’application nécessitent une dépendance directe et une connexion au système de gestion des secrets. Cela rend plus difficile le test des composants individuellement et nécessite généralement l’utilisation d’un KIT de développement logiciel (SDK).

Recommandations de conception

• Si possible, utilisez l’authentification Microsoft Entra pour vous connecter aux services au lieu d’utiliser des chaînes de connexion ou des clés. Utilisez cette méthode d’authentification avec les identités managées Azure afin d’éviter d’avoir à stocker des secrets sur la plateforme d’application.

• Tirez parti du paramètre d’expiration dans Key Vault et configurez les alertes pour les expirations à venir. Effectuez toutes les mises à jour de clé, de secret et de certificat à l’aide du processus de mise en production standard.

• Déployez Key Vault instances dans le cadre d’un tampon régional pour atténuer l’effet potentiel d’un échec d’un tampon de déploiement unique. Utilisez un instance distinct pour les ressources globales. Pour plus d’informations sur ces ressources, consultez le modèle d’architecture classique pour les charges de travail critiques.

• Pour éviter d’avoir à gérer les informations d’identification du principal de service ou les clés API, utilisez des identités managées au lieu des principaux de service pour accéder à Key Vault chaque fois que possible.

• Implémentez des modèles de codage pour garantir que les secrets sont récupérés à nouveau lorsqu’un échec d’autorisation se produit au moment de l’exécution.

• Appliquez un processus de rotation des clés entièrement automatisé qui s’exécute régulièrement dans la solution.

• Utilisez la notification d’expiration proche de la clé dans Azure Key Vault pour recevoir des alertes sur les expirations à venir.

Considérations spécifiques à IaaS lors de l’utilisation de machines virtuelles

Si vous devez utiliser des machines virtuelles IaaS, certaines des procédures et pratiques décrites précédemment dans ce document peuvent différer. L’utilisation de machines virtuelles offre plus de flexibilité dans les options de configuration, les systèmes d’exploitation, l’accès aux pilotes, l’accès au système d’exploitation de bas niveau et les types de logiciels que vous pouvez installer. Les inconvénients sont l’augmentation des coûts opérationnels et la responsabilité des tâches qui sont généralement effectuées par le fournisseur de cloud lorsque vous utilisez des services PaaS.

Considérations en matière de conception

• Les machines virtuelles individuelles ne fournissent pas de haute disponibilité, de redondance de zone ou de géoredondance.
• Les machines virtuelles individuelles ne sont pas automatiquement mises à jour après leur déploiement. Par exemple, un SQL Server déployé 2019 sur Windows Server 2019 n’est pas automatiquement mis à jour vers une version plus récente.
• Les services exécutés sur une machine virtuelle ont besoin d’un traitement spécial et d’outils supplémentaires si vous souhaitez les déployer et les configurer via l’infrastructure en tant que code.
• Azure met régulièrement à jour sa plateforme. Ces mises à jour peuvent nécessiter un redémarrage de la machine virtuelle. Mises à jour qui nécessitent un redémarrage sont généralement annoncés à l’avance. Consultez Maintenance des machines virtuelles dans Azure et Gestion des notifications de maintenance planifiée.

Recommandations de conception

• Évitez les opérations manuelles sur les machines virtuelles et implémentez les processus appropriés pour déployer et déployer les modifications.

  • Automatisez l’approvisionnement des ressources Azure à l’aide de solutions d’infrastructure en tant que code telles que des modèles Azure Resource Manager (ARM), Bicep, Terraform ou d’autres solutions.

• Vérifiez que les processus opérationnels pour le déploiement des machines virtuelles, les mises à jour, la sauvegarde et la récupération sont en place et correctement testés. Pour tester la résilience, injectez des erreurs dans l’application, notez les échecs et atténuez ces défaillances.

• Vérifiez que des stratégies sont en place pour revenir au dernier état sain connu si une version plus récente ne fonctionne pas correctement.

• Créez des sauvegardes fréquentes pour les charges de travail avec état, assurez-vous que les tâches de sauvegarde fonctionnent efficacement et implémentez des alertes en cas d’échec des processus de sauvegarde.

• Surveillez les machines virtuelles et détectez les défaillances. Les données brutes pour la surveillance peuvent provenir de diverses sources. Analysez les causes des problèmes.

• Vérifiez que les sauvegardes planifiées s’exécutent comme prévu et que les sauvegardes périodiques sont créées en fonction des besoins. Vous pouvez utiliser le Centre de sauvegarde pour obtenir des insights.

• Donnez la priorité à l’utilisation de Virtual Machine Scale Sets plutôt que de machines virtuelles pour activer des fonctionnalités telles que la mise à l’échelle, la mise à l’échelle automatique et la redondance de zone.

• Donnez la priorité à l’utilisation d’images standard provenant d’Place de marché Azure plutôt que d’images personnalisées qui doivent être conservées.

• Utilisez Azure VM Image Builder ou d’autres outils pour automatiser les processus de génération et de maintenance des images personnalisées en fonction des besoins.

Au-delà de ces recommandations spécifiques, appliquez les meilleures pratiques pour les procédures opérationnelles pour les scénarios d’application stratégiques, le cas échéant.

Étape suivante

Passez en revue le modèle d’architecture pour les scénarios d’application stratégiques :

Modèle d’architecture