Tester une bascule, superviser la redondance et documenter le mode dégradé

Tester une bascule, c'est provoquer volontairement la panne d'un composant redondant, mesurer la coupure et vérifier que le service continue. Superviser la redondance, c'est être prévenu dès qu'un composant tombe, avant que la panne suivante coupe le service. Documenter le mode dégradé, c'est écrire à l'avance ce qui fonctionne encore, ce qu'il faut faire et comment revenir à la normale. Ce chapitre donne la méthode d'un test de bascule, un plan de test complet, les indicateurs à superviser et un modèle de fiche de mode dégradé.

Pourquoi tester

Une redondance jamais testée est une hypothèse. Les raisons pour lesquelles un secours ne prend pas le relais le jour J sont presque toujours banales :

• la configuration du secours a dérivé : une règle ajoutée sur le principal et jamais recopiée ;
• le certificat du secours a expiré, puisque personne ne s'en sert ;
• un pare-feu local bloque les annonces VRRP, et les deux nœuds se croient seuls ;
• le relais DHCP ne connaît que le premier serveur ;
• le survivant ne tient pas la charge à lui seul ;
• la procédure de bascule manuelle n'a jamais été jouée, et personne ne sait la suivre sous pression.

Le référentiel du BTS SIO en fait d'ailleurs un indicateur de performance du bloc 2 SISR : le mode dégradé et les éléments de reprise doivent être vérifiés périodiquement. À l'E6, la commission ne se contente pas d'une configuration : elle veut voir la bascule (la recette de l'E6 SISR).

Préparer un test de bascule

Un test de bascule se prépare comme n'importe quelle intervention en production :

1. Formuler l'hypothèse à vérifier, chiffrée : « Si LB1 s'arrête brutalement, l'intranet reste accessible ; la coupure dure moins de 5 secondes ; aucune session n'est perdue. »
2. Choisir le créneau et l'environnement : la maquette d'abord ; en production, hors des heures de service, avec l'accord du responsable. En entreprise, un test en production passe par la gestion des changements.
3. Prévenir les utilisateurs concernés, même si aucune coupure n'est attendue.
4. Prévoir le retour arrière : comment remettre la situation d'avant si le secours ne prend pas le relais, et vérifier que la dernière sauvegarde est bonne.
5. Installer la mesure avant de provoquer la panne : sans chiffres, un test ne prouve rien.

Mesurer la coupure

La mesure se fait du côté du client, comme le ressentirait un utilisateur. Depuis un poste Linux du VLAN 10, une boucle interroge la page de santé de l'intranet deux fois par seconde et horodate chaque réponse :

while true; do
  code=$(curl -s -o /dev/null -w '%{http_code}' --max-time 2 https://intranet.ravelle.lan/sante)
  echo "$(date +%T.%3N) $code"
  sleep 0.5
done | tee mesure-bascule.log

Chaque ligne affiche l'heure à la milliseconde et le code HTTP : 200 quand tout va bien, 000 quand aucune réponse n'est arrivée (délai dépassé, connexion refusée), 503 quand le répartiteur répond mais n'a aucun serveur disponible. La coupure se lit entre la dernière ligne 200 avant la panne et la première ligne 200 après ; comme une requête en échec peut attendre jusqu'à 2 secondes (--max-time 2), la mesure est précise à une ou deux secondes près.

Depuis un poste Windows, le même principe en PowerShell :

while ($true) {
    try { $c = (Invoke-WebRequest https://intranet.ravelle.lan/sante -TimeoutSec 2 -UseBasicParsing).StatusCode }
    catch { $c = 'ERREUR' }
    '{0:HH:mm:ss.fff} {1}' -f (Get-Date), $c
    Start-Sleep -Milliseconds 500
}

Pour une simple adresse virtuelle, un ping rapide suffit : ping -i 0.2 10.10.20.30 envoie cinq paquets par seconde, et le nombre de réponses perdues multiplié par 0,2 seconde donne la durée de la coupure.

Les scénarios à tester

Une panne propre ne ressemble pas à une panne réelle. Teste plusieurs façons de tomber, de la plus douce à la plus brutale :

Le plan de test de l'intranet

Le plan de test (ou cahier de recette) liste chaque test avec son résultat attendu, écrit avant le test, puis le résultat obtenu. Voici celui de l'intranet de Ravelle Conseil après la mise en haute disponibilité :

Le test T8 montre l'intérêt du plan : sans lui, personne n'aurait remarqué que la supervision ignorait les bascules de keepalived. Un test non conforme n'est pas un échec du projet : c'est une correction à faire, puis un test à rejouer.

Superviser la redondance

On supervise à deux niveaux :

1. Le service de bout en bout, comme un utilisateur : une sonde qui interroge https://intranet.ravelle.lan/ depuis le VLAN utilisateurs, chaque minute. C'est elle qui mesure la disponibilité réelle, le SLI du chapitre 1.
2. Chaque membre de chaque redondance, séparément : sinon, la panne d'un membre reste invisible.

Les niveaux de gravité reprennent ceux de Zabbix (information, avertissement, moyenne, haute, désastre). Le principe : une perte de redondance mérite une intervention rapide aux heures ouvrées ; une perte de service, une intervention immédiate. Le cours supervision met en place Zabbix et Grafana, l'outil du labo SISR : hôtes, modèles et déclencheurs, puis les alertes. La supervision calcule aussi, à partir des sondes de bout en bout, le rapport de disponibilité mensuel à comparer à l'engagement de service.

Documenter le mode dégradé

Le mode dégradé est l'état d'un service qui fonctionne avec une partie seulement de ses composants. La fiche de mode dégradé décrit, pour chaque panne prévisible, ce qu'il faut savoir et faire. On l'écrit à froid, quand on a le temps de réfléchir, pour ne pas improviser sous pression.

Ce que contient une fiche :

1. La situation : quelle panne, comment on la reconnaît (l'alerte reçue, les symptômes).
2. L'impact : ce qui fonctionne encore, ce qui ne fonctionne plus, les performances attendues.
3. Le risque : ce qui se passera à la prochaine panne.
4. Les actions immédiates, dans l'ordre, avec les commandes.
5. La communication : qui prévenir, avec quel message.
6. Le retour à la normale : la procédure pour rétablir la redondance, et le délai visé.
7. La vérification : comment prouver que tout est revenu à l'état nominal.
8. Les contacts : l'administrateur d'astreinte, le prestataire, le fournisseur du matériel.

Exemple : un répartiteur hors service.

Fiche MD-03 : un répartiteur de l'intranet hors service

• Situation. Alerte « LB1 injoignable » ou « bascule VRRP », ou un répartiteur arrêté dans Proxmox.
• Impact. Aucun pour les utilisateurs : l'autre répartiteur porte la VIP 10.10.20.30. Performances inchangées (un répartiteur suffit à la charge).
• Risque. Plus de redondance : la panne du répartiteur restant coupe l'intranet.
• Actions immédiates. Vérifier sur le survivant qu'il porte la VIP (ip -br address show ens18) et que ses deux serveurs web sont UP (page de statistiques). Consulter le journal du répartiteur en panne (journalctl -u keepalived -u haproxy).
• Communication. Informer le responsable informatique ; aucun message aux utilisateurs tant que le service fonctionne.
• Retour à la normale. Réparer ou redéployer la VM à partir de la sauvegarde ; vérifier que sa configuration HAProxy est identique à celle du survivant (diff), la valider (haproxy -c), redémarrer HAProxy puis keepalived. Délai visé : un jour ouvré.
• Vérification. Les deux nœuds actifs, un seul porte la VIP, test de bascule T4 rejoué hors heures de service.
• Contacts. Administrateur d'astreinte ; responsable du contrat de service.

Les pannes qui demandent une action humaine pour basculer, comme la promotion du réplica de la base de données (chapitre 9), ont aussi leur procédure de bascule pas à pas, testée en maquette. Ces fiches font partie du plan de continuité ; le cours sauvegarde et PRA traite du plan de reprise, et le cours ITIL et support de la gestion de l'incident lui-même.

Tester régulièrement

Un test réussi en juin ne prouve rien en décembre : les configurations évoluent, les certificats expirent, les équipes changent. Planifie :

• un test de bascule de chaque redondance critique au moins une fois par trimestre, et après chaque changement important ;
• une revue des fiches de mode dégradé à chaque test, pour les corriger avec ce qu'on a appris ;
• un compte rendu de chaque test, avec ses mesures : c'est la preuve, pour la direction comme pour la commission de l'E6, que la disponibilité promise est réelle.

Les grandes entreprises du web vont jusqu'à provoquer des pannes aléatoires en production, en permanence, pour s'assurer que leurs systèmes y résistent : c'est l'ingénierie du chaos. Sans aller jusque-là, retiens l'idée : la seule façon de savoir qu'un système survit à une panne, c'est de la provoquer.

Exercices