Aller au contenu
IT White GloveConseil TI · Canada
Menu

Guide de surveillance et de correctifs · Canada · FR / EN

Savoir comment vous sauriez vraiment qu’un problème est survenu pendant la nuit.

This guide is maintained in English as well. Monitoring and patching →

La plupart des organisations présument que la surveillance et l’application des correctifs se font parce qu’un outil a été installé un jour. La bonne question n’est pas si un outil existe — c’est quelle preuve démontrerait, cette semaine, qu’une panne a été détectée, qu’une alerte a atteint une personne et qu’un correctif s’est réellement appliqué.

La décision à rendre possible

Décider ce qui est réellement surveillé, qui est alerté et à quelle vitesse, et quelle preuve — pas quelle présomption — démontre que surveillance et correctifs fonctionnent.

Séparer ce qui est installé de ce qui est surveillé

Un agent de surveillance installé sur un serveur prouve que l’agent existe, pas que quelqu’un observe ce qu’il rapporte. Confirmez qui reçoit les alertes, si ces alertes se rendent quelque part les soirs et fins de semaine, et ce qui arrive si personne n’accuse réception d’une alerte.

  • Quels systèmes ont des agents de surveillance installés et actifs
  • Qui reçoit réellement les alertes générées par ces agents
  • Ce qui arrive à une alerte que personne n’accuse réception dans un délai fixé

Demander ce qui compte comme preuve, pas un tableau de bord vert

Un tableau de bord montrant surtout des cases vertes peut quand même cacher une tâche de sauvegarde arrêtée silencieusement depuis des semaines ou un cycle de correctifs qui saute un sous-ensemble de machines à chaque fois. Demandez la preuve derrière la couleur du résumé — l’horodatage réel du dernier succès, pas l’icône.

Confirmer que la cadence de correctifs couvre ce qui en a vraiment besoin

Les mises à jour du système d’exploitation sont la partie visible des correctifs; les logiciels d’affaires, le micrologiciel de l’équipement réseau et les applications tierces sont la partie qui prend silencieusement du retard. Nommez ce qui est couvert par le processus actuel de correctifs et ce qui en est explicitement exclu.

  • Systèmes d’exploitation, applications et micrologiciels couverts par le processus actuel
  • Ce qui est explicitement exclu, et qui a accepté cette exclusion
  • Comment une tentative de correctif échouée ou sautée est détectée et reprise

Tester le chemin d’alerte, pas seulement l’outil de surveillance

La valeur de la surveillance est la réponse humaine derrière elle. Testez périodiquement si une vraie alerte atteint la bonne personne, à un moment où cela compterait, par un canal qu’elle consulte réellement — plutôt que de faire confiance à l’écran de configuration qui indique que les notifications sont activées.

Cadre de décision

Ce que la direction devrait pouvoir vérifier.

Ces critères ne produisent pas une note. Ils rendent visibles les questions qui doivent être résolues avant une décision responsable.

CritèreSignal utileQuestion de direction
CouvertureChaque système important a une surveillance active et confirmée — pas seulement un logiciel installé.Quels systèmes n’ont aucune surveillance, et qui a accepté cet écart?
PreuveLes états rapportés s’appuient sur un horodatage ou un journal, pas une couleur résumée.Qu’est-ce qui prouve que cette sauvegarde, ce correctif ou cette vérification a vraiment réussi la dernière fois?
Portée des correctifsLes systèmes couverts et exclus sont tous deux explicitement nommés.Qu’est-ce qui échappe silencieusement au cycle de correctifs actuel?
Chemin d’alerteLes alertes sont testées pour confirmer qu’elles atteignent une personne capable d’agir.Quand le chemin d’alerte a-t-il été testé pour la dernière fois avec un événement réel, pas simulé?

Scénarios pratiques

Le même cadre, appliqué à des décisions différentes.

Une sauvegarde a échoué silencieusement pendant trois semaines avant qu’on le remarque

Situation : Une sauvegarde planifiée a cessé de se compléter avec succès, et l’échec n’a été découvert que lorsqu’une restauration a été réellement nécessaire.

Réponse utile : Traitez ceci comme un échec de preuve, pas un échec d’outil — l’outil a probablement consigné l’échec; la lacune était dans qui devait voir et agir sur ce journal.

Limite : Ce guide n’effectue aucune récupération d’incident et n’évalue aucun produit de sauvegarde précis.

Un cycle de correctifs saute systématiquement un sous-ensemble de portables à distance

Situation : Les appareils souvent hors ligne pendant la fenêtre de correctifs planifiée accumulent silencieusement des mois de mises à jour manquantes.

Réponse utile : Confirmez quels appareils sont touchés, nommez-le comme une exception acceptée avec une échéance et une solution de contournement, ou ajustez l’horaire de correctifs pour vraiment atteindre ces appareils — plutôt que de le laisser non découvert.

Limite : Ce guide ne recommande aucune plateforme précise de RMM ou de gestion de correctifs.