Aller au contenu

Preuves et rétention

La fenêtre SLA d’un incident court de la confirmation par le quorum au rétablissement confirmé : les deux mêmes instants dont vous avez été averti. Quand un faux positif est écarté, la fenêtre d’exclusion qui en découle est calculée région par région : du dernier check réussi avant l’incident au premier check réussi après. Aucune minute n’est étirée pour flatter le chiffre.

Un incident entre dans le rapport s’il chevauche la période couverte. Deux catégories en sont écartées :

  • Les incidents exclus : une indisponibilité que vous avez écartée comme faux positif. L’exclusion est votre décision enregistrée, et la compter aussi dans les chiffres l’appliquerait deux fois.
  • Les incidents supprimés.

Les fenêtres de maintenance annoncées qui concernent le monitor figurent dans le rapport comme catégorie à part, si bien que le rapport montre exactement ce qui était prévu et ce qui ne l’était pas.

Les rapports portent les événements que vous publiez

Section intitulée « Les rapports portent les événements que vous publiez »

La chronologie d’un incident dans un rapport SLA contient les événements explicitement marqués publics. La visibilité d’un événement est internal par défaut, un événement ne sort donc que lorsque quelqu’un le publie.

Le filtre se trouve dans la requête qui construit le rapport, et il s’applique ainsi à chaque chemin qu’emprunte un rapport. Un rapport est fait pour sortir de la maison : il part chez des clients et des auditeurs. Le filtre dans la requête garantit qu’il ne porte jamais plus que ce qui peut sortir.

Pour qu’une note interne apparaisse dans une preuve destinée aux clients, marquez-la publique. Tout le reste reste interne par défaut.

La disponibilité est arrondie vers le bas, jamais vers le haut : un chiffre de SLA doit être une borne inférieure que vous pouvez défendre. L’exemple de rapport SLA montre la structure complète, avec des chiffres qui tombent juste. Donnez-le à qui vous voulez, qu’il refasse le calcul.

Les fenêtres sont de 7 jours (Free), 30 jours (Pulse), 90 jours (Sentinel), 365 jours (Command) et 730 jours (Enterprise). Perstat les applique par type de donnée, chacun avec son propre horizon :

Donnée ou vue Horizon appliqué
Historique public des incidents résolus liés à un monitor Limite de lecture à la fenêtre de la formule. L’incident n’est pas supprimé automatiquement.
Checks bruts des sondes externes La purge physique utilise la fenêtre de la formule plus une marge technique de 2 jours.
Courbes brutes des mesures de l’agent hôte Jusqu’à 90 jours, dans toutes les formules.
Historique d’uptime d’une page de statut Jusqu’à 365 jours, dans toutes les formules.
Agrégats quotidiens, versions d’incidents et de post-mortems, activité et autres enregistrements Cycle de vie propre à l’objet, indépendant de la fenêtre de la formule. Certains n’expirent actuellement pas automatiquement.

Les CGV indiquent par ailleurs 13 mois comme durée standard pour les données de mesure et d’événement. Cette page décrit le comportement du produit par type de donnée sans remplacer les conditions contractuelles. Confirmez les conditions de rétention applicables via la revue de sécurité avant achat ou déploiement.

Perstat fournit sur demande un export de l’organisation en CSV avec manifeste, et un export en libre-service est prévu. Avec une clé API, l’API REST lit à tout moment les monitors, les checks, les séries temporelles et les incidents. Pour une demande de sortie et le processus de suppression, suivez la voie décrite sur la page sécurité.

Perstat apporte horodatages système, mesures, maintenance et curation visible au travail plus large derrière un rapport d’assurance ou une notification DORA. Le rapport, la déclaration et la décision de conformité restent entre les mains de vos auditeurs et de votre équipe conformité. La page preuves pour la direction décrit ce partage des rôles avec précision.