Le périmètre de votre contrat MSP¶
Objectif. Savoir qui fait quoi selon votre niveau de contrat (N1, N2, N3), comment classer une demande et quand passer la main au MSP. Sources : la matrice de responsabilité et la grille de sévérité du portail.
Un modèle, pas votre contrat
Les tableaux ci-dessous décrivent la répartition type des trois niveaux. Les clauses de votre contrat (périmètre exact, horaires, délais, éventuelles exclusions) font foi en cas d'écart. Alignez cette fiche sur votre contrat lors du lancement et gardez-en une copie annotée.
Les trois niveaux en une ligne¶
| Niveau | Principe | Vous êtes… |
|---|---|---|
| N1 · Support | Vous exploitez, le MSP répond à vos tickets et vous guide | l'exploitant |
| N2 · Support + MCO | Le MSP assure le maintien en condition opérationnelle : mises à jour, disques, surveillance des sync | l'utilisateur de la plateforme et le premier témoin des incidents |
| N3 · Infogérance | Le MSP exploite la plateforme, détecte et intervient | le client d'un service, vous gérez vos VMs |
Qui fait quoi (modèle)¶
| Opération | N1 | N2 | N3 | Page de référence |
|---|---|---|---|---|
| Créer, cloner, migrer une VM | Client | Client | Client ou MSP | Migration à chaud |
| Restaurer une VM ou un fichier | Client, support si échec | Client, support si échec | MSP sur demande | RB-12, RB-13 |
| Remplacer un disque ZFS ou OSD Ceph | Client guidé | MSP | MSP | RB-03, RB-05 |
| Mises à jour mineures | Client | MSP | MSP | RB-08 |
| Mise à niveau majeure PVE, PBS, Ceph | Client, support conseil | MSP | MSP | PVE 8 → 9 |
| Surveillance des sync PBS vers le MSP | Client | MSP | MSP | RB-15 |
| Modification CRUSH, Corosync, SDN | MSP sur devis | MSP | MSP | Règles CRUSH |
| Incident cluster (quorum perdu, PG inactive) | Ticket P1, MSP intervient | Ticket P1, MSP intervient | MSP détecte et intervient | RB-09, RB-01 |
Chaque runbook rappelle cette répartition dans son bandeau « Qui : N1 / N2 / N3 ».
Ce que vous faites toujours vous-même¶
Quel que soit le niveau, certaines actions restent chez vous, sauf mention contraire du contrat :
- la gestion du contenu des VMs : système invité, applications, comptes, données ;
- la demande de restauration (ce qu'il faut restaurer, à quelle date) et la validation du résultat ;
- la déclaration rapide d'un incident constaté, avec la bonne sévérité ;
- la planification des fenêtres de maintenance avec vos métiers.
Ce qui est toujours confié au MSP¶
Les opérations qui peuvent arrêter tout le cluster ou détruire des données en une commande :
- topologie CRUSH, pools et règles Ceph ;
- configuration Corosync (liens, votes, QDevice), ajout ou retrait de nœud ;
- SDN (zones, VNets, EVPN) ;
- mises à niveau majeures (N2 et N3 ; en N1, le MSP conseille) ;
- reprise après perte de quorum ou PG inactive.
Choisir la sévérité¶
| Sévérité | Définition | Exemples |
|---|---|---|
| P1 · Critique | Production arrêtée ou données en danger immédiat | Perte de quorum, Ceph HEALTH_ERR avec PG inactive, OSD full, pool ZFS SUSPENDED, restauration urgente d'un service critique |
| P2 · Majeur | Production dégradée, plus de redondance | Nœud hors ligne avec HA active, deux disques en défaut, sauvegarde en échec deux nuits de suite, sync MSP en échec plus de 48 h |
| P3 · Mineur | Anomalie sans impact immédiat | Disque en pré-panne SMART, HEALTH_WARN inexpliqué depuis 24 h, nearfull persistant |
| P4 · Demande | Question, conseil, planification | Planifier une mise à jour, étude de capacité, création de compte |
Les délais de prise en charge associés à chaque sévérité sont ceux de votre contrat : ce portail n'en fixe aucun.
Arbre de décision : je fais ou j'ouvre un ticket ?¶
| Situation | Action |
|---|---|
| Opération listée « Client » pour votre niveau, runbook disponible | Vous l'exécutez en suivant le runbook |
| Opération listée « Client guidé » | Ticket P3 ou P4 avant de commencer, puis exécution guidée |
| Opération listée « MSP » | Ticket P4 de planification, vous ne touchez pas |
| Runbook bloqué à une étape, résultat inattendu | Stop, ticket avec l'étape atteinte et les sorties de commandes |
| Incident correspondant à une ligne P1 | Ticket P1 immédiat, puis appel selon la procédure de votre contrat |
Ce que contient un bon ticket¶
Plateforme, symptôme et heure de début, impact, ce qui a déjà été fait, sorties de commandes en texte (pveversion -v, pvecm status, sorties propres au sujet). Détail et modèle à copier : Ouvrir un ticket.
Pièges vus en support
- Ouvrir en P4 une sauvegarde en échec depuis trois nuits : elle relève du P2.
- Lancer une opération « MSP » en N1 pour gagner du temps (modifier
corosync.conf, une règle CRUSH) : le MSP doit ensuite réparer sans savoir ce qui a été changé. - Supposer qu'en N3 le MSP connaît vos applications : il gère la plateforme, pas le contenu des VMs.
- Joindre des captures d'écran au lieu des sorties texte : analyse plus lente.
Quand ouvrir un ticket iTop
En cas de doute sur la répartition ou la sévérité, ouvrez un ticket : le MSP requalifie si besoin. Une question de périmètre contractuel se pose en P4.