Continuamos con la serie de posts acerca de los bugs en el software. En el número pasado hablamos de bugs con consecuencias nefastas y glitches en los videojuegos. En este post me gustaría tratar los bugs en aplicaciones empresariales y servidores que almacenan grandes bases de datos.
Cuando tratamos aplicaciones de gestión en el que existen multitud de subcontratas o equipos de trabajo accediendo a la misma máquina, servidor de aplicaciones o tablas, existe una gran probabilidad de fallos de todo tipo. Durante el desarrollo de este tipo de aplicaciones es común la detección y corrección de fallos que, por la complejidad de la política de negocio del cliente, suelen aparecer.
Sin embargo, me gustaría tratar los fallos producidos por efectos colaterales que pueden aparecer cuando otro equipo o empresa accede o instala algún módulo o programa adiccional que debe convivir con tus aplicaciones. La problemática de realizar esta tarea es que el otro equipo es consciente de lo que ellos instalan, pero no conocen en que puede afectarte el programa con el que debe convivir con el tuyo ni que consecuencias existen en el caso de parar otro servicio.
Por ello todo servidor hay que diseñarlo como un "sistema equilibrado" en el que cada programa o módulo debe tener cierta independencia para realizar sus funciones pero nunca deben excederse en los límites de los recursos compartidos. Un buen administrador de sistemas debe asegurarse de que ningún programa intenta acaparar todos los recursos.
Por otra parte, cuando se comparten tablas también existen casos de incoherencia o error en las aplicaciones. Programas que llevaban meses funcionando, sin tocarlas, dejan de funcionar sin que hayas hecho nada al respecto.
A continuación comento algunos casos de problemas que se pueden tener:
Quedarse sin disco duro
Un caso no muy común pero que puede inutilizar completamente tu sistema es quedarse sin disco duro. Este problema puede llegar a ser tan crítico que incluso la máquina no pueda volver a arrancar por si sola. El principal motivo de quedarse sin disco duro es por la creación de grandes logs o tratar cantidades ingentes de datos. Es importante que cada equipo o empresa tenga un límite de disco duro de manera que si una aplicación colapsa el sistema, las otras puedan seguir funcionando.
Quedarse sin procesador
Al igual que podemos inutilizar una máquina dejándola sin disco duro, también podemos afectar al rendimiento de otras aplicaciones saturando el procesador mediante algún bucle infinito. Para evitar este problema, todas las aplicaciones deben estar monitorizadas para avisar al responsable del módulo o programa.
Bloquear tablas
Otro acceso compartido que puede afectar a otras aplicaciones es mediante el bloqueo de tablas. Esto afectará al rendimiento de otras aplicaciones que pretendan leer de la misma información. Para evitarlo, comprueba si ese bloqueo es necesario o es un fallo en la aplicación. Si es necesario ese bloquo quizá vaya siendo hora de rediseñar la aplicación para trabajar en copias de la bases de datos o utilizar servidores replicados.
Añadir un campo a una tabla
En algunas ocasiones existen diferentes módulos que acceden a las mismas tablas. Un día, uno de los equipos decide que necesita un campo y lo inserta. Automáticamente, sin quererlo puede haber hecho romper módulos que accedían a esta tabla. Uno de los motivos sería si utilizase un insert sin especificar los nombres de los campos.
También existe la posibilidad de que una consulta con join se rompa al añadir un campo si no se indican los alias. Por ejemplo, si tenemos un select codigo, nombre from tabla1 t1 join tabla2 t2 on (t1.id_relacion=t2.id_relacion) asumiendo que el código solo está en primera tabla. Si se añadiese un campo con el mismo nombre en la tabla dos, la consulta dejaría de funcionar. Como solución, cuando hagas una consulta pon siempre los alias a los campos.
Insertar valores a una tabla
Finalmente, otro caso común es la hacer inserciones que no se han realizado de la forma habitual sino que se han realizado mediante una exportación o traspaso. En ocasiones valores que deben ser nulos se introducen como ceros o vacíos o viceversa. Sin embargo, el problema se manifestará en el consumidor de los datos y no en el que los inserta. Por ello, asegurar mediante restricciones los valores de los datos cuando sea una tabla compartida te evitará estos problemas.
Conclusión
Cuando hay multitud de equipos accediendo a la misma máquina es necesario pensar que los programas deben convivir y que errores que existen en un módulo pueden manifestarse en otros módulos. Por ello una buena estrategia es aislar cada programa para facilitar la detección de errores. En el próximo número hablaremos de los errores más comunes en la programación.
En Genbeta Dev | Bugs en el software I: Accidentes y pérdidas graves por fallos en el software En Genbeta Dev | Bugs en el software II: Glitches en los videojuegos