Ejemplos resueltos para IncidentRelay v2.3.1, revisados el . Los nombres, identificadores y horarios a continuación son ilustrativos; valídelos en una implementación de prueba antes de usar las credenciales de producción.
Ejemplo empresarial · Configuración · Ejemplo resuelto · Comprobaciones de aceptación · Límites y modos de error
Ejemplo empresarial: una copia de seguridad nocturna nunca finaliza
Escenario ilustrativo, no un estudio de caso de cliente. Las métricas a continuación son sugerencias para su piloto, no ahorros medidos ni una afirmación de que IR incluye todos los paneles de informes.
Situación y riesgo. Una empresa realiza una copia de seguridad de su base de datos de pedidos en dos servidores antes de que comience la jornada laboral. Un trabajo se detiene silenciosamente; el otro lo consigue. Una única señal de éxito compartida ocultaría la brecha. El riesgo empresarial es descubrir un punto de recuperación antiguo o faltante sólo cuando se necesita una restauración.
Flujo de trabajo con IR. Defina una fecha límite de finalización y realice un seguimiento de cada servidor esperado por separado. Un host envía sus latidos solo después de que finalizan el trabajo y las comprobaciones de éxito. Una finalización faltante crea una alerta vencida enviada al respondedor de la plataforma, con una ruta de escalada de respaldo. El ingeniero investiga o vuelve a ejecutar el trabajo y registra el resultado.
Beneficio operativo para validar. Convierta un error silencioso de un trabajo programado en una tarea propia antes del siguiente turno de trabajo. El mismo patrón puede cubrir una exportación programada o un trabajo por lotes, siempre que su señal de finalización realmente represente un éxito.
Qué medir. Realice un seguimiento de los plazos incumplidos por servidor, el tiempo transcurrido desde la fecha límite hasta el reconocimiento y la antigüedad de la última copia de seguridad verificada. Mantener la verificación de la copia de seguridad y los resultados de la exploración de restauración en el sistema de copia de seguridad o en el informe de operaciones; no los infieras a partir de un latido verde.
Límite. Un latido demuestra que llegó una señal, no que los datos se puedan restaurar. No garantiza un punto de recuperación ni tiempo de recuperación. Pruebe las restauraciones de forma independiente y monitoree el propio IR desde fuera del mismo dominio de falla.
Trate el sistema de localización como un servicio que usted opera
Considere un equipo de plataforma que posee un clúster de producción y copias de seguridad de la base de datos todas las noches. Quiere IR cerca de su pila de monitoreo, pero eso también hace que el equipo sea responsable del sistema que lo activa. Nombre un propietario para el servicio web, el programador, la base de datos, los secretos y el procedimiento de recuperación.
La configuración de la versión Docker ejecuta servicios web y de programación por separado. Después de seguir esa guía de implementación en un entorno de prueba, inspeccione desde la versión de pago:
docker compose ps
docker compose logs --tail=50 incidentrelay
docker compose logs --tail=50 incidentrelay-schedulerEl proceso web acepta alertas entrantes; el programador maneja recordatorios, escalamientos y trabajos periódicos. No inicie un programador dentro de cada trabajador web. Una página de inicio de sesión que funcione no prueba que se esté ejecutando una escalada programada.
Detectar una copia de seguridad faltante en un host
Cree un latido de finalización programada que venza diariamente a las 03:00 en UTC, adjunto a una ruta cuyo origen sea heartbeat. Habilitar el seguimiento de instancias; para una flota fija, utilice instancias esperadas estáticas como db-1 y db-2. Adjunte la rotación de la plataforma o la política y los canales de prueba.
Una vez finalizada la copia de seguridad de un host y sus comprobaciones de éxito, envíe este cuerpo a POST /api/heartbeats/ping/HEARTBEAT_TOKEN con el tipo de contenido JSON. Utilice la URL secreta de ese latido, no un token de ruta ni un token administrativo API.
{
"status": "completed",
"instance": "db-1",
"payload": {
"job": "nightly-database-backup"
}
}Envíe un valor de instancia distinto de cada host. Sin seguimiento de instancias, un ping exitoso desde un servidor puede ocultar la copia de seguridad faltante de otro servidor. No envíe un ping exitoso incondicionalmente desde un controlador de limpieza de shell después de un trabajo fallido. Elimine las URL de ping secretas de los registros de trabajo y proxy.
Fallo de prueba, no solo inicio
- Haga ping a ambas instancias esperadas y luego omita deliberadamente una en un programa de prueba breve. Espere una alerta vencida para esa instancia mientras la instancia en buen estado permanece en buen estado.
- Reanudar la instancia que falta. Si la resolución automática está habilitada, verifique que su alerta vencida se resuelva sin resolver la falla de otra instancia.
- Detenga el programador solo en la implementación de prueba. Observar el efecto sobre el trabajo cronometrado y demostrar que un monitor independiente lo nota; luego restáurelo y verifique el procesamiento.
- Restaure la base de datos, la configuración y los secretos necesarios en un entorno aislado con notificaciones salientes bloqueadas. Revise los grupos de disparo antiguos antes de permitir la entrega, de modo que un simulacro de restauración no pueda localizar a los socorristas de producción.
Un ping exitoso no es una prueba de restauración
Los latidos del corazón detectan señales faltantes; no son sondas HTTP/TCP activas y no pueden demostrar que se pueda utilizar una copia de seguridad. IR tampoco puede notificarle de manera confiable sobre su propia interrupción total. Mantenga una verificación de disponibilidad externa y una ruta de contacto separada fuera del mismo dominio de falla.
El autohospedaje no elimina las dependencias de chat, correo electrónico, voz o red. Decida qué base de datos y modelo de implementación se ajustan a la carga de trabajo, fije la versión probada y ensaye las actualizaciones y reversiones. Estos ejemplos no establecen una alta disponibilidad ni una garantía de rendimiento.
Establezca la retención deliberadamente: el historial de alertas resueltas se conserva indefinidamente de forma predeterminada. La limpieza también puede eliminar comentarios vinculados y registros de entrega, y no necesariamente reduce el archivo de la base de datos. La retención no sustituye a las copias de seguridad.