Uitgewerkte voorbeelden voor IncidentRelay v2.3.1, gecontroleerd op . Namen, identificatiegegevens en tijdstippen hieronder zijn illustratief; valideer ze in een testimplementatie voordat u productiereferenties gebruikt.
Bedrijfsvoorbeeld · Opstelling · Uitgewerkt voorbeeld · Acceptatiecontroles · Limieten en foutmodi
Zakelijk voorbeeld: SaaS-klanten werken in verschillende tijdzones
Illustratief scenario, geen klantcasestudy. De onderstaande statistieken zijn suggesties voor uw pilot, geen gemeten besparingen of een bewering dat IR elk rapportagedashboard omvat.
Situatie en risico. Een B2B SaaS-team bedient klanten in Europa en Noord-Amerika. De werkdag van een klant overlapt de avond van een andere monteur en de gebruikelijke hulpverlener is op vakantie. Zonder een afgesproken schema vertrouwt het team op degene die de chat als eerste opmerkt. Het risico is een storing zonder eigenaar en herhaalde onderbrekingen voor personeel buiten dienst.
Workflow met IR. Maak afspraken over de bemande dekking en geef deze vervolgens weer met een basisrotatie en een werkdaglaag. Registreer vakantievervangingen als overschrijvingen en configureer een afzonderlijk back-up-escalatiedoel. Controleer overdrachten en toekomstige hiaten. Voor een geplande factureringsimplementatie gebruikt u een servicegericht onderhoudsvenster, terwijl niet-gerelateerde services meldingen blijven geven.
Operationeel voordeel om te valideren. Maak de verantwoordelijkheid voor ondersteuning en engineering, inclusief verlof en overdracht, voorspelbaar. Geplande werkzaamheden mogen niet vereisen dat de waarschuwingsstroom van het hele bedrijf wordt uitgeschakeld.
Wat u moet meten. Bekijk de niet-gedekte minuten in een bepaalde toekomstige periode, zoals de komende veertien dagen, handmatige overdrachten op het laatste moment en bevestigingen binnen het reactiedoel van het team. Vergelijk nachtelijke meldingen per monteur met de daadwerkelijke bezettingsplanning; een evenwichtige kalender alleen laat de werkdruk niet zien.
Grens. Een gevulde agenda zorgt niet voor extra personeel en bewijst niet dat iemand kan reageren. IR garandeert geen contractuele responstijd en berekent de beschikbaarheid van klanten niet op basis van ACK's. Houd personeelsbeslissingen, SLO-monitoring en klantcommunicatie in het bredere bedrijfsproces.
Bedek de nacht voordat u de werkdag optimaliseert
Stel dat een SRE-team eigenaar is van de factureringsbetrouwbaarheid tijdens een werkdag en een nachtrooster. Maak in één rotatie een basislaag met prioriteit 10 en onbeperkte 24/7 dekking. Voeg een laag toe met prioriteit 20, beperkt tot maandag t/m vrijdag, 09:00-18:00 in Europe/Berlin. Gebruik echte actieve leden en verifieer de gegenereerde kalender.
De actieve laag met de hoogste prioriteit levert aan de rechtverkrijgende; een overschrijving heeft voorrang op lagen. Dit zijn geen twee gelijktijdige responders. Configureer een afzonderlijk escalatiedoel of rotatie voor back-updekking. Als er geen laag actief is en er geen overschrijving van toepassing is, is er geen rechthebbende. Zie rotatie- en laagregels.
Onderbreek factureringsmeldingen tijdens een geplande implementatie
Maak een servicegericht venster via de interface, of dien deze configuratie in bij POST /api/maintenance-windows met behulp van een geverifieerde beheer-API-sessie met toestemming om het bereik te wijzigen. Een intakeroutetoken is geen managementreferentie. Vervang 42 door uw werkelijke factureringsservice-ID en kies een toekomstige testperiode.
{
"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
}
]
}Deze tijdstempels zijn wandkloktijden in de geselecteerde tijdzone, geen UTC-waarden met een weggelaten Z. Tijdens deze periode blijven inkomende factuurwaarschuwingen zichtbaar, maar worden meldingen, herinneringen en escalaties onderbroken. Andere diensten moeten onaangetast blijven. Dit gedrag is niet suppress_incident, waardoor nieuwe AlertGroups worden voorkomen, of pause_escalation_only, waardoor meldingen ingeschakeld blijven.
Test de grenzen, niet alleen midden in een dienst
- Inspectieopdracht vlak voor en na 09.00 uur en 18.00 uur, verspreid over een weekend en een zomer-overgang. Voeg een tijdelijke overschrijving toe, bevestig dat deze wint en verwijder deze vervolgens.
- Open de volledige check voor gezondheid op afroep. Bekijk het gecontroleerde toekomstige venster, hiaten, inactieve leden en bruikbare leveringsmethoden. Een groene samenvatting is geen bewijs van dekking voor altijd of bezorging op een telefoon.
- Verzend facturerings- en niet-gerelateerde servicetestgebeurtenissen tijdens onderhoud. Bevestig dat de facturering zichtbaar maar stil is en dat de niet-gerelateerde service nog steeds een melding geeft. Als u reeds onopgeloste waarschuwingen wilt opnemen, schakelt u expliciet de optie in om het venster op bestaande waarschuwingen toe te passen; het is standaard uitgeschakeld.
- Laat de facturering geactiveerd worden wanneer de periode eindigt. Als reactivering is ingeschakeld, controleert u of de normale melding wordt hervat zonder elke gemiste herinnering opnieuw af te spelen. Bevestig dat de daadwerkelijke responder het ontvangt en het kan bevestigen.
Een stille dienst is geen herstelde dienst
Onderhoud herstelt de service niet, trekt afgeleverde berichten niet in en impliceert geen oplossing. Reactivering aan het einde is standaard ingeschakeld; Als u dit uitschakelt, blijft het onderhoudseffect behouden nadat het venster is afgelopen. Overlappende vensters kunnen een waarschuwing stil houden totdat het laatste toepasselijke actieve of behouden effect wordt opgeheven. Bekijk deze bedieningselementen in de onderhoudsgids.
Bewaar SLO-berekeningen en brandsnelheidsdetectie in uw monitoringstack. IR routeert en coördineert de resulterende signalen. Een AlertGroup is eigenaar van technische erkenning, oplossing, meldingen en escalatie; een incident is een afzonderlijke operationele workflow. Door meerdere AlertGroups aan één Incident te koppelen, worden hun technische geschiedenissen niet samengevoegd. In v2.3.1 behoren hulpverleners en belanghebbenden nog steeds tot AlertGroups. Test beide levenscycli in plaats van een wijziging in de status van een incident te behandelen als een AlertGroup ACK.