Los empleos de futuro….

Ayer noche escuchaba un report de una multinacional Americana (no daré nombres para evitar controversias y centrarnos más en el tema) que decía que nuestros hijos iban a trabajar en empleos que aun no existen a día de hoy, como diseñadores de cuerpos….

Me quedé meditando un momento y me di cuenta que detrás de aquel grandilocuente mensaje no había más que una obviedad (que nadie se enfade, por favor)

O es que acaso mi padre tenia claro que mi empleo iba a tener que ver con la informática (en ciernes en aquellos momentos) y más aún en el mundo de la virtualización.

Hacia el año 2000 tuve la suerte de poder asistir a una charla que patrocinaba un gran banco, en la que un político (bastante brillante, pero volveré a omitir nombres) dijo una frase que sí me impactó: “Los cambios de los próximos 10 años van a suponer un cambio global superior a los cambios de los últimos 50 años”.

4b434777cc749c900b78a8469772ba04

Vistas estas dos reflexiones, el report de “los empleos del futuro” con ese horizonte tan basto y lejano, me parece un brindis al sol, y como decía Groucho “Sres, estos son mis razonamientos y si no les gustan, tengo otros”.

Después de esta “introducción”, por llamarla de alguna manera, creo que es hora que me moje yo sobre mi visión, pero amigos, no lo haré a “tiro largo”. Me voy a quedar cerquita…..

Para mí, estos son las “profesiones” que van a venir, o que ya están aquí y que van a generar una demanda alta de profesionales, curiosamente casi todas están relacionadas con la IT.

Ingenieros de BIG DATA Profesionales que sean capaces de enfrentarse a una montaña de datos, y que sean capaces de ofrecernos información y sobre todo conocimiento. Cercanos, imbuidos o “al lado” van a estar los DATA SCIENTIST.

Otra parte que va tener que tener mucho juego es la de la Seguridad Informática en sus dos vertientes, Enterprise y privada.

Seguridad Enterprise o Chief Security Officer.  Esta persona con rango de directivo va a ser la que declare las políticas de seguridad informática en la empresa, las implante, y monte los sistemas para vigilar si se cumplen o no.

Seguridad informática privada No estoy hablando de “Body Guards” ni nada por el estilo. Estoy hablando de que cada vez “somos” mas IT, con mas gadgets basados en un mini procesador. Todos tenemos uno o varios devices tipo Tablet o Smartphone, donde “guardamos” nuestra información más delicada. Ya hay audífonos con procesadores y no hablemos de los implantes biónicos que se pinchan en el cerebro. He visto hackear un automóvil desde un portátil dentro de el sin estar conectado físicamente y por mucho que el conductor frenaba o giraba el volante, el coche acabó en una mullida cuneta de hierba, pero fuera de la carretera. Alguien tendrá que dedicarse a inventar sistemas de seguridad para que no entren virus en implantes biónicos o los coches no vayan por ahí haciendo ataques cual “Christine” de Steven King.

Ingeniero E-Learning. Es ya una obviedad que el E-learning va teniendo auge cada vez más importante. Yo particularmente he dado mucha formación presencial y alguna por E-Learning y lo que me he dado cuenta es “que no es lo mismo” y que “no cualquiera es capaz de coger una materia presencial y pasarla a un E-Learning de calidad.

Abogacía y Judicatura Digital. Durante unos años me dediqué a la seguridad informática y con ello colabore con el Grupo de delincuencia tecnológica de la Policía. El Jefe superior de Policía de entonces me decía, soy consciente de que en unos años la delincuencia va a pasar de lo “físico” a lo “virtual”. Da más velocidad, mas anonimato y tenemos que estar preparados. Pero cuando llegábamos a Juicio y tenia el rol de Périto, ahí flipaba. Desde péritos que hacían sus informes en “balleno” que a duras penas las entendía yo, hasta yo que escribía dos informes en uno, el técnico y seguidamente comentado en términos vulgares. Es hora de que la legislatura incorpore este tipo de delincuencia es su tipificación o establezca ciertos juzgados especializados.

Psicología organizativa.  Para los que no lo saben, aparte de la Psicología clínica existe la organizativa, la que toma el pulso a la empresa, la que sugiere cambios y ascensos, la que propone establecer procesos o automatizarlos.

Ingenieros en 3D. Esta claro que esta “disciplina” cada vez tiene más aplicación y mayor demanda. Personalmente he oído aplicaciones que me han dejado con la boca abierta, desde ortopedias y “yesos” de bajo coste para brazos rotos, hasta comida en 3D. Como todo, nace con “cuatro chalados” que lo hacen funcionar y dos “frikis” que por la noche tratan de llegar más lejos que los que lo han diseñado, pero hace falta conocimiento y método para integrar cualquier cosa en nuestra “civilización” (Por llamarle de alguna manera)

Como último, y no porque no haya más, pero sino este post será interminable, dos que se apartan de los que hemos estado hablando.

Médico biónico. Esta claro que estamos en el inicio de poder ver personas con partes de ellas biónicas.

Agroingeniero. Que duda cabe que la alimentación va a ser crucial en los próximos ¿años? ¿lustros? ¿décadas?

Hasta aquí mi pobre visión, que como personal, es válida, que cada uno haga (si le interesa) un rato de retro-inspección y revisión y vea cual es la suya.

 

VMmark: benchmarks para nuestro entorno virtualizado

Realizar pruebas de carga sobre nuestra infraestructura para ver sus niveles de respuesta bajo niveles previamente estipulados es un “must”. Tanto en el momento de instalar como para evaluar el nivel de respuesta de la infraestructura ante potenciales cambios. Aún así, puede resultar difícil realizar test realísticos pues hay que o dominar muy bien la aplicación para crear cargas sintéticas, que simulen reales, o disponer de herramientas específicas para cada test de simulación de stress para cada recurso.

Aunque estas opciones sirven para dar ciertos niveles de información con sus métricas, ninguna de ellas está pensada para testear una infraestructura virtualizada orientada a la consolidación de servicios.

Al final, VMmark usa aplicaciones que usamos día a día en nuestros Datacenters. Las agrupa en “tiles”, que son grupos de VMs que ejecutan varios servicios, cada tile con su cliente. Esta unidad precisamente, el tile, nos sirve para medir la capacidad de consolidación de nuestra infraestructura, contabilizando cuantos de ellos podemos ejecutar bajo niveles aceptables de rendimiento. Los servicios que simula cada tile son:

  • VM en Standby
    • Windows Server 2003 32bit, 1 vCPU, 512MB RAM, 4GB disco
  • Mail Server (Exchange 2007)
    • Windows Server 2008 64bit, 4 vCPU, 8GB RAM, 72GB disco
  • Web 2.0 (Olio)
    • Back End: SLES 11 64bit, 2vCPU, 2GB RAM, 14GB disco
    • Front End: SLES 11 64bit, 4vCPU, 6 GB RAM, 80GB disco
  • E-commerce (DVDStore 2)
    • Back End: SLES 11 64bit, 4vCPU, 4GB RAM, 45GB disco
    • 3xFront End: SLES 11 64bit, 2vCPU, 2GB RAM, 10GB disco

Todos ellos con ficheros de configuración perfectamente descritos por las guías de VMware, los clientes para los servicios y sobretodo los scripts de ejecución y reporting, nos darán datos muy exhaustivos, reales y directamente orientados a un entorno virtualizado.

Podéis obtenerlo la herramienta vmmark benchmark aquí.

maxresdefault

Glosario

Bueno, Agosto va terminando, y con ello las vacaciones.

Por razones personales no he podido hacerlas (espero escaparme algo en un momento), y me he liado con un proyecto que os implica…..   Ya os iré contando. Y pensando un poco, ya que he pensado matar dos pájaros de un tiro sobre una idea que me dio alguien del Blog. ¿Porque no haces un post que sea un glosario técnico y lo vas actualizando?.

Pues bien, aquí os presento la primera version del Glosario técnico informático. Cualquier error o modificación que os parezca pertinente, por favor, mail o comentario y lo corregimos.

Un Saludo

Glosario

Acuerdo de Nivel de Servicio, “Service Level Agreement”, SLA: acuerdo escrito entre un proveedor de servicio y su cliente con objeto de fijar el nivel acordado para la calidad de dicho servicio.

All in one: Literalmente “Todo en uno”. Se refiere a aquellos sistemas en que todos los elementos vienen integrados en un solo sistema.

Almacenamiento conectado en red, “Network Attached Storage”, NAS: Tecnología de almacenamiento dedicada a compartir la capacidad de almacenamiento de un computador (servidor) con computadoras personales o servidores clientes a través de una red (normalmente TCP/IP), haciendo uso de un sistema operativo optimizado para dar acceso con los protocolos CIFS, NFS, FTP o TFTP.

Almacenamiento definido por software, “Software Defined Storage”, SDS:   Concepto evolutivo del almacenamiento de datos para gestionar, mediante políticas, aprovisionamiento y gestión de gestores de datos independientes.

Alta disponibilidad, “High Availability”, HA: Protocolo de diseño del sistema y la implementación asociada que asegura un cierto grado absoluto  de continuidad

“Back-end”: Sistema o capa de acceso a datos, procesándolos desde el “Front-end” o frontal.

Baremetal: Software que se ejecuta directamente sobre el Hardware.

Bloque: Parte particionada de un disco que una SAN ofrece dentro de una LUN.

Burning: Proceso por el cual una pieza nueva que ha estado en su envoltorio es, después de su instalación, puesta en producción “quemando” los barnices que la protegían. También se aplica al proceso de Test.

Caché R/W:  Memoria intermedia que hace de almacenamiento o “buffer” para acelerar los procesos de acceso a datos. Pueden ser de lectura (R) o lectura/escritura (W).

Canal de Fibra, “Fibre Channel”, FC: Tecnología de red utilizada principalmente para redes de almacenamiento, disponible primero a la velocidad de 1 Gbit/s y posteriormente a 2; 4 y 8 Gbit/s.

Canal de Fibra sobre Ethernet, “Fibre Channel Over Ethernet”, FCOE: Tecnología de red de comunicaciones que encapsula las tramas de Fibre Channel sobre redes Ethernet.

Centro de Proceso de Datos, CPD: Sala con sistemas de protección antibandálica y sistemas de climatización y extinción preparadas para alojar los sistemas informáticos de la compañía o compañías.

CIFS: Protocolo de red que permite compartir archivos, impresoras entre nodos de una rede de ordenadores que usan el sistema operativo Windows.

Cloud: Computación la nube. Es un paradigma que permite ofrecer servicios de computación a través de una red que usualmente es Internet.

Cluster: Conjunto de computadores construidos mediante la utilización de hardware común y que se comportan como si fuera un único ordenador.

Código Abierto, “Open – Source”: software distribuido y desarrollado libremente. Se focaliza más en los beneficios prácticos (acceso al código fuente) que en cuestiones éticas o de libertad que tanto se destacan en el software libre.

Computadora Central, “Mainframe”: computadora grande, potente y costosa, usada principalmente por una gran compañía para el procesamiento de una gran cantidad de datos; por ejemplo, para el procesamiento de transacciones bancarias.

Controladora de disco, “Disk controller”:  Subsistema encargado de gestionar los discos de un sistema así como la de control de los datos de Entrada y Salida.

Convergencia de Hardware: Sistemas conformados ya en origen por la asociación de dos o más fabricantes.

Copia de seguridad, “Backup”: Copia de la información de un sistema que se realiza principalmente para ser restaurada en caso de pérdida de datos o en caso de ser requerida con posterioridad.

CPD en Cluster Dividido, “Split Cluster CPD”:  CPD en la que los recursos de computación están repartidos en los dos sites, conformando entre ellos un cluster de Alta Disponibilidad.

Datastore: Unidad de almacenamiento que usa VMware para ubicar las VMs. Detrás de éste puede haber un disco, un recurso NFS o una LUN.

Default: Valores establecidos en un sistema “Por defecto”.

Dirección IP, IP Address, IP: número que identifica, de manera lógica y jerárquica, a una Interfaz en red (elemento de comunicación/conexión) de un dispositivo (computadora, tableta, portátil, smartphone) que utilice el protocolo IP (Internet Protocol), que corresponde al nivel de red del modelo TCP/IP.

Director Ejecutivo o General, “Chief Executive Officer“, CEO: La persona encargada de máxima autoridad dentro de la gestión y dirección administrativa en una organización.

Director de Tecnología e Información, “Chief Information Officer”, CIO: Responsable de toda la TI de la empresa, su estrategia, su mantenimiento y su operación, así como su seguridad, pasiva y activa.

Disco Flash SSD: Discos duro conformados por circuitería y memoria que trabaja a una elevadísima velocidad (al no tener movimiento no tiene rpm) con menos riesgos al no tener partes móviles).

Discos NLSAS: Discos duros de tipo magnético de 7,2k rpm.

Disco SAS: Discos duros de tipo magnético de 10k o 15k rpm.

Discos SATA: Discos duros de tipo magnético de 7,2k rpm.

DPACK o “Dell Performance Analisys Collection Kit”: Herramienta de análisis propiedad de Dell que permite monitorizar el numero de IOPS que consume un sistema, entre otras mediciones.

Driver: “controlador de dispositivo” o “manejador de dispositivo”, es el elemento software utilizado en diversos sistemas operativos.

Dummy: Máquinas o sistemas que han sido creados con el único propósito de “sufrir” las pruebas, sin valor informativo intrínseco.

Enchufar y listo, Plug & Play, P&P: Tecnología o cualquier avance que permite a un dispositivo informático ser conectado a una computadora sin tener que configurar, mediante jumpers o software específico (no controladores) proporcionado por el fabricante, ni proporcionar parámetros a sus controladores. Para que sea posible, el sistema operativo con el que funciona el ordenador debe tener soporte para dicho dispositivo.

“End of life”: Cuando un modelo de ordenador, automóvil, electrodoméstico, deja de ser “soportado” por el fabricante, dejando de fabricar tanto el modelo como sus recambios, el modelo ha llega a su “End of life”.

“Entry level”: Llamados así a los modelos más básicos y económico de cualquier artículo, desarrollado para que sea el “punto de entrada” para luego crecer.

FA: Fuente de Alimentación de un Ordenador, Servidor, etc.

FAS: Modelo de SAN del fabricante NetApp que se caracteriza por el uso primordial del protocolo NFS.

“FAST TRACK”: Carril rápido. En una serie de formaciones, Fast Track se refiere a una que es refundición de todas y aunque más dura, es más corta que las demás.

Fault-tolerance: Propiedad que le permite a un sistema seguir funcionando correctamente en caso de fallo de una o varias de sus componentes.

HyperConvergencia, “Hyperconverged Integrated System”, HCIS: En un entorno hyperconvergente todos los elementos de almacenamiento y computación están optimizados para trabajar junto en un solo elemento de un solo vendedor.

Hyper-V: Hipervisor y Virtualización del fabricante Microsoft.

Hypervisor: Software de ordenador que es capaz de crear y ejecutar máquinas virtuales.

Infraestructura de escritorios virtuales, “Virtual desktop Infraestructure”, VDI: Sistema o plataforma capaz de alojar y proporcionar recursos para el buen funcionamiento de máquinas virtuales con la particularidad de que las VMs son escritorios y van supeditados a un gestor o “Broker”.

Infraestructura Virtual, “Virtual infraestructure”: También denominada “On premise Cloud”. Sistema o plataforma capaz de alojar y proporcionar recursos para el buen funcionamiento de máquinas virtuales.

iSCSI: estándar que permite el uso del protocolo SCSI sobre redes TCP/IP.

Kick-off”: Primera reunión de un proyecto importante donde se explícitan objetivos, responsables, fechas de cumplimiento así como todos los actuantes.

KVM: Hipervisor del fabricante Red Hat.

Lista de Compatibilidad de Hardware, “Hardware Compatibility List, HCL: Lista de Hardware , incluyendo periféricos, etc, que cierto fabricante declara compatibles con cierto Sistema Operativo.

Lista de verificación, “Check-List”: Lista de verificación que se efectúa para que antes de poner en marcha un sistema o dispositivo, el operador esté seguro de que se han efectuado todas las operaciones previas precisas.

Mantenimiento adaptativo: Modifica el sistema en producción para poderlo adecuar o adaptar a nuevas normas de empresa, legales o cambios en la tecnología.

Mantenimiento correctivo: Aquel que corrige los defectos observados en los equipamientos o instalaciones, es la forma más básica de mantenimiento y consiste en localizar averías o defectos y corregirlos o repararlos

Mantenimiento evolutivo: Aquel que instala los nuevos releases o versiones o soluciona algún error menor.

Memory Balooning: Técnica para reclamar memoria en un ordenador usada por un hipervisor para permitir al sistema del host físico para recuperar memoria no usada de cierto Sistema Operativo de una VM y compartir con otras.

Migración “cut in cut off”: Migración planteada con la estrategia “paramos A”, “arrancamos B”.

Migración Smooth: Migración planteada con la estrategia de una forma escalonada i creciente.

Morning storm: Se refiere al colapso que puede sufrir la SAN cualquier mañana cuando todos los escritorios o VDI se ponen en marcha a la vez por los usuarios, requiriendo cantidades ingentes de IOPS de la SAN.

Murphy: Edward Aloysius Murphy, (11 de enero de 1918 – 17 de julio de 1990) fue un ingeniero aeroespacial estadounidense. Murphy trabajó en sistemas de seguridad críticos y es conocido por la homónima Ley de Murphy, que declara que “Si hay varias maneras de hacer una tarea, y uno de estos caminos conduce al desastre, entonces alguien utilizará ese camino”.

Multiprocesamiento simétrico, “Simetric Processing”, SMP: Los sistemas SMP permiten que cualquier procesador trabaje en cualquier tarea sin importar su localización en memoria; con un propicio soporte del sistema operativo, estos sistemas pueden mover fácilmente tareas entre los procesadores para garantizar eficientemente el trabajo.

Nodos: Puntos en redes que confluyen en un mismo lugar. Pueden ser cada ordenador de una red o cada servidor en Internet.

Núcleo, “Core”: Cada uno de los procesadores “lógicos” que alberga el procesador o “Socket” físico.

Objetivo de Punto de recuperación, “Recovery Point Objective”, RPO: Punto definido por el Plan de continuidad de negocio. Es el máximo período de tiempo que es asumible una pérdida de datos.

Objetivo de Tiempo de Recuperación, “Recovery Time Objective”, RTO:  tiempo definido dentro del nivel de servicio en el que un proceso de negocio debe ser recuperado después de un desastre o pérdida para así evitar consecuencias debido a la ruptura de continuidad de servicio.

Obligatorio, “Mandatory”: De obligado cumplimiento.

Obsolescencia programada, “Planned obsolescence”: Programación del fin de la vida útil de un producto.

Operaciones de Entrada Salida por segundo, IOPS: unidad de benchmark usada para medir el rendimiento de dispositivos de almacenamiento informáticos como unidades de disco duro (HDD), unidades de estado sólido (SSD) y acceso a almacenamiento en red (NAS).

Pasillos fríos y calientes: Técnica en los CPD para que con unos cierres semi estancos los ordenadores reciban por delante, de un pasillo frio, aire acondicionado, siendo este expulsado por detrás una vez utilizado y calentado a un pasillo caliente que disipara el calor.

Placa madre, “Mother Board”: La placa base, también conocida como placa madre o placa principal (motherboard o mainboard en inglés), es una tarjeta de circuito impreso a la que se conectan los componentes que constituyen la computadora.

Planificador de Capacidad, “Capacity Planner”: Herramienta en Cloud de VMware capaz de dimensionar una granja física ofreciendo un report de volumetrías.

Procesador: Ver CPU.

Proxmox: Virtualizacion Open Source.

Punto único de fallo, “Single Point of Failure”, S.P.O.F. Para garantizar la inexistencia de un SPOF en un sistema, todos sus componentes suelen ser redundados, conformando así un sistema de alta disponibilidad, que garantiza el correcto funcionamiento aún en caso de que alguno de sus componentes falle.

Recuperación de desastres, “Disaster recovery Plan”, DR: Proceso de recuperación que cubre los datos, el hardware y el software crítico, para que un negocio pueda comenzar de nuevo sus operaciones en caso de un desastre natural o causado por humanos.

Rollback: operación que devuelve a la base de datos o sistema a algún estado previo.

Sistemas de archivo en red,“Network File System”, NFS: protocolo para compartición de archivos, creado por Sun Microsystems para SunOS en 1984. Se caracteriza por compartir carpetas.

Red de Area de Almacenamiento, “Storage Area Network”, SAN: Una SAN es una red dedicada al almacenamiento que está conectada a las redes de comunicación de una compañía. Además de contar con interfaces de red tradicionales, los equipos con acceso a la SAN tienen una interfaz de red específica que se conecta a la SAN.

StoragevMotion: Componente de VMware vSphere que permite la migración en vivo de una VM en ejecución de sus ficheros, de un datastore a otro.

Support & Subscription: Es la quota que se abona al fabricante por concepto de “mantenimiento”, el primer concepto se refiere a que el fabricante dará soporte para que funcione el sistema, el segundo, que el cliente mantiene la capacidad de instalar siempre la última versión del sistema sin coste.

Sistema Operativo, “Operating System”, O.S., S.O.: Programa o conjunto de programas de un sistema informático que gestiona los recursos de hardware y provee servicios a los programas de aplicación de software.

Tarjeta de Red, “Network Card”, Nic:  es la periferia que actúa de interfaz de conexión entre aparatos o dispositivos, y también posibilita compartir recursos (discos duros, impresoras, etcétera) entre dos o más computadoras, es decir, en una red de computadoras.

Tecnología de la Información, “Information Technology”, TI, IT: Concepto que abarca lo otrora llamada “Informática”, con hincapié en su parte crítica en el negocio y su valor en la cadena de la empresa u organización.

Test de Carga: Valida y verifica atributos de la calidad del sistema, tales como la escalabilidad, fiabilidad y uso de los recursos.

Test de tolerancia fallos: Validan todos los elementos redundados que se han incluido en el diseño para evitar los S.P.O.F.

Throughput: es definido como la velocidad real de transporte de datos a través de una red telemática, el cual normalmente se mide en Mbit/s y siempre será inferior al ancho de banda o bandwidth.

UCS: Model de servidor de Cisco.

Unidad de Procesamiento Central, “Central Process Unit”, CPU: Subsistema de un ordenador que interpreta las instrucciones de un programa informático mediante la realización de las operaciones básicas aritméticas, lógicas y de entrada/salida del sistema.

Update: Supone un a nueva versión en la reléase, significando una “major” o “standalone” significando hallarse en una nueva versión.

Upgrade: Supone una subida en la versión de la reléase, pero continúa estando en la misma versión.

vApp: Permite a diferentes VMs trabajar como una sola máquina trabajando juntas en un stack.

Versión, Release: número o nombre que se asigna a un programa informático para mencionar su nivel de desarrollo y su actualización. Lo habitual es que el versionado esté dado por dos números, separados por un punto.

vCPU: También conocido como procesador virtual, es una unidad de procesamiento central física que ha sido asignada a una VM.

Virtualización: Creación a través de software de una versión virtual de algún recurso tecnológico, como puede ser una plataforma de hardware, un sistema operativo, un dispositivo de almacenamiento u otros recursos de red.

VM: software que simula a una computadora y puede ejecutar programas como si fuese una computadora real. Este software en un principio fue definido como “un duplicado eficiente y aislado de una máquina física”. La acepción del término actualmente incluye a máquinas virtuales que no tienen ninguna equivalencia directa con ningún hardware real.

vMotion: Permite la migración “en vivo” de una maquina virtual en ejecución desde un host físico a otro, sin caída de servicio.

 

Take care

Tu primer entorno de desarrollo con Vagrant

Vagrant es una herramienta que nos permite crear y configurar entornos virtuales de desarrollo de forma fácil. La ventaja de crear un entorno de desarrollo con Vagrant es que lo podemos ejecutar sobre nuestro portátil o estación de trabajo, sin necesidad de utilizar infraestructuras externas. Podemos arrancar y parar el entorno tantas veces como queramos y finalmente lo podemos compartir con el resto del equipo de sistemas y desarrollo para que estos lo puedan ejecutar en su portátil.

Con Vagrant podemos ejecutar servidores virtuales con Windows, Linux o Mac OS X, y lo podemos hacer utilizando los hypervisores VMware Workstations, VMware Fusion o VirtualBox. Además Vagrant también dispone de conectores para ejecutar estos servidores virtuales sobre proveedores de infraestructura como AWS Amazon o Digitalocean entre otros.

Cuando utilizamos Vagrant con un sistema de gestión de configuración como Chef o Puppet, podemos desplegar una copia exacta de un entorno de producción sobre nuestro portátil. Donde podemos hacer cambios de configuración y probarlos antes de aplicarlos a producción.

A continuación veremos un ejemplo de como crear un entorno de desarrollo utilizando Vagrant con el hypervisidor Virtualbox para crear un servidor Linux con Ubuntu 16.04 LTS.

Antes de nada, hay que instalar tanto VirtualBox como Vagrant en nuestro portátil. Una vez instalado VirtualBox y Vagrant, debemos buscar la Vagrant Box (imagen de disco) del sistema operativo que queremos instalar,  en nuestro caso Ubuntu 16.04 LTS. En https://atlas.hashicorp.com/boxes/search buscamos la Vagrant Box de Ubuntu 16.04 LTS que se llama “ubuntu/xenial64”.

El siguiente paso es crear el fichero Vagrantfile. Este tiene la finalidad de establecer el directorio del proyecto y describir el entorno que vamos a instalar y su configuración. Para crear el fichero Vagrantfile con la Vagrant Box “ubuntu/xenial64” abrimos un terminal en el directorio donde queremos crear el servidor virtual y ejecutamos el comando siguiente:

vagrant init ubuntu/xenial64

Al ejecutar vagrant init se crear el fichero Vagratfile en el directorio desde donde hemos ejecutado vagrant init. Este se ha configurado con la Vagrant Box “ubuntu/xenial64”. Si editamos el fichero Vagrantfile veremos que ha configurado el parámetro “config.vm.box” con la Vagrant Box “ubuntu/xenial64”.

# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure(2) do |config|
  config.vm.box = “ubuntu/xenial64”
end

Esta es la configuración basica del fichero Vagratfile, pero en el podemos configurar uno o más servidores virtuales que formaran nuestro entorno de desarrollo, y para cada uno de estos servidores podemos configurar sus recursos como la ram, ips, etc. En el fichero Vagrantfile también podemos configurar el método que vamos a utilizar para provisionar cada servidor.  Por ejemplo, podemos provisionar el servidor mediante un script bash o mediante un sistema de gestión de la configuración como Chef o Puppet. En otro post veremos como provisionar el servidor virtual mediante Chef.

Antes de arrancar el servidor descargamos la Vagrant Box y la guardamos en local para evitar que esta se descargue cada vez que arrancamos el servidor virtual.

vagrant box add ubuntu/xenial64

Cuando ya tenemos la Vagrant Box descargada ya podemos arrancar el servidor virtual, acceder por SSH y finalmente destruirlo cuando ya hemos finalizado el desarrollo.

Arrancar el servidor virtual:
vagrant up

Acceder por SSH al servidor virtual:
vagrant ssh

Destruir el servidor virtual:
vagrant destroy

vCheck para vSphere: Informes de nuestra infraestructura mediante PowerShell

Vengo esta semana con un post de alcance para presentaros otra herramienta que, siguiendo la línea de de los últimas semanas, nos aportará de manera sencilla y pseudo-nativa reportes de nuestro entorno de vSphere. En este caso, hablaremos de vCheck que nos dará un overview de nuestro entorno virtual y un detalle de los problemas que pueda presentar.

Además de ser una herramienta bastante utilizada y reconocida, he querido aprovechar para presentarla estos días porque en el VMworld que tendrá lugar a finales de este mes de agosto en Las Vegas se ha organizado un Hackhaton donde uno de los puntos que se va a desarrollar va a ser precisamente vCheck, esperemos que salgan mejoras y desarrollos interesantes. Por cierto, si tenéis la suerte de andar por Las Vegas el dia 29, os recomiendo mucho asistir al Hackhaton de VMware Code, podéis registraros a este evento aquí

Está basada en PowerCLI, la interface y cmdlets de PowerShell para gestionar las soluciones de VMware. Basta con disponer de PowerShell en versión 3.0 o superior, tener PowerCLI instalado y disponer del script de PowerShell que nos lanzará el reporte.

Podéis descargar el script aquí y disponéis de un pequeño vídeo de introducción donde el mismo Alan Renouf, desarrollador del script cuenta como empezar con ello.

sVMWare_preston_vcheck_report

DevOps con proveedores externos

Hay una pregunta que cualquier empresa puede hacerse cuando se plantea implantar prácticas de DevOps. ¿Puedo implantar prácticas DevOps cuando trabajo con proveedores externos ?

Son muchas las empresas que utilizan proveedores externos, ya sean estos desarrolladores, consultoras o proveedores de servicios. Y además, estos equipos externos realizan su trabajo remotamente desde diferentes lugares y zonas horarias. Para implantar Devops con proveedores externos hay un conjunto de pautas que ayudan a que la colaboración sea fluida.

Lo primero y esencial es establecer una comunicación abierta. La comunicación entre todos los equipos de trabajo, internos y externos, debe establecerse en todas las etapas, desde la fase de planificación a las fases  de pruebas, despliegue o operación. Es importante que todos los actores conozcan y participen en la definición de los proyectos y en la planificación. Para ello, es altamente recomendable establecer reuniones periódicas presenciales si es posible. El contacto genera empatía, permite compartir conocimiento e ideas y permite entender al otro, uno de los aspectos en que pone énfasis DevOps. En caso de no ser posible hacer reuniones presenciales, pueden hacerse reuniones utilizando programas de video conferencia como Skype o Hangouts.

DevOpsConProveedoresExternos

También es importante integrar a los equipos externos en los sistemas de mensajería internos como listas de correo, sistemas de Chat y permitir el acceso a los espacios de trabajo compartido como los recursos de red.

Por otro lado, también se puede integrar a los equipos externos en los procesos operativos y en los sistemas de gestión utilizados como los repositorios de código fuente, aplicaciones de gestión de proyectos, sistemas de monitorización, sistemas de automatización, etc.

Otro aspecto que ayuda mucho a la colaboración entre equipos remotos, es utilizar sistemas de virtualización o en cloud para el despliegue de los entornos de desarrollo y testing. Los sistemas de virtualización permiten a los equipos externos reproducir las infraestructuras de forma fácil y económica, y sin necesidad de compartir los sistemas internos.

En definitiva, el hecho de utilizar proveedores externos no debe ser un problema para utilizar prácticas DevOps. Lo que si que hay que ver en cada caso es como establecer una comunicación fluida entro todos los equipos de trabajo y como integrar a estos proveedores externos en los procesos internos de la empresa.

 

Eliminar builds de todos los proyectos.

Cuando un Jenkins está en producción y tiene muchos Jobs genera una gran cantidad de logs puedes eliminar esos logs usando scripting de jenkins así:

Página principal > Manage Jenkins > Script Console

Una vez allí pegar este script y darle a enviar.

def jobs = Jenkins.instance.projects.collect { it }
jobs.each { job -> job.getBuilds().each { it.delete() }}

EL CÓDIGO

El texto no es mío. Llego a mí no se como, sinó, citaría su procedencia.

El texto es largo y friki, pero para los que nos dedicamos a esto de la IT, cuando lo vas leyendo, vas sonriendo, porque reconoces muchas, muchas situaciones.

Os lo recomiendo leer, porque la moraleja es importante y hay más de una. No me alargo más, porque hay tela que cortar…….  PS. Muchos casos ahí expuestos los he vivido en propia carne 🙂


El código

Tengo la boca grande como un buzón. Media vida metido en el departamento de informática y aún me tengo que castigar el lomo yo mismo por lo inocente que soy. Pero no digo que tenga la boca grande por ser indiscreto, o faltón, que también; sino porque cada vez que me preguntan contesto con lo que yo sé que es verdad y no con lo que quieren escuchar.

Ser honesto en la vida es una puta mierda. Suprakillminds depende enormemente de la buena marcha de una aplicación muy particular. La dichosa aplicación la usan muchos usuarios y ha de ser rápida, veloz y ligera cual gacela huyendo de un guepardo con hambre de seis días y zapatillas nuevas. Cuando compraron la aplicación, y maldigo al lenguaje HTML por no tener suficientes herramientas de formato para remarcar el “compraron”; resultó que todo iba como la seda. Asignamos un servidor normalito, con treinta y dos gigas de RAM y dos procesadores de ocho núcleos con tres discos SAS de trescientos gigas en RAID 5. Una cosa normalita para mover una base de datos e intercambio de ficheros de operaciones. La aplicación en cuestión se comunica con dispositivos remotos mediante un fichero que se deja en un directorio y los dispositivos remotos preguntan si hay algo mediante FTP, o si tienen que dejar algo para que la aplicación procese, pues lo dejan mediante el mismo sofisticado mecanismo. Hasta ahí todo muy siglo XX, pero bien.

Entonces, la parte servidora hace lo que coño sea que tenga que hacer y devuelve el resultado a impresoras, dispositivos, gente, máquinas de café, etc. Todo esto que cuento no puede parecerle a nadie ni medio complicado. No lo es. De hecho, las operaciones se parecen mucho a un carrito de la compra. Sin embargo, de un tiempo a esta parte, la aplicación se ha ralentizado hasta límites inaceptables. La base de datos no es. Aquí mi colega el MKII ha sacado los diplomas Emecé, los ha puesto encima de la mesa y ha tuneado la base de datos puesto que el servidor de bases de datos fue forjado en Mordor. De hecho, la base de datos responde ahora como un puto tiro. Me voy a tener que hacer un Emecé para aprender cosas tan chula. No quisiera quitarle méritos a MKII por nada del mundo. Es un tío formado y serio. Pero que digo yo que se tiene que notar el aumento de rendimiento si pones índices coherentes a las tablas de la base de datos. Aunque sea uno. Porque no tenía ni un mal índice. Nada.

Descartada la base de datos miramos el procesador. Los procesadores. Nada. La aplicación provocaba algunos picos pero nada que perturbase la paz de los dieciséis núcleos instalados. Tan panchos estaban limándose las uñas. La memoria no era tampoco. Había memoria libre para aburrir. El disco tampoco estaba muy ocupado, la verdad. La red local estaba tocando las palmas y los enlaces al exterior relajados y con capacidad testada. No era tampoco. Aquello tenía pinta de que iba a ser el pin siete del RJ45 o que habíamos encendido el servidor con el dedo en ángulo de doce grados en lugar de dieciséis. Vamos, que sólo nos quedaba un sospechoso: el programa. Y ahí estuvo mi error. $Hyperboss fue informado pertinentemente por Gargamel de un problema informático sin resolver y nos reunió a MKII y a mi en su despacho. Muy serio. -Pero vamos a ver, Wardog: si el servidor es muy lento, cámbialo. -Que no. que no es lento, oiga. El servidor no es. -¡Ponle más memoria! -No le hace falta, no la está gastando. -¿Entonces? -Como no sea el programa… -¿Y por qué iba a ser el programa? -Por exclusión. Me quedan el programa y los usuarios. Y por una vez les voy a dar un voto de confianza a los usuarios porque no pueden tocar nada de la aplicación, sólo la echan de comer. –

Pues llama a los del programa. -Ya lo he hecho. -¿Y qué te dicen? -Que es por la red de la empresa, que a ellos les va bien. -¡Pues cambia la red! -No. Va bien. La red no es. -¿Lo sabrán mejor los del programa, no? -No. Ellos ni puta idea de cómo va nuestra red. Ellos saben de su programa. -Vale, pues si no es la red, ¿qué es? -Insisto: el programa o el usuario. Descarto el usuario. -Pues busca otra causa. -Un pitufo epiléptico ha estado practicando sexo tántrico con doce sapos encantados sobre los portales RFID me parece una causa razonable. -¡Una causa seria! -Con todos los respetos- interrumpe EL Máquina II,- pero Wardog tiene razón. No puede ser otra cosa que el programa. Hemos descartado las demás opciones y no tenemos ningún interés en llevar razón, sino que simplemente, el resto de posibles causas están funcionando perfectamente. -Vamos a ver si nos entendemos, muchachos-, se frota el puente de la nariz concienzudamente.- He pagado una cifra considerable a una empresa de desarrollo de software muy conocida para que esa aplicación vuele. No me puedo creer que, después de seis meses, ya no funcione. Algo habéis tocado. -No. Conforme la dejaron los artistas de $Bullshitsoft está. De hecho, ni siquiera hemos habilitado ningún puesto nuevo ni hemos quitado los existentes. Cero cambios. -¡Pues algo tiene que ser!- dice con un puñetazo en la mesa. -¡Pues es el programa!- replico con una palmada y un firulillo flamenco por encima de la cabeza. Nos miramos fijamente a los ojos. Él con el puño aún en la mesa. Yo, con la mano a diez centímetros de la cabeza y la palma hacia arriba. –

El programa no puede ser, Wardog. Que me ha costado una millonada. -Primera fase del duelo: negación. El Titanic también costó una millonada. Y ahí está, en calo. -Pues mira a ver qué falla en el programa y arréglalo. -No puedo. -¿Cómo que no puedes? -No puedo. Sabemos que en los dispositivos el cambio de una pantalla a otra tarda mucho, pero no sabemos qué coño hace en el intervalo. A veces la conexión explota y otras veces suelta un error inespecífico. Pero sin el código fuente no podemos saber qué es lo que le pica. -¡Pues que lo arreglen los de $Bullshitsoft! -No. Como son tan guays y tan caros, si no les damos un diagnóstico claro, no mueven un dedo. -¿Cómo que no? -Como que no. Que o les decimos qué va mal o no pueden hacer nada. Y nuestra mejor aproximación a un diagnóstico detallado es: “Todo va lento”. -¡Ponme con ellos! Marco el número en el teléfono de sobremesa de $Hyperboss. Pide hablar con soporte. Grita mucho. Dice que va lento. Se calma. Dice que eso espera. Cuelga. –

Ya está, solucionado. -¿Ya va rápido el programa? -No, joder. Mañana tenemos aquí a un ingeniero de la empresa para arreglarlo. Sólo hacía falta ponerse duro. -Entonces no está solucionado. -¡Pero mañana estará solucionado! -Vale, vale, si yo lo decía por hablar con propiedad. Al día siguiente, a las nueve de la mañana se presentó un ingeniero de $Bullshitsoft en $Suprakillminds, con su chaqueta, su corbata y las manos en los bolsillos. $Deity me libre de prejuzgar a la gente, pero mi olfato canino para detectar imbéciles me estaba alertando acerca de este individuo. Le cogí de la manita y me lo llevé, a petición suya, a ver cómo iban de lento los terminales equipados con su software. Se colocó detrás de un operario para ver cómo trabajaba el hombre. -Ahá-. Dijo muy concentrado el ingeniero.- Parece que tenemos un problema de velocidad. -¡No me digas! ¿Cómo lo has notado? ¿Quizá por el hecho de que nuestro operario puede pulsar un botón cada minuto y medio? -Sí. Parece que hay algo que ralentiza la aplicación. -Y así, concretando más… -No sé. Pero efectivamente, va todo muy lento. -Eso ya lo sabíamos y os lo hicimos saber. -Pero ahora ya lo sabemos con certeza. -Anda. Oye, me tienes que decir dónde estudia uno la carrera de saber las cosas con certeza. Porque ya hemos comunicado en varias ocasiones que todo el aplicativo se arrastra como una babosa coja. -Bien, yo hablaré con los programadores para que lo revisen. -¿Para que revisen qué? -El problema de lentitud. -¿Y cuál es la causa concreta por la que va lento? -No lo sé, es algo general. -Tócate los cojones.

Yo, de verdad, con vosotros es que aprendo. ¡Ay si yo me hubiese hecho ingeniero en vez de puta! El ingeniero ingenioso se fue con las manos en los bolsillos as fast as he came. Dejando en mi correo electrónico un precioso informe de dos líneas redactado al vuelo con su Ladrilloberry. Eso es un usuario móvil avanzado, amigos. Le enseñé el informe a $Hyperboss. Lo leyó doce veces, incrédulo. El informe rezaba: Detectada ralentización en todos los procesos de la aplicación. Se pasa tarea a soporte para corrección y puesta en producción. Y debajo la firma del Ingeniero en Diagnósticos por la prestigiosa Universidad Handinpockets. Casi podía apreciar cómo la ira se abría camino desde la vésicula biliar de $Hyperboss hacia su garganta y cómo el hombre, en un esfuerzo de autocontrol la retenía ahí. -Wardog… ¿cómo se llama eso que decís los informáticos para tocar los programas? -¿Dedo? – juego con él. -No, coño. Lo de programar. -Ah. Código fuente. -Si os consigo el código fuente, ¿podéis mirar qué coño le pasa a la aplicación? -Podemos intentarlo. Pero no le van a dar el código fuente. -Ya te digo yo que sí me lo dan. Dicho y hecho. Al día siguiente $Hyperboss se presentó en el departamento mientras desayunábamos y me puso en la mesa un pendrive con el código fuente de la aplicación de los cojones.

MKII y yo lo miramos atemorizados. Parece vibrar quedamente, emitir una especie de fulgor fantasmagórico. Era algo difícil de explicar. Como una luz oscura. Como si estuviese iluminado por la oscuridad que emitía. Al final lo cogí con más curiosidad que ganas y lo puse en mi equipo. Abrí el pendrive y vi que contenía un directorio de nombre “SRC”. Vamos bien, hasta ahí lo entiendo. Abro el directorio y veo el nombre Suprakillminds. Abro y tenemos “srv” y “clt”. Joder, qué bueno soy. Hasta aquí entiendo todo. Abro primero “srv” y veo un proyecto de Mordor Cé Cross Plus. Abro el proyecto y ante mí se muestra en toda su grandeza. Siempre me maravillo cuando veo un programa hecho con un lenguaje orientado a objetos que no implementa ni una clase. De hecho, el programa principal parece ser un monolítico fichero. Todo corre en un gigantesco loop cuya única condición de salida es, al parecer, un valor uno en una variable de nombre “salir”.

Empiezo a leer mientras MKII gestiona cosas, pero tanto me oye bufar que se trae la silla a mi puesto y se pone a leer en la pantalla. -Mira, tenemos seis scrolls completos sólo para las variables globales. No está mal, ¿eh? -¿Y por qué hay tantas variables globales? -Y yo qué sé. Espera, espera, terrible sospecha. Mira, ahí está. -¿El qué? -¿No lo ves? ¡Todas las funciones devuelven void! -¡No jodas! -¡Claro! ¡Son unos cracks! ¡Si todas las variables son globales no hace falta pasar parámetros ni devolver valores! -Pero eso no es eficiente. -¡Porque tú lo digas! ¡Es súper efectivo! ¡Efectivo que te defecas haciendo estrellitas! -¿Hablas en serio? -No. Ah, mira, ¿ves? Aquí hay funciones que no devuelven void. Desde luego, qué malpensado somos. -Oye, pero esa función… -Sí, ¿qué pasa? Suma dos variables globales y devuelve el resultado. Y te callas que te veo un poco talibán del Mordor Cé Cross Plus. -¿Hablas en serio? -Que no, coño, pero es que si no relajo tensiones con las coñas me van a empezar a sangrar los ojos. -Espera, espera, ¿qué es eso?- me dice MKII abriendo mucho los ojos y señalando la pantalla. Me da palmaditas con su mano helada en el antebrazo. -Oh. $deity desdoblado. Me envaro en la silla y empiezo a hiperventilar.

Antes nuestros estupefactos ojos se muestran brillantes, sólidos, rotundos y pulidos, incontables GOTOs destacando sobre el blanco del editor como una macha de sangre fresca en la nieve. Pero no es sólo el GOTO infame. Es que, uno tras otro, y sin orden lógico aparente, los GOTOs envían la ejecución del programa a etiquetas de nombre tan específico como “Label1″, “Label2″, “Label7″ y así hasta “Labeln” siendo n un número entero desaforado. Con los ojos a punto de salírsenos de las órbitas nos levantamos sin decir nada en busca de bálsamo caliente. Por el pasillo nos encontramos a $Hyperboss. Le miramos con nuestra cara de espanto. -¡Qué tal chicos! ¿Entendéis el código fuente ese? Salimos corriendo gritando mucho con los brazos levantados. Bueno, esa fue mi primera intención; y sé que MKII me hubiese imitado, pero no. Permanecimos con nuestra cara de espanto estoicamente. -¿Chicos? ¿Lo podéis arreglar? -Mire, $Hyperboss… eso no se puede arreglar. Por mucho que queramos. Es una perversión. Es… es… -¿Ya estamos con las quejas? Primero que si no tenéis el código fuente, luego que si lo tenéis. –

$Hyperboss- dice MKII.- Ese programa es obsceno. -Está tan mal hecho que parece fabricado con trozos aleatorios de manual. MKII y yo nos miramos inmediatamente. Claro, por eso las etiquetas de los gotos se llaman Labelx. Trozos de manual. -Becarios- decimos al unísono. -¿De qué habláis? -Este programa lo han debido hacer becarios en precario. -¿Con lo que cuesta lo van a haber hecho becarios? ¡Que es una empresa seria! -Con lo que cuesta. El programa compila y funciona cumpliendo los requisitos. Facturado. Los becarios son gratis o baratos. Más margen de beneficio.- replico. -Bueno, da igual. Me ha costado mucho conseguir el código fuente. Arregladlo como sea. -Haremos lo que esté en nuestra mano.- contesta demasiado dispuesto MKII. Con un café en el cuerpo la cosa parece más soportable. El ejecutable principal de la parte cliente no parece tener más problemas que la sobredosis de tumores de código. El hijo de puta es feo y deforme, pero como sólo tiene que recoger unos ficheros, leerlos y meterlos en la base de datos y vive en una máquina absolutamente sobredimensionada, corre que se las pela. -Pero hay una cosa que no veo.- Dice MKII. -¿El qué? -¿Cómo pasa parámetros desde el bucle principal al programa de impresión? –

No sé, veamos el programa de impresión. Abro “print.cpp” y busco la entrada de parámetros. No la veo. Edición, buscar argc. Nop. ¿Cómo es posible? MKII y yo nos miramos extrañados. ¿Cómo es posible que un programa necesite un parámetro para imprimir un resultado y no lo reciba al iniciar la ejecución? ¿Cómo puede ser tan sofisticado? Una lectura rápida de main lo explica de inmediato. -Esto es lo más grande, MKII. -¿Es eso lo que parece que es? -Los parámetros los coge de una variable de entorno del sistema. ¿Qué te parece? -Pero… ¿no se supone que si eso es así, se podría sobreescribir la variable de entorno y que las impresiones salgan por donde les de la gana? -Veámoslo en el programa principal. Buscamos la llamada a print. Resulta que no, que no se puede sobreescribir dicha variable de entorno porque resulta que la llamada a print está detrás de un bucle del que sólo se sale si otra variable de entorno está a cero: la variable “PUEDIMP”. Así, tal cual la escribo. Cuando PUEDIMP tiene el valor apropiado (no parece ser booleana, sino otra cosa, tal vez trileana con valores sí, no y psá) se imprime y se cambia de nuevo el valor para indicar que está dispuesta a imprimir otra vez. Un semáforo un poco rústico y sobre todo, muy seguro. -La madre que los parió. ¿Y tú sabes lo que ha costado esto, Maqui? -Lo sé. Y por eso sufro más que tú. -Al comercial de esta casa hay que juzgarlo en Estrasburgo. -En fin. Sigamos.

Esto está feo, pero no afecta a la velocidad. Vamos a ver el cliente qué hace. Abro el directorio del cliente. Ahogo un grito. Intento tragar saliva y me cuesta horrores. MKII me mira. Mira la pantalla. Suspira hondamente. Me levanto. Voy hacia un armario y con un suspiro lo abro. Aparto las tarjetas serialix, los conmutadores manuales de puerto paralelo, un disco duro de cuarenta megas y una bolsa de conectores BNC. Maldigo no haberme puesto guantes de amianto. Cojo la caja que hay al fondo, blanca y en cuyo frontal reza “Visual Basic 6.0″. Saco el disco y lo meto en la unidad. Lo instalo en una máquina virtual con XP y abro por fin el proyecto. Reconozco de inmediato los formularios de la aplicación y paso a ver lo que hay detrás. MKII no tiene experiencia con esta atrocidad y no lo lee con la misma fluidez que yo. -Los controles no tienen nombre. Bueno, tienen el nombre por defecto-le explico.- Bien. Cojonudo. El código no está indentado. Mejor todavía. -Para que luego digan que las llaves de C son un coñazo. -Son una bendición divina. No me jodas.

No pasa mucho rato hasta que veo el problema de lentitud de todos los clientes. El problema residen en la comunicación con la base de datos. -Mira, MKII, ya he encontrado el porqué de la lentitud. -¿Sí? ¿Dónde? -Mira, ¿ves esta matriz bidimensional? -La veo. -Pues ahí se monta la consulta SQL. -¿Y por qué en una matriz? -Por joder, porque no es para plantillar. -Vale, ¿entonces a un lado el campo y al otro el valor y luego se concatena la sentencia? –

Que no, que no. A un lado se pone “select *” y al otro “from tabla” y ya. -¿Cómo que “y ya”? -Y ya. No hay where. No se selecciona de más de una tabla. -¿Entonces cómo se filtran los resultados de la consulta? Sonrío como un maníaco. -Muy fácil: iteramos todos los valores de la consulta y nos quedamos con el que nos coincida. ¡Es genial! -¿Cómo? ¿Cómo? -¡Es genial! Y si necesito una subconsulta… ¡repito el proceso! Una risa nerviosa se apoderó de nosotros y nos tuvo fuera de combate durante una hora. ¡Bimbambidubi! ¡Dubi! -¡Jiajiajiajiajia! ¡Sistemas, Joker al habla! ¡Jajajajaja! -Cada día estáis peor ahí. Oye, que no tenemos internet y necesito entrar en los bancos. -¡Jajajajaja! ¡Jiaaaajajajaja! ¡Bancos! ¡Bancos! ¡No sé ni quién eres tú! ¡Jiajajajia! ¡Pero da igual! ¡Iré puesto por puesto comprobando si tienes internet! -¿De qué hablas? -¡Es súper rápido! ¡Jiajiajiaaaaaa! -¿Me lo arreglas o no? -¡No! ¡Jiaaaaajajajajaaaaa! Cuando por fin conseguimos rehacernos, desconectamos los teléfonos y pasamos varios días modificando chapuzas similares en ambas partes del programa.

Después de mucho tocar, de mucho corregir error de compilación tras error de compilación, conseguimos meter unos cuantos tumores que suplieran otros cuantos tumores más dañinos y la aplicación volvió a correr decentemente. Como Gargamel no informaba de nuestros progresos a $Hyperboss, decidí mandarle un correo electrónico. Asunto: La aplicación ya va bien. Cuerpo del texto: Pues eso. A los pocos minutos me llama al despacho. -He llamado a unos cuantos usuarios para comprobar que va bien y me han dicho que ya va como al principio. ¿Qué coño le pasaba al programa? -Técnicamente a este problema se le conoce como “Rendimiento diferencial demo-producción” o “Mal del becario”. -¿Y eso qué es? –

Pues que si un programa hace lo que tiene que hacer no necesariamente está bien hecho. -Explícate. -El programa fue bien cuando tenía pocos datos que manejar. Conforme la base de datos creció, resultó no estar bien preparado para manejar tantos datos. -¿Y cómo lo habéis solucionado? -Limitando los registros devueltos por la base de datos. ¿Pero por qué le interesan los detalles técnicos? Normalmente ésto le importa una mierda. -Para decírselo al ingeniero de Bullshitsoft. -Ah, yo les mando un informe. -¿No te importa? -En absoluto. -Vale, gracias, Wardog. -De nada. Oiga, una curiosidad. ¿Cómo consiguió el código fuente tan rápido? -¿Conoces a Astaroth? -¿El abogado? -Él se lo trajo en un pendrive en dos horas. -Joder. Yo seré BOFH, pero éste no veas lo cabrón que llega a ser en el mundo real. Astaroth es a los abogados lo que un volcán a un mechero de gas. Es capaz de acojonar a Satanás.

Volví a mi despacho y redacté un email Para: jefazos@bullshitsoft.es, CC: higiniero@bullshitsoft.esAsunto: Aplicación arreglada. Informe de reparación. Cuerpo: Ya funciona rápido. El problema era que tenéis a los becarios bajos de azúcar. Mantas. Enviar.

Update post el 18 de agosto
——————————————————-

Gracias a mis amigos Jose Félix y Jose, me han indicado que el texto tiene su origen Wardog y su mundo:http://mundowdg.com/blog/page/3/

Así al César lo que es del César. Wardog, no era mi interés aprovecharme, y de paso indicarte que verdaderamente es un texto que hay que leer y de “digestion lenta” como dice mi amigo Manuel Férez.

Un abrazo a todos

Obtener datos e informes de storage en tiempo real de nuestra infraestructura de vSphere II

La semana pasada vimos como sacar datos de caracterización y rendimiento de nuestros discos virtuales mediante la herramienta vscsiStats nativa de ESXi. Hasta donde conté en ese post, podíamos ver los datos directamente en el terminal pero además, podemos exportarlos y tratarlos para generar informes de uso que pueden resultar muy útiles.

graficos-stats

Para ello, primero de todo tenemos que modificar los comandos con opción –p para que exportar los histogramas a csv y luego poder tratarlos. El comando para exportar todos los histogramas a csv sería:

# vscsiStats -p all –w <worldID> -c > /root/vscsiStats-export.csv

Una vez generado en el directorio que le indiquemos como parámetro, lo podemos importar mediante scp por ejemplo. Una vez descargado en nuestro equipo es cuando podemos empezar a tratarlo. De por sí tendremos los datos en “crudo”, pero hay maneras de poder graficar los resultados para analizarlos de manera más visual.

Lo que necesitaremos es Excel y una macro que podemos obtener aquí desarrollada por Paul Dunn y Matt Kelliher. Así los obtendremos:

  • Abrir el fichero csv que hemos obtenido desde el ESX en excel
  • Apretar alt+f11 y añadir el código de la macro
  • Para ejecutar el código, bastará con apretar f5

Con ello, obtendremos los gráficos de los datos que hemos recabado desde vscsiStats.

Otra gran herramienta más sencilla y directa es ésta desarrollada por virten.net. Subimos el fichero .csv  e inmediatamente obtendremos los gráficos.

Monitorización en tiempo real, Elasticsearch, Logstash y Kibana

Si analizamos la infraestructura que gestionamos veremos que tenemos multitud de datos en forma de logs o de emails de sistema. Normalmente cada uno de estos logs con su propia aplicación de acceso y o  formato y sin ninguna relación con el resto de sistemas. A menudo, solo utilizamos esta información para evaluar lo sucedido después de una incidencia. Pero la verdad, es que si pudiéramos disponer de todos estos datos dispersos centralizados y normalizados en un formato común, dispondríamos de una fuente de información muy valiosa para gestionar nuestra infraestructura.

Existen diferentes herramientas que permiten centralizar todos estos datos y normalizar su formato. Estas herramientas facilitan el acceso a estos datos y permiten la generación de métricas de gestión y también la generación de alertas. Una de estas herramientas es ELK (Elasticsearch, Logstash y Kibana). Esta herramienta nació de la unión de los proyectos open source Elasticsearch, Logstash y Kibana que gestiona la empresa elastic…

  • Elastisearch es un sistema distribuido de almacenamiento de documentos JSON con un sistema de búsqueda de datos basado en Apache Lucene.
  • Logstash es un sistema para la centralización de logs que permite procesar estos logs y almacenarlos en Elasticsearch entre otros sistemas de almacenamiento.
  • Kibana es un a interface web para acceder a los datos almacenados en Elasticsearch de forma rápida y ordenada.

Lo que inicialmente era una herramienta de gestión de logs centralizada a evolucionado hacia un sistema capaz de captar datos de cualquier fuente, en cualquier formato y analizarlos, establecer correlaciones y mostrarlos en tiempo real. Actualmente, el núcleo de la herramienta esta formado por Elasticsearch, Logstash, Kibana y Beats, todos open source. Este último, Beats, es una plataforma para la recolección y envío de datos a Elasticsearch, datos que podrán ser visualizados en Kibana de forma ordenada. De base existen cuatro tipos de Beats, Filebeats, Packebeats, Topbeats o Metricbeats y Winlogbeats.

  • Filebeats permite recoger ficheros de log, preprocesarlos y enviarlos a Elasticsearch.
  • Packetbeat permite recoger el tráfico de red de cualquier protocolo como por ejemplo http o mysql y enviarlo a Elastisearch para ser analizado.
  • Topbeats (Metricbeats en las siguientes versiones) recoge información de sistema como uso de ram, cpu, espacio de disco, etc. a intervalos definidos (10 segundos por ejemplo) y enviarlos a Elasticsearch para ser analizados.
  • Winlogbeats permite recoger información de sistema, de aplicación y de seguridad del registro de eventos de Windows y enviarlo a Elasticsearch.

La plataforma Beats, no se limita a Filebeat, Packetbeat, Topbeat y Winlogbeat, sino que dispone de una librería open source llamada Libbeat que permite definir nuestros propios Beats de recogida de datos para enviarlos a Elasticsearch.

elastic search

Top Dashboard: Fuente www.elastic.co

Este tipo de herramientas como ELK, permiten definir una nueva aproximación a la monitorización de  infraestructuras y aplicaciones, basada en la generación de gráficas en tiempo real, el disparo de alertas cuando se produce un evento y la correlación de datos de diferentes fuentes. A título de ejemplo, con Elasticsearch podemos disponer de estadísticas en tiempo real  de uso de los recursos (cpu, ram, disco, …) de lo servidores físicos, virtuales o en cloud, estadísticas de errores HTTP y de rendimiento del servidor web, estadísticas de rendimiento del servidor de base de datos, estadísticas de usuarios conectados, etc. Y todo esto con la posibilidad de correlar diferentes fuentes de información.