Aller au contenu

Explications complémentaires sur les CAASCHR#

Planification#

Début et fin de l'opération#

Le début de l'opération commence toutes les heures ou demi-heures afin de faciliter le cadencement entre les opérations (les réunions et autres rendez-vous eux aussi planifiés par demi-heures) et éviter que les gens mettent des heures comme 10h07 ou 15h54.

Une opération doit démarrer

  • à partir de 8h. Il y a peu de chances qu'un incident surviennent au début de l'opération et, plus tard, il commencera à y avoir du monde pour aider si besoin.

Warning

jusqu'à 9h, la résolution d'un incident rentre dans le périmètre de l'astreinte.

  • à 17h au plus tard, soit 1h avant la fin des horaires de Supervision (9h - 18h). Il faut pouvoir compter sur la présence d'un OPS pour aider à la résolution d'un éventuel incident.
  • de telle sorte l'opération prenne fin à 18h au plus tard pour la même raison que ci-dessus.

Il existe des cas connus où le respect de ces horaires n'est pas possible. L'horaire de l'intervention sera alors discutée avec les OPS (et éventuellement un manager).

Durée#

Le format de la durée "30m" ou "1h" a été choisi de cette façon pour homogénéiser l'affichage dans les dashboards Jira (dont le 12800)

[STG] ou [PRD] dans le résumé du ticket#

A l'origine, il y avait un champ pour indiquer si l'opération touchait la production ou non. Ce champ a été supprimé pour simplifier la création des CAASCHR.

Par ailleurs, le champs Zones indique clairement les environnements et donc si l'action se passe en production ou non.

Cependant, lorsque deux CAASCHR (un de staging, l'autre de production) sont liés à un ticket, il n'est pas possible de les distinguer facilement sans cette mention. C'est pour cette raison que la mention de staging ou de production se trouve dans le résumé du CAASCHR.

Puis, à l'usage, sur le dashboard des CAASCHR, cette mention à staging ou production est devenue une facilité pour avoir une vue d'ensemble des interventions de la journée.

Le format [STG] ou [PRD] dans le titre répond à ces besoins :

  • distinguer 2 CAASCHR (un stg, un prd) quand ils sont en lien
  • améliorer la vue d'ensemble des interventions du jour
  • le format [STG] ou [PRD] est figé pour une meilleure lisibilité.

Champ "Caascad Product"#

Bien qu'il ne serve pas aux OPS+Support, ce champs est conservé : il sert aux PO.

Lien Jira vers les MR#

Les liens Jira vers les MR servent plusieurs objectifs :

  • ils montrent les changements qui sont appliqués
    • dans le cas où la MR a été mergée lors du CAASCHR de stg, voire avant, la mettre en lien est nécessaire pour montrer ce qui va changer
    • bien qu'on puisse retrouver la MR en lien d'un CAASCHR/stg, il faut la mettre dans le CAASCHR/prd pour que ce dernier se suffise à lui-même.
  • ils permettent aux OPS qui valident les CAASCHR de vérifier que les MR ont bien été vérifiées par un tiers.

Tickets CAASCHR-SUPIT de création des utilisateurs#

Au 22/11/2021, il a été décidé en DSM que

  • il faudrait un CAASCHR dit "standard", que nous ne sommes pas encore en mesure de faire.
  • la traçabilité est faisable par ticket SUPIT, mais cela constitue un 2e référentiel de changements, ce que nous voulons éviter.
  • il faudrait un mécanisme d'assistance pour la création de ce ticket CAASCHR pour rendre le processus plus léger.
  • une demande a été formulée à l'intention de l'équipe "Dashboard" ce 22/11/2021 à 12h11 sur Rocket.Chat (#mvp_dashboard)
  • en attendant cette aide, il est décidé qu'un ticket SUPIT est acceptable. Il faut mettre un lien dans le ticket SUPIT vers la MR de changement.
  • cette situation doit rester temporaire.

Copier/coller de la demande du 22/11/2021 à l'équipe Dashboard :

Hello, nous avons discuté en DSM supervision ce matin d'une feature qui nous intéresserait :

  • Les demandes au support pour l'arrivé d'un nouveau collaborateur chez caascad se font via des tickets Jira SUPIT.
  • L'ajout de l'utilisateur à nos outils se fait via une MR en modifiant : https://git.corp.caascad.com/caascad/terraform/envs-ng/-/blob/master/contexts/caascad/users.cue
  • Comme il y a un changement en production, un ticket Jira CAASCHR est nécessaire.

Pour simplifier le travail de nos équipes, il faudrait une interface avec un formulaire d'ajout d'utilisateur qui viendrait automatiser tout ça (MR + CAASCHR). Je vous laisse reboucler avec le #support pour les détails d'ergonomie etc.