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 : les clients SaaS travaillent sur plusieurs fuseaux horaires
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 équipe SaaS B2B sert des clients en Europe et en Amérique du Nord. L'après-midi de travail d'un client chevauche la soirée d'un autre ingénieur et l'intervenant habituel est en vacances. Sans horaire convenu, l’équipe s’appuie sur celui qui remarque le chat en premier. Le risque est une panne involontaire et des interruptions répétées pour le personnel hors service.
Workflow avec IR. Convenez d'une couverture en personnel, puis représentez-la avec une rotation de base et une couche de jours ouvrables. Enregistrez les substitutions de jours fériés en tant que remplacements et configurez une cible d'escalade de sauvegarde distincte. Vérifiez les transferts et les lacunes futures. Pour un déploiement de facturation planifié, utilisez une fenêtre de maintenance étendue au service pendant que les services non liés continuent de notifier.
Avantage opérationnel à valider. Rendre la responsabilité prévisible en matière d'assistance et d'ingénierie, y compris les congés et les transferts. Le travail prévu ne devrait pas nécessiter la mise en sourdine du flux d'alertes de l'ensemble de l'entreprise.
Ce qu'il faut mesurer. Examinez les minutes non couvertes au cours d'une période future définie, comme les 14 prochains jours, les transferts manuels de dernière minute et les accusés de réception dans le cadre de l'objectif de réponse de l'équipe. Comparez les notifications nocturnes par ingénieur avec le calendrier réel du personnel ; un calendrier équilibré à lui seul ne montre pas la charge de travail.
Limite. Un calendrier rempli ne crée pas de personnel supplémentaire et ne prouve pas que quelqu'un peut répondre. IR ne garantit pas un temps de réponse contractuel ni ne calcule la disponibilité des clients à partir des ACK. Gardez les décisions en matière de personnel, la surveillance des SLO et la communication avec les clients dans le processus opérationnel plus large.
Couvrir la nuit avant d'optimiser la journée de travail
Supposons qu'une équipe SRE possède une fiabilité de facturation sur une période de travail de jour ouvrable et une rotation de nuit. En une seule rotation, créez une couche de base avec la priorité 10 et une couverture illimitée 24 /7. Ajoutez une couche avec la priorité 20, limitée au lundi et vendredi, de 9h00 à 18h00 dans Europe/Berlin. Utilisez de vrais membres actifs et vérifiez le calendrier généré.
La couche active la plus prioritaire fournit le destinataire ; un remplacement est prioritaire sur les calques. Il ne s’agit pas de deux intervenants simultanés. Configurez une cible d’escalade ou une rotation distincte pour la couverture de sauvegarde. Si aucun calque n’est actif et qu’aucun remplacement ne s’applique, il n’y a pas de responsable. Consultez les règles de rotation et de calque.
Suspendre les notifications de facturation lors d'un déploiement planifié
Créez une fenêtre au niveau du service via l'interface ou soumettez cette configuration à POST /api/maintenance-windows à l'aide d'une session de gestion authentifiée API avec l'autorisation de modifier la portée. Un jeton de route d’admission n’est pas un titre de gestion. Remplacez 42 par votre ID de service de facturation actuel et choisissez une future fenêtre de test.
{
"name": "Billing deploy",
"behavior": "suppress_notifications",
"timezone": "Europe/Berlin",
"starts_at": "2026-10-20T10:00:00",
"ends_at": "2026-10-20T11:00:00",
"enabled": true,
"scopes": [
{
"scope_type": "service",
"service_id": 42
}
]
}Ces horodatages sont des heures d'horloge murale dans le fuseau horaire sélectionné, et non des valeurs UTC avec un Z omis. Pendant cette fenêtre, les alertes de facturation entrantes restent visibles, mais les notifications, rappels et escalades sont suspendus. Les autres services ne devraient pas être affectés. Ce comportement n'est pas suppress_incident, qui empêche les nouveaux AlertGroups, ni pause_escalation_only, qui maintient les notifications activées.
Testez les limites, pas seulement au milieu d'un quart de travail
- Inspectez la mission juste avant et après 9h00 et 18h00, pendant un week-end et un passage à l'heure d'été. Ajoutez un remplacement temporaire et confirmez qu'il gagne, puis supprimez-le.
- Ouvrez le bilan de santé d'astreinte complet. Passez en revue sa fenêtre future vérifiée, ses lacunes, ses membres inactifs et ses méthodes de livraison utilisables. Un résumé vert ne constitue pas une preuve de couverture permanente ou de livraison sur un téléphone.
- Envoyez des événements de facturation et de test de service non liés pendant la maintenance. Confirmez que la facturation est visible mais silencieuse et que le service non lié vous avertit toujours. Pour inclure des alertes déjà non résolues, activez explicitement l'option permettant d'appliquer la fenêtre aux alertes existantes ; il est désactivé par défaut.
- Laissez la facturation se déclencher à la fin de la fenêtre. Lorsque la réactivation est activée, vérifiez que les notifications normales reprennent sans rejouer chaque rappel manqué. Confirmez que le répondeur réel le reçoit et peut l'accuser de réception.
Un service silencieux n'est pas un service récupéré
La maintenance ne répare pas le service, ne retire pas les messages délivrés et n'implique pas de résolution. La réactivation à la fin est activée par défaut ; sa désactivation conserve l'effet de maintenance après la fin de la fenêtre. Les fenêtres qui se chevauchent peuvent maintenir une alerte silencieuse jusqu'à ce que le dernier effet actif ou retenu applicable soit libéré. Consultez ces commandes dans le guide de maintenance.
Conservez les calculs de SLO et la détection du taux de combustion dans votre pile de surveillance. L'IR achemine et coordonne les signaux résultants. Un AlertGroup possède l'accusé de réception technique, la résolution, les notifications et l'escalade ; un incident est un workflow opérationnel distinct. Lier plusieurs AlertGroups à un seul Incident ne fusionne pas leurs historiques techniques. Dans la version 2.3.1, les intervenants et les parties prenantes appartiennent toujours aux AlertGroups. Testez les deux cycles de vie au lieu de traiter un changement de statut d'incident comme un AlertGroup ACK.