Évalue la supervision et l'exploitation d'une infrastructure

01Contrat de l’évaluation

assessmentId : BTS-SISR-Y2-OBS-001
blocs        : Bloc 1 + Bloc 2 SISR + Bloc 3
format       : TP évalué + incidents contrôlés + reprise + dossier de preuves
contexte     : SORIA Distribution — laboratoire synthétique
objectif     : définir → superviser → observer → qualifier → diagnostiquer → restaurer → prouver

Cette évaluation ne fournit ni suite de commandes ni chemin de menus Centreon. L’étudiant doit réutiliser les cours techniques, choisir ses checks et justifier ce qu’ils prouvent réellement.

02Contexte métier

SORIA Distribution veut exploiter son portail DMZ sans attendre qu’un utilisateur signale une panne.

Le laboratoire met à disposition :

MON-CENTREON01   : plateforme de supervision
WEB-DMZ01        : portail HTTPS publié en DMZ
SRV-DNS01        : résolution du nom du portail
CLIENT-EXT       : client légitime simulé
pare-feu         : politique de flux déjà validée

Le service métier attendu est :

https://portail.dmz.soria.test/

Le candidat ne doit pas déduire que ping = OK signifie que le portail fonctionne.

03Livrable A — stratégie de supervision

Avant toute configuration, remets une fiche couvrant au minimum trois niveaux de preuve :

NIVEAU HOTE    : l'équipement ciblé peut être contrôlé selon la politique retenue
NIVEAU RESEAU  : le poller atteint le service autorisé
NIVEAU SERVICE : le portail répond selon le protocole et le nom attendus

Pour chaque check :

Un check sans limite explicitée est incomplet.

04Livrable B — matrice de flux

Construis la matrice des communications réellement nécessaires à la supervision.

Elle doit distinguer :

poller -> cible supervisée
client -> service métier
administrateur -> console de supervision
flux explicitement interdits

Pour chaque flux autorisé, précise :

source
destination
protocole/port
justification
mécanisme de vérification
mécanisme de rollback

La désactivation globale du pare-feu invalide l’épreuve correspondante.

05Baseline saine obligatoire

Avant les incidents, constitue une baseline horodatée T0.

Elle doit prouver au minimum :

nom DNS du portail résolu depuis les points pertinents
service HTTPS accessible depuis CLIENT-EXT
check Centreon du portail sain
sortie du dernier check conservée
heure du dernier check conservée
politique réseau appliquée
un test négatif de flux interdit toujours refusé

Si la baseline n’est pas saine, l’étudiant doit corriger ou déclarer l’anomalie avant l’injection de panne.

06Incident A — le service métier tombe

Le formateur sélectionne une panne qui rend le portail indisponible sans casser volontairement Centreon.

Exemples admissibles :

service frontal arrêté
configuration de service invalide déjà préparée pour rollback
écoute HTTPS supprimée dans le laboratoire

Le candidat doit fournir une chronologie :

T1 = début de panne
T2 = premier symptôme utilisateur observable
T3 = changement d'état de supervision
T4 = incident qualifié
T5 = cause localisée
T6 = service restauré
T7 = recovery confirmé

Les durées mesurées sont des observations du laboratoire, pas des SLA universels.

07Prise en compte de l’alerte

Lorsque l’état non sain est confirmé, l’étudiant doit montrer comment il signale la prise en charge de l’incident.

Le commentaire ou la trace associée doit contenir :

responsable de la prise en charge
heure
symptôme constaté
hypothèse actuelle
prochaine action
référence du ticket ou de l'épreuve

Question orale obligatoire :

Pourquoi un acknowledgement ne constitue-t-il pas une correction ?

Une maintenance planifiée doit être distinguée d’un incident réel. L’utilisation d’un downtime pour masquer rétroactivement l’incident invalide la preuve de détection.

08Diagnostic de l’incident A

Le candidat choisit ses contrôles et les ordonne par hypothèses.

Le raisonnement doit distinguer au minimum :

DNS
connectivité / filtrage
écoute TCP
TLS
frontal web
backend si applicable
ressources système si un symptôme le justifie

Il n’est pas demandé d’exécuter toutes les commandes connues. Il faut sélectionner les observations qui discriminent les hypothèses.

09Restauration et recovery

Après correction, la recette doit repartir du point de vue de l’utilisateur puis revenir vers la supervision :

CLIENT-EXT accède au portail
→ DNS/TLS/service sont cohérents
→ le check Centreon redevient sain
→ l'événement de recovery est identifiable
→ le test négatif réseau reste négatif

Le dossier doit montrer l’état avant incident, pendant incident et après restauration.

10Incident B — le service reste sain mais la supervision se trompe

Le deuxième incident doit être d’une autre nature.

Le formateur choisit par exemple :

flux poller -> cible bloqué
paramètre du check erroné
nom utilisé par le check incorrect
secret/communauté de laboratoire invalide si le scénario en utilise un
plugin incapable d'exécuter le contrôle attendu

Contrainte : le portail doit rester accessible depuis le client légitime.

Le candidat doit démontrer simultanément :

service métier sain côté client
supervision non saine ou UNKNOWN selon le cas
cause située dans le chemin ou la configuration de monitoring
correction ciblée
retour du check à l'état sain

11Question de discrimination

Le candidat remplit le tableau à partir de ses observations :

Il doit expliquer pourquoi aucune colonne, prise isolément, ne suffit toujours à identifier la cause racine.

12Seuils et qualité des alertes

Si un check utilise un seuil, le candidat doit justifier :

mesure
unité
valeur WARNING
valeur CRITICAL
impact visé
risque de faux positif
risque de faux négatif

Aucun « seuil BTS » n’est fourni. Une valeur non justifiée est traitée comme un choix arbitraire.

Pour un check fonctionnel binaire, le candidat peut expliquer pourquoi un seuil numérique serait artificiel.

13Sécurité de la supervision

Le dossier doit prouver que la mise en place des checks n’a pas dégradé la politique de sécurité.

Contrôles attendus :

console Centreon non publiée vers CLIENT-EXT
flux poller limités au besoin
aucun secret dans les captures ou livrables
compte/check non privilégié lorsque possible
administration séparée de la simple collecte
règle temporaire supprimée si elle n'est plus nécessaire

Toute règle « any/any » créée uniquement pour faire fonctionner l’épreuve doit être corrigée et documentée avant validation.

14Comparaison des deux modèles étudiés

Le candidat rédige une courte comparaison entre :

Centreon : hôtes, services, checks, états, exploitation d'incident
Prometheus : métriques, séries temporelles, règles et alerting

La réponse ne doit pas chercher un gagnant. Elle doit expliquer ce que chaque approche rend observable dans le laboratoire et où leurs périmètres se recouvrent ou se complètent.

15Dossier de preuves final

Le candidat remet :

1. stratégie de supervision ;
2. matrice de flux ;
3. baseline T0 ;
4. configuration logique des hôtes/services/checks ;
5. preuves incident A ;
6. preuve de prise en charge ;
7. diagnostic et correction A ;
8. recovery A ;
9. preuves incident B ;
10. diagnostic et correction B ;
11. tests positifs et négatifs après remise en état ;
12. limites et risques de faux positifs/faux négatifs.

Chaque preuve suit le contrat :

EXIGENCE
→ CONTEXTE
→ ACTION
→ RESULTAT / VERIFICATION
→ LIMITE

Aucun secret, donnée personnelle réelle ou topologie de production n’est accepté dans le dossier.

16Critères d’évaluation

Une solution techniquement fonctionnelle mais obtenue en désactivant les contrôles de sécurité ou en masquant les alertes ne satisfait pas l’évaluation.