Demodatos

Guía de elección del servicio de alojamiento web

2010-11-26T20:00:00.002+01:00

Introducción
El proceso de elección del servicio de alojamiento web puede parecer una tarea desalentadora. ¡Una primera búsqueda rápida en google ofrece millones de resultados! ¿Quiénes son todas estas empresas? Nadie lo sabe realmente. En el mercado del alojamiento web no existe apenas reconocimiento de marca, lo que significa que el consumidor tiene que investigar bastante para asegurarse de que llega a un proveedor de alojamiento web de calidad.

¿En qué consiste dicho servicio de alojamiento web?
Un proveedor de alojamiento web es una empresa que alquila el uso de servidores (ordenadores) y ancho de banda de transmisión para los que desean publicar un sitio web. El servicio de alojamiento web proporciona a su cliente una cuenta, que puede ser utilizada para cargar documentos HTML, scripts PHP, gráficos, y mucho más.

¿Qué hay que buscar?
Hay muchas variables que definen un servicio de alojamiento. Esta guía pretende presentar las variables más importantes que deberían considerarse. Las empresas suministradoras de los servicios no siempre ofrecen toda esta información en sus páginas, por lo que es posible que haya que ponerse en contacto con ellas por correo electrónico o teléfono para obtener las respuestas deseadas.

Tipos de alojamiento web
Las soluciones de servidores web corporativos, los sitios web personales, y los sitios pequeños de comercio electrónico requieren cada una de ellas soluciones de alojamiento web muy diferentes. Una empresa grande puede querer sin ningún genero de dudas un servidor web dedicado, que sea administrado las 24 horas del día, los 7 días de la semana, por un equipo de administradores altamente cualificados. Por el contrario, alguien que tenga un sitio informal, una web personal, puede encontrar que un servicio de alojamiento básico gratuito es más que suficiente para él.

Al elegir un proveedor de alojamiento web es muy importante considerar en primer lugar cuáles son las necesidades. Después de haberlas establecido llega el momento de elegir el tipo de alojamiento apropiado.

Los tipos se pueden clasificar en las siguientes categorías:
Alojamiento compartido básico - gratuito, cuenta con las funciones mínimas para empezar.
Alojamiento compartido - los más populares, el sitio web está ubicado en un servidor que aloja otros muchos sitios.
Servidor dedicado sin administración (poca o ninguna atención al cliente), la administración del servidor recae en el cliente.
Servidor dedicado con administración (incluye asistencia al cliente), el proveedor se encarga de ella.

Alojamiento compartido básico – gratuito

Para aquellos que empiezan en la creación de sitios web no tiene mucho sentido pagar una cuota mensual por un servicio de alojamiento cuando apenas saben cómo crear un sitio o apenas reciben visitantes. La elección de un alojamiento gratuito es una solución lógica para empezar con un nuevo proyecto. El alojamiento gratuito generalmente incluye una cantidad pequeña de almacenamiento y ancho de banda suficientes para empezar. Las características también tienden a ser limitadas. En pocas palabras el alojamiento gratuito es ideal para practicar el diseño de páginas web o incluso alojar sitios web para la familia, amigos o grupos reducidos. Sin embargo, el alojamiento gratuito no es una solución plausible para webs con mucho tráfico o requisitos exigentes.

Alojamiento compartido

El alojamiento compartido es el tipo de alojamiento web más popular del mercado. Casi todos los negocios pequeños, los sitios web intermedios o incluso de gran tamaño y los sitios web profesionales requieren sólo una pequeña fracción de los recursos de un servidor web completo. Sería antieconómico para estos clientes alojar todo en un servidor propio; el alojamiento compartido es la mejor elección.
Dependiendo del plan específico de alojamiento, deberían estar disponibles más o menos funciones de servidor web y una cantidad mucho mayor de almacenamiento y ancho de banda que en un alojamiento gratuito. Si se piensa recibir pagos a través de internet, hay que comprobar que el plan de alojamiento lo permite (certificado SSL, …).

La desventaja de tener un servidor compartido es en cuanto a rendimiento y seguridad, debido al hecho de que se comparte con otras decenas o cientos de clientes y además por lo general el número total de direcciones de correo electrónico, bases de datos y dominios no son ilimitados.
Un aspecto importante a tener en cuenta a la hora de elegir al proveedor es que muchos de ellos ofrecen alojamiento o anchos de banda de transferencia ilimitados en su afán de captar clientes, conscientes de que la mayoría no hacen uso de estas características. Pero hay que saber que estos factores sí les cuestan a las empresas proveedoras y es obvio que no van a dejar que se abuse de ello y a aquellos clientes que superen los límites que la empresa internamente tenga fijados, y que no habían hecho públicos, se les va a invitar amablemente a que se pasen a otro tipo de soluciones más caras.

Servidores dedicados - no administrados

En caso de que el alojamiento compartido no proporcione suficiente ancho de banda, almacenamiento o las características requeridas, el hosting dedicado puede ser la solución. Con los servidores dedicados no hay límites en el número de bases de datos y alias de correo electrónico que se pueden crear. El ancho de banda es mucho mayor, los planes típicos de transferencia de datos suelen ser del orden de Terabytes por mes. Si se necesita más espacio de almacenamiento, simplemente se añaden nuevos discos duros a su servidor. Pueden ser más seguros porque no se comparten con nadie. Se puede instalar software adicional específico necesario para su web. El único inconveniente: hay que saber mucho acerca de la administración de servidores.
Convertirse en un experto administrador de servidores requiere una gran cantidad de formación y conocimientos de informática. Si se dispone de poco dinero en efectivo y se está dispuesto a aprender administración de servidores de la manera difícil, adelante, tampoco es imposible. Sin embargo, si el presupuesto es lo suficientemente grande, el hosting dedicado administrado puede ser una solución mejor.

Servidores dedicados – administrados

Si el sitio web tiene grandes requerimientos y el alojamiento compartido no sirve, y no se sabe configurar el servidor web ni adaptarlo a las necesidades, se va a necesitar mucha ayuda para que todo funcione y cuando dejen de funcionar. La solución es un proveedor que proporcione administración.
Este es un mercado muy especializado, con una amplia gama de precios que dependen de la cantidad de seguridad, fiabilidad y el nivel de asistencia que se necesita. Al elegir un proveedor administrador de servidores dedicados no es conveniente apresurarse en un contrato a largo plazo sin saber bastante sobre el proveedor de servicios.

Los servidores dedicados pueden ser virtuales (reserva de recursos, sin especificación de la máquina en donde se alojan) o físicos (ordenadores totalmente independientes). En los virtuales se ofrecen desde máquinas más pequeñas con precios más ajustados a las necesidades hasta las máquinas que pueden cubrir las necesidades más exigentes. Se pueden ampliar en función de picos de carga de manera transparente y pagar sólo por lo que se necesita.

¿Cuánto ancho de banda de transferencia de datos es necesario?

Tiene que ver con la cantidad de datos que se envían desde el servidor web hasta los equipos de los visitantes. Si se tiene una gran cantidad de visitantes y todos descargan archivos de gran tamaño, se necesita una gran cantidad de ancho de banda para atender a todos. Muchos administradores no planifican bien e inadvertidamente sus sitios web dejan de admitir visitas en la mitad del mes debido a que estos fueron mucho más populares de lo que ellos esperaban. Para evitar que esto ocurra, hay que vigilar cuidadosamente el consumo de ancho de banda y planificar.

La principal diferencia entre el plan básico y el caro de cualquier proveedor de alojamiento es la cantidad de ancho de banda por mes. La mayoría de los proveedores expresan la cantidad de ancho de banda en GB (Gigabytes, 1 GB = 1.000 MB). A continuación se muestra una forma sencilla de calcular la cantidad de ancho de banda que se necesita cada mes.

Total = visitas al día * páginas vistas por visita * El tamaño medio de las páginas * 30 (número de días al mes)
Ejemplo de un sitio con 1000 visitas diarias, 4 páginas vistas por visita, y un tamaño de página de 45 KB (kilobytes):
1000 * 4 * 45KB * 30 = 4.500.000 KB = 4500 MB = 4.5 GB

En este ejemplo se requiere un plan con un mínimo de 4,5 GB de ancho de banda al mes. Sin embargo, para permitir el crecimiento, sería conveniente elegir un plan con un ancho de banda mayor, para prevenir que haya una cantidad inusualmente grande de visitantes en un mes.

Líneas dedicadas

Algunas opciones de alojamiento, más comúnmente entre los planes de servidor dedicado, vienen con una conexión dedicada de una determinada velocidad. En general estas líneas dedicadas varían desde 256 kb/s (kilobits por segundo) hasta 100Mb/s (megabits por segundo). Estas opciones son ideales para sitios web con un flujo constante de tráfico, que no necesitan atender transferencias puntuales de gran cantidad de datos. Si se dispone de una línea dedicada, en vez del contrato de una cierta cantidad de GB al mes, el sitio no será capaz de atender picos de visitas.
A continuación se muestra una tabla de la cantidad de ancho de banda (en GB) que sería capaz de ofrecer una línea dedicada, en condiciones ideales, con la carga de transferencia repartida uniformemente durante las 24 horas de todos los días del mes. Nota: es probable que no se consigan las velocidades máximas, y se ha incluido una cantidad media más real, que probablemente estará más cerca de los GB que se consigan realmente.

Línea Dedicada / GB por mes / GB reales por mes

256kb/s ~ 82 GB 75 GB
512kb/s ~ 165 GB 130 GB
1 Mb/s, 324 GB ~ 270 GB
10 Mb/s 3240 ~ 2700 GB GB
100 Mb/s 32.400 GB ~ 27.000 GB

La mayor parte de la información proviene de: http://www.tizag.com/webhost/

Finalmente sólo nos cabe informar que nosotros proporcionamos cualquiera de las soluciones anteriormente expuestas.

Nueva web

2010-09-22T12:08:00.001+02:00

Seguimos trabajando para encontrar la información allá donde se encuentre.

Sentimos las molestias que se pudieran ocasionar a nuestros clientes y lectores por el cambio de web.

Si no encuentra lo que busca aquí, puede buscarlo en demodatos.wordpress.com.

Esperamos que el cambio sea para mejor,

Un saludo

Bienvenidos

2010-09-01T12:22:00.000+02:00

Bienvenido a nuestro blog.

Somos una empresa especializada en extraer información de los datos.

Todos nos movemos en un mundo donde la información es importante y donde su desconocimiento nos lleva a perder nuestro tiempo, nuestro bien más preciado y del que no existe sustituto. Por lo que defendemos el derecho del acceso a la información, no sólo la que viene en los periódicos. Nuestro objetivo es conseguir datos para todos.

Nuestros clientes suelen ser organizaciones que quieren mejorar el rendimiento de sus actividades. Para lograr este fin analizamos el flujo de información, los procesos de negocio, detectamos problemas y cuellos de botella y sugerimos maneras de optimizarlos. Al mismo tiempo iniciamos un sistema de monitorización que permite seguir la marcha de la organización en tiempo real para que las personas apropiadas sepan en todo momento como funciona y puedan detectar los problemas cuando surgen y eviten de esta manera perder tiempo, dinero y clientes. También estudiamos donde se encuentran los datos, los reorganizamos y proporcionamos herramientas para poder analizarlos.

Nuestro campo de acción incluye por una parte, en lo que se refiere a los negocios, lo que en inglés se conoce como Business Intelligence (BI) y Business Process Management (BPM). En español los términos están menos establecidos y los podemos encontrar como inteligencia empresarial o inteligencia de negocios y gestión de procesos de negocio entre otras variantes menores.
Por otra parte, desde un punto de vista más genérico, de la gestión de la información, nuestro trabajo incluye ETL (Extract, transform and load), data warehousing y data mining. En español, se trata de extraer los datos allá donde se encuentren, de transformarlos y cargarlos en un sitio conveniente para su almacenamiento; y finalmente de analizarlos y presentarlos (minería de datos).

Ofertas de trabajo publicadas sobre Business Intelligence en España

2009-03-14T16:15:00.001+01:00

Aqui tenemos recogidas algunas de las ofertas de trabajo de Business Intelligence en España, provenientes de los buscadores más importantes (infojobs, tecnoempleo, informáticos, monster, google base, trabajos, trovit, simplyhired,michaelpage). Faltan al menos las ofertas de elpais y laboris porque no hemos encontrado sindicadas sus ofertas.

Suerte

Gestión distribuida de cartera de clientes

2009-01-21T16:15:00.000+01:00

El departamento comercial de las empresas no sólo necesita saber todo lo referente a los clientes, entre otros datos los presupuestos ofertados a cada uno de ellos; sino que también debe ser ágil en el trato y uno de los aspectos más sensibles es la rapidez en crear nuevos presupuestos adaptados a cada uno.

Cliente: una empresa gráfica

Necesidad: crear un sistema de gestión de cartera de clientes que fuera capaz de generar presupuestos sin necesidad de estar conectados a la oficina.

Situación previa: cada comercial llevaba su información en hojas Excel y tenía que pasar la información necesaria al departamento de producción para que estos pudieran elaborar el presupuesto que a veces se demoraba días en función de la carga de trabajo.

Desarrollo del sistema: Se creó un modelo relacional en una BBDD en Oracle con toda la información recuperada de los comerciales y de los datos que mantenía la empresa. Posteriormente se creó un modelo multidimensional que sincronizaba los datos con esta BBDD. Los comerciales llevaban en su portátil esta BBDD multidimensional junto con unas hojas Excel con las que generaban instantáneamente los presupuestos. Para generar estas hojas Excel se tuvo que sistematizar y encontrar las reglas del proceso de generación de presupuestos que utilizaba la empresa.

Resultados: Esto permitió a los comerciales negociar e interactuar mejor con los clientes pues podían ver en el momento cuáles eran los efectos de variar algunas de las variables de los pedidos: número de impresiones, tamaño de la impresión, número de tintas,... Se podía consultar en todo momento cuáles habían sido los presupuestos ofertados. Y se ahorró mucho trabajo administrativo.

Entorno de inteligencia empresarial

2008-12-15T17:07:00.000+01:00

No basta con crear los informes ideales, hay que distribuirlos a las personas apropiadas y sólo a ellas, a tiempo, protegidos para que nadie más pueda verlos, ejecutarlos sin interferir en la operativa de la empresa. Además convendría que los usuarios finales pudieran generar sus propios informes sin que tuvieran que investigar en modelos complejos; que se pudiera administrar desde un lugar central en las empresas con múltiples sedes; que ...
Las necesidades son variadas y es necesario encontrar soluciones que satisfagan todas ellas. En este caso se optó por BusinessObjects Enterprise XI, una solución proporcionada por SAP, tras la adquisición de la empresa Business Objects.

Cliente: una empresa inmobiliaria

Necesidad: crear un entorno de inteligencia empresarial que mantuviera la confidencialidad de la información en una empresa con varias sedes y departamentos.

Situación previa: se utilizaban muchos informes desarrollados con herramientas distintas que cada departamento administraba y guardaba.

Desarrollo del sistema: Se instaló la administración de BusinessObjects Enterprise XI en un servidor dedicado. Se rehicieron y optimizaron los informes y se creó una política de seguridad para toda la empresa. Se crearon "universos" para los departamentos que necesitaban generar consultas a medida.

Resultados: Los gerentes tuvieron por primera vez la sensación de controlar la información que circulaba por su empresa y los empleados tuvieron un mejor acceso a la información que necesitaban.

Coste del proyecto: 200 días + licencias

Informes periódicos de evolución de ingresos y gastos

2008-09-20T19:18:00.000+02:00

Las herramientas informáticas de gestión habituales no son lo suficientemente flexibles como para cubrir todas las necesidades de las empresas. Una de las carencias habituales son los informes muy especializados que utilizan los directores y que permiten ver la marcha de un negocio para poder adoptar decisiones estratégicas sobre el mismo.
Cliente: una empresa inmobiliaria
Necesidad: generar una serie de informes de periodicidad mensual para seguir la evolución del negocio de alquileres de diversos propietarios.
Situación previa: estos informes se generaban a mano para unos pocos propietarios en hojas Excel y se guardaban para consultas posteriores y presentar los resúmenes anuales. Era un proceso muy lento, poco flexible, proclive a introducir errores y difícil de mantener.
Condicionantes del proyecto: muchos de los datos necesarios estaban dispersos por la organización en hojas Excel y no se querían modificar ni las aplicaciones ni la BBDD de la empresa. Por lo tanto, la solución debería almacenar los datos necesarios para generar los informes (Data Mart) e incluir un sistema de introducción y revisión de los mismos, ser flexible de manera que los propios empleados pudieran modificar los informes y, sobre todo, muy económico de desarrollar y mantener.
Estructura de los datos: en su mayor parte, los datos estaban organizados por inmuebles y meses y se querían conseguir los valores agregados de portales, edificios, propietarios y tipos de propietarios por años y acumulados en el año para cada uno de los meses. Este tipo de informes es lo que mejor maneja las BBDD multidimensionales o cubos OLAP.
Solución elegida: de las distintas opciones que existen en el mercado se eligió PALO de Jedox por llevar incorporada su propia BBDD de nulo mantenimiento y perfectamente integrada con el motor de generación de informes y por tener un conector con Excel que permite que los propios usuarios generen informes sencillos y puedan modificar los diseñados a medida fácilmente, lo que permite un costo de mantenimiento muy bajo. Cualquier usuario con conocimientos medios de Excel puede entender la estructura de los informes y modificarlos. Una ventaja adicional es que el costo por licencia es cero de manera que independientemente del número de usuarios que utilicen el producto su costo será nulo.
Implementación: se realizó una copia de la BBDD Oracle de la empresa y se generó las consultas para recuperar los datos necesarios. A continuación se diseñó la BBDD multidimensional. Luego, las pantallas de los datos que se debían introducir a mano y finalmente los informes que se solicitaban.
Coste del proyecto: 80 días x hombre + 0 euros por licencias.

Copias de seguridad con Veritas Netbackup

2008-09-20T19:14:00.000+02:00

Los datos no se pueden perder. Es necesario tener un sistema fiable de copias de seguridad. Y esto no quiere decir que basta con elegir un buen programa, hay que llevar la política correcta de copias para cada empresa y comprobar que se recuperan los datos en el tiempo que se estime como adecuado para cada uno de los escenarios posibles de pérdidas de datos.
Cliente: un banco
Necesidad: Diseñar y operar un sistema de copias de seguridad para el cluster que iba a llevar la operativa del banco.
Situación previa: el sistema anterior dependía de un mainframe de IBM en el centro de datos del banco matriz, que llevaba su propio sistema de copias.
Condicionantes del proyecto: debería interferir lo menos posible con el funcionamiento normal del banco.
Descripción del sistema: un cluster de Sun con una base de datos Oracle en modo Archivelog.
Solución elegida: Veritas Netbackup, ahora de Symantec, con un robot de cintas y un agente para Oracle.
Implementación: Se diseñó la política de copias en colaboración con los encargados del banco para definir la frecuencia de copias, el período de retención y los requisitos de recuperación. Así se estableció una copia completa los fines de semana y copias incrementales todas las noches por duplicado, una de las cuáles se enviaba a las instalaciones del banco central todos los días. Se hicieron pruebas de recuperación de datos con medición de tiempos y del sistema entero. Durante el proyecto hubo que migrar el cluster a otra ubicación y se puso a prueba una vez más el sistema de recuperación. Durante todo el proyecto trabajé en colaboración con un informático del banco para que pudiera continuar operando el sistema una vez que terminara.
Coste del proyecto: 100 días x hombre + licencia de Netbackup con agente de Oracle+robot de cintas.

Datawarehouse empresa inmobiliaria

2008-07-04T18:12:00.000+02:00

Los almacenes de datos comunes para toda la empresa evita la incomunicación entre los departamentos y facilita la gestión de los gerentes.

Cliente: una empresa inmobiliaria

Necesidad: Homogeneizar los distintos datos que manejaban los departamentos de la empresa.

Situación previa: La mayor parte de la información estaba en un programa de gestión específico para empresas inmobiliarias pero además había varias BBDD de Access y muchas hojas Excel que manejaban los distintos departamentos. Existía mucha información duplicada y, lo peor, discordante.

Implementación: Se agruparon todos los datos que estaban dispersos por la organización. Una vez creado el modelo de datos y la BBDD en Oracle, hubo que modificar los procesos de la empresa para que emplearan los datos de este repositorio común. Se empleó Oracle Datawarehouse Builder en este proyecto.

Coste: 300 días + licencias

Creación del modelo de datos de un periódico digital de negocios

2008-06-30T18:27:00.000+02:00

Los periódicos necesitan organizar su información (texto y documentos multimedia) y dar facilidades a los lectores para encontrarla fácilmente.
Cliente: un grupo editorial
Necesidad: crear la versión digital del periódico.
Situación previa: sólo existía la versión impresa.
Descripción del sistema: BBDD Oracle para los datos con la opción Text option.
Implementación: Lo primero que hubo que hacer es adaptar la opción “Text option” para indexar documentos en español. Oracle no proporcionaba ninguna ayuda, venía preparado para indexar en inglés y se ve que tenía pocos clientes en español. Lo más importante era determinar las palabras por las cuáles no se quería indexar. Un internauta desconsiderado podría llegar a hacer caer la BBDD si se lo proponía. Una vez parametrizada correctamente esta opción, se creó el modelo de datos a partir de las necesidades expuestas en las entrevistas con el cliente y los desarrolladores que iban a desarrollar el periódico digital.
Coste del proyecto: 40 días+Oracle Text option

Creación de modelos de datos para grupo de comunicación

2008-06-30T18:21:00.000+02:00

A lo largo de un año se crearon unas cuantas Web para diferentes empresas del grupo.
Cliente: grupo de comunicación
Necesidad: crear los modelos de datos para desarrollar sobre ellos las aplicaciones web.
Descripción del sistema: BBDD Oracle.
Implementación: .Mediante entrevistas con el cliente y la empresa desarrolladora de las páginas web, determinaba las necesidades de almacenamiento y generaba el modelo de datos pertinente.
Coste del proyecto: 200 días

Creación de un entorno de certificación

2008-06-30T18:17:00.000+02:00

Los entornos de certificación son fundamentales sobre todo en los sistemas que dependen de otros para funcionar. El desarrollo a menudo olvida algunas de las relaciones que existen con otros y muchas puestas en producción fracasan por no haber previsto las consecuencias que acarrearían. Suponen pérdidas importantes o por los gastos asociados por volver al sistema anterior o simplemente por la disfuncionalidad que implica en el negocio.
Cliente: una empresa de desarrollo de un grupo de telecomunicaciones
Necesidad: crear un sistema de certificación de varios servidores Unix interdependientes con varias BBDD Oracle distribuidas para poder llevar a cabo las tareas de certificación de la empresa.
Situación previa: se disponía de un sistema de certificación pero no se estaba seguro de que fuera exactamente igual que el entorno de producción y no funcionaba correctamente, entre otras cosas el sistema de réplicas entre las BBDD. Por lo que se decidió volver a crear el entorno desde cero.
Integrantes del proyecto: un administrador de BBDD y un técnico de sistemas para la configuración de los servidores.
Descripción del sistema: Clusters de HP con BBDD distribuidas Oracle.
Implementación: A partir de los backups de las máquinas de producción se reprodujeron los servidores mientras que las BBDD hubo que crearlas de manera especial porque sino las replicas no funcionaban. Apuntaban a las tablas de producción en vez de las de certificación. La solución consistía en crear la BBDD, los distintos usuarios con sus esquemas y finalmente las tablas replicadas una por una apuntando a las de certificación.
Coste del proyecto: 40 días x 2 técnicos

Organización de un equipo de soporte 24h

2008-05-20T18:51:00.000+02:00

En el cambiante mundo de la informática, cada técnico ha recibido una formación distinta y va pasando por experiencias diferentes que le van especializando progresivamente. Pero el soporte de sistemas complejos necesita de personas polivalentes que tengan conocimientos en un amplio abanico de temas aunque no necesariamente muy profundos. La cuestión de las guardias complica el desempeño de su labor. Ante la imposibilidad de tener de guardia a todo el equipo es necesario que cada uno de ellos tenga los conocimientos mínimos para resolver el mayor número de incidencias posibles.
Cliente: una empresa de servicios
Necesidad: crear un equipo de soporte con personal joven sin experiencia o con poca, que pudiera mantener un sistema de atención de averías y proporcionar soporte de 24h.
Situación previa: el soporte estaba repartido entre la empresa que había diseñado el sistema y la empresa que lo mantenía. Se quería dejar de depender en cuestiones de mantenimiento de la empresa desarrolladora.
Descripción del sistema: el núcleo del sistema estaba formado por un cluster de HP con Service Guard. Con un SGBD Oracle distribuido, aplicaciones cliente en Windows y servidores web basados en servlets Java.
Implementación: Inicialmente a cada uno de los técnicos se le responsabilizó de unas tareas en función de su formación y experiencia. Se les fue formando mediante unos talleres en los que se explicaba cómo funcionaba el sistema desde el punto de vista del mantenimiento: los clusters, la BBDD Oracle, las tablas replicadas, las consultas distribuidas, los servidores Unix, etc. Al mismo tiempo se empezó a documentar todos los problemas que iban surgiendo y se les acostumbró a que lo consultaran y lo mantuvieran. Se desarrollaron una serie de consultas a la BBDD. y de scripts en Unix que comprobaban que todo iba bien. Todas las mañanas todos los integrantes del equipo comprobaban el resultado, para asegurarse de que lo comprendían. Cada uno de ellos tenía que conocer lo que hacían los demás por lo que se iban rotando para intercambiarse las tareas. Para facilitar las guardias nocturnas se diseñó con BMC Performance Manager (Patrol) un sistema de consultas automático basado en las consultas anteriormente citadas que incansablemente exploraba el sistema y enviaba mensajes al móvil de guardia en cuanto se detectaba algo anormal. Quizás el principal problema fue el estrés inicial de los técnicos de llevar solos por la noche la responsabilidad de todo el soporte del sistema, pero el hecho de haber pasado durante el día por todas las posibles tareas les fue confiriendo progresivamente la suficiente confianza para reducirlo.
Coste del proyecto: 400 días x 14 técnicos

Mantenimiento del sistema informático de un banco de negocios

2008-05-20T18:38:00.000+02:00

Los bancos tienen características especiales que diferencian sus sistemas informáticos de los demás. La seguridad y la fiabilidad son fundamentales. Sin olvidar la velocidad de respuesta.
Cliente: un banco
Necesidad: mantener el sistema informático recién creado mientras se formaban a los técnicos del banco en las nuevas tecnologías introducidas.
Situación previa: el soporte del sistema antiguo lo llevaban los técnicos del banco pero al introducir un nuevo sistema que dependía menos del mainframe del banco del que eran filial, las tareas de mantenimiento se ampliaron y se determinó que por un tiempo transitorio haría falta nuevo personal.
Integrantes del proyecto: un jefe del proyecto y cuatro técnicos de sistemas, uno de los cuáles seguiría en el banco cuando el proyecto finalizase.
Descripción del sistema: Principalmente un cluster HA de dos máquinas Sun, con un servidor de aplicaciones Tuxedo, un SGBD Oracle y un gestor de colas MQSERIES. Además Veritas Netbackup con un robot para backups y el planificador de procesos controlM de BMC.
Implementación: Hubo que poner el sistema en producción, diseñar la planificación de tareas y definir la política de backups. Se llevó a cabo la administración de las BBDD, su parametrización, la optimización de las consultas, las migraciones de versiones, el control de usuarios, tanto de producción como la de desarrollo. Aparte del mantenimiento diario de los procesos, había que introducir cambios frecuentes en el sistema para incluir los nuevos módulos que se iban desarrollando. Se ofreció un soporte 24h. con un sistema rotatorio de guardias. Durante el proyecto hubo que migrar el sistema a otra ubicación, al centro de datos del banco matriz y redimensionarlo tras una fusión del banco con otro.
Coste del proyecto: 300 días x 5 técnicos

Dimensionamiento de un sistema tras una fusión

2008-04-18T18:56:00.000+02:00

Las fusiones de empresas conllevan muchos cambios y aparte de que puedan sobrar personas hay que redimensionar los sistemas y eliminar todo lo innecesario.
Cliente: un banco, antes dos
Necesidad: Comprobar si el sistema informático de uno de los bancos tendría capacidad suficiente para atender a los clientes de los dos.
Situación previa: uno de los bancos acababa de invertir mucho dinero en un sistema informático moderno y se quería ver si había que ampliarlo para alojar el negocio de los dos.
Condicionantes del proyecto: Se tenía mucha prisa para llegar a una conclusión.
Descripción del sistema: un cluster unix de Sun, funcionando con el gestor de transacciones Tuxedo sobre una BBDD de Oracle. Además se utilizaba MQseries para comunicación con el Mainframe del banco matriz.
Implementación: se llevaron en paralelo dos métodos de evaluación. Uno de ellos consistía en evaluar con la ayuda de un programa cuanto aumentaría la carga de los diversos parámetros del sistema cuando se tuvieran a todos los clientes que se estimaba (cuatro veces más). El otro consistía en hacer una simulación real de la nueva carga. Para ello se creó una BBDD con cuatro veces más datos en clientes y en las tablas relacionadas. Sobre ella se inyectaron las transacciones que se estimaba que se producirían una vez fusionados y se midieron los tiempos de respuesta. El primer método, el de la estimación, determinó que había que aumentar el sistema. El segundo que había que aumentarlo aún más pero se comprobó que la carga la producían un par de peticiones al sistema y tras optimizar las consultas Oracle que incluían, el resultado fue que había menos carga sobre el sistema que en la situación de partida con cuatro veces menos clientes. Con lo cual se llegó a la conclusión de que no hacia falta ninguna ampliación, pero como estaba aprobado el presupuesto de todas maneras se amplió, por si acaso, aunque no en la medida que se había previsto inicialmente.
Coste del proyecto: 15 días x 3 técnicos+consultoría de dos empresas

Soporte 24h con BMC Performance Manager

2008-03-12T18:02:00.000+01:00

El soporte de 24 horas es fundamental para algunas empresas y no es factible en muchos casos tener a alguien comprobando periódicamente si todo va bien. Es mucho mejor tener un proceso automático que compruebe con la frecuencia necesaria aquello que nosotros consideremos apropiado.
Cliente: una empresa de telecomunicación
Necesidad: Llevar el soporte 24h. de un sistema crítico del que dependen miles de trabajadores y cientos de miles de clientes.
Situación previa: los tiempos de respuesta eran pésimos. Podían pasar horas hasta que alguien daba el aviso de que algo marchaba mal o por el contrario se avisaba por cuestiones puntuales que no requerían intervención.
Condicionantes del proyecto: el sistema era muy complejo. Y durante las guardias sólo una persona debía llevar el soporte de todo.
Descripción del sistema: Se utilizaban ordenadores personales (cientos), servidores UNIX en cluster, redes complicadas, bases de datos Oracle distribuidas.
Solución elegida: Patrol de BMC, ahora Performance Manager.
Implementación: Se analizaron los problemas más comunes y se vio la mejor manera de detectarlos. Se diseñaron consultas a la BBDD, tanto al diccionario de datos como a las tablas de las aplicaciones para ver si se trabajaba correctamente. Por otra parte se crearon scripts en UNIX que exploraban los ficheros de mensajes de errores de las aplicaciones más importantes y comprobaban si ejecutaban las tareas necesarias. También se analizaban los tiempos de respuesta de determinadas tareas. El resultado de todo esto era gestionado por Patrol que mandaba alertas en forma de SMS y correos cuando se sobrepasaban los umbrales definidos. Por otra parte los resultados se podían consultar posteriormente para evaluar el rendimiento del sistema. Ahora el soporte no era el último en enterarse sino que en muchas ocasiones solucionaba los problemas antes de que se produjeran o era el primero y nadie se daba cuenta de que realmente hubiera llegado a producirse una incidencia. Por otra parte, la tarea de soporte se simplificaba porque se sabía donde fallaba el sistema, o al menos donde no fallaba, aparte de las opiniones contradictorias de los usuarios.
Coste del proyecto: 100 días x hombre + licencia de BMC Patrol.

Control en tiempo real con Oracle

2007-09-20T19:11:00.000+02:00

Muchas veces los informes llegan tarde. Hay que saber en todo momento la marcha de una empresa para dirigirla con eficacia.
Cliente: una empresa de telecomunicación
Necesidad: Control en tiempo real de la calidad del servicio de soporte al cliente de la empresa
Situación previa: se lanzaban periódicamente consultas sobre la base de datos operacional de atención al cliente que medían unos cuantos parámetros de calidad. Era un proceso muy pesado para la base de datos por lo que se procuraban lanzar a horas de poca carga. Los resultados sólo los sabían interpretar unas pocas personas porque no eran claros y había que transformarlos mucho a mano para generar los informes.
Condicionantes del proyecto: la BBDD operacional tenía que tener una disponibilidad de 24h y no debía verse degradado su funcionamiento por la gran importancia que se le concedía al servicio al cliente.
Estructura de los datos: los datos de partida se encontraban en la BBDD operacional de seguimiento de incidencias, en la BBDD maestra de clientes y proveedores de la empresa y en otra BBDD con los datos de tráfico de red.
Solución elegida: La BBDD de Oracle porque todas las demás lo eran, la empresa tenía un buen contrato de mantenimiento y personal especializado en este entorno.
Implementación: en un entorno de desarrollo se creó el modelo de datos que satisfacía los requisitos especificados, se adaptaron los datos y cargaron en el modelo y finalmente se crearon los informes solicitados. El sistema resultante tenía un desfase máximo de una hora con respecto a los datos operacionales, pero algunos indicadores se elaboraban con los datos originales (sin desfase) y existía la posibilidad, si así se estimaba, de consultar otros.
Coste del proyecto: 200 días x hombre + licencias.

Informes de gestión para Oracle Financials

2007-09-20T19:05:00.000+02:00

Los sistemas de gestión integral de empresas del tipo de Oracle Financials son muy flexibles, valen para todo tipo de empresa siempre que se personalice para las necesidades particulares de la misma. Pero esta flexibilidad conlleva también una gran complejidad del modelo de datos y, por tanto, una gran dependencia de los productos proporcionados por Oracle y sus socios, que no siempre aportan una solución a las necesidades particulares del cliente. La otra solución es dedicar un trabajo adicional a buscar los datos perdidos.
Cliente: una empresa de fabricación
Necesidad: Generar informes específicos sobre rentabilidad .
Situación previa: se desconocían muchos detalles de la marcha del negocio. Sólo se disponía de los informes tipo que suministra Oracle Financials, los resultados de unas cuantas consultas que se ejecutaban sobre la BBDD y los datos que se suponían más fiables de los distintos departamentos involucrados.
Condicionantes del proyecto: los datos que mostraba Oracle Financials no coincidían con los datos de los distintos departamentos por utilizar criterios diferentes. La generación de los informes no debería interferir en el funcionamiento del sistema.
Estructura de los datos: modelo de datos orientado a la flexibilidad sin nombres reconocibles de campos ni tablas.
Solución elegida: Se eligió acceder directamente a las tablas con Crystal Reports, para tener un control fino de los datos que se utilizarían en los informes.
Implementación: sobre el mismo entorno de producción por no disponer de entorno de desarrollo. Se consiguió hacer coincidir los informes con los datos de los departamentos. Se estudió en que se diferenciaban con los proporcionados por Oracle Financials y se detectaron algunas inconsistencias que se corrigieron.
Coste del proyecto: 150 días x hombre + licencia de Crystal Reports.