Hoy tengo el placer de presentarles un excelente artículo enviado por nuestro amigo Pablo Espinar en el que se detallan las ventajas de utilizar un servidor virtual como soporte para la operativa sistemática. También nos describe, como caso práctico, algunos aspectos de su experiencia personal empleando esta tecnología.

DIFERENTES ENTORNOS, DIFERENTES NECESIDADES.

En Informática se suelen diferenciar, al menos, entre dos entornos de trabajo (entorno: conjunto formado por hardware, software, red,  y suministros varios - electricidad, temperatura, etc.). Veremos que dicha distinción puede fácilmente hacerse extensiva a la operativa sistemática:

— Entorno de desarrollo: son los ordenadores y demás infraestructura en los que los programadores trabajan para hacer los programas. Se caracteriza por no tener unos requerimientos de disponibilidad y rendimiento demasiado exigentes, ya que los programas no están a disposición del usuario final, y por lo tanto los errores que puedan surgir no tienen especial importancia.

En operativa sistemática esto se puede comparar con los ordenadores que utilizamos para hacer programación, backtesting, walk -forward, estimación de riesgo, gestión del portfolio, etc. En general las tareas que no dependen de un data-feed en tiempo real.

— Entorno de producción: son los ordenadores y demás infraestructura en los que los programas se ponen a disposición del usuario final para su explotación. En este entorno, los requerimientos de disponibilidad y rendimiento son máximos, siendo habitual en los últimos tiempos que se requiera una disponibilidad 24 x 7, y un rendimiento tan alto como permita el presupuesto de inversión en infraestructuras.

En operativa sistemática esto se puede equiparar a la infraestructura que utilizamos para el tiempo real: tanto los sistemas que tenemos funcionando sobre cuentas reales, como los que tenemos en simulación en modo "incubadora".

En el resto del artículo nos centraremos en este último entorno, sin duda el más crítico para nuestra actividad. El entorno de desarrollo en nuestro caso puede ser cualquier ordenador que tengamos en casa, simplemente cuanta más CPU, menos tardará en llevar a cabo nuestras "mega-optimizaciones".  

LO QUE PUEDE IR MAL IRÁ MAL.

La puesta a punto de un entorno de producción no es en definitiva más que un ejercicio de gestión de riesgos: hemos de imaginarnos todo lo que puede fallar y, a continuación, hemos de implementar "contramedidas" que palien al máximo dichos puntos de posible fallo.

Vamos por lo tanto a enumerar las posibles causas de fallo de nuestro sistema de producción de trading, así como las contramedidas usuales para cada uno de ellos.

1) Fluido eléctrico. El problema más usual con el que nos podemos encontrar. Desde que la parienta enchufa la plancha, el microondas y el calentador de la niña todo junto, y se van los plomos a hacer puñetas, hasta el apagón general en media ciudad (en Barcelona algunos estuvimos hasta tres días sin luz hace un par de años). Esto se "soluciona" mediante la instalación de un  SAI (Sistema de Alimentación Ininterrumpida), que permita tanto a nuestro ordenador como a nuestro router, seguir funcionando durante un período de tiempo. Normalmente, sin embargo, las baterías de estos sistemas son muy caras, y apenas alcanzan para un par o tres de horas de funcionamiento. Si el apagón se prolonga más tendremos que detener la operativa.

2) Conectividad a Internet. Otro clásico. De alguna manera, - normalmente por culpa de nuestro proveedor de Internet, aunque a veces el problema puede ser más general, - nuestra conexión con el broker y/o el data feed cae y todas nuestras posiciones abiertas quedan "huérfanas" del ojo del amo. La contramedida usual es disponer de una conexión a Internet de backup, el típico "pincho" USB de un operador móvil, por ejemplo. Seguimos añadiendo costes, por cierto.

3) Fallo hardware. No es tan habitual como los puntos 1 y 2, pero también puede suceder. Cualquier componente de nuestro PC de trading nos puede dejar "tirados" en un momento dado. Lo más habitual es que sea el disco duro, pero también se averían las placas bases, tarjetas gráficas, monitores, etc. Aquí lo más práctico es tener directamente otro ordenador de repuesto para estas contingencias. En esta categoría podríamos incluir también eventos que afecten a nuestro PC, tales como inundaciones (la lavadora!!), altas temperaturas, etc.  

4) Caída del broker. También puede suceder que nuestro broker o proveedor de datos tenga dificultades técnicas. Esto es un imponderable que no depende de nosotros, y poco se puede hacer. Algunos aconsejan tener cuenta en otro broker y abrir posiciones contrarias mientras dure la avería en nuestro broker "primario".

En todo caso, y tanto para esto como para el resto de averías, siempre es aconsejable contar con el teléfono del broker anotado en una agenda de papel para, eventualmente, cerrar todas nuestras posiciones.

5) Fallo software. De largo el fallo más habitual. "NinjaTrader ha detectado un error y debe cerrarse"... Los fallos pueden deberse tanto a la plataforma utilizada, como a las estrategias que hayamos programado. En este último caso no hay más remedio que probarlas tanto como sea posible, aquí ayuda un generoso periodo de incubadora, así como una correcta gestión de la calidad del software que generemos: registro de los errores y acciones correctivas, etc. En cuanto a las plataformas, las hay más y menos estables. En mi opinión, NinjaTrader es "bastante" estable (siempre hablando de la versión 6.5, versiones beta nunca tienen que acercarse ni de lejos al entorno de producción), pero algún que otro disgustillo suele dar de vez en cuando. Algo que si es importante aquí es que el ordenador de producción tenga el menos software instalado posible, para que no aparezcan las temidas incompatibilidades, a menudo generadoras de fallos y bajadas de rendimiento. En mi caso por ejemplo, ni siquiera tengo antivirus en mi entorno de producción.

Bien, lo lamentable de todo esto es que al final tenemos nuestro pobre despacho lleno de cachivaches, que se calientan, meten un montón de ruido y lo entorpecen todo (la parienta no suele estar muy contenta con esta disposición). Si además algún día tenemos que mudarnos, por ejemplo, los quebraderos de cabeza se multiplican.

Veamos si existe alguna otra alternativa más cómoda.

MANDÁNDOLO TODO A "LA NUBE"

En los últimos años se ha extendido en informática el concepto de "cloud computing", que básicamente consiste en que las empresas (o particulares), para ofrecer sus servicios sobre una plataforma informática, en lugar de comprar e instalar servidores en sus propias oficinas, lo que hacen es alquilarlos a proveedores de servicios de "hosting", que cuentan con enormes "datacenters" que albergan cientos de servidores de sus clientes, en condiciones de seguridad, disponibilidad y rendimiento muchos mayores de las que puede permitirse una pequeña empresa (no digamos ya un particular). Ello unido a la madurez de las tecnologías de virtualización de sistemas, hace que en la actualidad haya una oferta tremendamente competitiva en costes incluso para el trader particular.

El nombre de cloud computing viene porque se dice que tus servidores los tienes alojados en "la nube": algún sitio de Internet, (el sitio físico en el mundo muchas veces ni se conoce, por motivos de seguridad adicional) al que nos conectamos de manera remota, pero indistinguible de la situación en que los tuviésemos en nuestras instalaciones.

Existen dos tipos de ofertas en cuanto a "alojamiento" (hosting) de servidores:

• Alojamiento de un servidor físico. El proveedor te proporciona un servidor físico completo para ti sólo, te lo pone en su datacenter y te lo alquila mediante un pago mensual. Aquí no hay grandes economías de escala, por lo que la cuota es bastante alta.

Otra opción dentro de este mismo esquema es que tú te compras el servidor, y el proveedor lo único que hace es alquilarte el espacio en su datacenter.

• Servidores "virtuales". Aquí se trata de que el proveedor dispone un servidor físico, bastante potente, y sobre él, mediante software de virtualización, instala varios servidores virtuales (ocho, diez, o doce, o más por cada servidor físico). A ojos del cliente, estos servidores son indistinguibles de los físicos, pero para el proveedor supone un aprovechamiento máximo de recursos hardware, con lo que se puede realizar una oferta mucho más competitiva. Aquí los costes son mucho más contenidos, del orden de 30 $ a 100 $ mensuales, dependiendo de sistema operativo, memoria, etc.
  
  
  

>> Ampliar.

Y desde entonces estoy funcionando con esto desde abril de este año, y todavia no he tenido ni un sólo incidente, siempre he podido acceder a mi "Virtual Private Desktop" sin problemas. Empecé con una configuración mínima (512 Mb de memoria), y recientemente la he actualizado a 1 Gb de memoria, ya que con 512 Mb el Ninja va un poco justo, aunque se puede trabajar.

Finalmente comentar también, para el que le pueda interesar, un par de aspectos de mi forma de trabajar con esta configuración:

• No habría inconveniente en tener la consola remota encendida todo el día y tenerla en una pantalla como si de un ordenador local se tratara. En mi caso, sin embargo, me encuentro más cómodo "olvidándome" del entorno de producción, para así poder centrarme en las tareas de diseño y desarrollo de nuevos sistemas (si se está cada dos por tres consultando la consola de producción, se pierde eficacia en el resto de tareas, y se aumenta el stress, en mi opinión, que es, por supuesto, muy personal). Sin embargo esto no significa que tenga la operativa completamente desatendida, lo que no sería prudente. En mi caso lo que hago es que algunas estrategias, en algunos momentos del día (puntos de control) me envían un mensaje de correo electrónico, lo que me confirma que todo sigue funcionando correctamente. El código en NT que hace esto sería algo así:

       // Alarma de inicio de sesion

       if (Bars.BarsSinceSession == 0)

SendMail ("xxx@gmail.com", "xxx@gmail.com", "Inicio sesión Ok " +  this.Name + "_" + Instrument.MasterInstrument.Name + "_" + BarsPeriod.Value + "m", " ");    

• Automatización del registro de los trades. Soy un firme defensor de automatizar todo lo posible las tareas que no aportan valor añadido. Para realizar el registro de los trades de mis sistemas me valgo del excelente programa Market System Analyzer (MSA), del que ya se ha hablado aquí en otras ocasiones. Dicho programa almacena los datos de las operaciones en ficheros de texto con extensión csv. Pues bien, yo me he fabricado una rutina, que he incorporado a todas mis estrategias, que lo que hace es escribir directamente en ese fichero en tiempo real los datos del trade, entrada, salida, stop loss... De esa manera siempre tengo actualizados los ficheros MSA sin necesidad de introducir los datos a mano. Adicionalmente, me valgo de otra característica de "la nube": se trata de Dropbox (http://www.dropbox.com), un disco duro "virtual" (gratuito hasta 1 Gb) ubicado en Internet, como Gmail por ejemplo. Una particularidad especialmente útil de Dropbox es que viene con un programa (el único que tengo instalado en la estación de producción, además de NT 6.5) que permite tener sincronizadas algunas carpetas de tu disco duro, con las carpetas del servidor central, y eso lo puedes instalar en tantos ordenadores como desees. De esta manera, almaceno mis ficheros MSA en esas carpetas, y para ver los resultados de mis trades de cada día ni siquiera tengo que conectarme a la consola: basta con que abra los ficheros MSA de mi PC local que ya están actualizados en tiempo real con los datos de las operaciones.

En el área de descargas de la web hemos dejado una copia de la rutina de volcado de los trades, por si a alguien le resultara de interés.

© Pablo Espinar.

Tradingsys.org, 2010.