Tratamiento de avisos TCE

Los que vienen de SICE (FAX a sicosoft)

Constan de 3 hojas con una portada a nombre de SICE que indica la estación y un núm. de avería, y el nivel.
Los niveles 1 los soluciona SICE
Los niveles los pone IG, por lo que no suele ser cierto.
Nivel 1: Hardware básico (periféricos -teclados- y fuentes de alimentación). Requiere ir a la estacion para diagnosticar algo, y eso lo hace SICE.
Nivel 2: Software

Los HDDs son nivel 1 pero no se ha transpasado a SICE ese tema. ïdem con las tarjetas de red. Tampoco tienen repuestos de pastillas de memoria ni de ordenadores. Tampoco monitores (ugh!).

Relevancia, en la segunda página arriba a la derecha hay una fecha y hora que es la "Fecha Alta" que es cuando ocurrió la incidencia.

Después la "Descripción" es el diagnóstico que dice el metro (aunque vale para poco, a veces sí da pistas).

En la tercera página están las "Observaciones" que es la que explica el diagnóstico, y debería estar en todas las incidencias.

Casos prácticos

las más básicas

En las que no se encuentre nada en las observaciones y el diagnóstico dice alguna cosa demasiado genérica ("SIN COMUNICACIÖN CON TODOS LOS SUBSISTEMAS" o "ICONOS EN NARANJA"), pues simplemente se saca un VNC contra la estación, se comprueba que no es cierto.
Para lo de iconos en naranja, se hace un grep del hostaname de la estación al Router.Log de ese día en el front-end correspondiente la estación y se mira a ver si estaba comunicando; si comunicaba se cierra con un "Sin anomalía para sico [X]Cancelada" y la fecha de comienzo y final.

Cuando no se hace ninguna actuación hay que cancelarlas.

Aplicación bloqueada

Cuando en la descripción ponen un "APLICACIÓN BLOQUEADA", hay que mirar en el sar.

% cd /var/adm/sa % sar -f sa<numero_de_dia> -s 04:35
Y con eso sale el día entero hasta las 23:55, cada 5 min (es un log del S.O.). Si se ven interrupciones ahí, hay que volver a ejecutar el comando (hay un bug en Solaris 8 y 9) a partir de 5 min después de la hora en que se interrumpe (ya que dicho bug lo que hace es que apra el listado en las interrupciones, pero los datos están ahí, sólo hay que pedir como hora de inicio el momento en que vuelve a estar arriba la máquina).

Una vez que se ha comprobado que el S.O. no tiene interrupciones, lo siguiente que hay que comprobar es la aplicación:

% pcl % pwd (directorio de trazas del unite)
Y después con un more o un zmore se mira a ver si hay saltos largos (de media hora o ma) a ver si hay ratos con la apli parada. Y también se ve en ese fichero si han movido el ratón (si hay ordenes de ventilador, liberar cámaras, etc, que se hacen con el ratón a través de los iconos) que eso significa que la aplicación NO estaba bloqueada. En caso de tener saltos ir al /var/adm/messages:
% su % grep SunOS /var/adm/messages
que dirá las veces que se ha reiniciado el S.O.

Si había una pausa se dice algo del estilo de "problema de alimentación entre tal y cual hora. Sin incidencia para sico [X] Cancelada".

Otras

Si hay que hacer algún tipo de actuación...

Si p.ej. no tiene ping, hay que hacer lo que dice el documento de procedimientos de Rosa.
P.Ej. Reiniciar con el reboteador, conectándose desde main1 a la IP del reboteador (que se consulta en un fichero de texto en josue:/home/metro/beatriz/ReboteadoresSCSS.txt). Con apc/pluto. Si no se levanta, hay que mandar a alguien. Si no hay ping con el reboteador: la energíua de ese reboteador está mal o se ha caído el nodo (primero llamar a IG para ver si se ha caído el nodo: ¿hay algún problema en tal sitio, porque no veo ni al PC ni al reboteador" "sí" pues entonces "Sin incidencia [X]Cancelada", en caso contrario hay que ir, bien los de CIMA bien Santiago).

Si el PC tiene ping pero no telnet

Entonces el PC está esperando un fsck; entrar por el KVM al PC (las IPs está en el 2aUIS.txt en el mismo directorio que en el de los reboteadores). No hay KVMs en todos los sitios.

Si necesitaba un fsck, se hace, se reinicia y si todo vuelve a la normalidad, pues se rellena la incidencia con "Necesitaba un file system check [X] Terminada" y se pone la hora de inicio y de fin (mínimos una hora, ayq ue ha habido que "ir allí").

Problema: En ningún vestíbulo del metro kay KVM (ni teclado, etc), sólo está la posibilidad del reboteador, y si eso no funciona, tine que ir alguien con teclado y monitor para acceder a ese PC (y escribirá lo que le digamos por tlf).

Si la máquina se puede entrar por la ELAN (WAN) pero no desde la VLAN (pcl)

Hay que comprobar:

boca del swicth (probando a poner el latiguillo del pupitre_sc en esa boca a ver si funciona)
el cable (intercambiando los latiguillos de pupitre_sc y el pc)
el slot (cambiar la tarjeta de sitio)
la tarjeta (se haya roto, cambiarla)

Una incidencia de estas hay que arreglarla en el día.

De tipo funcional ({luces de túnel, escaleras, ascensores...} no funcionan)

En general se quqjan de lo que controla el unite (porque es lo que sí requieren mando remoto por no operarlas in situ)

Se hace un more o zmore del xEventosPcl del día que toque y se mira.

salchicha$ fgo +f10 +cas "pcl" castilla 2% ping maestra maestra is alive (esta maestra es modbus, no unitelway, y por eso tiene ping) (Si dice unknown host es que es unitelway Si intenta y no tiene ping, se cierra con "Que se ha comprobado las comunicacioones del TCE y son correctas [X]Cancelada" (ellos deberían estar viendo iconos amarillos en los subsistemas del unite)) castilla 3% pcl /home/metro/sistema/V/CtrlPcl/PCL01011 castilla 4%more xEventosPcl [...]

La gente llega allí a las 6am, por lo que no suele terner relevancia lo que acurre antes de esa hora.

Vamos a analizar algunas de las líneas del fichero de trazas:

24/07/06 06:02:07 Recibida orden de CAMBIO_CODIGO_OPERADOR desde (1 1 1 - contro l) Codigo 15806 24/07/06 06:02:08 Codigo de Operador 15806 Escrito BIEN

Eso significa que tiene teclado y ratón, ya que ha podido rellenar el código de usuario y entrar en el sistema.

24/07/06 06:02:25 recibida orden de SET_UI desde (1 1 1 - UI_ESCALERA) 302 Esc09

Cada set_ui es un click con el ratón, con lo que con eso tb. se confirma que les funciona el ratón.

24/07/06 06:02:28 Recibida orden de MARCHA_SUBIR_ESCALERA desde (1 1 1 - UI_ESCA LERA) con buf Esc09 (esto es que el usuario ha iniciado una acción en el ui: marcha subir) [...] 24/07/06 06:02:28 SeleccionarEscalera 9 (Adrr 19) 24/07/06 06:02:28 EscribirOrden: Orden Escrita BIEN (El ack de la maestra de que está escrito) [...] 24/07/06 06:02:29 Se instala el escaneo ScanTmpComprSecEscaleras : 8526350 24/07/06 06:02:30 Estado : ESPERANDO_COMPROBAR_MONITOR Evento : COMPROBAR_MONITO R (eso significaq ue la maestra le ha dicho al TCE que la imagen está puesta en un monitor) [...] 24/07/06 06:02:41 Estado : ESPERANDO_ENTRADA_USUARIO -> Orden VALIDADA por el us uario (El usuario ha dicho que ha visto la imagen y le parece bien, ha validado la orden) [...] 24/07/06 06:02:43 Estado : ESPERANDO_CAMBIO_ESTADO Evento : MARCHA_SUBIR Esc09 24/07/06 06:02:43 Escalera Esc09 En Marcha SUBIENDO (Se puso a subir)

Eso es una secuencia completa, con comentarios :-).
Si hubiera un "expirado timeout" significa que no responde y hay que contestar "Las órdenes se escriben bien en la unidad maestra. Sin incidencia [X]Cancelada".

Tal y como es:
[TCE]---[Maestra]---{[aparato1][aparato2][aparato2]...}

Si dicen "Luz del túnel no comunica" pues se responde "El TCE no establece directa con ninguna luz de túnel. Sin incidencia [X]Cancelada".

NOTA: En las [X]Canceladas habría que poner en el texto de la explicacióin al final un "Sin incidencia" (en alguno de los ejemplos de arriba se nos ha olvidado O:-).

Los que vienen de Metro (son de línea 3, nos llegan por e-mail)

Son iguales que las de SICE, pero las cursa directamente metro (y hay que mandar el FAX de respuesta a otro número). Sólo hay que imprimir las dos últimas páginas.