Aller au contenu

Workflow de réalignement zones hibernées#

Important

Ce workflow est une ébauche.

Nous avons établi ce workflow dans le cadre du ticket CAASSUPV-10 afin de permettre de maintenir les zones hibernées à jour, mais celui-ci est overkill pour le moment, car il n'y a qu'une seule zone hibernée à maintenir à jour actuellement (le 18/01/2022).

Les zones hibernées sont réveillées tous les mardis pour être réalignées.

Un OPS dédié à l'orchestration des opérations de réalignement est choisi chaque semaine. Cela est indiqué dans le calendrier supervision.

Prérequis : Communication aux clients#

  • Qui ? L'équipe support.
  • Quand ? Une seule fois, pour chaque client ayant des cluster hibernés.

Le mail suivant sera envoyé à tous les clients ayant au moins un cluster hiberné :

Objet : [Caascad] Mise à jour clusters hibernés

Cher Client,

Vous disposez d'un ou plusieurs clusters Caascad en état hiberné. Afin qu'ils puissent être maintenus en conditions opérationnelles et qu'ils bénéficient de toutes les évolutions Caascad, nous mettons en place une mise à jour hebdomadaire des clusters hibernés.

A compter de mardi XX/XX/XXX, vos clusters hibernés seront allumés par les équipes Caascad tous les mardis à XXh. Nous effecturons les opérations de maintenance nécessaires et les hibernerons de nouveau dès la fin de nos actions.

Si vous préférez que vos clusters hibernés restent allumés à la fin de nos opérations de façon systématique ou ponctuelle, vous pouvez nous l'indiquer par mail en précisant le nom du(des) cluster(s) concerné(s). Dans le cas contraire, vos clusters seront remis en état hiberné.

Nous restons à votre disposition pour toute information complémentaire.

Cordialement,

l'Equipe Caascad

Les clients indiqueront par mail s'ils souhaitent qu'on laisse allumés leurs clusters après nos opérations de réalignement qui ont lieu chaque semaine.

Etape 1 : Création CAASCHR#

  • Qui ? La personne qui crée un CAASCHR pour des zones clientes non hibernées.
  • Quand ? Au moment de la création dudit CAASCHR.

Un ticket CAASCHR supplémentaire devra être créé pour les zones hibernées lors de la création d'un CAASCHR pour déployer sur les zones clientes.

  • La Date of Change à indiquer devra être le mardi prochain à 9h, mais l'heure précise sera suscpetible d'être ajustée lors de la réunion d'orchestration décrite ci-dessous.
  • Il n'y aura plus besoin de créer de ticket SUPIT de réveil des clusters hibernés.
  • Les changes en zone cloud qui dépendent du change en zone cliente pourront être déployés au même moment.

Etape 2 : Validation CAASCHR#

  • Qui ? L'OPS dont c'est le créneau de supervision.
  • Quand ? Au moment où les CAASCHR sont mis en To Review, avant lundi 17h.

Les OPS valident ces CAASCHR commes les autres.

Etape 3 : Réunion d'orchestration#

  • Qui ? Les intervenants du réalignement dont l'OPS qui orchestre.
  • Quand ? Le lundi à partir de 17h.

L'OPS dédié à l'orchestration des opérations de réalignement devra :

  1. créer un CAASCHR chapeau avec :
    • tous les CAASCHR de réalignement du mardi en lien de ce ticket,
    • titre du CAASCHR : “réalignement zone hibernées DD/MM/YYYY”,
    • vérification que les CAASCHR de réalignement sont tous validés ;
  2. définir l'abre de dépendance entre les différents CAASCHR de réalignement et l'indiquer dans le ticket chapeau ;
  3. publier l'arbre de dépendance sur Rocket.Chat ;
  4. faire un jitsi avec les intervenant pour organiser et gérer les conflits.

Etape 4 : Réveil des clusters#

  • Qui ? L'équipe support.
  • Quand ? Au début de l'opération.

Les clusters clients hibernés seront tous réveillés le mardi à 9h si au moins une opération de réalignement est prévue ce jour.

Etape 5 : Réalignement#

  • Qui ? Tous les intervenants du réalignement dont l'OPS qui orchestre.
  • Quand ? Dès que les clusters sont réveillés.

Les personnes qui effectuent le réalignement sont responsable de leur périmètre. L’OPS n’est pas là pour assister à ce réalignement, mais seulement pour orchestrer.

Les changes devront être appliqués les uns à la suite des autres le plus rapidement possible (comme prévu lors de la réunion de la veille) et en parallèle lorsque cela est possible.

Une war room sera mise en place pour orchestrer les déploiements de manière efficace.

Etape 6 : Validation globale des MAJ#

  • Qui ? L'OPS qui orchestre (avec l'aide des autres intervenants).
  • Quand ? Immédiatement après la fin de l'ensemble des réalignements.

Valider que tout est bon :

  1. trackbone plan -z <zone_hibernée> --runners 5 --detailed-exitcode ;
  2. lancer les tests fonctionnels des zones hibernées et de leurs zones cloud respectives.

S’il y a des différences avec le résultat souhaité :

  • expliquer les différences ;
  • si un CAASCHR a mal été réappliqué, on le réapplique (et on note l’opération en commentaire dudit CAASCHR) ;
  • s’il faut réaligner alors que ce n’était pas prévu, on effectue ce réalignement et on le documente en commentaire du CAASCHR chapeau ;
  • en cas d’incident (impossibilité à réaligner), il faut créer un CAASINC et remettre les clusters dans un état stable.

A la fin, fermer le CAASCHR chapeau.

Etape 7 : Réhibernation des clusters des clusters#

  • Qui ? L'équipe support.
  • Quand ? Après la fermeture du CAASCHR chapeau.

Réhiberner les clusters clients, sauf si les clients souhaitent qu'on les laisses allumés (cf. Etape 0 : Communication aux clients).

Etape 8 : Préparation de la semaine suivante#

  • Qui ? L'OPS qui orchestre la semaine en cours.
  • Quand ? Après la fermeture du CAASCHR chapeau.

Vérifier :

  • qu’il y a bien un OPS dans le calendrier pour la semaine suivante (lundi après-midi + mardi) ;
  • que les créneaux de supervision de lundi après-midi et mardi (toute la journée) ne sont pas occupés par l’OPS qui gère l’opération de réalignement.

Proposition : désigner l’OPS qui a pris le créneau tournant du lundi après-midi la semaine précédant l’opération.