Ayer en el trabajo a primera hora tuve una interrupción sobre mi línea principal de desarrollo. Un correo avisándome de que un proceso nocturno de migración de datos entre 2 sistemas superinfalibles que cuestan millones de euros había fallado en 4 documentos. Esos documentos están relacionados con un proyecto muy importante dentro del Ministerio de Educación denominado CSV desarrollado íntegramente por mi, pero usado por muchas aplicaciones, entre otras el registro electrónico, también desarrollada por mi. Paro todo lo que estoy haciendo y me dedico a intentar encontrar una solución aplicando el método científico.
Analizo el correo (una traza de logs) y veo que el error es porque no encuentra 4 documentos. Compruebo que los 4 documentos tienen un patrón común: todos empiezan por una numeración consecutiva. Los requisitos de la aplicación CSV definían que los códigos debían ser únicos, consecutivos y aleatorios. Al ser consecutivos saco la primera conclusión: O se ha producido un error en el NAS (sistema superinfalibre de millones de euros) o algo o alguien ha borrado esos ficheros (da igual que sea de forma intencionada o accidental).
El NAS además de ser superinfalibre tiene un sistema de backups muy completo (que luego me explicaron en detalle en una discusión que tuve con la gente de Sistemas). Me tranquilizo un poco. Si se han borrado, estarán en los backups y se podrán recuperar.
No están en los backups, ni rastro de ellos por ningún sitio (aquí es cuando tengo la discusión con sistemas). Yo apuesto por un fallo del NAS. Los de sistemas lo niegan tajantemente y apuestan porque algo o alguien los ha borrado en el intervalo entre que se guardaron y el momento en que se hace el backup (cada hora).
Acotamos el rango de tiempo. El problema ocurrió entre el 17 de abril y el 19 de Abril.
Mi responsable directo, gran persona y amigo, además de un gran profesional, que estaba al tanto de todo desde el principio y colaborando aportando ideas me llama y me menciona la navaja de Ockham. Le pregunto que que es es eso. Me cita textualmente: “La explicación más sencilla es la más plausible”.
Le pregunto que tiene que ver eso con nuestro problema y me sugiere que la explicación más sencilla es que se han borrado y que no ha sido nadie de manera intencionada, así que ha tenido que ser el proceso de migración el que ha producido el fallo. Bueno, es una solución sencilla: yo he metido la pata en la programación del código de migración y dicho código borra los ficheros antes de grabar dicho fichero en el otro sistema y de actualizar la base de datos.
Le desmontó su teoría en 2 segundos. El proceso de migración se ejecutó ayer, no durante el periodo que habíamos acotado, por lo que si fuera así estaría en los backups. Pero además, herido en mi orgullo, seguimos el rastro del código fuente juntos y le demuestro que primero leo el fichero (que es donde falló); después se guarda en el segundo sistema (si no es posible la operación se aborta y se genera un log); después se actualiza la base de datos (la base de datos no estaba actualizada, pero también está contemplada esta posibilidad, por lo que si falla, de nuevo la operación se aborta y genera un log); por último se borra el fichero original. Si, era una solución sencilla, pero ha quedado demostrado que no es plausible. Después, dándole vueltas llegué a la conclusión de que ni siquiera era una explicación sencilla. ¿Qué probabilidad hay de que ocurra en error de programación que borre 4 ficheros consecutivos en un intervalo de tiempo relativamente corto, cuando ese mismo proceso ha realizado correctamente la migración de 4 millones de documentos durante un periodo de más de un año?
Acotamos aún más el error. Encontramos el documento inmediatamente anterior al primer fallo y el documento inmediatamente posterior al ultimo fallo. Todos los documentos llevan una firma digital con un sello de tiempo firmado por una autoridad de sellado de tiempo. El error se produjo Entre las 4:03:16 y las 8:47:36 del día 18 de Abril.
No me creo que entre ese intervalo de tiempo tan corto y a esas horas tan matutinas alguien haya borrado intencionadamente los ficheros. No existe ningún otro proceso automático que borre ficheros de la ruta concreta donde se localizan los documentos. Además son difíciles de encontrar, ya que se balancean en subdirectorios en función de su código aleatorio, lo que garantiza una repartición homogénea de archivos a largo plazo en un sistema de directorios de 3 niveles.
Por todo lo explicado anteriormente yo sigo suponiendo que falló el sistema susperinfalible y costoso del NAS, aunque la gente de sistemas lo siga negando alegando que no tengo pruebas de ello. Es cierto, no tengo pruebas concretas, pero si evidencias. Por ello modifiqué el código que escribe en el NAS para que después de escribir en él compruebe si el fichero existe. De esta forma es imposible que ocurra un error en el NAS y no nos demos cuenta.
Después llegué a mi casa, más tarde de lo habitual por este asunto, y me dediqué a buscar información sobre la navaja de Ockham. Mi jefe lo había mencionado y también lo escuché hace poco en una canción por lo que mi curiosidad innata no me dejó otra opción. Encontré el artículo de la Wikipedia, lo leí con detenimiento, y para mi sorpresa vi, dentro de los ámbitos de aplicación, que en la informática lo denominan Principio KISS (Keep It Simple, Stupid!). Este principio si lo conocía y lo aplico continuamente a mis desarrollos de software. Y veo con gran preocupación que otros profesionales no lo aplican y hacen cosas muy complejas sin necesidad de ello, en contra también del manifiesto ágil, del que soy gran defensor y firmante del mismo.
Si has llegado a leer hasta aquí, te doy las gracias enormemente :-)
Besos y abrazos.
"Todo hay que reducirlo a su máxima simplicidad, pero no más."