Épreuve blanche n° 2 : être alerté quand l'intranet tombe

Reformulation. « Superviser l'intranet comme le voit un utilisateur, pas seulement les serveurs ; alerter par courriel en moins de 5 minutes en cas d'indisponibilité, dès 85 % de disque sur les serveurs web, et au retour à la normale ; fournir une procédure à l'astreinte. »

Implicites et hypothèses.

• Le test doit passer par le chemin des utilisateurs : nom DNS, HAProxy, HTTPS. Un processus HAProxy actif ne prouve rien : sans serveur disponible, il répond une erreur 503.
• Une page d'erreur peut répondre 200 : je vérifie aussi un texte de la page (« Intranet Ravelle »).
• Flux : ZABBIX, dans le VLAN 30, doit joindre 10.10.20.30 en TCP 443. Les règles actuelles autorisent le 10050, le SSH et le DNS vers les contrôleurs de domaine (TCP/UDP 53, nécessaire à tout le VLAN d'administration) ; il manque le 443 : une règle à ajouter sur l'interface du VLAN 30.
• Résolution : ZABBIX doit résoudre intranet.ravelle.lan, donc utiliser les DNS de l'annuaire ; le flux DNS est déjà ouvert, je le vérifie quand même avant de configurer le scénario.
• Certificat : émis par l'autorité interne. Le scénario web de Zabbix ne vérifie pas le certificat par défaut ; je le laisse ainsi et je le dis.
• Ambiguïté à signaler : le contrat de service couvre 8 h à 19 h. « Faut-il alerter la nuit ? Je propose d'alerter à toute heure pour l'intranet ; si l'astreinte ne couvre que les heures ouvrées, on limite la période active du média de l'utilisateur. »
• « En moins de 5 minutes » : un test chaque minute donne une détection en 1 à 2 minutes, et laisse de la marge pour la livraison du courriel.

Spécifications techniques.

Démarche. Instantané de ZABBIX ; règle de pare-feu et test curl -skI https://intranet.ravelle.lan/ depuis ZABBIX ; hôte et scénario ; déclencheur ; macros ; action ; tests de déclenchement ; procédure d'astreinte ; rapport de test.

Cahier de recette.

1. « Parce que l'incident de mardi l'aurait raté : HAProxy tournait, mais sans serveur disponible il répondait une erreur 503. Le scénario web teste ce que voit l'utilisateur : le nom, le répartiteur, le certificat, un serveur web, le contenu de la page. »
2. « Une seule règle : de 10.10.30.20 vers 10.10.20.30, TCP 443. Le serveur de supervision n'a pas besoin d'atteindre tout le VLAN serveurs sur tous les ports. Si Zabbix était compromis, chaque flux ouvert serait une porte de plus. »
3. « Non. Sur un disque de 20 Go, 15 % libres font 3 Go ; sur un disque de 2 To, 300 Go. Pour les serveurs web de 20 Go, 85 % laisse le temps d'agir, d'après la vitesse de remplissage observée lors de l'incident. Sur les gros volumes, je combinerais un seuil en espace libre absolu ou une prévision de remplissage. »
4. « Personne aujourd'hui, et c'est une limite : si ZABBIX tombe, plus aucune alerte. Je proposerais un contrôle externe minimal, par exemple une tâche planifiée sur SRV-BAK qui vérifie que l'interface de Zabbix répond et envoie un courriel sinon. Je le note dans les perspectives, ce n'est pas dans la demande. »

La réalisation, étape par étape.

1. Instantané de ZABBIX. Sur pfSense, interface du VLAN 30 : règle « autoriser TCP 10.10.30.20 vers 10.10.20.30 port 443 », placée avant les blocages. Depuis ZABBIX : getent hosts intranet.ravelle.lan renvoie 10.10.20.30, puis curl -skI https://intranet.ravelle.lan/ renvoie HTTP/1.1 200 OK.
2. Data collection > Hosts > Create host : Intranet, groupe Services web, aucune interface.
3. Sur cet hôte, onglet Web puis Create web scenario : nom Intranet, intervalle 1m. Onglet Steps : étape Accueil, URL https://intranet.ravelle.lan/, Required string Intranet Ravelle, Required status codes 200, Timeout 15s.
4. Sur l'hôte Intranet, Triggers > Create trigger : nom « Intranet injoignable pour les utilisateurs », gravité High, expression last(/Intranet/web.test.fail[Intranet])<>0.
5. Sur WEB1 et WEB2, onglet Macros : {$VFS.FS.PUSED.MAX.WARN:"/"} = 85.
6. Alerts > Actions > Trigger actions : l'action existante du service informatique reçoit la condition « groupe d'hôtes = Services web » (en plus de Serveurs web) et une gravité minimale Warning ; dans Recovery operations, « notifier toutes les personnes impliquées ».
7. Tests T1 à T6, avec l'heure de chaque événement notée dans le journal.
8. Documentation, puis rapport de test.

La procédure d'astreinte (extrait de la documentation technique) : alerte « Intranet injoignable pour les utilisateurs ».

1. Ouvre Zabbix (https://zabbix.ravelle.lan) depuis le poste d'administration : Monitoring > Problems. D'autres problèmes en même temps (disque, serveur indisponible) ?
2. Sur SRV-LB : systemctl status haproxy, puis echo "show servers state" | socat stdio /run/haproxy/admin.sock. Combien de serveurs web sont disponibles ?
3. Sur chaque serveur web indisponible : df -h /, systemctl status nginx, journalctl -u nginx --since "-1h".
4. Disque plein : journalctl --vacuum-size=200M et suppression des anciens journaux Nginx compressés ; puis systemctl restart nginx.
5. Vérifie que l'alerte passe en « résolu » et que l'intranet répond depuis un poste du VLAN 10.
6. Non résolu en 30 minutes : appelle le responsable informatique. Plus de 15 minutes d'indisponibilité : préviens les utilisateurs par la liste de diffusion.
7. Ouvre un ticket d'incident dans GLPI avec l'heure de détection, les actions et l'heure de retour à la normale.

Le rapport de test.

Le déroulé de la recette. Rappel du besoin. T1 à l'écran (Monitoring > Web, le scénario au vert). T2 et T3 en direct : arrêt de HAProxy, apparition du problème, courriel dans la boîte du service, redémarrage, courriel de rétablissement. T4 et T5 montrés par leurs captures si le temps manque. Puis la procédure d'astreinte et le rapport de test.

1. Arrête HAProxy sur SRV-LB et commente pendant l'attente : « Le scénario s'exécute chaque minute ; le prochain passage échouera, le déclencheur passera en problème et l'action enverra le courriel. » Montre le problème, puis le courriel avec son heure.
2. « C'est le choix que j'ai proposé en phase 1 : l'intranet est critique, et l'alerte la nuit permet d'agir avant 8 h. Si le cabinet n'a pas d'astreinte la nuit, je limite la période d'activité du média courriel de l'utilisateur, par exemple 1-5,08:00-19:00, et l'alerte de la nuit sera vue au matin dans Zabbix. C'est une décision du responsable, pas la mienne. »
3. « La supervision détecte, elle ne prévient pas la cause. La cause de mardi était la rotation des journaux de Nginx : je vérifie /etc/logrotate.d/nginx (rotation quotidienne, 14 fichiers gardés, compression) et je teste avec logrotate -d /etc/logrotate.d/nginx. C'est le passage de l'incident au problème. »
4. « Le risque est faible ici : Zabbix et l'intranet sont dans le même réseau interne, et un certificat expiré ferait de toute façon échouer l'accès des utilisateurs. Mais un certificat qui expire est une panne annoncée : j'ajouterais une alerte sur la date d'expiration du certificat, 30 jours avant, avec l'élément de Zabbix agent 2 qui lit le certificat d'un site web. »