Aller au contenu

Gestion du changement (CAASCHR)#

Version courte

Voir la section : Quels sont les points de contrôle du format du CAASCHR ?

Principe des changements#

Pourquoi organiser une gestion du changement ?#

  • Visibilité des risques et impacts.
  • Communication auprès des équipes et des clients.
  • Traçabilité des évolutions.

Quand doit-on faire une déclaration de demande de changement ?#

En cas de changement, temporaire ou permanent, pouvant impacter la production ou le staging (voir les lignes des zones Caascad et NGOT).

Important

Uniquement en cas d'intervention immédiate sur incident, un ticket d'incident (CAASINC) pourra se substituer à un ticket de changement (CAASCHR). Les opérations correctrices effectuées seront indiquées en commentaire du CAASINC.

Exemples de changements courants :

  • Création/suppression/mise à jour de composant ;
  • Modification de configuration, même sans effet apparent ;
  • Résolution différée d'incident ;
  • Réalisation d'une demande d'un client.

Création d'une demande de changement#

Comment créer une demande de changement ?#

Une demande de changement se fait par le biais d'un ticket CAASCHR dans Jira.

Quel type de changement créer ?#

Il existe deux types de changements :

  • les Changements Normaux ;
  • les Changements Standards.

Un Changement Standard est un changement qui respecte les critères suivants : faible risque, faible impact, prédéfini, pré-existant. Il permet d'accélerer le processus avec une phase de validation plus légère. Il faut suivre des procédures spécifiques.

Lorsque les critères d'un Changement Standard ne sont pas remplis, il s'agit d'un Changement Normal, ce qui représente la large majorité des changements.

Quelles sont les règles à respecter ?#

Un CAASCHR doit :

Important

Un CAASCHR de production fait l'objet de contraintes supplémentaires.

  • Il ne peut avoir lieu ni le vendredi ni une veille de jour férié, sauf exception.
  • Il doit être précédé d'un changement sur staging afin de valider sa viabilité.
    • Ils ne peuvent être soumis en même temps, la réussite du CAASCHR de staging étant un pré-requis du ticket de production.
    • Ces deux changements doivent être espacés d'au moins 24h (sauf Changement Standard).

Toute exception nécessaire devra être vue avec les OPS. Cependant, pour certaines particularités récurrentes, il existe une section décrivant comment gérer un cas d'exception.

Comment remplir une demande de changement ?#

jira UI screenshot

Projet#

Caascad Change Request (CAASCHR)

Type de ticket#

Indiquer Change Caascad ou, le cas échéant, Change Standard.

Caascad Product#

Le nom du produit concerné par le changement.

Résumé#

[STG] ou [PRD], suivi d'une espace, suivi d'un résumé simple du ticket.

Rapporteur/Reporter#

Personne qui rédige le CAASCHR.

Responsable/Assignee#

Personne réalisant l'opération et responsable de son déroulement.

Validateur#

Personne qui valide la planification du CAASCHR.

Warning

Ce champ doit être vide.

Date of Change#

Proposition d'horaire de réalisation du changement.

Info

L'opération doit commencer en début d'heure ou de demi-heure, entre 8h et 17h. Elle doit être terminée avant 18h.

Info

En fonction du planning, la personne qui valide le CAASCHR sera potentiellement amenée à refuser cet horaire.

Duration#

Info

Il doit s'agir d'un multiple de 30 minutes.

La durée de l'opération comprend :

  • le déroulement de la procédure de mise en production (ou staging) ;
  • la vérification des résultats ;
  • le temps d'un retour arrière éventuel.

Le format à suivre est : 30m, 1h, 1h30, 2h, ou 2h30.

Important

Pour les opérations de 3h ou plus, il devient nécessaire de contacter les OPS pour voir :

  • si le changement peut être opéré tel quel ;
  • si un découpage en plusieurs CAASCHR de l'opération est préférable ;
  • si un plan d'action spécifique est à définir.
Customer impact#

Deux éléments sont à prendre en compte lors de la qualification de l'impact :

  • le workload du client ;
  • son accès aux services Caascad.

Les options proposées résultent des règles de communication avec le client et sont fonction de la durée de l'impact et de son périmètre. Elles déterminent la nécessité d'un ticket SUPIT lié à l'opération et affecté à l'équipe Support.

Les choix possibles sont les suivants, avec le délai de prévenance rappelé entre parenthèses.

  • Workload <1m AND Caascad Services <5m (-)
  • Workload <15m AND Caascad Services <30m (48h)
  • Workload 15m+ OR Caascad Services 30m+ (7d)

Info

La valeur Aucune ou None n'est pas acceptée. Lorsque l'impact est mineur, il faut choisir la première option.

Descriptif#

Voir la section dédiée : Comment remplir le descriptif ?

Pièce jointe#

Peut servir à joindre un fichier si besoin.

Tickets liés & Tickets#

Indiquer les tickets liés et leur relation à ce CAASCHR.

  • le ticket PF définissant le besoin à l'origine de ce changement ;
  • le(s) ticket(s) CAASINC pouvant expliquer la création de ce CAASCHR.

Si l'opération concerne la production :

  • le ticket SUPIT de communication si nécessaire, voir : Change/Incident - Communication Client ;
  • le ticket SUPIT de réveil des clusters hibernés si nécessaire, voir : Hibernation/Wake Cluster Client ;
  • Le CAASCHR de l'opération correspondante en staging (à l'état Clos et avec un commentaire de vérification). Pour un changement non reproductible, l'absence de CAASCHR de staging sera justifiée en commentaire du ticket.
Zones#

Ignorer ce champ.

Comment remplir le descriptif ?#

Le champ description contient la procédure détaillée qui sera suivie par le Responsable/Assignee le jour de l'opération. Cette procédure doit comprendre :

  • la liste exhaustive et explicite des zones, séparées par des espaces. Cette liste définit le périmètre exact de l'opération ;
  • une courte explication du changement et de son but ;
  • les actions de mise en silence des alarmes ;
  • le mode opératoire, indiquant clairement :
    • l'ensemble des commandes nécessaires à la réalisation de l'opération (en facilitant le copier/coller),
    • la ou les cibles de chacune des actions (zone, cluster, namespace, vm, etc.). Cette liste ne doit pas être dynamique,
    • les liens vers les Merge Requests au moment où celles-ci sont nécessaires. Elles doivent avoir été validées par une autre personne en maîtrise du sujet via un approval dans l'interface ;
  • une vérification et validation complète du résultat de l'opération :
    • elle est spécifique à chaque CAASCHR, c'est au Rapporteur/Reporter de définir la procédure adéquate,
    • elle permet de vérifier que les changements prévus ont bien été effectués,
    • elle doit porter sur toutes les cibles du déploiement,
    • elle prouve a posteriori que le changement a bien été réalisé,
    • elle peut être effectuée par la CI. Dans ce cas, il faut indiquer dans le CAASCHR l'ensemble des points contrôlés automatiquement.

Un bon mode opératoire doit pouvoir être suivi par une personne autre que le Responsable/Assignee !

Liens Jira#

Info

Le formulaire de création des CAASCHR ne permet pas d'ajouter de liens. Il faut éditer le ticket à postériori.

Ajouter, dans la section des liens Jira :

  • toutes les Merge Requests mentionnées dans le descriptif ;
  • autres liens "web".

Merge Requests#

Les Merge Requests nécessaires à la réalisation du changement doivent être toutes mentionnées en lien du CAASCHR.

Elles doivent avoir été validées par une autre personne en maîtrise du sujet via un approval dans l'interface GitLab. Il ne doit y avoir aucune action push (commit, rebase...) postérieure à ce dernier dans la chronologie des commentaires.

Si la Merge Request est modifiée, une revalidation est nécessaire, soit par une autre personne, soit par la même qui devra révoquer son approval pour revalider.

Comment gérer un cas d'exception ?#

Warning

Justifier de l'exception dans la description du ticket.

Confirmer la faisabilité avec les OPS.

CAASCHR en production le vendredi ou veille de jour fériés#

Cela s'applique si :

  • le client est à l'origine de la demande (présence d'un ticket CW) ;
  • le périmètre de l'opération est limité à ses zones (zone d'administration et/ou zones clientes associées) ;
  • il n'a pas explicitement interdit d'intervention à cette date ;
  • il s'agit d'un changement standard (voir la liste).

Dans ce cas :

  • indiquer le ticket CW en lien Jira du CAASCHR.

Lors de la réalisation :

  • informer l'équipe Support pour le retour client en fin d'opération.

CAASCHR étalé sur plusieurs jours#

Cela s'applique si :

  • l'opération forme un ensemble cohérent d'actions à mener successivement ;
  • elle ne peut être réalisée sur une durée classique ;
  • les actions ne peuvent pas être trop espacées dans le temps.

Dans ce cas :

  • échanger avec les OPS ;
  • bloquer les autres opérations si nécessaire.

Lors de la réalisation :

  • indiquer régulièrement en commentaire le statut de l'avancement.

Opération en heures non ouvrées (HNO)#

Cela s'applique si :

  • l'opération est impactante et il est préférable de la réaliser en heures non ouvrées.

Dans ce cas :

  • une validation du manager est obligatoire en commentaire du CAASCHR ;
  • échanger avec les OPS (en particulier pour en informer les personnes d'astreinte).

Changement de code sans modification sur les environnements#

Cela s'applique si :

  • des changements de code ont lieu (refactorisation...) mais ne provoquent pas de modification sur les environnements.

Dans ce cas :

  • il est possible de déployer sur Staging et Production avec un seul CAASCHR ;
  • le titre du CAASCHR devra commencer par [STG+PRD] ;
  • la description mentionnera explicitement que les changements ne provoquent pas de modification sur les environnements.

Ajout d'un utilisateur Caascad#

Cela s'applique si :

  • un nouvel utilisateur rejoint Caascad, son compte doit être ajouté dans le fichier users.cue.

Dans ce cas :

  • il faut créer une MR portant la modification du fichier users.cue ;
  • la validation de la MR par un autre membre de l'équipe Supervision est nécessaire ;
  • la MR est en lien du ticket Support de création du compte ;
  • la MR mentionne ce ticket dans son titre ;
  • le processus est le suivant :
    • un trackbone apply est lancé via un commentaire dans la MR Gitlab,
    • la MR est mergée après le déploiement ;
  • il n'y a pas besoin de CAASCHR.

Des outils sont-ils utilisables pour générer un CAASCHR ?#

Il est possible d'utiliser des templates ou tout autre solution automatisée pour créer des tickets. Cependant ils doivent toujours respecter les règles de validation décrites ci-dessous.

Comment soumettre une demande de changement ?#

Une fois la vérification du respect des critères de Validation d'un changement effectuée (hors planification de la date de l'opération), le ticket peut-être passé à l'état To Review.

Aucune autre action n'est nécessaire.

Validation d'un changement#

Qui est habilité à valider un changement ?#

Les personnes habilitées à valider un changement dépend de la nature du changement :

  • Changements Normaux : seul un OPS est habilité à le valider ;
  • Changements Standards : un membre de l'équipe.

Le Rapporteur/Reporter n'est JAMAIS habilité à valider son propre ticket.

Faut-il notifier le passage en Review d'un ticket ?#

Non, un message sera automatiquement publié lors du changement d'état dans Jira.

Dans quel ordre sont validés les changements ?#

Les tickets en To Review se retrouvent classés dans le Dashboard CAASCHR par date de dernière modification, et sont vérifiés par l'OPS dans cet ordre.

Tout changement ultérieur d'un CAASCHR le fait redescendre dans la pile. Si le ticket est valide mais nécessite un changement de date à la demande de l'OPS, il restera bien entendu prioritaire dans la validation.

Quels sont les points de contrôle du format du CAASCHR ?#

  • Présence de [STG] ou [PRD] dans le titre.
  • Titre explicite.
  • Vérification de la cohérence du Responsable/Assignee et du Rapporteur/Reporter.
  • Le type est Change Caascad sauf si les critères d'un changement standard sont réunis.
  • Le contenu du champs Customer impact :
  • Liste exhaustive de toutes les zones concernées par l'opération.
  • Présence des commandes ou procédures à exécuter :
    • pas de liste d'environnements dynamique dans celles-ci.
  • Présence de la méthode de confirmation du résultat de l'opération :
    • en cas de vérification par la CI, les points contrôlés doivent être listés.
  • Pour les opérations en production :
    • lien vers le CAASCHR de staging, à l'état Clos, incluant un commentaire de vérification. La réalisation des deux CAASCHR doit être espacée d'au moins 24h (sauf s'il s'agit d'un Changement Standard),
    • lien vers le ticket SUPIT de réveil des clusters hibernés si nécessaire, voir : Hibernation/Wake Cluster Client.
  • Merge Requests en lien du ticket :
    • la CI/CD peut être rouge. C'est à l'équipe technique de juger de sa pertinence,
    • présence d'un approval,
    • pas de conflit visible au moment de la validation.

Quels sont les points supplémentaires à traiter par le validateur ?#

  • Vérification de la date :
    • les horaires sont respectés (8h-17h, fin avant 18h),
    • les mises en production sont autorisées ce jour,
    • il n'y a pas d'autre opération planifiée au même moment (Dashboard CAASCHR) sur le même périmètre ou attribuée au même Responsable/Assignee.
  • Remplissage du champ Validateur.

Que se passe-t-il si la date ne convient pas ?#

Si la date proposée n'est pas acceptée, le validateur revient vers le Responsable/Assignee pour discuter d'une nouvelle option satisfaisante pour les deux parties.

Que se passe-t-il si le ticket n'est pas valide ?#

Le validateur ajoute un commentaire dans le ticket indiquant les points de validation non respectés.

En fonction de la nature des corrections à effectuer, le validateur peut décider de repasser le ticket en Open.

Le Rapporteur/Reporter effectue les corrections demandées puis passe de nouveau le ticket en To Review.

Modification d'un changement validé#

Comment modifier ou replanifier un changement validé ?#

Un CAASCHR Validated peut au besoin et à tout moment être repositionné à l'état Open. Il pourra dès lors être corrigé, replanifié, etc.

Warning

Il devra obligatoirement faire l'objet d'une nouvelle validation.

Comment gérer un ticket expiré ?#

Le Dashboard CAASCHR mentionne les tickets expirés. Il s'agit de ceux qui sont à l'état Validated ou In Progress et qui ont démarré la veille ou avant.

Pour traiter ce cas :

Réalisation du changement#

Quels sont les éléments à ne pas oublier avant de démarrer ?#

Important

Il ne doit pas y avoir d'incident en cours !

Une opération réalisée dans un environnement dégradé pourrait s'avérer irréalisable. Il y a un risque d’aggraver les problèmes (sur-incident). Le bruit généré pourrait ralentir l'identification de la source des erreurs.

Une vérification de l'état initial de l'environnement est souhaitable, en fonction du périmètre du changement : logs, metrics, alerts... Si une alerte est présente avant toute action, elle pourra être indiquée en commentaire.

Pour un changement en production, aucun problème ne doit être apparu entre temps suite au CAASCHR de staging correspondant.

Vérifier que les Merge Requests peuvent être mergées lors de l'opération (pas de conflits). Si un rebase est nécessaire, il faudra :

  • le préparer avant l'opération ;
  • faire revalider la Merge Request, soit par la même personne qui devra révoquer son approval pour revalider, soit par une autre personne en maîtrise du sujet ;
  • mentionner ce rebase dans un commentaire du CAASCHR. Il n'est pas nécessaire de faire revalider le CAASCHR pour un rebase simple.

Comment se déroule l'opération ?#

Le ticket doit être passé à In Progress.

Les alarmes et le salon #supervision de Rocket.Chat doivent être surveillés pendant l'opération. En cas de doute les actions doivent être suspendues et les OPS contactés.

La procédure décrite dans le CAASCHR doit être suivie :

  • silence des alarmes ;
  • lancement des commandes ;
  • merge du code lorsqu'approprié ;
  • vérifications.

Warning

Tout imprévu doit être mentionné en commentaire du ticket.

Que faire si la procédure doit être adaptée lors de sa réalisation ?#

La procédure peut être éditée mais la version validée doit être conservée. Il est conseillé de barrer les anciennes lignes avant d'ajouter les nouvelles et d'expliquer la correction.

Fin du changement#

Quels sont les points à vérifier ?#

  • Les résultats des vérifications et de l'opération dans sa globalité sont spécifiés en commentaire du ticket.
  • Les silences ont été supprimés, il n'y a pas de nouvelle alerte.
  • Il n'y a pas d'erreur dans les logs.
  • Les graphs ne montrent rien d'anormal suite à l'opération.

Comment indiquer la fin de l'opération ?#

Lorsque l'opération est terminée, le ticket doit être Clos, un motif de Résolution/Resolution doit être sélectionné :

DoneL'opération s'est déroulée correctement dans son intégralité.
IncompleteL'opération s'est déroulée correctement, mais pas dans son intégralité.
RollbackedL'opération ne s'est pas déroulée correctement mais il a été possible de revenir à l'état initial.
FailedL'opération ne s'est pas déroulée correctement et l'environnement n'est à ni l'état cible ni à l'état initial.

Comment faire si un changement dure plus longtemps que prévu ?#

Info

La durée d'un changement doit inclure le temps nécessaire à l'analyse de problèmes éventuels ainsi qu'au rollback.

Le réalisateur de l'opération doit tout faire pour tenir le délai. Lorsqu'il se rend compte que ce ne sera pas le cas :

  • s'il est possible d'interrompre le changement sans impact de service, l'opération doit être arrêtée. Se référer à la section Comment gérer une opération partiellement réalisée. ;
  • dans tous les autres cas, les OPS doivent être avertis. Si l'interruption du changement n'est pas envisageable, il faudra choisir l'option la moins impactante entre finir le déploiement et le rollback.

Lorsqu'un incident survient, qu'il soit causé ou non par le changement, la suite des opérations doit être coordonnée par les OPS.

Pour clore le CAASCHR en échec, se référer à la section : Comment gérer l'échec d'une opération ?

Comment gérer une opération partiellement réalisée ?#

L'opération s'est bien déroulée mais n'a pas pu être intégralement terminée.

Il faut indiquer clairement en commentaire, selon le cas :

  • les étapes réalisées et celles qui ne l'ont pas été ;
  • les environnements ou composants qui sont à l'état souhaité et ceux qui ne le sont pas.

Bien que l'état cible ne soit pas intégralement atteint, le ticket doit être Clos avec pour motif de Résolution/Resolution : Incomplete.

Pour pouvoir reprendre l'opération, un nouveau CAASCHR doit être créé. Il s'agit d'un nouveau changement mais avec les étapes restantes ou un périmètre moins large que le précédent.

Comment gérer l'échec d'une opération ?#

Important

Si l'échec a un impact immédiat et qu'une correction urgente est nécessaire, un ticket d'incident CAASINC doit être créé.

Il faut indiquer clairement en commentaire du CAASCHR :

  • l'état des environnements ou composants ;
  • un résumé de la raison de l'échec.

Si un CAASINC est relatif au CAASCHR, les deux doivent être liés.

Bien que l'état cible ne soit pas atteint, le ticket doit être Clos avec pour motif de Résolution/Resolution : Failed ou Rollbacked.

Si l'opération doit toujours être réalisée, un autre CAASCHR doit être créé. Il s'agit d'un nouveau changement.

Cycle de vie de la demande de changement#

Quelles sont les étapes d'un CAASCHR ?#

Open#

Que signifie cet état ?Le CAASCHR est en cours cours de rédaction
Qui travaille dessus ?Le Rapporteur/Reporter
Qui va le passer dans l'état suivant ?Le Rapporteur/Reporter

To Review#

Que signifie cet état ?Le CAASCHR est en attente ou en cours de validation
Qui travaille dessus ?Une personne habilitée à valider, autre que le Rapporteur/Reporter ou le Responsable/Assignee
Qui va le passer dans l'état suivant ?Une personne habilité à valider, autre que le Rapporteur/Reporter ou le Responsable/Assignee

Validated#

Que signifie cet état ?Le changement est prêt à être réalisé dans le créneau horaire prévu
Qui travaille dessus ?-
Qui va le passer dans l'état suivant ?Le Responsable/Assignee

In Progress#

Que signifie cet état ?Le changement est en cours de réalisation
Qui travaille dessus ? Le Responsable/Assignee
Qui va le passer dans l'état suivant ?Le Responsable/Assignee

Closed#

Que signifie cet état ?Le changement est terminé. Les vérifications ont eu lieu et sont indiquées en commentaire du CAASCHR
Qui travaille dessus ?-
Qui va le passer dans l'état suivant ?-

Quels autres états peut avoir un CAASCHR ?#

Cancelled#

Que signifie cet état ?Le CAASCHR est annulé
Qui travaille dessus ?-
Qui va le passer dans l'état suivant ?-

Que faire si le changement d'état a été oublié ?#

  • L'opération n'a pas eu lieu.
    • Si l'opération est annulée, mettre le CAASCHR à l'état Cancelled.
    • Si une nouvelle date de réalisation est immédiatement proposée, modifier le champ "Date of Change" et mettre le ticket à l'état To Review.
    • Sinon mettre le ticket à l'état Open.
  • L'opération suit son cours ou est finie.

Que faire si un changement d'état a eu lieu par erreur ?#

Il faut le remettre au plus vite dans l'état souhaité.

  • Les contraintes de changement d'état peuvent être ignorées.
  • Si nécessaire, plusieurs transitions peuvent se succéder.
  • Ajouter un commentaire dans le ticket pour indiquer l'erreur de manipulation.