martes, 2 de julio de 2019

Esfer@ un caso de externalización y de una incorrecta configuración del servidor (y de la programación posiblemente)

En la Generalitat de Cataluña cambiaron el sistemas de almacenar las notas de los alumnos. Este nuevo sistema ha traído muchos problemas, hasta tal punt que muchos centros han tenido que volver a introducir notas a mano en papel.




Lo que vamos a analizar en este artículo es básicamente cómo está realizada la nueva web de notas de Esfer@. Sinceramente me cuesta entender cómo un sistema se puede hacer tan mal, pero en realidad no considero que sea culpa de los informáticos que lo hayan elaborado, sino de la propia estructura de poder. Pero eso más adelante. Vamos poco a poco.

¿Cómo está elaborada la web?

Vamos a utilizar nmap para esto y ver qué puertos tiene abiertos. Ojo, extensiones como Wappalyzer ya hacen esto. Otras pueden ser BuiltWith.



Nmap ya nos devuelve que utilizar Oracle Application Server, lo que ya nos puede explicar muchas cosas.

Para empezar, no termino de comprender por qué no se utiliza directamente un Apache o Nginx en lugar de OAS, puesto que el rendimiento que se lograría sería mejor y además, nos ahorramos costes de la licencia. Aquí precios de OAS.

Voy a comentar cómo se podría montar, la misma web de Esfer@ de una manera que garantice la concurrencia de usuarios y esté disponible el máximo tiempo posible con unas configs muy básicas.

1. Instalación de Apache. Para mí es fundamental. No necesitas compilar los módulos (lo cual te puede llevar a problemas en caso de actualización). Muy estable y compatible con paqueterías.
2. Configuración de Apache en Prefork o incluso en Worker. Sobre esto ya hemos hablado en el blog bastante.


En realidad, con esos 3 artículos ya podríamos lograr una disponibilidad mayor y una mayor optimización de nuestro servidor.

Ojo, que esto no es seguir esta receta y que se nos garantice el correcto funcionamiento de la aplicación. Muchas veces vamos a tener que ir probando. 

Por ejemplo, si no queremos utilizar Worker por el tema de no trabajar con hilos, lo que, en caso de que falle uno, puede afectar a toda la infraestructura, podemos utilizar Prefork, aunque podamos tener "problemas de rendimiento" al trabajar con subprocesos y ante aplicaciones muy pesadas podríamos volver más lenta la conexión.   No obstante tiene una fácil solución, que es montar un sistema de caché y ya esos problemas desaparecen.


Esta es una de las imágenes que las profesoras y los profesores de Cataluña más veían, ese "Carregant" permanente y que no se iba. Y es que, a pesar de lo dicho, quedan muchas preguntas como:

¿Has puesto índices en la Base de datos?
¿Han equiparado el número de conexiones que permite el servidor con el número de conexiones que permite la base de datos puesto que sino, en donde el número sea menor ahí es donde vendrán los cuellos de botella?
¿El código de la aplicación está optimizado?
¿Está bien depurado el código?

Muchas preguntas que se deben responder, y como he mencionado, no creo que sea culpa del personal que lo haya realizado, pues veo que el problema está en la externalización de la mano de obra y presiones para sacar este "Producto" en el menor tiempo posible. Esto se podría solucionar con un sector público de informáticos como ya comenté.Un sector público que trabaje sin los criterios de rentabilidad sino del trabajo bien hecho, tarde lo que se tarde. No es muy difícil, es simplemente voluntad y superar este sistema.

¿Hackeamos el Mundo?


No hay comentarios:

Publicar un comentario

Related Posts Plugin for WordPress, Blogger...

Entrada destacada

El server me sabe a poco.

Soy un fanático del Rock y de Debian . (Creo que voy a inventar Rockbian, que suena bien y todo xD) Llevaba tiempo queriendo unir estos 2 c...