La robustesse
des opérations

Serveur de surveillance, serveur de sauvegarde, règle 3-2-1, pivotage, et la vérité sur les forfaits infonuagiques.

Un serveur pro se juge à ses mauvais jours

N'importe qui peut faire tourner un site un mardi tranquille. La différence entre l'amateur et le professionnel, ce n'est pas la vitesse du beau temps : c'est ce qui se passe le jour de la panne, de l'attaque, ou du pic imprévu.

• L'amateur découvre la panne par ses clients; le pro par ses alertes.
• L'amateur espère ne jamais restaurer; le pro restaure tous les mois pour s'entraîner.
• L'amateur soigne sa machine; le pro peut la remplacer en minutes.

Ce diaporama monte l'équipement de ces mauvais jours : des serveurs DÉDIÉS aux opérations.

Le serveur de surveillance

La surveillance mérite SA machine, séparée de ce qu'elle surveille. La raison est limpide : si le serveur web meurt et que la surveillance vivait dessus... qui vous préviendra ?

• Chaque machine surveillée exécute un petit agent qui rapporte ses signes vitaux : processeur, mémoire, disque, services.
• Le serveur de surveillance collecte, trace les courbes, et surtout alerte : courriel ou message quand un seuil casse.
• Outils du métier : Netdata pour le tableau de bord immédiat, Prometheus et Grafana pour l'arsenal complet, Zabbix chez les classiques. Le principe est le même partout.

Le serveur de sauvegarde, qui TIRE

Même logique : la sauvegarde mérite sa machine. Et un détail d'architecture sépare les survivants des victimes : le sens du transfert.

Règle d'or : celui qui pourrait être attaqué ne doit jamais pouvoir détruire ses propres sauvegardes.

La règle 3-2-1

Et la rétention : garder plusieurs générations (quotidiennes, hebdomadaires, mensuelles). Une corruption découverte au jour 9 se répare avec la copie du jour 8... si elle existe encore.

Une sauvegarde jamais restaurée n'existe pas

• La sauvegarde qui échoue en silence est un classique tragique : le script tourne, le fichier est vide, personne ne regarde.
• Le rituel du pro : restaurer RÉGULIÈREMENT, sur une machine de test, chronomètre en main.
• Deux chiffres à connaître pour son entreprise : combien de temps pour revenir en ligne (l'objectif de reprise), et combien de données on accepte de perdre (l'objectif de perte : une heure ? une journée ?).
• Ces deux chiffres décident de tout le reste : la fréquence des sauvegardes et le degré d'automatisation du pivot.

Le pivotage : le plan de match du pire jour

Attaque réussie ou panne fatale : on ne répare pas un serveur compromis, on le remplace. Le plan de match, écrit d'avance et répété :

• Isoler : couper la machine malade du réseau. On ne discute pas avec un serveur compromis.
• Réinstancier : une machine neuve, propre, chez le fournisseur.
• Rejouer la partition : Docker et la recette remontent l'application en minutes.
• Restaurer : les données reviennent du serveur de sauvegarde (la copie que l'attaquant n'a pas pu toucher).
• Rebrancher : l'adresse publique (DNS ou IP) bascule vers la machine neuve.

Sans conteneurs ni sauvegardes tirées, ce plan prend des jours. Avec eux : des minutes. C'est TOUT le module 1 qui devient un plan de survie.

Ce qu'on loue vraiment dans l'infonuagique

Un forfait de serveur virtuel, c'est quatre chiffres : processeurs virtuels, mémoire vive, disque, transfert réseau. Exemple d'échelle typique (Linode, facturé à l'heure) :

La facturation à l'heure change la mentalité : une machine n'est plus un achat, c'est un robinet. On ouvre, on ferme, on redimensionne. Mais redimensionner... comment, au juste ?

Peut-on vraiment « étirer » un serveur ?

Oui... avec des guillemets. Le redimensionnement (resize) existe chez tous les fournisseurs, mais voici ce qui se passe vraiment :

• La machine est éteinte (ou migrée) : le serveur virtuel déménage souvent vers un hôte physique plus gros. Comptez des minutes d'interruption.
• Au redémarrage : plus de processeurs et plus de mémoire, immédiatement visibles. Ça, ça suit tout seul.
• Vers le HAUT, donc : oui, on étire. Vers le BAS, c'est une autre histoire (diapositive suivante).

L'étirement n'est pas magique : c'est un déménagement organisé par le fournisseur. Rapide, mais pas invisible.

Et le système de fichiers, va-t-il suivre ?

LA question piège, et la réponse est : pas tout seul, pas toujours. Trois étages doivent grandir, dans l'ordre :

• Bonne nouvelle : les images infonuagiques modernes (cloud-init) font souvent ces étapes toutes seules au démarrage. Mais le pro VÉRIFIE avec df -h au lieu d'y croire.
• Le piège en sens inverse : un système de fichiers ext4 ne rétrécit pas à chaud. Pour DESCENDRE de forfait, il faut réduire le disque d'abord, démonté, à froid - laborieux et risqué. L'ascenseur monte bien mieux qu'il ne descend.

Étirer ou réinstancier ?

La leçon troupeau : quand la recette et les sauvegardes sont solides, réinstancier devient PLUS SIMPLE qu'étirer. C'est le signe qu'une opération est devenue robuste.

L'équipement des mauvais jours

• La surveillance et la sauvegarde vivent sur leurs PROPRES serveurs; la sauvegarde TIRE, elle n'attend pas qu'on la pousse.
• 3 copies, 2 supports, 1 hors site - et des restaurations répétées, chronomètre en main.
• Le pivotage est un plan écrit : isoler, réinstancier, rejouer, restaurer, rebrancher.
• Étirer un serveur marche vers le haut (avec interruption, et growpart + resize2fs pour que le système de fichiers suive); descendre est pénible; réinstancier est souvent la voie robuste.

Au laboratoire de la semaine 5, tout ceci devient concret : vous surveillez, vous sauvegardez, vous détruisez... et vous restaurez, chronomètre en main.