Spanair, malware y gestión del servicio

Aunque a estas alturas seguro que ya habéis oido hablar del tema, parece ser que ha saltado la noticia sobre un troyano que pudo intervenir en el accidente aéreo de Spanair, infectando el sistema que gestionaba los registros sobre incidencias técnicas en los aviones e impidiendo a los técnicos de mantenimiento percatarse de que existían incidencias repetitivas asociadas a uno de los dispositivos que, según parece, intervino en la causa del accidente.

Más allá de los titulares sensacionalistas que hemos podido ver en algunos medios, que poco menos que afirman que el virus fue el causante del accidente, es evidente que cuanto mayor es la dependencia que tiene la actividad humana diaria de los sistemas de información más probabilidades habrá de que un virus informático acabe afectando a dicha actividad, con consecuencias cada vez más imprevisibles. No es la primera vez que en este blog hablo del tema, y de hecho hay una etiqueta específica, seguridad y salud, bajo la que se agrupan esos post. Sin embargo, hoy no tengo intención de profundizar en este caso en cuestión, ya que creo que el nivel de incidencia que pudo tener es bastante relativo (puede contribuir al desastre, por supuesto, pero no creo que sea uno de los factores más importantes, al menos por la información a la que he podido acceder).

Lo que sí que quiero destacar es el concepto ITILero que subyace en el funcionamiento del sistema de gestión de incidencias técnicas de Spanair, y que según parece computa automáticamente una incidencia repetitiva de manera especial (mediante una "alarma"). El funcionamiento es bastante similar a la gestión de incidentes (o alguien prefiere hablar de incidencias?) y su escalado a "problemas" que se utiliza en el mundo de la gestión de servicios TI. También parece que la práctica habitual a la hora de registrar los incidentes permitía demorar dicho registro durante 24 horas, lo que implica que la catalogación como problema puede retrasarse 24 horas. ¿Son esas 24 horas un tiempo aceptable para la detección de problemas originados por incidentes repetitivos? O dicho de otro modo... ¿Debería haberse fijado un SLA asociado al tiempo de generación de una alarma provocada por un incidente repetitivo? Y si Spanair considerase que el tiempo es insuficiente, y que los incidentes deberían registrarse en tiempo real... ¿Cuál sería el coste de la infraestructura necesaria para que los técnicos pudieran registrar los incidentes de forma inmediata?

Con estas dos preguntas lo que quiero destacar es el hecho de que muchas veces, cuando pensamos en gestión de servicios TI, nos limitamos a seguir las prácticas comúnmente aceptadas, sobre todo a la hora de fijar indicadores y SLAs, sin pararnos a reflexionar en las necesidades específicas que puede tener nuestra organización a causa de la actividad que realiza. Sencillamente, el indicador que le conveniene a nuestro negocio no tiene por qué ser un indicador "clásico". Pero tampoco podemos "perder el norte" y subir los niveles de exigencia de los SLAs a valores hiper-exigentes, a riesgo de que el coste asociado a su consecución sea inasumible. Lo que sí debería ser exigible es que las organizaciones estuvieran obligadas a hacer esa reflexión, y que en este caso Spanair pudiera justificar el motivo por el cual sus protocolos de actuación funcionaban de ese modo. ¿Habrá hecho la compañía este ejercicio? Seguiremos atentos a la evolución de los acontecimientos...