Exemples concrets pour IncidentRelay v2.3.1, vérifiés le . Les noms, identifiants et horaires ci-dessous sont donnés à titre indicatif ; validez-les dans un déploiement de test avant d’utiliser les informations d’identification de production.
Exemple commercial · Configuration · Exemple pratique · Contrôles d'acceptation · Limites et modes de défaillance
Exemple commercial : une sauvegarde nocturne ne se termine jamais
Scénario illustratif, pas une étude de cas client. Les mesures ci-dessous sont des suggestions pour votre projet pilote, et non des économies mesurées ou une affirmation selon laquelle IR inclut chaque tableau de bord de reporting.
Situation et risque. Une entreprise sauvegarde sa base de données de commandes sur deux serveurs avant le début de la journée de travail. Un travail s'arrête silencieusement ; l'autre réussit. Un seul signal de réussite partagé masquerait l’écart. Le risque commercial réside dans la découverte d'un point de récupération ancien ou manquant uniquement lorsqu'une restauration est nécessaire.
Workflow avec IR. Définissez une date limite d'achèvement et suivez chaque serveur attendu séparément. Un hôte envoie son battement de cœur uniquement une fois le travail et les contrôles de réussite terminés. Une achèvement manquant crée une alerte de retard acheminée vers le répondeur de la plateforme, avec un chemin d'escalade de secours. L'ingénieur étudie ou réexécute le travail et enregistre le résultat.
Avantage opérationnel à valider. Transformez l'échec d'une tâche planifiée silencieuse en tâche détenue avant le prochain changement d'activité. Le même modèle peut couvrir une exportation planifiée ou une tâche par lots, à condition que son signal d’achèvement représente véritablement un succès.
Ce qu'il faut mesurer. Suivez les délais non respectés par serveur, le temps écoulé entre la date limite et l'accusé de réception et l'ancienneté de la dernière sauvegarde vérifiée. Conserver les résultats de la vérification des sauvegardes et des analyses de restauration dans le rapport du système de sauvegarde ou des opérations ; ne les déduisez pas d’un battement de cœur vert.
Limite. Un battement de cœur prouve qu'un signal est arrivé, et non que les données peuvent être restaurées. Cela ne garantit pas un point de récupération ou un temps de récupération. Testez les restaurations de manière indépendante et surveillez l'IR lui-même depuis l'extérieur du même domaine de défaillance.
Traitez le système de radiomessagerie comme un service que vous exploitez
Prenons l'exemple d'une équipe de plate-forme possédant un cluster de production et des sauvegardes de base de données nocturnes. Il veut que l'IR soit proche de sa pile de surveillance, mais cela rend également l'équipe responsable du système qui le réveille. Nommez un propriétaire pour le service Web, le planificateur, la base de données, les secrets et la procédure de récupération.
La version Docker configuration exécute les services Web et de planification séparément. Après avoir suivi ce guide de déploiement dans un environnement de test, inspectez-les à partir de la validation de la version :
docker compose ps
docker compose logs --tail=50 incidentrelay
docker compose logs --tail=50 incidentrelay-schedulerLe processus Web accepte les alertes entrantes ; le planificateur gère les rappels, les escalades et les tâches périodiques. Ne démarrez pas de planificateur dans chaque Web Worker. Une page de connexion fonctionnelle ne prouve pas qu’une escalade programmée est en cours.
Détecter une sauvegarde manquante sur un hôte
Créez un pulsation d'achèvement planifié dû quotidiennement à 03h00 UTC, associé à un itinéraire dont la source est heartbeat. Activer le suivi des instances ; pour une flotte fixe, utilisez des instances statiques attendues telles que db-1 et db-2. Attachez la rotation de la plateforme ou la politique et testez les canaux.
Une fois la sauvegarde d'un hôte et ses vérifications de réussite terminées, envoyez ce corps à POST /api/heartbeats/ping/HEARTBEAT_TOKEN avec le type de contenu JSON. Utilisez l'URL secrète de ce battement de cœur, et non un jeton de route ou un jeton d'administration API.
{
"status": "completed",
"instance": "db-1",
"payload": {
"job": "nightly-database-backup"
}
}Envoyez une valeur d'instance distincte à partir de chaque hôte. Sans suivi d'instance, un ping réussi provenant d'un serveur peut masquer la sauvegarde manquante d'un autre serveur. N'envoyez pas de ping de réussite sans condition à partir d'un gestionnaire de nettoyage du shell après l'échec d'une tâche. Supprimez les URL de ping secrètes des journaux de proxy et de tâches.
Échec du test, pas seulement au démarrage
- Pingez les deux instances attendues, puis omettez-en délibérément une dans un court programme de test. Attendez-vous à une alerte de retard pour cette instance pendant que l'instance saine reste OK.
- Reprenez l'instance manquante. Si la résolution automatique est activée, vérifiez que son alerte de retard est résolue sans résoudre l'échec d'une autre instance.
- Arrêtez le planificateur uniquement dans le déploiement de test. Observer l'effet sur le travail chronométré et prouver qu'un contrôleur indépendant le remarque ; puis restaurez-le et vérifiez le traitement.
- Restaurez la base de données, la configuration et les secrets requis dans un environnement isolé avec les notifications sortantes bloquées. Examinez les anciens groupes de tir avant d’autoriser la livraison, afin qu’un exercice de restauration ne puisse pas appeler les intervenants de production.
Un ping réussi n'est pas un test de restauration
Les battements de cœur détectent les signaux manquants ; ce ne sont pas des sondes HTTP/TCP actives et ne peuvent pas prouver qu'une sauvegarde est utilisable. IR ne peut pas non plus vous informer de manière fiable de sa propre panne totale. Conservez un contrôle de disponibilité externe et un chemin de contact distinct en dehors du même domaine de défaillance.
L'auto-hébergement ne supprime pas les dépendances en matière de chat, de courrier électronique, de voix ou de réseau. Décidez quelle base de données et quel modèle de déploiement correspondent à la charge de travail, épinglez la version testée et répétez les mises à niveau et les restaurations. Ces exemples n’établissent pas de haute disponibilité ni de garantie de débit.
Définissez délibérément la conservation : l'historique des alertes résolues est conservé indéfiniment par défaut. Le nettoyage peut également supprimer les commentaires liés et les enregistrements de livraison, et il ne réduit pas nécessairement le fichier de base de données. La conservation ne remplace pas les sauvegardes.