Aller au contenu

Étude du Workflow du Changement#

Introduction#

Cette page représente un historique des sujets étudiés lors de la rédaction et de la maintenance du workflow du changement.

De 2019 à 2022, cet historique est non classé et non daté car nous n'avons pas pensé à le faire lors de nos prises de notes. De plus, bien que tous les points aient été traités, la solution n'a pas été systématiquement notée.

04/01/2024#

Changements standards#

Ajout d'un critère de vérification sur le type de changement.

11/12/2023#

Changements standards#

Les CAASCHR peuvent prendre le type "Changement Standard".

25/07/2023#

Changements standards#

La documentation prend en compte que l'on peut réaliser des changements standards.

03/03/2023#

MR en Draft à cause de dépendance#

Lors de la validation d'un CAASCHR, certaines MR en lien du ticket Jira ne peuvent pas être mergées car elles sont en draft. Pourtant, cela peut être justifié, par exemple pour le déploiement d'appli qui nécessite un run RDS ou S3 avant (donc si run avant opé -> KO).

Solution apportée : dans les points de contrôle, distinction entre la notion de "pas de conflits" et de "possibilité de merger". Le deuxième point à été supprimé de la doc et n'est plus contrôlé.

Lecture confuse de la doc au niveau du "cycle de vie"#

La section du "cycle de vie" rend la lecture confuse. Les gens cliquent dessus pour l'aller sur les infos de l'étape en question afin de savoir ce qu'ils doivent faire. Cependant, la section "cycle de vie" a pour objectif de seulement présenter les états et comment on passe de l'un à l'autre. Ce que recherchent les gens se trouve plus loin dans la documentation.

Solution apportée : la section "cycle de vie d'un changement" est déplacée à la fin de la documentation.

Cas d'exception : pas de CAASCHR pour l'ajout d'utilisateurs#

L'ajout d'utilisateurs dans users.cue avait été débattue il y a longtemps et il en résultait que ce cas était une exception ne nécessitant pas de CAASCHR. Cela n'apparaissait pas dans la documentation.

Solution apportée : clarification du point dans les cas d'exception.

Liens à revoir#

Le lien "Change/Incident - Communication Client" pointe vers Confluence qui pointe vers la doc interne. On peut faire pointer ce lien directement sur la doc interne. Ce lien apparaît deux fois dans la documentation.

Solution apportée : Le lien a été changé : il pointe maintenant directement vers la documentation interne.

Changements liés à un ticket CW sans CAASCHR#

Certains tickets CW sont traités sans tickets CAASCHR alors qu'ils impliquent un changement sur la Production. Exemples :

  • CW-1866
    • https://jira.corp.caascad.com/browse/CW-1866
    • https://git.corp.caascad.com/caascad/terraform/envs-ng/-/merge_requests/2716
  • CW-1864
    • https://jira.corp.caascad.com/browse/CW-1864
    • https://git.corp.caascad.com/caascad/terraform/envs-ng/-/merge_requests/2709

On note l'absence de CAASCHR pour ces exemples.

Problème :

La traçabilité depuis les CAASCHR est mauvaise. Mais elle est complète : y'a une MR, qui mentionne un ticket CW, et le CW mentionne la MR. La vérification est effectuée à la discrétion de l'opérateur et est confirmée par le client. De plus, il y a des SLA à respecter.

Cependant, la traçabilité depuis les CAASCHR reste mauvaise et, pour cette raison et diverses autres, Elvis a re-précisé sur Rocket.Chat sur #general le 12/01/2023 :

rappel de service : les demandes client (ticket CW) qui donnent lieu à un changement en production doivent passer par un ticket de changement (CAASCHR) afin d'être tracés.

Il n'y a donc pas lieu de changer le workflow des changements.

Solution apportée : un point 'Réalisation d'une demande d'un client' a été ajouté dans la documentation pour les exemples de changements afin de signifier explicitement que ce cas nécessite bien un CAASCHR.

25/01/2023#

trackbone plan préalable à un CAASCHR#

Ne devrait-on pas faire un trackbone plan juste avant de démarrer ? Et vérifier le résultat ?

Cette pratique de certains a pu les sauver d'un CAASCHR non réalisable en Production avant de le commencer. Faut-il ajouter cette bonne pratique dans la documentation ?

Solution apportée :

  • la doc n'est pas un lieu pour les bonnes pratiques
  • la doc se veut générique, et ne cite pas l'outillage

Cette bonne pratique ne sera donc pas documentée dans le workflow.

11/01/2023#

Comment gérer les modifications sans changement ?#

Exemples : CAASCHR-1683 CAASCHR-1762 CAASCHR-1823

Note : recherche Jira 

project = "Caascad Change Request" AND summary ~ STG AND summary ~ PRD ORDER BY summary DESC

Scope : refacto sans envs cible - contexts - caascad-zones - updates de toolbox / trackbone dans envs-ng - no-changes

Pour ce cas, un préfixe a été choisi pour le titre des CAASCHR : [STG+PRD]

Un CAASCHR est nécessaire. Cela a été reconfirmé par Elvis le 11/01/2022 sur Rocket.Chat en privé.

Solution apportée : ajout d'un nouveau cas d'exception "Changement de code sans modification sur les environnements"

Rebase de MR après validation du CAASCHR#

Cas d'usage : j'ai fait valider mon CAASCHR. Mais j'ai remarqué que ma MR, qui pouvait être mergée au moment de la validation, ne l'est plus. Alors j'ai rebasé (ou fait les corrections nécessaires). - est-ce que je dois faire revalider la MR ? - est-ce que je dois faire revalider le CAASCHR ?

Proposition : s'il n'y a pas de changement fonctionnel dans la MR, alors la revalidation du CAASCHR n'est pas nécessaire. Note : si les vérifications ne changent pas, c'est un indice qu'il n'y a pas de changement fonctionnel. Inversement, si le mode opératoire change, alors là il faut une revalidation du CAASCHR.

Solution apportée : ajout d'une explication dans la section "Quels sont les éléments à ne pas oublier avant de démarrer" pour traiter de ce cas.

Sujets traités de 2019 à 2022#

Cohérence dans la doc#

Référence : admonitions

Revue de la cohérence de la documentation :

  • pertinence et type des admonitions
  • listes (ponctuation, majuscules)

Critère de validation des MR : vérifier qu'il n'y a plus de commit après l'approval#

Suite à un commentaire le 24/06/2022 :

cela m'arrive régulièrement de voir des MR validées, mais encore plusieurs commit après la validation. La version validée n'a presque plus rien a voir avec la MR qui sera deployée. Il est important de vérifier que la validation est faite pour la version finale de la MR. peut-être spécifier cela dans la procedure de validation de caaschr ?

Ce qui a été fait : écrire qu'il ne doit pas y avoir de commits après la validation. Et les OPS ne contrôlent pas spécifiquement ce point.

CAASCHR du vendredi (cf réunion du 22/03/2022)#

Peut-on réaliser un CAASCHR le vendredi ?

Solutions :

  • Rédaction du cas d'exception (https://git.corp.caascad.com/caascad/docs/docs-internal/-/merge_requests/474) (déjà communiqué le 08/04/2022)

  • Refacto de la section "Quelles sont les règles à respecter ?" (https://git.corp.caascad.com/caascad/docs/docs-internal/-/commits/caaschr-21092022)

Revoir la section "Quand doit-on faire une déclaration de demande de changement ?"#

  • La définition doit inclure clairement le cas d'un changement sans modification (exemple alignement d'une conf pour coller à la réalité de la prod)

Feedback (en 2021) (Contexte : CAASCHR-976 CAASCHR-1005)

Quand doit-on faire une déclaration de demande de changement ?/En cas de changement en production (prd) ou en staging (stg) :/Tout autre cas non explicitement listé ici : ce truc n'est pas clair.

La personne voulait tracer qu'elle faisait une modif dans envs-ng. Impact de la modif : aucun (genre : refacto sans impact). Nous lui avons dit : si pas d'impact sur STG+PRD, alors pas de CAASCHR; la traçabilité est assurée par celui qui valide la MR.

Ce qu'elle avait compris avant qu'on ne le lui dise, c'est que sa modif (sans impact STG/PRD) rentrait dans le cas Tout autre cas non explicitement listé ici

Notre perception suite à cela : cette ligne est trop vague, elle englobe tout alors que dans certains cas, pas besoin de CAASCHR parce que pas de modif en STG/PRD.

Après re-re-relecture de la doc, on a noté ceci : En cas de changement en production (prd) ou en staging (stg) : qui est pourtant explicite. Si plusieurs personnes (avec qui on en a également discuté) l'ont loupé, alors c'est qu'il n'est pas assez visible ?

Ce qui a été fait (2021-09-22) : bien définir un changement (exemple : ajouter une section "c'est quoi un changement ?")

Commentaires 20/09/2022 (possibles doublons avec le reste)#

Liste "exhaustive" des zones : doublon avec "pas de liste dynamique" ?

Le contenu des champs Changed services impacting _ si présents. à renommer

Ce point a été traité

Vérifications post-opé : Le contenu des champs Changed services impacting _ si présents.#

Ce qui a été fait : reformulé suite à la modif du 07/09/2022

Le change impacting caascad "us/internal"#

Ce qui a été fait, avec l'aide d'un expert Jira :

Les deux champs ont été remplacés par une liste déroulante "service downtime" avec les durées nécessitant com' client/délais (<5m, 5m<..<30m, 30m ou +)

impact <1m && downtime <5m    (rien)
impact <15m && downtime <30m  (48h)
more than that                (7j)

La doc a été mise à jour

Ce changement a été communiqué lors du Point de Synchro

Validation : présence des silences d'alarmes#

Ce sujet était initialement en attente de d'outillage (MVPMON-368)

Etat des lieux au 07/07/2021 : 

    - le script pour mettre un silence existe (voir avec Cyril B.).
    - Il faut le mettre dans la toolbox.
    - Personne ne sait faire ça chez Monitoring
    - Il faut trouver un moyen d'obtenir de l'aide
    - MVPMON-368

Etat des lieux au 25/05/2022 :

    - Il existe un script dans la toolbox : amtool-caascad
    - MVPMON-368 cancelled (reprise dans MVPMON-507)
    - MVPMON-507 (devenu PF-483) fini
    - PF-881 (doc technique sur les silences) fini
    - CAASSUPV-19 (doc orga sur les silences): **à faire**

Ce qui a été fait :

  • le responsable du ticket détermine si des silences sont nécessaires ou non pour son opé. Pas de vérification de ce point par les OPS pour ne pas alourdir le process. Donc rien à faire niveau workflow.
  • la convivialité du wrapper est à revoir pour le populariser. Mais c'est hors sujet CAASCHR.

Durée d'opé de 15m#

La question se posait si on augmentait la granularité des créneaux d'opérations à 15 min au lieu des 30 min actuelles.

Ce n'est pas une bonne idée car il faut tenir compte du temps de correction/rollback/verif etc. compris dans la durée d'intervention.

Une même personne est assignée sur 2 opérations en même temps#

Exemples :

  • https://jira.corp.caascad.com/browse/CAASCHR-1565
  • https://jira.corp.caascad.com/browse/CAASCHR-1566

Bien qu'il s'agisse d'une mauvaise pratique, il a été décidé de ne rien indiquer dans le workflow. En effet, dans certains cas cela peut être acceptable à condition que ce soit justifié. L'OPS qui valide est ensuite libre d'accepter ou non ce cas particulier en fonction des explications qui lui auront été données.

Horaires des CAASCHR (8h-17h fin 18h)#

Entre 8h et 9h, on est encore sur le créneau d'astreinte. On nous a proposé d'éviter ce créneau. Et si le changement a lieu malgré tout avant 9h, prévenir la personne d'astreinte.

Il a été choisi de laisser "8h" :

  • cela permet d'effectuer des opérations gênantes pour Caascad à des horaires qui n'ennuient pas les gens.
  • Cela permet d'avoir un créneau horaire d'une durée de 4h le matin.
  • Pour le suivi, il y a un CAASCHR.

CAASSUPV-10 : proposition d'ajout d'un critère de validation#

La problématique est que lorsque des opérations ont lieu sur les clusters clients, vérifier que les clusters hibernés (aujourd'hui, seulement "ma") n'ont pas été oubliés.

Ce sujet sera à reprendre lorsque le sujet de l'hibernation des clusters aura été traité.

Il faudra alors reformuler la problématique car CAASSUPV-10 ne sera plus d'actualité.

Le validateur doit-il comparer la liste des envs du champ zones avec les diverses listes qui se trouvent dans la description du ticket ?#

Le contrôle n'est pas obligatoire. Mais il n'est pas interdit de le faire, surtout s'il y a des doutes quant à la procédure.

Si on voulait effectuer ce contrôle de façon systématique, il nous manquerait de l'outillage et la compréhension technique des procédures. De plus, cet outillage pourrait être mis en défaut dès qu'il y a des exceptions.

Après la réorg : revoir la doc et remplacer MVP par le truc qui va bien#

Ce point a été traité

Présence d'un approval (les pouces sont encore temporairement tolérés)#

Il a été proposé de retirer la mention sur les pouces.

Cela a été fait.

Le champs "zones" est trop court#

Exemples :

  • https://jira.corp.caascad.com/browse/CAASCHR-1223
  • https://jira.corp.caascad.com/browse/CAASCHR-1296

La documentation a été changée.

L'ancien champ est devenu optionnel et caché dans Jira (pour préserver les anciens tickets)

Il faut maintenant mentionner la liste des zones directement dans la description du ticket.

Les CAASCHR "spéciaux" Itération 1#

Il faut faire un CAASCHR (Exemple : CAASCHR-1203 ?)

Ajouts dans la doc pour dire que :

  • le CAASCHR peut être étalé sur plusieurs jours (c'est une exception)
  • expliquer un peu comment on fait un tel CAASCHR pour pas que ce ne soit trop difficile à faire.
  • il faut que la personne qui réalise mette des commentaires dans son CAASCHR au fur et à mesure de la réalisation pour qu'on sache ce qui a été fait.

Ajout d'un utilisateur -> remplacer le CAASCHR par un SUPIT pour simplifier#

  • Discuté en DSM sup le 22/11/2021 avec le Responsable de la Production
  • Demande pour "automatiser" l'ajout d'un caascadeur via un formulaire web faite à l'équipe dashboard (sur #mvp_dashboard le 22/11/2021 à 12h11).
  • Création automatique d'un caaschr évoquée. Mais pas évidente pour le moment.
  • En attendant, un SUPIT (uniquement) est toléré, documenté dans la doc annexe mais pas dans la page de gestion du changement car temporaire.

Problème après la réouverture d'un CAASCHR clos#

Exemple : CAASCHR-1093.

Quand un CAASCHR passe à l'état clos, si jamais on le ré-ouvre (soit fausse manip, soit mal-compréhension du process -> peu importe), on est coincés.

  • Soit on le "cancel"
  • Soit on lui fait revivre un cycle de validation (ce qui a été fait pour CAASCHR-1093, faute de mieux)

Comment faire ? Ajouter une possibilité de transition open->close ?

Est-ce qu'on peut mettre des commentaries dans un CAASCHR clos ? Réponse : oui. Cela a été fait dans le CAASCHR-4.

Ce qui a été fait : cela a été indiqué dans la documentation.

Lors d'un changement d'heure de réalisation, comment marque-t-on que cela a été validé par un OPS ?#

Exemple : CAASCHR-1028

  • validé une fois
  • validé pour 10h (cf commentaire)
  • réalisation entre 15h30 et 16h30 <- aucune trace de validation d'OPS) pour ce nouveau changement d'horaire.

Solution : déjà dans la doc : -> repassage en Open pour replanification

Validation "check CI and merge"#

Dans certains cas, le retour de la CI est suffisant. Exemple : CAASCHR-1004 la vérification, c'est la création de l'objet. La CI indique cette création.

Dans d'autres cas, le retour de la CI n'est pas suffisant, on ne sait pas précisément ce qui a été changé, on ne sait pas si des pods qui devaient redémarrer ont effectivement redémarré...

Comment faire comprendre à l'OPS qu'on va effectivement se contenter du retour de la CI ?

Comment l'OPS peut-il voir qu'il ne s'agit pas d'un oubli, que le retour de la CI est suffisant ?

Solution : cela a été indiqué dans la documentation : il faut spécifier explicitement ce qu'on regarde dans le retour de la CI.

Une personne devant impérativement connaître le contenu de la doc ne l'a pas lue#

  • solution 1 : ajout d'un TLDR dans la doc
  • solution 2 : voir avec la personne pourquoi elle n'a pas lu la doc

Solution : on a choisi la solution 1. On est trop loin après l'événement, la personne ne se souvient pas forcément de la situation. On abandonne la solution 2.

Templating pour les CAASCHR ?#

  • cf l'outil Cloudwatt mep_toolbox, trop difficile à l'usage, trop complexe
  • cf l'outil de JP (lien mort) : https://git.corp.caascad.com/jpbraun/envs-ng-caaschr/

Actuellement il faut modifier la config pour les équipes non-infrakaas

Il manque la partie "vérification" pour la vérification fonctionnelle de l'appli qui a été changé lors du CAASCHR

Ce sujet est reporté à plus tard. Il faudra d'abord aborder le sujet des Changements Standards qui peuvent simplifier les choses.

Validation : impact of change#

  • doit-on le contrôler ?
  • à quoi sert-il ? (demander à Mikhael/Elvis ?)

Solution : renommage coupure ou dégradation du service -> description et durée + need ticket com' client / com sur Rocket.Chat (#OPS ?)

ajouter un point de contrôle de validation ?

Ce qui a été fait :

  • remplacer le champ impact of change par
    • un champ texte libre Changed services impacting customers
    • un champ texte libre Changed services impacting us

Note : ce point a été revu ultérieurement

  • revoir la doc :
    • expliquer qu'on veut une description courte de ce qui est impacté, si c'est coupé ou dégradé, et la durée.
    • point de validation : si un des deux champs n'est pas vide, valider qu'il y a bien une communication prévue (SUPIT/client ou Rocket.Chat/caascad)

A quoi sert le status "On Hold" des CAASCHR ?#

Etat des lieux

  • Quand on est en Open, on n'a qu'à le laisser en Open
  • Quand on est en "To Review", l'OPS le passe en "Validated" ou le remet en "Open". Il n'a aucune raison de le passer en On Hold
  • Quand on est en "Validated", si y'a un NO-GO, on peut le repasser en "Open"
  • Quand on est en "In Progress", on va jusqu'au bout (ou pas) et on le passe en "Close". Il ne faut pas passer un ticket "In Progress" en "On Hold" avec notre workflow !

Solution : champ supprimé

Confluence -> mkdocs#

La documentation du Workflow des Changements était initialement dans Confluence. Il a été migré dans mkdocs.

Certaines personnent démarrent leurs opérations avant leur créneau#

Solution : not our business. C'est au Responsable de la Production de gérer ces "erreurs" et aux gens qui font ce genre de choses d'assumer leurs responsabilités.

Question sur le découpage d'une opération qui revient#

  • Par tâche, par env, etc.
    • cela dépend de chaque opération. C'est ceux qui font l'opération qui savent le mieux
    • mais on peut indiquer des bonnes pratiques (dans la doc ?)
  • Exemple : réalisation des CAASCHR alertmanager (suivi dans MVPMON-315) : ce sont des opérations lourdes. Il n'y a pas eu de découpage parce que le script faisait tout le travail. L'opération a duré 2h10.

Solution : il n'y a pas vraiment de sujet. La durée maximum préférable est déjà indiquée dans la doc (3h). Il n'y a pas de point de contrôle de durée pour les OPS. Si le problème survient, les OPS sauront discuter avec le réalisateur du CAASCHR.

Bouton Merge : peut-on valider lorsqu'il est rouge ?#

Dans une MR, lorsque le bouton "Merge" est rouge, cela ne veut pas dire qu'on ne peut pas merger. Il ne faut pas refuser un CAASCHR si le bouton "merge" de la MR est rouge. On refuse le CAASCHR si le bouton "merge" de la MR est grisé avec une indication de conflit

Il faut clarifier cela dans la doc

Solution : rien à faire car on est censés connaître le fonctionnement de Gitlab et savoir que la couleur rouge d'un bouton "Merge" est liée à la CI et non à la possibilité de merger ou non.

Note : ce point avait été déjà vu auparavant (cf ci-dessous).

Validation: tickets en liens#

Faut-il ajouter un critère de validation sur les tickets en lien ? Est-il normal d'avoir des CAASCHR à blanc, sans relation à un CAASINC ou un MVPxxx ?

Oui pour cloudwatt (pas de MVP). Pour Caascad, la réponse est différente.

Solution :

  • Un lien avec un CAASINC se fait naturellement : on lie le CAASCHR au CAASINC et donc cela se voit dans le CAASCHR.
  • Un lien vers un MVPxxx n'est intéressant que pour les équipes techniques. Il n'y a pas d'intérêt ni au niveau de la validation ni au niveau du suivi.
  • Conclusion : on laisse les choses se faire. On ne documente pas.

Que faire si la CI est rouge ?#

Responsabilité des gens capables de faire les review de code. A eux de juger si c'est important ou non, et de valider (par un pouce/approval) les MRs en conséquence. Les OPS se contentent de vérifier cette validation. Note : du rouge dans la CI peut indiquer un problème de déploiement et non un problème futur sur la plateforme

Note : ce point a été vu une nouvelle fois ultérieurement (cf ci-dessus)

Peut-on "approve" au lieu de mettre un pouce dans les MR Gitlab ?#

  • Le approval est mieux que les pouces : on voit dans le flux des commentaires l'instant où l'approval a été fait (et donc si de nouveaux changements ont suivi).
  • Dire aux gens d'utiliser approval, tolérer les pouces pendant la période transitoire.

Format de la durée#

  • 60m on accepte ?
  • 1h30 : on met 1h30 ou 90m ou ... ?
  • à l'usage, on se rend compte que les gens mettent soit 30m soit un multiple d'une heure, mais jamais 1h30...

Solution : on laisse les choses se faire car ce sujet est trop marginal. À voir directement avec la personne qui ferait ça, inutile d'alourdir la doc.

Cas d'un CAASCHR qui dépasse le délai et où on peut continuer#

  • Par principe, l'opération doit être stoppée.
  • Si l'opération peut être stoppée mais que la suite revient à 1/ fermer le CAASCHR, 2/ cloner le CAASCHR (avec un périmètre plus restreint), 3/ demander une validation à un OPS pour exécution immédiate, 4/ validation de l'OPS parce qu'il n'y a pas de raison de s'opposer, 5/ suite de l'opération avec le nouveau CAASCHR, alors :
    • les étapes 2 et 3 sont "bureaucratiques"
    • il suffirait de demander à l'OPS l'autorisation de continuer sur le CAASCHR initial
  • Le point ici est juste d'éviter la partie "bureaucratique" pour une opération hors délai qui peut être prolongée
  • A voir si le problème est ponctuel ou récurrent.
  • A voir aussi si les gens respectent les délais ou "trichent" en prolongeant les CAASCHR hors délais sans en parler aux OPS

La doc est explicite. Si le problème survient, le réalisateur peut aller discuter avec un OPS : cela sera traité au cas par cas.

Pas de modif de la doc.

Champ customer#

  • Quand on n'est pas en prod, mais qu'on impacte un cluster dit "client", est-ce qu'on coche la case ? Cette case est liée aux vrais client (qui paient ou qui paient presque) ou aux clusters clients ?
    • si j'interviens sur delta par exemple, est-ce que je coche la case "customer" ?

Solution : la doc est déjà à jour : on parle d'impact potentiel "peut impacter" et de clients externes (donc ceux qui paient)

Quel est le workflow pour les tickets expirés ?#

  • parce qu'il n'y a rien dans la doc
  • en attendant, on contacte la personne pour savoir si le ticket n'a pas été réalisé (-> open pour replanification) ou si...
  • ... si le ticket a été réalisé, mais pas cliqué sur "in progress" + "close" (-> on fait comment dans ce cas ?)

Solutions :

  • l'OPS qui s'en aperçoit doit contacter la personne concernée et faire un point sur l'opération.
  • la doc est complétée pour ce cas spécifique

Quelle est la plage horaire journalière pour les CAASCHR ?#

Proposition :

  • début : 8h
  • heure maxi de début d'opé : 17h
  • heure maxi de fin d'opé : 18h00 (plus d'OPS après 18h)

Réflexion :

  • les interventions doivent être terminées à la fin de la période
  • avant 8h, c'est trop tôt parce qu'il n'y a pas grand monde pour aider si quelque chose casse. Et attention, on est encore dans le périmètre de l'astreinte
  • 18h c'est trop tard : il n'y a plus d'OPS et c'est bientôt le périmètre de l'astreinte
  • Mais des fois, il faut faire des opérations à des heures décalées pour ne pas impacter tout le monde (exemple : MAJ Jira)

La documentation reprend la proposition. Pour les cas particuliers, ils seront discutés avec les OPS.

Déploiement spécifique à un env de prod : quid du CAASCHR/stg ?#

  • Parfois, on fait un déploiement spécifique à un environnement de prod.
  • Cas d'usage MEP comme CAASCHR-502 : A-t-on besoin d'un CAASCHR pour un déploiement de nouvelle zone ?
  • Cas d'usage correctif spécifique à une zone, hors CAASINC : Ne peut-on pas mettre un commentaire pour expliquer pourquoi il n'y a pas de CAASCHR/stg ?

Solution : la doc indique ce cas (commentaire à ajouter dans le CAASCHR pour justifier ce cas)

Mon CAASCHR s'est bien déroulé sauf sur une zone. Rien n'a été fait sur cette zone, donc il n'y a pas d'échec. Mais ce n'est pas un succès non plus#

  • si on met "Failed" comme le prévoit la doc, on témoigne d'un problème. Or il n'y a pas eu de problème. C'est perturbant, "Failed" quand il n'y a pas eu de problème et que c'est juste qu'on n'a pas fini.
  • si on met "Done", c'est pas vrai
  • est-ce qu'on peut ajouter "Incomplete" dans la doc ?
  • CAASCHR-454 est un exemple.

Note : la solution à ce point n'a pas été notée. Soit la doc était à jour, soit elle a été revue. Ce point a été traité.

Retour sur les MRs à mettre en lien :#

Conversation entre une personne de Caascad et un OPS :

  • La personne : "J'aimerai te remonter une petite remarque s'il te plaît par rapport aux CAASCHR, en fait, quand on crée un CAASCHR STG, on y met les MR, puis quand on crée le CAASCHR PRD, on le lie au ticket CAASCHR STG, alors qu'on doit encore remettre les MR dans le ticket CAASCHR PRD. est ce qu'indiquer les MR dans le CAASCHR STG ne serait pas suffisant? merci d'avance!"
  • Moi : "C'est vrai qu'on peut se poser la question, mais selon les opé il peut y avoir deux MRs différentes, une stg et une prd, ou une seul pour stg et prd. Après ça voudrait dire qu'on doit aller regarder tout l temps le ticket de STG voir si il y a déjà des MRs dedans, bref ça serait moins pratique pour les reviews 😕"

Solution : ajout d'une explication dans https://md.corp.caascad.com/caaschr?view#Lien-Jira-vers-les-MR

Note : cette explication a été déplacée avec la documentation dans mkdocs.

Mise en commentaire Jira de la validation des CAASCHR#

Les commentaires fait directement au rédacteur par l'OPS dans Rocket.Chat sont "perdus", impossible de retracer le chemin de validation du ticket dans Jira.

Il faut donc mettre ces conversations en commentaire des CAASCHR.

Quand une opération échoue, combien de temps se donne-t-on avant de clore (fail) et de créer un CAASINC ?#

Exemple : CAASCHR-341

Solution : Ajout de la section "Comment faire si un changement dure plus longtemps que prévu ?"

Une opé échouée sur STG, le ticket est resté en In Progress pour "debug"#

Si on a besoin de déboguer, alors on est en incident -> CAASINC.

Opé planifiées à xxH15 ou xxH45, relou avec la règle des 30min...#

Solution : info dans le champ date

Confusion sur la liste exhaustive des zones#

  • Expliciter la raison ?
  • Champ Zones vs Description, clarifier le contexte des commandes ?

  • Note : expliquer également pourquoi la liste à espaces (parce que copier/coller plus faciles)

  • Solution : clarification dans le champs Zones et dans le Descriptif

Question sur l'étendue de la validation/vérification de l'opération#

  • Jusqu'où je dois aller dans mes checks ?
  • quel niveau de détail mettre dans le commentaire du ticket pour montrer que ça fonctionne comme prévu ? vérif OK est insuffisant. Mais trop de détail peut devenir une souffrance pour les gens qui réalisent l'opération.
  • CAASCHR/prd faut-il une seconde vérification du CAASCHR/stg juste avant la MEP ? (oh nooon, c'est lourd...)

Solution : clarification dans le descriptif; la vérification est à la responsabilité de celui qui exécute; pour le moment, pas de 2eme verif avant CAASCHR/prd.

A discuter, si validation KO -> remettre le ticket à l'état Open ?#

Déjà fait sur des tickets passés en review par 2 : stg et prd en même temps. Impossible de valider la review du ticket prd si le stg n'est pas encore passé. Retour à Open. (https://jira.corp.caascad.com/browse/CAASCHR-297 et https://jira.corp.caascad.com/browse/CAASCHR-298)

Réflexion :

  • Si tickets passés par 2 (stg et prd) on peut ignorer le ticket de prd. Inconvénient : il ne sera pas validé avant la prochaine demi-journée (et le nouvel OPS qui prendra le créneau). Meilleure proposition : dire aux gens de ne passer en review les tickets prd que lorsque les tickets stg sont finis + repasser à 'open' les tickets quand les gens s'obstineraient à passer les tickets par 2.
  • Si ticket non valide mais nécessitant des modifications courtes : le tickets reste en validation (genre : j'ai oublié de peser les tomates au supermarché : je fonce les peser et je reviens dans la seconde)
  • Si ticket non valide mais nécessitant des modifications plus longues : le ticket revient à 'open' (genre : mon fils/ma fille fait la queue au supermarché pendant que je fais les courses, comme ça je passe plus vite)

Solution : le passage en 'open' est à la discrétion de l'OPS qui valide. S'il n'a pas d'interlocuteur pour traiter rapidement la question, il passe systématiquement le ticket en 'open'; ajout d'une section "Que se passe-t-il si le ticket n'est pas valide ?"

Point de contrôle supplémentaires sur la validation des MR :#

  • la MR ne doit pas être en WIP
  • la MR doit pouvoir être mergée au moment de la validation (pas de conflit de merge au niveau git)
  • s'il y a des contrôles complémentaires (CI, hook...) ils doivent être au vert également (bien que je propose, je n'y suis personnellement pas favorable)

Solution : clarification dans la section "Quels sont les points de contrôle du format du CAASCHR ?". MR en WIP : acceptable car cela peut être le workflow d'une équipe. Contrôles CI complémentaires : s'ils sont rouges, peu importe car gitlab devrait interdire le merge (cf ce qu'on a écrit dans la doc)

Soumission des tickets par paire STG/PRD#

Dialogue :

  • La personne : Dans le cas d'un changement en STG puis en PRD, est-ce qu'on peut balancer les deux CAASCHR en même temps, à condition que la "Date of Change" soit espacé de 24h ? Ou est-ce qu'il vaut mieux attendre d'avoir la confirmation que le change en staging se soit bien déroulé ?
  • Moi : Je vais le noter dans les points à clarifier. Implicitement, il faut une CAASCHR au status OK pour une review, donc le ticket PRD ne devrait pas être soumis avant la fin de l'opé et les vérifs sur STG.

Nous avons noté un cas réel correspondant à cette discussion.

  • CAASCHR-323/stg et CAASCHR-324/prd : CAASCHR-323 a été validé, mais sans regarder CAASCHR-324. Inconvénient de cette démarche : la personne doit attendre le créneau de supervision suivant pour que quelqu'un valide (est-ce grave ? il doit y avoir minimum 24h entre les 2 tickets, donc ça laisse du temps au suivant pour valider)
  • le CAASCHR de stg vient d'avoir lieu (avec succès et ajout des résultats de la vérif en commentaire du ticket immédiatement après déploiement). Le CAASCHR de prd est immédiatement soumis à la validation. Qu'est-ce qui doit attendre 24h ? la validation de l'OPS ou la durée entre la réalisation de chaque CAASCHR ?

Solution : Clarification à 3 endroits dans la doc ("Création d'une demande de changement/Quelles sont les règles à respecter ?" + "Tickets liés & Tickets" + "Quels sont les points de contrôle du format du CAASCHR ?")

Critères de validation : cas d'une personne à qui on a refusé un CAASCHR parce qu'il y avait trop de zones impactées#

La personne a été contactée en privé pour avoir des explications...

Le problème était une combinaison de

  • distinction prod et pas-prod
  • connaissance des environnements : c'est quoi infra-stg, c'est quoi ocb-test05 (leur rôle, prod ou pas prod...)

Il n'y a pas eu d'autre action qu'une explication.

Si un CAASCHR dure plus de 4h, il faut le découper.#

Note : la solution à ce point n'a pas été notée. Soit la doc était à jour, soit elle a été revue. Ce point a été traité.

J'ai un CAASINC, est-ce que je fais un CAASCHR ?#

  • Si on doit résoudre l'incident immédiatement, alors pas de CAASCHR (on explique dans les commentaires du CAASINC)
  • Si on peut résoudre l'incident ultérieurement, alors le CAASCHR est obligatoire

Solution : cela a été reporté dans la documentation.

MR en lien : que fait-on des MR déjà mergées qu'on veut ajouter à titre indicatif ?#

  • proposition : on ne fait rien avec. L'OPS va les voir, constate qu'elles sont déjà mergées et cela n'a pas d'importance.
  • OK tant qu'elles ont un pouce.

MR en lien. L'OPS ne vérifie que la présence du pouce (mais pas si elle est mergée ou non)#

Note : la solution à ce point n'a pas été notée. Soit la doc était à jour, soit elle a été revue. Ce point a été traité.

Champs Failed et Rollbacked à rediscuter#

Une fois le change effectué, le Rapporteur passe le status en Closed en saisissant la résolution du change. Il y a deux nouveaux champs : Failed et Rollbacked. Ces champs sont à rediscuter.

  • "Done/Terminé" fait
  • "Rollbacked" pas fait, mais retour à l'état initial (comme s'il n'y avait pas eu de change)
  • "Failed" fait, arrêté à la moitié du chemin et je laisse des trucs sales

Note : la solution à ce point n'a pas été notée. Soit la doc était à jour, soit elle a été revue. Ce point a été traité.

Tickets SUPIT : est-ce le même pour la communication au client et pour le réveil/hibernation d'un cluster ?#

Faut-il les différencier dans la doc sur les CAASCHR ?

Solution : oui (un ticket SUPIT "communication" pour le client et un "tâche" pour le réveil/hibernation). Cela a été reporté dans la documentation.

Ajouter le lien https://espace.agir.orange.com/display/BPF/Process+Support+Caascad dans la doc.#

Cela a été reporté dans la documentation.

Nouvelle capture d'écran du formulaire de création de CAASCHR#

La capture d'écran a été mise à jour.

Indiquer le format de la durée (30m, 1h, 1h30, 2h45 ...)#

Note : la solution à ce point n'a pas été notée. Soit la doc était à jour, soit elle a été revue. Ce point a été traité.

Comment annoncer aux autres un changement d'état ?#

  • en début de chaque section d'explication (exemple : section "Comment indiquer la fin de l'opération ?")
  • au début de la section "Cycle de vie de la demande de changement" ?

Note : la solution à ce point n'a pas été notée. Soit la doc était à jour, soit elle a été revue. Ce point a été traité.

Section Comment gérer l'échec d'une opération : nouvelle formulation#

  • Faut-il mentionner que le CAASINC et le CAASCHR doivent être liés ? Si oui, là (bof) ou ailleurs (chsépaoù) ?
  • Bien que l'état cible ne soit pas intégralement atteint, le ticket doit être Clos. : on laisse tel quel, ou on le met dans un cadre 'info' pour que ce soit plus visible ?

Note : la solution à ce point n'a pas été notée. Soit la doc était à jour, soit elle a été revue. Ce point a été traité.

Le lien vers le dashboard CAASCHR est trop caché dans la doc.#

  • proposition : nouvelle section 1.3 Où consulter les déclarations de demandes changement
  • placer le lien dans cette section

Note : la solution à ce point n'a pas été notée. Soit la doc était à jour, soit elle a été revue. Ce point a été traité.

Finalisation : supprimer la note en haut de page#

Ce point a été traité.

Documenter "C'est quoi la production, c'est quoi le staging ?"#

  • définir la production et le staging
  • placer cela dans une doc (celle des CAASCHR ou ailleurs ? -> ailleurs)

Note : la solution à ce point n'a pas été notée. Soit la doc était à jour, soit elle a été revue. Ce point a été traité.

Lien facilitant la création d'un SUPIT pour réveille/hiberner un cluster : à ajouter dans la doc.#

Ce point a été traité.

Dashboards CAASCHR : supprimer le 14218 et l'annoncer#

https://jira.corp.caascad.com/secure/Dashboard.jspa?selectPageId=14218

Ce point a été traité.

Peut-on ajouter, dans le formulaire de création d'un CAASCHR la possibilité d'ajouter des liens externes (vers des MR) ?#

Ce point a été traité.

Champs Caascad Product à discuter pour suppression#

  • permet de suivre les changements par équipe.
  • A garder, utilisé par les PO.

Solution : pas d'action.