|
|
|
# Procedimiento
|
|
|
|
|
|
|
|
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. 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
|
|
|
|
1. Si el sellador solucionó el problema, debe informarlo en el ticket
|
|
|
|
1. Al menos dos NOCs de monitoreo deben confirmar que ven al nodo sellar correctamente y marcar el ticket como resuelto
|
|
|
|
1. El responsable del nodo sellador deberá _cerrar_ el ticket
|
|
|
|
* Si el responsable del nodo sellador solicita la suspensión temporal de su permiso de sellado, debe marcar el ticket como _wontfix_, iniciar el proceso de suspensión de su nodo y _cerrar_ el ticket
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Algunos requerimientos
|
|
|
|
|
|
|
|
Deberíamos afilar un poco la base de datos de selladores en https://gitlab.bfa.ar/selladores/lista y el equipo de monitoreo debería tener acceso a la misma (hoy en día sólo los selladores tienen acceso).
|
|
|
|
|
|
|
|
Es **necesario** que _todos_ los nodos selladores tengan _al menos_ un contacto técnico.
|
|
|
|
|
|
|
|
También es necesario que cada sellador tenga un _contacto técnico **principal**_ en cabeza de quien se generarán los tickets (en todo caso, quizás podríamos tener un mecanismo simple para cambiar el contato técnico principal de un nodo sellador).
|
|
|
|
|
|
|
|
Es **necesario** que el _contacto técnico principal_ tenga registrado los siguientes datos:
|
|
|
|
|
|
|
|
* Teléfono móvil
|
|
|
|
* Correo electrónico
|
|
|
|
* Cuenta de Telegram
|
|
|
|
|
|
|
|
Todos los contactos técnicos principales estarán en un grupo Telegram monitoreo-selladores
|
|
|
|
|
|
|
|
|
|
|
|
Deberíamos armar una lista similar de "_monitoreadores_" con todos los que trabajan en los NOCs de monitoreo (podríamos usar también algunas cuentas genéricas en cada NOC para la gente que trabaja _indirectamente_ como ser quien cubre un turno en el NOC de la ASI o PNA). |
|
|
|
\ No newline at end of file |
