| ... | ... | @@ -4,7 +4,7 @@ Ver [requerimientos](monitoreo-procedimiento/requerimientos) |
|
|
|
|
|
|
|
1. Se detecta inconveniente con un nodo sellador (e.g: no sella hace más de 90 minutos)
|
|
|
|
1. Se comunica al grupo Telegram @monitores-bfa (donde sólo están los que monitorean, no los selladores). Esto es para evitar tickets duplicados cuando un inconveniente es detectado por más de un NOC
|
|
|
|
1. Se acuerda cuál de los NOC levantará el ticket (si no hay respuesta en el grupo Telegram, el que detectó el inconveniente levanta el ticket (si se llegan a crear múltiples tickets, a medida que se detecta que es el mismo caso, se cierran los tickets duplicados con referencia al ticket que se defina como principal).
|
|
|
|
1. Se acuerda cuál de los NOC levantará el ticket (si no hay respuesta en el grupo Telegram en 10 minutos, el que detectó el inconveniente levanta el ticket); si se llegan a crear múltiples tickets, a medida que se detecta que es el mismo caso, se cierran los tickets duplicados con referencia al ticket que se defina como principal.
|
|
|
|
1. El NOC seleccionado crea un ticket en el proyecto del gitlab que se defina (debe ser un proyecto al que sólo tienen acceso los responsables de los nodos selladores, el equipo de monitoreo, el CdA y el comité técnico).
|
|
|
|
1. El ticket se debe asignar al _contacto técnico **principal**_ del nodo afectado
|
|
|
|
1. Una vez que el responsable del nodo toma conocimiento, debe o bien solucionar el problema (y que esto se refleje en las consolas de monitoreo) o solicitar la suspensión temporal de su permiso de sellado
|
| ... | ... | |
