7 Razones por las Cuáles Debes Prestar Atención a los Problemas de Interoperabilidad Imagen gratuita tomada de freepixels.com

7 Razones por las Cuáles Debes Prestar Atención a los Problemas de Interoperabilidad

^Destacado

by Osabuena author page

No comment Empresas Virtuales Martes, 13 Enero 2015

tamaño de la fuente disminuir el tamaño de la fuente aumentar tamaño de la fuente
Imprimir
Email

La interoperabilidad es una cuestión de practicidad al momento de existir en la web. Hace poco tuvimos un proyecto que aunque no lo creas, pareciera haber sido la obra maestra de Murphy, ya que si algo pudo fallar, falló, si tuvimos la posibilidad de que algo fallara, efectivamente lo que más causó daño, fue el primer inconveniente, y por encima de todo, cuando algo no podía fallar, falló a pesar de todo.

Con esta Oda a Murphy, te comento los tipos de incidentes para que me comprendas un poco mejor, y sin que sea una excusa, el principal problema ocurrió desde la parte comercial de una empresa que funcionaba como un tercero (El Tercero), entre mi cliente (El Cliente) y mi empresa (La Empresa).

Primera Razón: La Infraestructura puede Fallar (Capa Física - Modelo OSI)

El agente comercial de El Tercero juró por encima de todas las cosas que nuestro servidor (un shared hosting server Linux, que no tenía Apache Tomcat), funcionaría a la perfección cuando fuéramos a hacer las instalaciones y configuraciones pertinentes. Aquí empezó todo.

Confiados en las palabras de El Tercero, La Empresa empezó el desarrollo del software para El Cliente, y UNA VEZ TERMINADO y listo para salir a producción, El Tercero nos entregó los certificados digitales que debíamos instalar, encontrando que justamente este tipo de certificados, necesitaban un reservorio de certificados en JAVA para poder funcionar, y ya que el servidor de hosting era compartido, no podíamos instalar Tomcat porque esto ayudaba a ralentizar el funcionamiento del mismo, y no se puede bajar el servicio para cientos de usuarios, solo porque un usuario necesita el ajuste.

Segunda Razón: La Dependencia Entre Factores

Al revisar el caso, El Tercero hizo referencia a que la implementación de un servicio de hosting Windows VPS, podría ser suficiente para solucionar este tipo de inconveniente, y así utilizaríamos el reservorio nativo del Windows para poder gestionar los certificados. Aquí el tema estuvo bien porque al crear el nuevo VPS (que por demás está decir que fue el más económico que conseguimos - 1 giga en ram -, gracias a la recomendación técnica que El Tercero hizo, en vista del primer error), los certificados pudieron implementarse sin problema.

Pero lo que nunca pensamos porque no fue claro, fue en que no habían firewalls gratuitos para Peer-To-Peer en Windows, o no al menos para el tipo de procesos que debíamos llevar a cabo, así que dentro de la posterior investigación, se llegó a la conclusión de que se necesitaba un firewall Peer-to-Peer tipo Júniper (firewall físico US$200 mensuales), que permitiera el uso de los certificados para poder crear el túnel que iba a dar vida a la VPN que garantizaba la seguridad en la comunicación.

Al inicio, El Tercero había sido claro en que el Firewall que podríamos utilizar, podría ser el mismo que traía el Windows, o en su defecto, existían montones de ellos gratuitos que pululaban por las redes, pero al momento de realizar la implementación, no fue así.

Tercera Razón: La Planeación de la Inversión

Cuando planeas la inversión de un proyecto, debes tener un colchón para imprevistos, y a este paso, el colchón no solo se había acabado, sino que empezaban a aparecer cosas que nunca se habián pensado, leído o tenido en cuenta, razón por la cual El Cliente tenía ya pavor de proceder para cualquier tipo de solución, so pena de errar nuevamente, y adivina qué pasó?, volvió a ocurrir.

Después de revisar y revisar, El Tercero nos hizo una recomendación de un software económico y que cumplía con los requerimientos de conexión necesarios, y que además funcionaba perfectamente con el Windows, y solucionaba de cabo a rabo todos los problemas que teníamos hasta el momento, por estas razones, lo adquirimos.

La primera semana de pruebas de la VPN fueron un poco enredadas, ya que cuando íbamos a hacer la conexión, descubrimos que el VPS había abortado y se había bloqueado la conexión.

Intentamos hacer un monitoreo del servidor VPS para poder averiguar qué estaba ocurriendo, pero lamentablemente los reportes no eran tan claros, como cuando uno contrata un VPS monitoreado por el Data Center, recuerda que te conté que el VPS era el más económico, porque se supondría que funcionaría.

Hay dos formas de contratación de un servicio de hosting VPS que también funciona para servidores dedicados (Dedicated Servers), se trata de la contratación con monitoreo y la contratación SIN monitoreo, por obvias razones, SIN tiene menos valor que CON, pero lo que nunca íbamos a adivinar porque eso tampoco se encuentra ni siquiera en la letra menuda de los contratos, es que cuando contratas un VPS SIN monitoreo, este se ubica en una red LAN diferente de los que vienen CON monitoreo, razón por la cual, si íbamos a cambiar el VPS, no se trataba de una actualización, o mejora, sino de eliminar el actual, y crear otro nuevo dentro de la red LAN habilitada para ello.

Repasemos, esto era solamente para poder tener la garantía del monitoreo del Data Center que proveía el servicio, ya que era un poco complejo saber por qué estaba cayéndose el VPS a cada rato.

Revisamos, revisamos y volvimos a revisar, y al contactar con el proveedor del software firewall, nos dimos cuenta de que este software requería al menos 2 gigas para funcionar a la perfección, sin producir estas alteraciones en el servicio, pero como el VPS ya había sido contratado, ni modo, aquí decidimos cambiar el VPS, pero para cambiarlo, teníamos que tener en cuenta todas las posibles implicaciones que esto traía para evitar que la nueva adquisición trajera más problemas en vez de soluciones.

El proceso ya venía siendo tortuoso y con miles de complicaciones (Murphy estaría feliz), pero al fin pudimos restablecer todo el servicio en un nuevo VPS de 4 gigas de ram, con las mismas condiciones anteriores de disco duro y procesador, ya que esas estaba bien mantenerlas.

Nuevo problema: Cambió la IP. El cambio de Dirección IP, generó un problema en la licencia del software firewall que habíamos adquirido, razón por la cual tocó contactar el equipo de soporte del software y explicarles lo ocurrido, para que no nos fueran a refacturar. Afortunadamente no hubo ningún problema, y pudimos reactivar la licencia del software en este nuevo VPS.

El aumento en la memoria RAM también sirvió para que el software no volviera a saturar el sistema y así fue como detuvimos los impases, ahora si, por fin estábamos listos depsués de 8 meses de procesos realizados casi que a ensayo y error, donde La Empresa ensayaba las soluciones de El Tercero, y El Cliente sufría las consecuencias de un mal servicio, comprendido su origen claro está.

Esto se había convertido en un juego en donde El Tercero ponía un obstáculo, y La Empresa tenía que resolverlo como fuera, tratando al máximo de evitar que El Cliente pagara más, y en cambio tratando de solucionar las cosas de manera rápida y eficiente.

Así las cosas, pasamos al fin por la primera prueba llamada Fase I y Fase II, pero algo no dejaba conectar la VPN. La gran ventaja era que teníamos a nuestra disposición el monitoreo del Data Center, un firewall súper poderoso, una ram que aguantaba con todo, y un VPS con una dirección IP nueva y limpia, ¿qué más podría pasar?

La importancia de la sincronización automática de la fecha y hora en los servidores VPS. Aunque tu veas que la hora del reloj coincide con la hora de tu VPS, y aunque cambien de manera sincrónica, debes tener en cuenta que el método de conexión a un VPS implica un delay o retardo en la comunicación, y que no vas a ver la hora exacta o real, ahora, real según quien? real según los servidores de hora exacta de Microsoft.

Una vez se habían descartado todos los posibles problemas, solo quedaba ajustar la hora, y así se hizo. La respuesta, un completo NO. Al parecer no era.

Aquí ocurrió lo que suele pasar en las películas épicas o de ciencia ficción, en las que al final cuando ella está a punto de morir, él llega y desciende de un hermoso caballo, o de una gran nave espacial, la rescata, revive y todo finaliza a la perfección, solo que sin caballo y sin nave, y sin él ni ella, a nosotros nos tocó vivir un hermoso despertar al día siguiente de esa última revisión, en donde aún nunca supimos por qué, pero la VPN se logró conectar, y el túnel quedó arriba.

Es claro que nunca supimos el por qué, pero funcionó, ahora todo estaba listo para la orden de salida a producción.

Reuniendo tanta felicidad como asombro, luego de un año y dos meses de trabajo permanente con este proyecto, se aprobó la salida a producción, cosa que nos hizo festejar a todos, aunque la felicidad no tardaría mucho en desaparecer, ya que la salida a producción fue un completo fracaso.

Cuarta Razón: La Auditoría de los Servidores VPS

Aunque contábamos con casi todas las cartas a nuestro favor, el software nunca pudo funcionar de manera adecuada, aunque según las auditorías realizadas por parte de El Tercero, todo estaba en orden y en perfecto estado, es decir que por alguna esotérica razón, nadie podía saber por qué nada servía.

Esto fue el colapso de todo, El Cliente tenía una demora que rayaba en los 15 meses, su Junta Directiva desconfiaba incluso del personal a cargo, y habían problemas ya fuertes y marcados. Ahora lo cuento con gracia y chiste, pero en su momento, el estar de cabeza y con la incertidumbre era el pan de cada día.

Aquí apareció una nueva luz, según El Tercero, había que implementar un sistema de auditoría, que obviamente nunca estuvo dentro de los planes iniciales, pero que en definitiva, solucionaría el problema ya que permitiría tener acceso al log de procesos que el sistema debía generar para poder conocer a nivel de máquina lo que estaba ocurriendo.

Se discutió entre La Empresa y El Cliente cuánto podría tardar y costar, y se llegó a la conclusión de que tocaba implementarlo, y así se hizo. Una semana más tarde, el sistema de auditoría se encontraba funcionando a la perfección y reportando los logs tan ansiados, que fueron enviados con toda la prisa a El Tercero, para su análisis y revisión.

El Resultado: Nadie dentro de la empresa de El Tercero, tenía idea de lo que estaba pasando. Hicieron reuniones, juntas, investigaciones, y hasta cero que conjuros e invocaciones pero nadie respondió, nadie sabía, el conocimiento se había agotado.

Quinta Razón: El Detrimento Patrimonial

En Colombia existe un delito en el que se incurre luego de que has invertido en algo y ese algo no da los resultados esperados, y si miramos la historia de las malas inversiones realizadas en el gobierno en general, encontraremos las miles de razones expresadas en billones de dólares, que explican el por qué se creó el Detrimento Patrimonial como delito.

Lo que nunca pensaron los legisladores, fue en que nos íbamos a encontrar con El Tercero, que no tenía ni idea de cómo vender su servicio, de cómo implementarlo, de como monitorearlo, de cómo auditarlo, y de cómo conectarlo, y ya que no existía un contrato explícito entre El Tercero y El Cliente, ni siquiera entre El Tercero y La Empresa, solo podíamos considerar el actuar de El Tercero como un buen consejo de amigo que desea colaborar.

En este punto, se evaluó el "Cambio de Amigo Consejero", pero se llegó a la conclusión de que no podíamos cambiarlo, ya que la inversión realizada en el VPS, luego en el Firewall Peer To Peer, luego en el cambio de VPS y luego en el montaje del sistema de auditoría, hacían que fuera una inversión considerable, y que esto obligaba a El Cliente, a terminar el correspondiente proceso con El Tercero, sin poder finiquitar sus servicios. Es decir, la implementación se debía hacer con El Tercero, a pesar de todos los inconvenientes, problemas, dilaciones y falta de conocimiento y políticas para poder resolver el tema, ya que si lo hacíamos con Otro Tercero, se incurría en Detrimento Patrimonial. :O

Sexta Razón: Volver a Validar el Proceso

Después de un año y siete meses, se encontró que la mejor forma de verificar los problemas ocurridos, y aunque suene a chiste negro y de mal gusto, era devolver el proceso a pruebas, pero para eso, El Tercero necesitaba que El Cliente le verificara de manera legal, que comprendía las implicaciones que esto significaba, y que por supuesto, estaba de acuerdo y no tendría ningún inconveniente en volver a empezar el proceso que ya llevava un año y siete meses, ya que de manera madura y analítica, comprendía que era la mejor solución.

Te imaginarás la expresión de todos y todas en nuestros rostros. Creo que ver flotar de nuevo a la Atlántida no nos habría generado tanto asombro, o incluso una abducción ET tampoco habría sido tan estrepitoza en nuestras almas como escuchar eso por parte de El Tercero.

Séptima Razón: La Evolución Tecnológica

A este paso, El Cliente había descubierto que sus visitas y otros requerimientos les obligaban a olvidar su ya tan querido Shared Hosting Server, y empezar con un servicio de Servidor Dedicado, ya que con eso se ahorraban el valor adicional del VPS.

Con lo que no se contaba, era que si se convertían al servidor dedicado, TODA la configuración que se había realizado en el VPS, se perdería, y tocaba volver a empezar desde el principio.

Hasta la fecha de hoy, lo único que hemos resuelto, ha sido llevar a cabo una reunión física que según El Tercero, nunca se había tenido que llegar hasta allá, porque todo el mundo se conectaba de una manera fácil y rápida, gracias a los excelentes asesores comerciales con los que contaban.

Y podrá sonar a cuento de los Hermanos Grimm, o a que he creado un corolario de alguna historia fantástica de Hanz Christian Andersen, pero lamentablemente es la cruda realidad.

Si te ha pasado algo similar, o irónico en el uso de los sistemas, hosting o demás servicios, cuéntanos para aprender, nunca nadie tiene la última palabra.