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 de negocio: los clientes de SaaS trabajan en diferentes zonas horarias
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. Un equipo B2B SaaS atiende a clientes en Europa y Norteamérica. La tarde de trabajo de un cliente se superpone a la tarde de otro ingeniero y el personal de respuesta habitual está de vacaciones. Sin un horario acordado, el equipo depende de quien se dé cuenta primero del chat. El riesgo es una interrupción sin dueño y repetidas interrupciones para el personal fuera de servicio.
Flujo de trabajo con IR. Acuerde la cobertura del personal y luego represéntela con una rotación base y una capa de jornada laboral. Registre las sustituciones de días festivos como anulaciones y configure un objetivo de escalamiento de respaldo separado. Consultar traspasos y futuros huecos. Para una implementación de facturación planificada, utilice una ventana de mantenimiento centrada en el servicio mientras los servicios no relacionados continúan notificando.
Beneficio operativo para validar. Haga que la responsabilidad de soporte e ingeniería sea predecible, incluidas las licencias y los traspasos. El trabajo planificado no debería requerir silenciar el flujo de alertas de toda la empresa.
Qué medir. Revise los minutos descubiertos en un período futuro definido, como los próximos 14 días, los traspasos manuales de último minuto y los acuses de recibo dentro del objetivo de respuesta del equipo. Compare las notificaciones nocturnas por ingeniero con el horario de personal real; un calendario equilibrado por sí solo no muestra la carga de trabajo.
Límite. Un calendario lleno no crea personal adicional ni prueba que alguien pueda responder. IR no garantiza un tiempo de respuesta contractual ni calcula la disponibilidad del cliente a partir de los ACK. Mantenga las decisiones de personal, el monitoreo de SLO y la comunicación con el cliente en el proceso operativo más amplio.
Cubrir la noche anterior optimizando la jornada laboral
Supongamos que un equipo SRE posee confiabilidad en la facturación durante un turno de día laboral y un turno nocturno. En una rotación, cree una capa base con prioridad 10 y cobertura 24/7 sin restricciones. Agregue una capa con prioridad 20, restringida de lunes a viernes, de 09:00 a 18:00 en Europe/Berlin. Utilice miembros activos reales y verifique el calendario generado.
La capa activa de mayor prioridad suministra al asignado; una anulación tiene prioridad sobre las capas. Estos no son dos respondedores simultáneos. Configure un objetivo de escalamiento separado o una rotación para la cobertura de respaldo. Si no hay ninguna capa activa y no se aplica ninguna anulación, no hay ningún asignado. Consulte reglas de rotación y capas.
Pausar las notificaciones de facturación durante una implementación planificada
Cree una ventana con ámbito de servicio a través de la interfaz o envíe esta configuración a POST /api/maintenance-windows mediante una sesión de administración autenticada API con permiso para modificar el alcance. Un token de ruta de admisión no es una credencial de administración. Reemplace 42 con su ID de servicio de facturación real y elija una ventana de prueba futura.
{
"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
}
]
}Estas marcas de tiempo son horas de reloj de pared en la zona horaria seleccionada, no valores UTC con un Z omitido. Durante este período, las alertas de facturación entrantes permanecen visibles, pero las notificaciones, los recordatorios y la escalada están en pausa. Otros servicios no deberían verse afectados. Este comportamiento no es suppress_incident, que impide nuevos grupos de alertas, ni pause_escalation_only, que mantiene las notificaciones habilitadas.
Pon a prueba los límites, no sólo la mitad de un turno
- Inspeccione la asignación justo antes y después de las 09:00 y las 18:00, durante un fin de semana y una transición de horario de verano. Agregue una anulación temporal y confirme que gana, luego elimínela.
- Abra la comprobación completa de Salud de guardia. Revise su ventana futura marcada, brechas, miembros inactivos y métodos de entrega utilizables. Un resumen verde no es prueba de cobertura para siempre ni entrega a un teléfono.
- Envíe eventos de prueba de facturación y servicios no relacionados durante el mantenimiento. Confirmar que la facturación es visible pero silenciosa y el servicio no relacionado aún notifica. Para incluir alertas que ya no están resueltas, habilite explícitamente la opción para aplicar la ventana a las alertas existentes; está desactivado de forma predeterminada.
- Deje que la facturación se active cuando finalice la ventana. Con la reactivación habilitada, verifique que se reanude la notificación normal sin reproducir cada recordatorio perdido. Confirme que el respondedor real lo reciba y pueda reconocerlo.
Un servicio tranquilo no es un servicio recuperado
El mantenimiento no repara el servicio, retrae mensajes entregados ni implica resolución. La reactivación al final está habilitada de forma predeterminada; al desactivarlo se conserva el efecto de mantenimiento una vez finalizada la ventana. Las ventanas superpuestas pueden mantener una alerta silenciosa hasta que se libere el último efecto activo o retenido aplicable. Revise estos controles en la guía de mantenimiento.
Mantenga los cálculos de SLO y la detección de tasa de consumo en su pila de monitoreo. IR enruta y coordina las señales resultantes. Un AlertGroup posee reconocimiento técnico, resolución, notificaciones y escalamiento; un Incidente es un flujo de trabajo operativo independiente. Vincular varios Grupos de Alertas a un Incidente no fusiona sus historiales técnicos. En v2.3.1, los respondedores y las partes interesadas todavía pertenecen a AlertGroups. Pruebe ambos ciclos de vida en lugar de tratar un cambio de estado de incidente como un grupo de alertas ACK.