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: één nachtelijke back-up is nooit klaar
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 bedrijf maakt een back-up van zijn orderdatabase op twee servers voordat de werkdag begint. Eén klus stopt stil; de ander slaagt. Eén enkel gedeeld successignaal zou de kloof kunnen verbergen. Het bedrijfsrisico is het ontdekken van een oud of ontbrekend herstelpunt alleen wanneer herstel nodig is.
Workflow met IR. Definieer een voltooiingsdeadline en houd elke verwachte server afzonderlijk bij. Een host verzendt zijn hartslag pas nadat de taak- en succescontroles zijn voltooid. Een ontbrekende voltooiing zorgt voor een achterstallige waarschuwing die naar de platformresponder wordt gerouteerd, met een back-up-escalatiepad. De ingenieur onderzoekt of voert de taak opnieuw uit en legt het resultaat vast.
Operationeel voordeel om te valideren. Verander een stille geplande taakfout in een eigen taak vóór de volgende bedrijfsploeg. Hetzelfde patroon kan betrekking hebben op een geplande export- of batchtaak, op voorwaarde dat het voltooiingssignaal daadwerkelijk een succes vertegenwoordigt.
Wat u moet meten. Houd gemiste deadlines bij per server, de tijd vanaf de deadline tot de bevestiging en de leeftijd van de laatste geverifieerde back-up. Bewaar back-upverificatie- en herstelanalyseresultaten in het back-upsysteem of het bedrijfsrapport; leid ze niet af uit een groene hartslag.
Grens. Een hartslag bewijst dat er een signaal is ontvangen, niet dat de gegevens kunnen worden hersteld. Het garandeert geen herstelpunt of hersteltijd. Test herstelbewerkingen onafhankelijk en bewaak IR zelf van buiten hetzelfde foutdomein.
Behandel het oproepsysteem als een dienst die u beheert
Overweeg een platformteam dat eigenaar is van een productiecluster en nachtelijke databaseback-ups. Het wil IR in de buurt van zijn monitoringstack, maar dat maakt het team ook verantwoordelijk voor het systeem dat het wakker maakt. Noem een eigenaar voor de webservice, planner, database, geheimen en herstelprocedure.
De release Docker-installatie voert web- en planningsservices afzonderlijk uit. Nadat u de implementatiehandleiding in een testomgeving hebt gevolgd, inspecteert u deze via de release-checkout:
docker compose ps
docker compose logs --tail=50 incidentrelay
docker compose logs --tail=50 incidentrelay-schedulerHet webproces accepteert inkomende waarschuwingen; de planner verwerkt herinneringen, escalaties en periodieke taken. Start niet in elke webwerker een planner. Een werkende inlogpagina bewijst niet dat er een getimede escalatie actief is.
Detecteer een ontbrekende back-up op één host
Maak een geplande voltooiingshartslag die dagelijks om 03:00 uur in UTC moet worden verwacht, gekoppeld aan een route waarvan de bron heartbeat is. Schakel het volgen van instanties in; gebruik voor een vaste vloot statische verwachte instanties zoals db-1 en db-2. Voeg de platformrotatie of het beleid en de testkanalen toe.
Nadat de back-up van een host en de succescontroles zijn voltooid, stuurt u deze hoofdtekst naar POST /api/heartbeats/ping/HEARTBEAT_TOKEN met het inhoudstype JSON. Gebruik de geheime URL van die hartslag, niet een routetoken of een administratief API-token.
{
"status": "completed",
"instance": "db-1",
"payload": {
"job": "nightly-database-backup"
}
}Stuur een afzonderlijke exemplaarwaarde van elke host. Zonder instance-tracking kan een succesvolle ping van de ene server de ontbrekende back-up van een andere server verbergen. Stuur niet onvoorwaardelijk een succesvolle ping vanaf een shell-opruimingshandler na een mislukte taak. Redigeer geheime ping-URL's uit proxy- en taaklogboeken.
Testmislukking, niet alleen opstarten
- Ping beide verwachte exemplaren en laat er vervolgens bewust één achterwege in een kort testschema. Verwacht een waarschuwing voor dat exemplaar terwijl het gezonde exemplaar in orde blijft.
- Hervat het ontbrekende exemplaar. Als automatisch oplossen is ingeschakeld, controleert u of de waarschuwing voor te laat is opgelost zonder de fout van een ander exemplaar op te lossen.
- Stop de planner alleen in de testimplementatie. Observeer het effect op getimed werk en bewijs dat een onafhankelijke toezichthouder dit opmerkt; herstel het vervolgens en verifieer de verwerking.
- Herstel de database, configuratie en vereiste geheimen in een geïsoleerde omgeving waarbij uitgaande meldingen zijn geblokkeerd. Controleer oude ontstekingsgroepen voordat u levering toestaat, zodat een hersteloefening de productiehulpverleners niet kan oproepen.
Een succesvolle ping is geen hersteltest
Hartslagen detecteren ontbrekende signalen; het zijn geen actieve HTTP/TCP-tests en kunnen niet bewijzen dat een back-up bruikbaar is. IR kan u ook niet op betrouwbare wijze op de hoogte stellen van zijn eigen totale storing. Zorg voor een externe beschikbaarheidscontrole en een apart contactpad buiten hetzelfde storingsdomein.
Met zelfhosting worden de afhankelijkheden van chat, e-mail, spraak of netwerk niet verwijderd. Bepaal welke database en welk implementatiemodel bij de werklast passen, zet de geteste release vast en oefen upgrades en rollbacks. Deze voorbeelden bieden geen hoge beschikbaarheid of een doorvoergarantie.
Stel bewust bewaren in: de geschiedenis van opgeloste waarschuwingen wordt standaard voor onbepaalde tijd bewaard. Opschonen kan ook gekoppelde opmerkingen en leveringsrecords verwijderen, en het databasebestand wordt niet noodzakelijkerwijs kleiner. Retentie is geen vervanging voor back-ups.