Contexto funcional

Se investigó un sistema Java distribuido relacionado con gestión aeroportuaria, vigilancia y operación automática de vuelos.

Los módulos mencionados incluían, entre otros:

  • RPS;
  • ADM;
  • SCM;
  • SDM;
  • APS;
  • MCC.
También existían interacciones con sistemas externos o dominios como:
  • SCENA;
  • SIGMA;
  • SACTA.
El problema no era simplemente un error técnico reproducible. Se observaba que determinados vuelos que habitualmente podían operarse automáticamente terminaban requiriendo operación manual.

Dificultad del análisis

En sistemas distribuidos, el lugar donde se manifiesta un problema no tiene por qué ser el lugar donde se origina.

Una operación manual puede ser consecuencia de:

  • ausencia de un mensaje anterior;
  • estado incorrecto;
  • pérdida de una señal;
  • correlación fallida;
  • configuración;
  • evento fuera de orden;
  • condición funcional no satisfecha;
  • sistema externo que toma la operación.
Por tanto, buscar únicamente una excepción Java sería insuficiente.

Decisión: reconstruir el flujo extremo a extremo

Antes de concluir qué módulo fallaba, se planteó reconstruir el flujo de comunicaciones.

Conceptualmente:

mermaid
flowchart LR
    EXT1[Sistemas externos] --> RPS
    EXT1 --> SDM
    RPS --> ADM
    SDM --> ADM
    ADM --> SCM
    ADM --> APS
    SCM --> SCENA
    APS --> SCENA
    SIGMA --> VAP
    SACTA --> VAP

El diagrama exacto debe adaptarse a la arquitectura real, pero el principio fue identificar:

  • quién produce;
  • quién recibe;
  • quién transforma;
  • quién decide;
  • quién publica;
  • quién ejecuta la acción final.

Decisión: correlacionar por vuelo y ordenar cronológicamente

Para investigar una operación concreta, los logs debían agruparse usando identificadores del vuelo, por ejemplo:

  • matrícula;
  • flight plan;
  • callsign;
  • stand;
  • timestamps;
  • identificadores internos.
Después debían ordenarse temporalmente.

Formato deseable:

text
10:14:31.120 SDM  -> recibido aircraft update
10:14:31.342 ADM  -> correlacionado vuelo
10:14:31.611 ADM  -> evento MobileEvent
10:14:32.001 APS  -> evaluación
10:14:32.200 SCM  -> operación

Esto permite ver causalidad, no solo coincidencias.

Hipótesis sobre UP=0 / UP=1

Uno de los puntos de análisis fue localizar qué significaban y dónde se evaluaban estados del tipo UP=0 y UP=1.

La metodología adecuada para este tipo de investigación es:

text
1. localizar configuración
2. localizar código que la lee
3. localizar código que toma decisión
4. localizar log producido
5. correlacionar con vuelo real

No basta con encontrar una propiedad con el mismo nombre.

Hay que demostrar que esa propiedad forma parte del camino de ejecución responsable de la operación.

Señal de stand y transpondedor

Otro escenario analizado fue qué ocurre si en una salida no existe señal de stand y el transpondedor se activa después del despegue.

Esto obliga a pensar en la semántica de la automatización.

Una automatización suele depender de una serie de hitos:

text
vuelo planificado
      |
      v
asignación / correlación
      |
      v
detección física
      |
      v
evento de zona / stand
      |
      v
condición de operación
      |
      v
sistema que ejecuta

Si un hito no existe, puede haber una ruta alternativa, una degradación a manual o una operación generada por otro sistema.

La investigación debía comprobarlo con trazas, no asumirlo.

Valor técnico de este proyecto

Este trabajo se parece más a systems engineering / production troubleshooting que a desarrollo convencional.

Requiere combinar:

  • código Java;
  • logs;
  • arquitectura;
  • reglas funcionales;
  • mensajería;
  • sistemas distribuidos;
  • configuración;
  • conocimiento de negocio;
  • correlación temporal.
Ese tipo de trabajo es especialmente valioso para perfiles senior porque el problema no viene encapsulado en un ticket con una función rota.