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 : le paiement échoue après la fermeture du bureau
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 boutique en ligne compte quatre ingénieurs. A 22h40, sa surveillance détecte les demandes de paiement échouées alors que les clients sont encore en train de payer. Un message dans le chat général n’indique pas au support qui gère le problème. Les achats inachevés et une file d'attente d'assistance croissante constituent le risque commercial ; l'alerte elle-même n'est que le signal.
Workflow avec IR. Envoyez l'alerte de facturation au répondeur principal actuel. Si personne ne le reconnaît, la politique est déplacée vers la sauvegarde nommée. L'ingénieur désigné reconnaît le groupe et enquête ; Le support peut utiliser le processus d'incident convenu pour trouver ce propriétaire et obtenir une mise à jour. Testez cette chaîne avec la paire de panne et de récupération ci-dessous.
Avantage opérationnel à valider. Remplacez la recherche manuelle d'un ingénieur disponible par une chaîne de propriété prédéfinie. Gardez la responsabilité visible tout au long du transfert plutôt que de supposer qu'un message de discussion envoyé signifie que quelqu'un y travaille.
Ce qu'il faut mesurer. Enregistrez le temps écoulé entre la première alerte exploitable et ACK, la part reconnue au sein de votre cible interne et le nombre de réaffectations manuelles. Suivez séparément les échecs de paiement et le temps écoulé avant la reprise des paiements réussis dans la surveillance du commerce.
Boundary. IR ne répare pas les caisses ni les prestataires de paiement. Un ACK ne prouve pas que les clients peuvent payer à nouveau, et une politique de remontée d'informations ne peut pas aider si aucun des ingénieurs n'est joignable. Conservez le chemin de contact de secours et un véritable contrôle de recouvrement des paiements.
Quatre ingénieurs, un service de facturation, une chaîne de propriété
Supposons que quatre ingénieurs partagent la prise en charge d'une facturation API. Commencez avec une équipe et une rotation primaire hebdomadaire. Donnez à l'itinéraire un service par défaut et un canal de livraison testé. Ajoutez explicitement une personne de secours ; une salle de discussion partagée n’est pas une politique de remontée d’informations.
| Objet | Exemple de paramètre dans l'interface utilisateur |
|---|---|
| Propriété | Équipe payments ; service billing-api ; rotation payments-primary avec quatre membres actifs et une couverture de 24/7. |
| Admission | Source webhook, service par défaut billing-api, mode d'escalade des règles et canaux de notification associés. |
| Escalade | Règle 1 : rotation primaire, délai 300 secondes. Règle 2 : un utilisateur de sauvegarde nommé, délai de 600 secondes. Définissez repeat_count=0 pour ce pilote. |
Configurez les canaux et les contacts du répondeur avant d'envoyer une alerte. Ouvrez les diagnostics d'intégrité d'astreinte : le résumé du tableau vert à lui seul n'analyse pas la couverture future ni ne prouve qu'un message parvient à un téléphone.
Envoyer un échec, puis sa récupération
Envoyez ces JSON corps séparément à POST /api/integrations/webhook avec Content-Type: application/json et Authorization: Bearer ROUTE_TOKEN. Remplacez l'espace réservé par le jeton d'itinéraire de test de l'interface utilisateur ; gardez-le hors du contrôle de source et des journaux partagés. Il s'agit du format webhook générique, et non d'un événement de simulateur normalisé.
{
"status": "firing",
"fingerprint": "billing-api:health:prod",
"title": "Billing API health check failed",
"severity": "critical",
"labels": {
"alertname": "BillingUnavailable",
"environment": "production",
"service": "billing-api"
}
}{
"status": "resolved",
"fingerprint": "billing-api:health:prod",
"title": "Billing API health check failed",
"severity": "critical",
"labels": {
"alertname": "BillingUnavailable",
"environment": "production",
"service": "billing-api"
}
}Conservez les mêmes étiquettes d’itinéraire, d’empreinte digitale et de regroupement pour la récupération. L'empreinte digitale identifie l'alerte enfant ; le remplacer par une nouvelle valeur aléatoire à chaque requête annule la déduplication. Une récupération orpheline ne crée pas de nouveau groupe.
Prouvez la chaîne avant un vrai quart de nuit
- Envoyez le corps de tir deux fois. Attendez-vous à une alerte enfant, au service prévu et au responsable principal actuel ; confirmer la livraison réelle, pas seulement un HTTP succès.
- Laissez une alerte de test distincte sans accusé de réception. Vérifiez que la sauvegarde devient la cible après le premier délai de stratégie. La cadence du planificateur, la file d'attente et la livraison par le fournisseur signifient qu'il ne s'agit pas d'un SLA de livraison exact en cinq minutes.
- Accusez réception d'un autre groupe de test et vérifiez que les notifications en attente de déclenchement uniquement s'arrêtent. Envoyez la récupération et confirmez que le groupe se résout lorsqu'il ne reste plus d'enfants licenciés.
- Créez un remplacement de rotation temporaire et répétez le test. Confirmez que le remplacement est le destinataire effectif, puis supprimez la configuration de test.
Sachez quand la chaîne s'arrête
En mode Stratégie, les escalades basées sur des rappels d'équipe sont ignorées. Une fois que toutes les règles et répétitions autorisées sont épuisées, les rappels de politique s'arrêtent ; l'alerte peut toujours être déclenchée. Une personne de secours sans coordonnées professionnelles n'est qu'un nom dans une base de données.
ACK est la propriété et non la récupération du service de facturation. IR ne peut pas réparer l'application ni fournir un ingénieur manquant. Conservez un moyen externe de joindre l'équipe si IR ou son fournisseur de notification n'est pas disponible, et convenez de cette solution de secours lors de l'intégration.