Considérations relatives à la mise à jour d’une solution mutualisée

L’un des avantages de la technologie cloud est l’amélioration continue et l’évolution. En tant que fournisseur de services, vous devez appliquer des mises à jour à votre solution. Vous devrez peut-être apporter des modifications à votre code d’application, à votre infrastructure Azure, à vos schémas de base de données ou à tout autre composant. Il est important de planifier la façon dont vous mettez à jour vos environnements. Dans une solution multilocataire, il est particulièrement important d’être clair sur votre stratégie de mise à jour, car certains de vos locataires peuvent hésiter à autoriser les modifications apportées à leurs environnements, ou ils peuvent avoir des exigences qui limitent les conditions dans lesquelles vous pouvez mettre à jour leur service.

Lorsque vous planifiez une stratégie pour mettre à jour votre solution, vous devez :

• Identifiez les exigences de vos locataires.
• Clarifier vos propres exigences en matière d’exploitation de votre service.
• Trouvez un solde que vous et vos locataires pouvez accepter.
• Communiquez clairement votre stratégie à vos locataires et à d’autres parties prenantes.

Cet article fournit des conseils aux décideurs techniques sur les approches de mise à jour des logiciels clients et des compromis impliqués.

Exigences de vos clients

Les clients ont souvent des exigences explicites ou implicites qui peuvent affecter la façon dont votre système est mis à jour. Tenez compte des aspects suivants pour créer une image de tous les points de préoccupation que les clients peuvent déclencher :

• Attentes et exigences : Découvrez les attentes ou exigences que les clients peuvent avoir à propos de la mise à jour de leur solution. Ces attentes ou exigences peuvent être communiquées formellement à vous dans les contrats ou les contrats de niveau de service, ou elles peuvent être informelles.

• Fenêtres de maintenance : Déterminez si vos clients attendent des fenêtres de maintenance définies par le service ou autodéfinis. Ils peuvent avoir besoin de communiquer avec leurs utilisateurs sur les pannes potentielles. Ils peuvent également s’attendre à tester des aspects importants de votre service une fois la mise à jour terminée.

• Règlement: Indiquez si les clients ont des préoccupations réglementaires qui nécessitent une approbation supplémentaire avant que les mises à jour puissent être appliquées. Par exemple, si vous fournissez une solution de santé qui inclut des composants IoT, vous devrez peut-être obtenir l’approbation de l’Administration américaine des aliments et des médicaments (FDA) avant d’appliquer une mise à jour.

• Sensibilité: Déterminez si l’un de vos clients est particulièrement sensible ou résistant à l’application des mises à jour. S’ils le sont, essayez de comprendre pourquoi. Par exemple, s’ils exécutent un magasin physique ou un site web de vente au détail, ils peuvent vouloir éviter les mises à jour autour de Black Friday, car les risques sont plus élevés que les avantages potentiels.

• Historique : Passez en revue vos propres antécédents de réussite dans l'exécution des mises à jour sans impact sur vos clients. Vous devez suivre de bonnes pratiques devOps, de test, de déploiement et de surveillance pour réduire la probabilité de pannes et vous assurer que vous identifiez rapidement les problèmes introduits par les mises à jour. Si vos clients savent que vous êtes en mesure de mettre à jour leurs environnements en douceur, ils sont moins susceptibles de s'y opposer.

• Restauration : envisagez si les clients souhaitent revenir en arrière sur les mises à jour en cas de changement disruptif, et qui déclenche une telle demande de retour en arrière.

Vos besoins

Vous devez également prendre en compte les questions suivantes de votre propre point de vue :

• Contrôler que vous êtes prêt à fournir : Est-il raisonnable pour vos clients d’avoir le contrôle sur le moment où les mises à jour sont appliquées ? Si vous créez une solution utilisée par les grands clients d’entreprise, la réponse peut être oui. Toutefois, si vous créez une solution axée sur le consommateur, il est peu probable que vous accordiez un contrôle sur la façon dont vous mettez à niveau ou utilisez votre solution.

• Versions: Combien de versions de votre solution pouvez-vous maintenir raisonnablement à la fois ? Si vous trouvez un bogue ou une vulnérabilité de sécurité et que vous devez appliquer un correctif logiciel, vous devrez peut-être l’appliquer à toutes les versions actuellement utilisées.

• Conséquences des anciennes versions : Quel est l’impact de laisser les clients tomber trop loin derrière la version actuelle ? Si vous publiez régulièrement de nouvelles fonctionnalités, les anciennes versions deviennent-elles obsolètes rapidement ? En outre, selon votre stratégie de mise à niveau et les types de modifications, vous devrez peut-être gérer des infrastructures distinctes pour chaque version de votre solution. Par conséquent, il peut y avoir des coûts opérationnels et financiers, car vous conservez la prise en charge des versions antérieures.

• Rollback: Votre stratégie de déploiement peut-elle prendre en charge les restaurations vers les versions précédentes ? Voulez-vous activer cette fonctionnalité ?

Trouver un solde

Si vous laissez la cadence de vos mises à jour de service entièrement à la discrétion de vos locataires, ils peuvent choisir de ne jamais mettre à jour. Il est important de vous permettre de mettre à jour votre solution, tout en tenant compte des préoccupations ou contraintes raisonnables que vos clients peuvent avoir. Par exemple, si un client est particulièrement sensible aux mises à jour le vendredi, car c’est le jour le plus chargé de la semaine, déterminez si vous pouvez différer facilement les mises à jour vers lundi sans affecter votre solution.

Une approche qui peut fonctionner correctement consiste à déployer des mises à jour sur une base client par locataire à l’aide de l’une des stratégies de déploiement. Informez vos clients des mises à jour planifiées. Autoriser les clients à refuser temporairement, mais pas définitivement. Mettez une limite raisonnable lorsque vous avez besoin que la mise à jour soit appliquée.

Envisagez de vous donner la possibilité de déployer des correctifs de sécurité ou d'autres correctifs logiciels critiques, avec peu ou pas de préavis. Assurez-vous que les locataires comprennent cette pratique et son importance pour protéger leurs données.

Une autre approche peut être d’autoriser les locataires à lancer leurs propres mises à jour pendant une période qu’ils choisissent. Là encore, vous devez fournir une échéance, à quel moment vous appliquez la mise à jour pour leur compte.

Indépendamment de ce que vous faites, assurez-vous que vous disposez d’un processus de surveillance de l’intégrité de vos locataires, en particulier avant et après l’application des mises à jour. Les incidents de production critiques, également appelés incidents de site en direct, se produisent souvent après les modifications apportées au code ou à la configuration. Par conséquent, il est important de surveiller et de répondre de manière proactive à tous les problèmes afin de conserver la confiance des clients. Pour plus d’informations, consultez Gestion des incidents pour les charges de travail SaaS sur Azure.

Communiquer avec vos clients

La communication claire est essentielle pour renforcer la confiance de vos clients. Il est important d’expliquer les avantages des mises à jour régulières, notamment les nouvelles fonctionnalités, les correctifs de bogues, la résolution des vulnérabilités de sécurité et les améliorations des performances. L’un des avantages d’une solution hébergée dans le cloud moderne est la livraison continue de fonctionnalités et de mises à jour.

Posez-vous les questions suivantes :

• Informerez-vous les clients des mises à jour à venir ?

• Si c’est le cas, demandez-vous implicitement l’autorisation en fournissant un processus d’opt-out et quelles sont les limites relatives à la désactivation ?

• Avez-vous une fenêtre de maintenance planifiée que vous utilisez quand vous appliquez des mises à jour ?

• Que se passe-t-il si vous avez une mise à jour d’urgence, comme un correctif de sécurité critique ? Pouvez-vous forcer les mises à jour dans ces situations ?

• Si vous ne pouvez pas informer de manière proactive le client des mises à jour à venir, pouvez-vous fournir des notifications rétrospectives ? Par exemple, pouvez-vous mettre à jour une page sur votre site web avec la liste des mises à jour que vous avez appliquées ?

• Combien de versions distinctes de votre système conserverez-vous en production ?

Communiquer avec votre équipe de support client

Il est important que votre propre équipe de support technique dispose d’une visibilité complète des mises à jour qui ont été appliquées à l’infrastructure de chaque locataire. Les représentants du support client doivent être en mesure de répondre facilement aux questions suivantes :

• Les mises à jour ont-elles récemment été appliquées à l’infrastructure d’un locataire ou aux composants partagés ?

• Quelle est la nature de ces mises à jour ?

• Quelle était la version précédente ?

• À quelle fréquence les mises à jour sont-elles appliquées à ce locataire ?

Si l’un de vos clients rencontre un problème en raison d’une mise à jour, vous devez vous assurer que votre équipe de support technique dispose des informations nécessaires pour comprendre ce qui a changé.

Stratégies de déploiement pour prendre en charge les mises à jour

Réfléchissez à la façon dont vous déployez des mises à jour sur votre infrastructure. Votre stratégie de mise à jour dépend fortement du modèle de location que vous utilisez. Trois approches courantes pour le déploiement des mises à jour sont des tampons de déploiement, des indicateurs de fonctionnalité et des anneaux de déploiement. Vous pouvez utiliser ces approches indépendamment, ou vous pouvez les combiner pour répondre à des exigences plus complexes.

Dans tous les cas, assurez-vous d’avoir suffisamment de rapports et de visibilité. Vous devez connaître la version de l'infrastructure, du logiciel ou de la fonctionnalité utilisée par chaque locataire, ce vers quoi il est éligible à migrer, ainsi que toutes les données temporelles associées à ces états. Le suivi de ces informations est souvent l’une des responsabilités d’un plan de contrôle.

Modèle d’empreintes de déploiement

De nombreuses applications multilocataire sont bien adaptées au modèle d’empreintes de déploiement. Dans ce modèle, vous déployez plusieurs copies de votre application et d’autres composants. En fonction de vos exigences en matière d’isolation, vous pouvez déployer une empreinte pour chaque locataire ou des empreintes partagés qui exécutent les charges de travail de plusieurs locataires.

Les timbres sont un excellent moyen de fournir une isolation entre les locataires. Elles vous offrent également une certaine flexibilité pour votre processus de mise à jour, car vous pouvez déployer les mises à jour progressivement entre les empreintes sans affecter les autres.

Indicateurs de fonctionnalités

Les indicateurs de fonctionnalité vous permettent d’ajouter des fonctionnalités à votre solution, tout en exposant uniquement cette fonctionnalité à un sous-ensemble de vos clients ou locataires.

Envisagez d’utiliser des indicateurs de fonctionnalité si l’un de ces scénarios s’applique à vous :

• Vous déployez régulièrement des mises à jour, mais vous souhaitez éviter d’afficher de nouvelles fonctionnalités jusqu’à ce qu’elle soit entièrement implémentée.

• Vous souhaitez éviter d’appliquer des modifications de comportement jusqu’à ce qu’un client opte.

Vous pouvez incorporer la prise en charge des indicateurs de fonctionnalité dans votre application en écrivant vous-même du code ou à l’aide d’un service tel qu’Azure App Configuration.

Anneaux de déploiement

Les boucles de déploiement vous permettent de déployer progressivement des mises à jour sur un ensemble de locataires ou d’empreintes de déploiement. Vous pouvez affecter un sous-ensemble de locataires à chaque anneau dans la séquence de déploiement.

Vous pouvez déterminer le nombre d’anneaux à créer et ce que chaque anneau signifie pour votre propre solution. En règle générale, les organisations utilisent les anneaux suivants :

• Canary : Un anneau de canari inclut vos propres locataires de test et vos clients qui souhaitent recevoir des mises à jour aussi vite que possible. Toute personne sur la boucle de canari doit comprendre qu’elle peut recevoir des mises à jour plus fréquentes. Ces mises à jour n'ont peut-être pas fait l'objet d'un processus de validation aussi complet que les mises à jour dans d'autres anneaux.

• L’utilisateur précoce : Un anneau d’adoption précoce contient des locataires légèrement plus risqués, mais toujours prêts à recevoir des mises à jour régulières.

• Utilisateurs: La plupart de vos locataires appartiennent à l’anneau des utilisateurs , qui reçoit des mises à jour moins fréquentes et plus hautement testées.

Versions de l’API

Si votre service expose une API externe, pensez que toutes les mises à jour que vous appliquez peuvent affecter la façon dont les clients ou les partenaires s’intègrent à votre plateforme. En particulier, vous devez être conscient des changements cassants sur vos API. Envisagez d’utiliser une stratégie de contrôle de version d’API pour atténuer le risque de mises à jour de votre API.

Contributeurs

Microsoft gère cet article. Les contributeurs suivants ont écrit cet article.

Auteur principal :

• John Downs | Ingénieur logiciel principal, modèles Azure & Pratiques

Autres contributeurs :

• Chad Kittel | Ingénieur logiciel principal, modèles Azure & Pratiques
• Daniel Scott-Raynsford | Stratège de la technologie partenaire
• Arsenal Vladimirskiy | Ingénieur client principal, FastTrack pour Azure

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Ressource associée

• Mapper des requêtes à des locataires dans une solution multilocataire