Supervision et astreinte

La plupart des pannes que nous reprenons n'ont pas été détectées par une alerte : elles ont été signalées par un client mécontent, souvent plusieurs jours après. Et l'inverse existe aussi, plus insidieux : une supervision qui envoie tant d'alertes que plus personne ne les lit. Une alerte doit être rare, exacte, et dire quoi faire. Nous surveillons la disponibilité, les erreurs applicatives, les ressources des serveurs, et surtout ce que personne ne surveille : les traitements de nuit qui devaient tourner et qui ne tournent plus.

Ce que vous recevez

Les livrables

• check_circleLes sondes en place, avec les seuils écrits et discutés
• check_circleLes journaux centralisés et consultables
• check_circleLe canal d'alerte : qui est prévenu, comment, sous quel délai
• check_circleLe compte rendu écrit après chaque incident : ce qui s'est passé, ce qui l'empêchera de revenir

Questions fréquentes

Vous intervenez la nuit et le week-end ?

Selon le contrat. Nous préférons être francs : une astreinte réellement permanente demande une organisation qu'une petite structure ne peut pas promettre sérieusement. Ce que nous tenons, nous l'écrivons ; ce que nous ne tenons pas, nous ne le vendons pas.

Combien de temps sont conservés les journaux ?

Un mois par défaut, ce qui couvre largement le diagnostic d'un incident. Plus longtemps si une obligation réglementaire l'impose — auquel cas la durée est décidée avec le registre de traitements, pas au hasard.

Vous supervisez une application que vous n'avez pas écrite ?

Oui. La disponibilité, les certificats, les ressources et les tâches planifiées se surveillent de l'extérieur, quelle que soit la technologie. La supervision fine des erreurs applicatives demande, elle, un accès au code.