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: el proceso de pago falla después del cierre de la oficina
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 tienda online tiene cuatro ingenieros. A las 22:40, su seguimiento detecta solicitudes de pago fallidas mientras los clientes aún están realizando el pago. Un mensaje en el chat general no le dice al soporte quién está manejando el problema. Las compras inacabadas y una creciente cola de soporte son el riesgo comercial; la alerta en sí es sólo la señal.
Flujo de trabajo con IR. Envíe la alerta de facturación al respondedor principal actual. Si nadie lo reconoce, la política pasa a la copia de seguridad nombrada. El ingeniero asignado reconoce al grupo e investiga; El soporte puede utilizar el proceso de incidentes acordado para encontrar ese propietario y obtener una actualización. Pruebe esta cadena con el par de falla y recuperación a continuación.
Beneficio operativo para validar. Reemplace la búsqueda manual de un ingeniero disponible con una cadena de propiedad predefinida. Mantenga la responsabilidad visible durante la transferencia en lugar de asumir que un mensaje de chat entregado significa que alguien está trabajando en él.
Qué medir. Registre el tiempo desde la primera alerta procesable hasta el ACK, el porcentaje reconocido dentro de su objetivo interno y el número de reasignaciones manuales. Realice un seguimiento por separado de los pagos fallidos y del tiempo hasta que se reanuden los pagos exitosos en el monitoreo del comercio.
Límite. IR no repara el proceso de pago ni un proveedor de pagos. Un ACK no prueba que los clientes puedan volver a pagar y una política de escalamiento no puede ayudar si ninguno de los ingenieros está disponible. Mantenga la ruta de contacto alternativa y un control real de recuperación de pagos.
Cuatro ingenieros, un servicio de facturación, una cadena de propiedad
Supongamos que cuatro ingenieros comparten soporte para una facturación API. Comience con un equipo y una rotación primaria semanal. Dale a la ruta un servicio predeterminado y un canal de entrega probado. Agregue una persona de respaldo explícitamente; una sala de chat compartida no es una política de escalada.
| Objeto | Configuración de ejemplo en la interfaz de usuario |
|---|---|
| Propiedad | Equipo payments; servicio billing-api; rotación payments-primary con cuatro miembros activos y 24/7 de cobertura. |
| Consumo | Fuente webhook, servicio predeterminado billing-api, modo de escalamiento de políticas y canales de notificación adjuntos. |
| Escalada | Regla 1: rotación primaria, retraso de 300 segundos. Regla 2: un usuario de respaldo designado, demora 600 segundos. Establezca repeat_count=0 para este piloto. |
Configure canales y contactos de respuesta antes de enviar una alerta. Abra el diagnóstico de salud de guardia completo: el resumen de la tabla verde por sí solo no analiza la cobertura futura ni demuestra que un mensaje llega a un teléfono.
Enviar una falla, luego su recuperación.
Envíe estos JSON cuerpos por separado a POST /api/integrations/webhook con Content-Type: application/json y Authorization: Bearer ROUTE_TOKEN. Reemplace el marcador de posición con el token de ruta de prueba de la interfaz de usuario; manténgalo fuera del control de fuente y de los registros compartidos. Este es el formato de webhook genérico, no un evento de Simulador normalizado.
{
"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"
}
}Mantenga la misma ruta, huella digital y etiquetas de agrupación para la recuperación. La huella dactilar identifica la alerta infantil; cambiarlo a un nuevo valor aleatorio en cada solicitud anula la deduplicación. Una recuperación huérfana no crea un grupo nuevo.
Prueba la cadena ante un verdadero turno de noche
- Envía el cuerpo de fuego dos veces. Espere una alerta infantil, el servicio previsto y el asignado principal actual; confirmar la entrega real, no solo un HTTP éxito.
- Deje una alerta de prueba separada sin reconocer. Verifique que la copia de seguridad se convierta en el objetivo después del primer retraso de la política. La cadencia del programador, las colas y la entrega del proveedor significan que este no es un SLA de entrega exacto de cinco minutos.
- Reconozca otro grupo de prueba y verifique que se detengan las notificaciones pendientes de solo disparo. Envíe recuperación y confirme que el grupo se resuelva cuando no queden niños despedidos.
- Cree una anulación de rotación temporal y repita la prueba. Confirme que la anulación sea el asignado efectivo y luego elimine la configuración de prueba.
Sepa cuándo se detiene la cadena
En el modo de política, se ignora la derivación basada en recordatorios del equipo. Una vez agotadas todas las reglas y repeticiones permitidas, los recordatorios de políticas cesarán; la alerta aún puede estar activada. Una persona de respaldo sin datos de contacto laborales es solo un nombre en una base de datos.
ACK es propiedad, no recuperación del servicio de facturación. IR no puede reparar la aplicación ni proporcionar un ingeniero faltante. Mantenga una forma externa de comunicarse con el equipo si IR o su proveedor de notificaciones no están disponibles y acuerde ese recurso alternativo durante la incorporación.