Notifications / annonces
Le bon déroulement d’un lancement dépend en partie du fait que toutes les parties prenantes soient au courant du lancement imminent et comprennent le plan de lancement, ainsi que leur rôle et leurs responsabilités. En plus d’aviser les équipes qui y participeront activement, il peut aussi être utile d’aviser celles qui pourraient devoir intervenir si quelque chose tourne mal. Avoir quelqu’un de garde pendant un lancement peut accélérer la réponse en cas de problème. Assurez-vous de repérer et d’aviser toute équipe qui pourrait avoir à répondre aux questions des clients, y compris sur les médias sociaux.Parties à aviser
- Clients
- Partenaires d’affaires, le cas échéant
- Équipe(s) d’application touchée(s) par le lancement
- Équipes de soutien
- Équipes réseau (changements au réseau, de garde, en cas de problèmes)
- Équipes de sécurité (de garde, en cas de problèmes)
- Équipes marketing (prêtes pour les annonces et à réagir aux problèmes)
- Équipes des médias sociaux (prêtes à surveiller les médias sociaux et à intervenir)
- Équipes de vente (prêtes à répondre aux questions des clients)
- Équipes de succès client (prêtes à répondre aux questions des clients)
Plan de notification
Votre plan de notification devrait inclure des éléments comme l’ cible, les principaux points à communiquer à cette audience, le contenu du message, le plan de diffusion de la notification et la façon de tester le message. Voici une liste des éléments à inclure dans le plan :- Audience cible (tenir compte des audiences internes et externes)
- Message
- Moment d’envoi
- Dépendances
- Responsables (qui l’enverra)
- Mécanisme (comment ce sera communiqué)
- Message de test et livraison (s’il y a lieu — tester pour s’assurer que les notifications sont bien envoyées)
Distribution des notifications
Une pratique courante consiste à envoyer les notifications par lots afin d’étaler la charge initiale et de limiter l’ampleur de la confusion en cas de bogues imprévus. Il est plus facile de corriger les problèmes avec un petit groupe que lors d’un lancement à grande échelle.- Une approche consiste à commencer par un lot de notifications relativement petit et, si aucun problème n’est détecté, à augmenter graduellement la taille des lots.
- Vous pouvez aussi envoyer les lots selon un horaire échelonné à l’échelle mondiale afin de répartir la charge sur le système et de faire en sorte que les notifications arrivent à un moment optimal dans chaque fuseau horaire, ce qui augmente les chances que les messages soient lus.
- Vous pouvez faire un lancement progressif auprès d’une partie des utilisateurs, par exemple certains clients, certaines régions ou un autre regroupement pertinent pour votre application.
Fenêtres d’indisponibilité (au besoin)
Certaines organisations exigent une demande officielle pour prévoir une fenêtre d’indisponibilité si une interruption de service ou un temps d’arrêt est nécessaire dans le cadre d’une mise en production. Si c’est le cas dans votre organisation, assurez-vous de déterminer si un temps d’arrêt est nécessaire pour le basculement ou la mise en production (ou pour d’autres systèmes connexes) et de soumettre à l’avance les demandes d’interruption ou de changement requises, en respectant tout délai de préavis applicable.Plan de basculement (au besoin)
Certaines mises en production impliquent le passage d’une solution existante à une nouvelle solution. Si votre projet correspond à ce scénario, assurez-vous de recenser tout ce qui doit être fait, ainsi que les dépendances, le responsable de chaque tâche et l’échéancier nécessaire. Vous pourriez aussi prévoir des remplaçants pour tous les rôles importants ou dans chaque région, au cas où quelqu’un tomberait malade ou serait autrement indisponible de façon imprévue. Voici une liste de vérification des éléments à prendre en compte dans le plan de basculement :- Avez-vous documenté le plan de basculement et le plan de retour arrière, au besoin ?
- Faut-il faire des sauvegardes avant le changement ?
- Des changements préparatoires aux données sont-ils requis ?
- Des enregistrements DNS doivent-ils être modifiés ?
- Des changements au pare-feu sont-ils nécessaires ?
- De nouvelles cibles de monitoring sont-elles nécessaires ?
- Y a-t-il des logiciels à déployer ?
Critères de go / no-go
Dans l’ensemble de votre plan de lancement, il est utile d’établir des critères de go/no-go et de discuter à l’avance des types de problèmes qui pourraient survenir, de ceux qui pourraient être réglés et de ceux qui exigeraient un retour en arrière. Un plan de lancement peut prévoir des points de suivi périodiques, avec des critères précisant ce qu’il faut évaluer à chaque étape et combien de temps un problème peut demeurer non résolu. Pour chaque étape du lancement, il est utile de définir des critères de succès indiquant que le lancement progresse comme prévu et peut se poursuivre. Voici quelques exemples de critères possibles :- Croissance des inscriptions d’utilisateurs avec un minimum d’erreurs
- Connexions des utilisateurs au rythme prévu, avec un minimum d’erreurs
- Problèmes de soutien signalés sous un certain seuil
- Aucun problème relevé pouvant entraîner une corruption des données
- Pourcentage élevé d’inscriptions ou de connexions d’utilisateurs entraînant des erreurs qui ne peuvent pas être résolues rapidement
- Nombre élevé de problèmes de soutien qui ne peuvent pas être résolus rapidement
- Situation relevée pouvant entraîner une corruption des données
- Découverte d’un problème de sécurité grave
Retour arrière
Il est toujours prudent d’avoir un plan pour effectuer un retour arrière ou annuler un lancement, au cas où surviendrait un imprévu impossible à résoudre. Passer en revue le plan de lancement pour chaque étape qui implique un changement peut aider à cerner les tâches ou les modifications nécessaires pour annuler un lancement ou un basculement. Le plan de retour arrière doit inclure les étapes à suivre, leur ordre, le temps prévu pour chacune et la personne responsable. Comprendre le temps cumulatif nécessaire pour revenir en arrière peut aider à déterminer le moment de la décision finale de go/no-go afin de respecter toute fenêtre d’indisponibilité requise. Si des données sont migrées ou modifiées pour le lancement, le plan doit préciser comment les rétablir, au besoin. Le rétablissement peut exiger l’exécution de scripts pour annuler des changements opérationnels ou la restauration d’un stockage de données à partir d’une sauvegarde effectuée avant le début du processus de lancement. Il faut aussi prévoir le cas où certaines données sont saisies dans un nouveau système avant qu’il faille effectuer un retour arrière. Ces données / transactions devront-elles être abandonnées lors du retour arrière, ou aurez-vous un moyen de les consigner et de les reporter ailleurs afin qu’elles ne soient pas perdues? Si la résolution des problèmes ou le processus de retour arrière risque de prendre plus d’un quart de travail, vous voudrez vous assurer qu’une personne principale et peut-être une personne de relève sont disponibles et prêtes à gérer la situation pendant chaque quart de travail. Si un problème exige une intervention prolongée, bien au-delà d’un seul quart, il y a des limites au temps pendant lequel les gens peuvent raisonnablement fonctionner sans pause. Il peut être utile de prévoir des ressources pour une intervention de type follow-the-sun, au besoin.Personnes-ressources de garde
À l’approche du jour du lancement, il est judicieux de déterminer toutes les personnes-ressources qui pourraient être nécessaires pour le dépannage ou la résolution de problèmes, et de leur demander d’être de garde et prêtes à aider au besoin. La personne responsable du lancement devrait avoir les coordonnées de chaque personne figurant sur la liste de garde afin d’accélérer les communications. S’il y a une « salle de lancement » physique ou virtuelle, les personnes de garde devraient savoir où elle se trouve et être prêtes à s’y joindre au besoin. Le fait d’avoir une salle centrale ou une vidéoconférence déjà prête peut accélérer les communications et le dépannage entre toutes les parties si un problème survient.Critères de succès
La préparation d’un lancement réussi demande beaucoup de planification, mais saurez-vous comment en évaluer les résultats? Si vous définissez des critères de succès avant le lancement, vous pourrez déterminer ce qu’il faut surveiller et si une surveillance ou des vérifications supplémentaires doivent être mises en place pour l’évaluer. Par exemple, si l’un des critères de succès est le nombre d’inscriptions ou de connexions, avez-vous un moyen d’en faire le suivi, et a-t-il été testé pour en assurer l’exactitude? Vous voudrez disposer de statistiques pour pouvoir démontrer le succès de votre lancement. Vous ne voulez pas découvrir après le lancement que vous n’avez recueilli aucune donnée pour mesurer tout le travail acharné que votre équipe y a consacré.Plan des risques et mesures d’atténuation
Ce n’est pas très agréable de penser à ce qui pourrait mal tourner, mais s’il arrive quoi que ce soit, vous serez bien content de l’avoir fait, car avoir un plan peut accélérer l’intervention. Voici quelques exemples de situations à prévoir :- Bogue dans l’application
- Incompatibilité de l’application avec les paramètres du navigateur de l’utilisateur
- Panne ou interruption du réseau
- Attaque par déni de service (DoS)
- Défaillance de l’environnement d’hébergement
- Problèmes de charge ou de capacité
- Problèmes de données ou de corruption
- Vulnérabilité de sécurité découverte