Other posts related to it

Ganado en lugar de mascotas

25/4/2013 5:36 am

Influenciado por la lectura del libro del proyecto Phoenix, que os recomiendo a todos, creo que voy a escribir este articulillo en versión novelada sobre el tema de tratar servidores como ganado en lugar de como mascotas (cattle no pets), a ver qué tal se da.

5532770373_3811034fd7

“Son las 3 de la mañana y el maldito “busca” vuelve a sonar. Puff, ¡menuda semanita llevo!, pienso mientras a tientas busco el maldito cacharro en la mesita de noche para poner fin a sus convulsiones y chillidos. “Webserver15.httpfarm load average ALERT”. Por un instante pienso en volverme a dormir. Un solo nodo cargado y ninguna otra alerta, como por ejemplo retardos en la carga de la página no debería ser un problema, pero… algo en mi interior me lo impide y ¿si es importante?. A mi lado mi mujer murmura algo acerca del maldito zumbido mientras me voy incorporando para llegar a la mesa del despacho donde presiono el botón de inicio del portatil, que tampoco parece feliz de ser despertado en medio de la noche.

Al parecer, un par de procesos se han quedado bloqueados esperando a un recurso compartido que estaba tardando demasiado en responder y eso ha elevado la carga en ese nodo, mientras en todos los demás todo sigue bien. Mando al nodo sospechoso al banquillo modificando la configuración del balanceador para ser examinado mañana más a fondo, y decido terminar la noche durmiendo en el sofá para no molestar en caso de que la rebelión continue. Solucionar el problema me llevó 15 minutos pero ya no puedo dormir en las siguientes horas así que dejo entrar a Oscar, nuestro gato, para que me haga compañía. Mientras acaricio su panza pienso que algunos de nuestros servidores requieren más cuidados que una mascota.

A la mañana siguiente, despues de la reunión de arranque del equipo, me dedico a investigar que le pasó al nodo molesto. Al parecer, una de las modificaciones que hicimos hace varios meses a la granja de servidores web había sido aplicada, pero el recurso no había sido remontado, con lo cuál no había tenido efecto.

¡Maldita sea!, otro copo de nieve (aka snowflake), parece que nuestro proceso de homogeneización no está tan refinado como creíamos. Reinstalar el servidor es un proceso completamente automatizado que tan sólo lleva unos minutos. Una vez que ha vuelto a la vida verifico que el nuevo nodo es exactamente igual que sus compañeros del corral, para a continuación abrir el grifo en el balanceador para que comience a llegarle tráfico de nuevo. Todo funciona a la perfección.

En la mayoría de los casos y con el nivel de redundancia que tenemos es obvio que es un error tratar a cada servidor como una mascota. Debemos de empezar a pensar en ellos más como ganado, y especialmente en diseñar nuestros sistemas para que en caso de error, el procedimiento sea sustituir al enfermo por uno exactamente igual y ya en caso de requerir una intervención especial entonces alertar a uno de los doctores. Una de las ventajas es que todas las gráficas de rendimiento y los logs de los servidores se mantienen en servicios separados, con lo que no estaremos borrando pistas para el analisis post-mortem. Incluso podríamos ponerlo simplemente en cuarentena.

Paso el resto del día poniendo en práctica esta idea de “ganado en lugar de mascotas” en nuestra granja de servidores web reconfigurando el sistema de monitorización para, en caso de detectar un nodo enfermo jugar el combo de cartas: “tiro en la cabeza” y “resurreción de entre los muertos”. En aquellos casos en los que la alerta se repita en breve en el mismo nodo, alertaremos al vaquero de turno. Ahora, para asegurar que el sistema funciona y que lo seguirá haciendo, es hora de soltar al “mono del caos” que introducirá errores en los servidores cada cierto tiempo de forma que el procedimiento se esté verificando constamente.

Los resultados en la granja web han sido muy satisfactorios y hemos decidido empezar a extender el proceso a todos los servidores. De hecho, este evento nos ha hecho replantearnos cómo vamos a hacer el proceso de alerta fuera del horario de oficina, sustituyendo cientos de alertas individuales (cpu alta, sistemas de ficheros lleno, etc) por otras que eliminen la individualidad del asunto (el portal está caido, la búsqueda media es demasiado lenta, etc).

Espero que mi gato Oscar no esté preocupado porque lo sustituya por un corralito lleno de cerdos.”

Cultura devops en REA

5/8/2012 11:41 am

Como muchos sabéis ya, hace algo más de 4 meses que inicié mi aventura en tierras Australianas y comencé a trabajar para REA, grupo que se dedica a la gestión de publicidad online para el mercado inmobiliario, principalmente en Australia, pero con presencia internacional en Italia, Luxemburgo, HongKong, etc…

Deajando aparte el factor aventura, y las ganas de conocer esta parte del mundo, cuando me ofrecieron este trabajo se unieron la oportunidad de trabajar en una compañía que maneja algunos de los portales con más tráfico de Australia con mi interás por dedicarme a las operaciones web a gran escala. Uno de los elementos que más me atrajo fue la cultura de la compañía, que por lo que pude adivinar en las entrevistas, y he verificado postriormente, destaca por una implantación muy alta de metodologías ágiles, equipos de alto rendimiento y gran nivel técnico, mentalidad hacker, mimo por los empleados y una cultura devops muy evolucionada.

Un ejemplo del arraigo de la cultura devops en la empresa es que los dos grupos que celebran reuiones en la zona sobre el tema: “Melbourne devops” e “Infrastructure coders” están siempre sobre poblados de gente de REA, ya sea en el público, como colaboradores o como organizadores. Fuera de Australia, cuando uno de mis compañeros recientemente asistió a Velocity y Devopsdays en Estados Unidos recibió comentarios de admiración sobre el grado de implantación de la cultura devops en la compañía.

Pero después de tanto rollo, ¿cómo es la cultura devops en REA? Podría decirse que en una compañía como esta, en la que los conceptos de agilismo y lean están tan marcados en todos sus estratos, la búsqueda de la eficacia y las mejores prácticas es una evolución constante. Si aplicamos estos elementos al concepto de cómo operamos nuestros servicios nos damos cuenta de que se trata de un viaje que implica un cambio constante. Podemos marcar el comienzo de este viaje hace ya algún tiempo, cuando las operaciones eran ejecutadas de forma centralizada por el equipo de Operaciones Web (dentro del área de IT). Los ya consabidos problemas consecuencia de la separación de Operaciones y Desarrollo, sumados a la desalineación de ambos con los intereses del área de negocio, llevaban a un funcionamiento ineficiente. Operaciones estaba descontento porque no podía solucionar los problemas endémicos, ya que no estaba presente en el proceso de creación y/o mejora de los productos. El equipo de Desarrollo por su parte veía en Operaciones un elemento bloqueante, que no le permitía alcanzar la velocidad demandada por el entorno del negocio, en aras de mantener la estabilidad del entorno. Y todo acaba con las consabidas peleas de perros y gatos, tan ilustradas en cualquier presentación sobre devops.

Los primeros refinamientos del proceso se basaron en empezar a “infiltrar” miembros del equipo de Operaciones en los distintos equipos de Desarrollo, para intentar mejorar la comunicación, y para conseguir que el elemento de operaciones estuviera presente en el día a día del desarrollo y mejora de los servicios. Al parecer el comienzo no fue muy fácil ni agradable y en algunos casos los equipos rechazaban al nuevo miembro, como cuando un cuerpo rechaza un transplante, y también había choques culturales, siendo los “infiltrados” los que no se sentían cómodos en este nuevo ambiente. Su trabajo consistía casi únicamente en realizar pasos a producción de forma manual una y otra vez. Por aquel entonces, había un segundo equipo denominado SPA (Site performance and availability) que se encarga del soporte global de las operaciones, es decir del cuidado de las infraestructuras y gestión de incidencias relacionadas con producción.

Transcurrido algún tiempo comenzaron a hacerse evidentes las ventajas del modelo, gracias al éxito de los equipos que lo habían implementado. Esto dió paso a prácticas que mejoraron el proceso de despliegue y gestión de los servicios mediante la automatización de los mismos y al comienzo de la adopción de un modelo PaaS (Plataforma cómo servicio) cuyo objetivo era la estandarización de los entornos y la simplificación en las operación de los mismos.

Los siguientes pasos en este proceso son la incorporación de la obre la gestión de las operaciones en estos equipos que ahora serán responsables del servicio de forma global incluyendo la creación, mejora y operación del mismo. Este proceso incluye la gestión y resolución de incidencias, ahora los miembros de SPA se han enbebido completamente en los equipos, y el siguiente paso es conseguir que la responsabilidad de solucionar los problemas recaiga en todo el equipo: desarrolladores, calidad, operaciones e incluso los productores y responsables de negocio que poco a poco se han ido incorporando al equipo en su día a día, formando algo parecido a mini startups dentro de la empresa. Por lo que ahora todo el equipo se sienta en la misma zona de la oficina, atiende a las reuniones diarias (standups) y participa en el trabajo cómo uno más. Se acabó esto no lo podemos resolver esto porque X o G no colaboran. Los problemas se priorizan dentro del equipo y se decide que demandas se deben atajar primero y el diseño de nuevas funcionalidades siempre cuenta con la idea de cómo vamos a operar el servicio cuando este esté en producción.

Respecto a la tecnología usada dentro de los equpos relacionada con devops podríamos describirlo cómo que cada equipo tiene libertad para utilizar los elementos que le sean más productivos para conseguir sus objetivos, es la ventaja de tener el control y la responsabilidad de extremo a extremo de los elementos, y en muchos casos esta apoyada en la estandarización que provee el uso de una plataforma común, de la que ya hablaré en un articulo posterior. Por tanto nos encontramos elementos muy distintos cómo puppet o chef para la gestión de configuración, el uso de rpms para la distribución de nuestras aplicaciones, nagios, newrelic, gomez y graphite para monitorización y métricas entre otros muchos.

La implantación de la cultura devops en una compañía no puede medirse cómo blanco o negro, más bien se trata de un gris que va cambiando de tono ya que está en constante evolución persiguiendo el fin último de mejorar la forma en que ofrecemos nuestros servicios y aumentamos el valor para nuestros clientes, así que os mantendré informador de futuras mejoras y la implantación de los planes actuales.

Aplicando Scrum en el departamento de IT

9/10/2011 8:24 pm

Esta entrada la tengo pendiente desde hace bastante tiempo y resume un poco las experiencias que hemos tenido en el uso de Scrum y metodologías ágiles dentro del departamento de IT. Cómo hay muchísimo ya escrito sobre cómo aplicar Scrum y sus efectos beneficiosos voy a enfocarme en una lista de comentarios sobre cómo he visto nuestra aplicación de la metodología.

– Cómo nuestro trabajo tiene un componente alto de resolución de incidencias y solicitudes que deben ser atendidas en un periodo muy corto de tiempo no pudiendo esperar a ser incluidas en el siguiente sprint al finalizar las dos semanas de este optamos por dedicar un porcentaje de nuestro esfuerzo diario al sprint en curso y el resto del porcentaje a las tareas del día a día, resultando ser bastante efectivo y sólo en algunos casos comiendose el tiempo de uno el otro.

– Inicialmente para que el salto de concepto no fuera demasiado grande no empezamos usando historias de usuario sino algo más parecido a una división por tareas y las valoraciones de dificultad estaban más enfocadas sobre el tiempo que le llevaría a cualquiera de nosotros llevar a cabo la misma que en la dificultad intrinseca de la misma. – Para evitar eternas discusiones de si eso era la forma “verdadera” de hacer Scrum les decíamos que nosotros hacíamos Scrutch no Scrum.

– La reunión de planificación del Sprint resulta mucho más útil que el modelo tradicional en la que alguien se encarga del diseño y el calculo de esfuerzos y luego todo el equipo debe responder por ello. Así todo el equipo recibe una visión temprana del volumen de trabajo y las dificultades y crea también una especie de compromiso con lo pronosticado, mucho mayor que si alguien te impone una cifra. Además el Planning Poker es divertido y también saca un poco la personalidad de cada uno a la hora de estimar tareas, ejercicio muy recomendable junto con las reuniones de retrospectiva.

– La pizarra con los postit y el burndown chart son una medida muy útil para que todo el mundo pueda ver de un vistazo dónde estamos y lo que queda por hacer para llegar al final del sprint a tiempo, además resultó un atractivo para el resto de equipos que no veían muy claro que hacíamos con los postit.

– Otro punto muy positivo fue el de la defnición de terminado para una tarea. Para nosotros en este caso no sólo siginificaba que estuviera hecho sino que estuviera provado, documentado y su correspondiente ticket actualizado, sin los cuales la tarea no se podía parasar a finalizada y así comenzar otra, con lo que todo el mundo tenía muy claro lo que había que hacer.

– Uno de nuestros fallos fue no conseguir una mayor implicación por parte de los distintos product owners, en muchos casos actuando la misma persona, vamos yo, actuaba cómo product owner, scrum master y miembro del equipo, lo que quitaba un poco el factor integrador que nos da el uso de Scrum. Otro fallo en algunos proyectos que implicaban otras areas fue no incluirlos en nuestro Sprint y simplemente esperar que para cuando nosotros estuvieramos en el punto de necesitar sus productos estos estarían listos.

– El product backlog es una herramienta que sigo utilizando para todo tipo de actividades para que nada quede en el olvido, se clasifique y se prepare su entrada a la ejecución.

– La valoración de la satisfacción creo que fue bastante grande y sobretodo una gran mejora frente a no utilizar ninguna metodología, quizá poco a poco se podría ir incorporando más conceptos puros de Scrum y mantener aquellas modificaciones que nos han sido de utilidad.

– Actualmente sólo lo usamos en momentos puntuales cuando aparece un trabajo que nos va a costar más de dos semanas y que debe ser llevado por varios miembros del equipo

– Constantemente pienso que Kanban podría ser una alternativa más global que nos permitiría también meter la gestión de incidencias y tengo pendiente que hagamos algún piloto para ver que tal nos funciona.

Trabajar desde casa

15/8/2011 9:27 am

Hoy me ha vuelto a suceder. La luz entra a raudales por la ventana y eso que son las 7 de la mañana, ya desde las 5 había amanecido en esa isla del todo al revés, y voy hasta el baño a lavarme la cara y vestirme. Este gesto mundano y diario conlleva una ferrea disciplina y un lema “no trabajaras en pijama“, cosa que puede parecer una tontería pero ayuda a situarte en la realidad por mucho que cada vez que intento convencerme mis contactos en redes sociales clamen por defender que es lo mejor del mundo.

Bajo las escaleras hasta la planta de abajo mientras todo está en silencio y arriba siguen durmiendo. El ritual de abrir la “oficina” se ha convertido en abrir las cortinas que dan a la calle, encender el interné que ahora me ha dado por apagar por la noche y el portátil.

Debí haber captado el primer sintoma, que para ser Lunes había muy pocos correos en mi bandeja de entrada pero decido tomarlo por algo normal ya que lo revisé anoche antes de irme a dormir, deformación profesional. Comienzo a revisar la lista de tareas para esta semana y a organizarme. A continuación enciendo mis dos inseparables compañeros de trabajo desde que estoy en la isla: el chat y el skype. Otra nueva pista ignorada, apenas si hay gente del curro en el chat, pero aún así mi mente dice que debe ser por vacaciones o que aún no han llegado a la oficina. La idea de ir hasta la oficina me hace recordar los días de Agosto por la calle ferrocarril de Getafe, ida y vuelta a la oficina bajo un sol de justicia y ni una sombra dónde esconderse. Calor, que envidia, semanas leyendo en facebook a la gente quejarse del calor y yo creo que este año no “pisaré” una piscina. Aunque, hoy parece que el sol también se ha aparecido por aquí y puedo estar en manga corta, ¡milagro!. Este tema, a diario, genera comentarios de mis compañeros cuando me conecto por videoconferencia con ellos, ¿pero que haces con un jersey puesto en pleno Agosto? Ea, hijos mios, aquí esto es así. Para chincharles tengo puesto un cartel que pone Home justo detrás mio perfectamente visible por la cámara web, muahahaha.

Mi mirada a través de la ventana abandona al cielo claro de hoy y termina posada en la lavanda de la entrada de la casa. Decenas de abejas y abejorros también han empezado ya la jornada, incansables, inagotables, bien cansinos, siempre están ahí de flor en flor. No os creais que es un trabajo carente de riesgos, ya que por la zona acecha una araña bien “gordaca” que está haciendo el Agosto a costa de los abejorros cazandolos en su tela mientras se encuentra in itinere de una lavanda a otra. No sé si el seguro de Abajorros S.A. cubre este tipo de accidentes pero por lo observado son cada vez más comunes.

De nuevo de regreso a las 20 pulgadas que se han convertido en mi otra ventana, esta vez digital, por la que me relaciono con mis compañeros de curro. Pena que por aquí no se puede compartir el café con porras de las mañanas y los chascarrillos, de byte en byte, parecen un tanto descafeinados. El primer mes intenté pasarme a la costumbre inglesa del té, pero después de probar unos cuantos tipos de té me he dado cuenta que no hay quien le gane al cafecito de por la mañana para despertar. Mmmm, café, creo que debería meterme algo en el cuerpo para intentar arrancar. Pero primero voy a mirar si tengo alguna cita hoy en el calendario corporativo… Noooooooooooo, otra vez, ¿cómo ha podido volverme a suceder? El calendario dice: Asunción de la virgen ¿por qué nadie me ha avisado que hoy es fiesta? Cachis en la mar, mira que ando perdido en eso de las fiestas últimamente, quizá efectos de seguir haciendo el calendario de Getafe a pesar de estar en otro país.

Me encuentro fuertemente tentado de volverme a la cama, pero decido ponerme al día con los comentarios del Barca-Madrid de ayer y luego voy y me pongo a escribir todo esto. No prometo no irme a la cama después, que conste.

Va a ser verdad lo que dice mi mujer que desde que curro desde casa curro más. Lo de la separación es bien difícil, si vengo a ver algo de mis cosas al ordenador termino abriendo el correo del trabajo y encontrandome con algo urgente que demanda mi atención. Además desde que comenzamos las operaciones en Panama y ya tenemos un compañero de IT allí me toca muchas veces adaptarme a su horario, justo el opuesto al nuestro al menos durante la jornada de Verano, para poder coordinarnos.

En fin, el Viernes ya estuve por primera vez en la oficina que hemos alquilado en West Cambridge, justo al ladito del Willian Gates Building para que los tenga bien vigilados. Está completamente vacía y en una semana comenzarán los trabajos de reforma lo que quiere decir que en no mucho más de un mes podría estar trabajando allí. Estoy seguro que voy a echar de menos el caer rodando por las escaleras y en 5 minutos estar ya en el puesto de trabajo, más cuando empiece el frio (Winter is coming) pero durante el rato que estuve trabajando en la cafetería que hay frente a la oficina me dí cuenta que extraño el ambiente y el bullicio de la gente trabajando al rededor. ¡Qué demonios! Y a todos los pesados de mis compis que por mucha lata que dieran me daban mucha vidilla y que os hecho mucho de menos. Snif, snif. Seguiremos reportando.

En el openstack EMEA day

16/7/2011 1:35 pm

Son las 6:30 de la mañana y el despertador ya está sonando, por la ventana hace ya tiempo que empezó a entrar la luz del sol y el OpenStack EMEA day me está esperando en Londres. Antes aún me quedaba pedalear hasta la estación de tren de Cambrdige, dejar mi bici apelotonada junto a la de otros cientos de commuters que para su desgracia hacen esto a diario, tomar el tren hasta King Cross y luego el metro hasta London Bridge. Luego descubrí que mi trayecto que parecía cansado no era nada en comparación con otra gente que vino de España en avión o incluso en tren de París, pero a mí me había confirmado la idea que ya me iba haciendo que Londres no está tan cerca de Cambridge cómo lo estaba Madrid de Getafe 😀 .

La ubicación del evento, aka la “venue” para los angloparlanchines, era bastante chula y la sala estaba abarrotada cuando llegué, tarde a pesar de mi madrugón. Me perdí la primera charla introductoria, pero no me dolió mucho porque había estado en alguna anteriormente dónde se había visto lo básico de la tecnología.

A modo de introducción y para los que no lo conozcáis openstack, se trata de un proyecto que persigue la creación de una implementación libre y altamente escalable de “la nube”, principalmente en los temas relacionados con las infraestructuras cómo servicio (IaaS). El proyecto fue iniciado por RackSpace y la NASA pero últimamente está teniendo una gran aceptación y un gran número de empresas cómo Citrix o Ubuntu están participando activamente en el proyecto. OpenStack se divide en varios subproyectos que intentan abarcar los diferentes elementos necesarios para la construcción de estas nubes cómo son la provisión de máquinas virtuales, de almacenamiento o el servicio de imágenes junto entre muchos otros una consola de gestión web. Uno de los puntos fuertes de openstack es su API, o sus APIs ya que tb tiene una versión compatible con Amazon, que nos van a permitir relacionarnos de forma altamente flexible con nuestra nube.

Después de la introducción, las siguientes charlas cubrieron temas variados como por ejemplo cómo están contribuyendo las distribuciones al desarrollo y la integración de Nova con la intervención de la gente de Citrix (Xen Server), Ubuntu y los compatriotas de StackOps a los que fue un gustazo poder saludar por tierras inglesas y que a día de hoy han desarrollado una de las distribuciones de OpenStack más interesantes sobretodo si no quieres complicarte la vida en la instalación. La verdad fue una alegría ver que Ubuntu ya ha incorporado en varias de sus últimas versiones paquetes oficiales de OpenStack y también cómo Citrix también apuesta por openstack para su implementación de nubes, y en gran parte el exito es debido a la independencia de openstack del hypervisor elegido permitiendo así elegir el que más se ajuste a tus necesidades.

También fue curioso las varias referencias que hubo a temas cómo devops o al uso que hacen internamente para el despliegue de múltiples nodos mediante puppet o chef distintas empresas que están trabajando en la implementación de openstack. En Andago llevamos ya bastante tiempo siguiendo la pista de OpenStack y está en el roadmap migrar nuestra nuble interna de computación de un desarrollo previo a medida de IaaS sobre Xen a OpenStack sobre KVM, pero esperamos poder tener el primer piloto disponible en breve.

La charla de seguridad en la nube entre otros nos recordó lo importante que es en los casos que estas ofreciendo servicios de computación a clientes externos mediante virtualización la relación que existe entre el servidor anfritión físico y las máquinas virtuales. Hay bastantes iniciativas en este aspecto tanto desde fabricantes de hardware cómo intel a otras basadas en software cómo el uso de SE-Linux para conseguir una independencia total del host anfitrión y sus ahijadas virtuales. Por cierto, mencionaron un tipo de ataque que no conocía llamadobluepill.

Otro de los aspectos importantes que se comentaron durante la sesión fue cómo poder particpar en la comunidad de openstack y cómo se está organizando el desarrollo que muestran una comunidad robusta y sana y con una de las mayores proyecciones dentro del espectro del software libre. Por ahora y hasta no consiga elevar algo más mi nivel de programación en python mi granito de arena en el proyecto ha sido la traducción de gran parte de las cadenas de texto de Nova del inglés al español, aunque aún quedan unas cuantas nuevas que van aparecinedo cada día y os animo a contribuir.

Aplicando devops en una empresa TIC

10/7/2011 9:52 am

No me había percatado que no había puesto en el blog las transparencias de la charla “Aplicando devops en una empresa TIC” que dí en Madriddevops en las oficinas de Tuenti en Mayo. Aquí os las dejo:

Presentar en madriddevops era una espinita que tenía clavada ya que es uno de los grupos que más he disfrutado los últimos meses que estuve por Madrid. Las charlas suelen tener un gran nivel en los asistentes con preguntas y comentarios de un altisimo nivel, que incluso se ve incrementado en la tertulia posterior frente a las cañas, dicho sea de paso otro gran acierto del evento.

En la charla conté un poco cómo intentamos aplicar técncias de devops en Andago y entre otras cosas las dificultades para conseguirlo, lo que nos ha aportado y cómo algunas han sido exitosas y otras no tanto, pero que en general son una serie de prácticas revolucionarias en la forma de llevar a cabo nuestro trabajo y que lo han mejorado en gran medida.

Ahora estoy deseando que se celebre la próxima edición de Londondevops, uno de los grupos más activos en este sentido, y ver que se cuece por esta isla, a ver si con eso me quito la morriña de los grandes momentos pasados en madriddevops. Si estáis por Madrid os aconsejo no perder la oportunidad de participar en la próxima charla.

Mis inicios en la informática

13/5/2011 5:30 pm

Como contaba en el post anterior y aprovechando todo lo que preparé para la última charla voy a intentar hacer una serie de posts sobre mis experiencias en la administración de sistemas y la gestión de IT. Como en la charla, la idea es mostrar un poco la evolución y transformaciones que tanto a nivel personal, como en el arte de la administración han tenido lugar en los últimos 15 años.

Así que allá vamos con los Inicios.

Muchas veces digo que nuestra generación es la de los 8 bits, tanto por los ordenadores como por las consolas con las que empezamos nuestras primeras andanzas, en mi caso con un MSX que aún conservo. Quizá de ahí venga el amor a la línea de comando, a hacer programillas para automatizar las tareas más básicas o a interntar optimizar el rendimento de cualquier cosa que nos encontramos. Además con gran probabilidad estos inicios son los que luego hicieron que tiráramos más por los rumbos de UNIX que por las flamantes ventanitas del señor puertas.

Luego ya pasamos a la arquitectura x86, vinieron muchos ordenadores después, muchas horas trasteando con el DOS y probando programas y sacándole el jugo de una forma increible a cada cosa que podía hacer el ordenador. Así que cuando llegó la hora de elegir una carrera lo tenía bastante claro, la informática era lo mío.

Los primeros años de la Universidad los recuerdo con mucho cariño. Recuerdo lo duro que fue pasar los primeros cursos y la dura prueba que suponían las asignaturas como Calculo, Álgebra y Física que eran requisito básico para poder ganarnos el no sé si adecuado título de ingenieros. Aún me cae una gota de sudor cuando recuerdo un ejercicio llamado “Diagonalización de un endomorfismo” y todo un verano “encerrado” en la biblioteca (este otro post explica más bien en qué consistía eso) tratando de dominarlo para que luego años más tarde no sea capaz ni de recordar de qué iba la película.

Una vez superado el primer curso empezaban a aparecer algunas asignaturas más interesantes mezcladas con algunas otras que eran realmente decepcionantes y que no aportaban nada al camino que poco a poco había elegido para mi carrera: la administración de sistemas. Así que una vez superada la ingeniería técnica tenía que decidir por donde iba a continuar mi aprendizaje y así decidí comenzar varios caminos al tiempo:

– Comenzé los dos cursos que me faltaban para la ingeniería “superior o no técnica”, pero para motivarme decidí escoger todas las asignaturas relacionadas con los temas que me interesaban como la seguridad, la administración de redes o los sistemas operativos. No sé si fue un acierto o un error, pero una vez terminadas todas estas asignaturas me encontré con un montón de temas que ya no me interesaban para nada pero que por orgullo fuí sacando poco a poco hasta que decidí abandonar la carrera a falta de 4 asignaturas y el proyecto de fin de carrera. No había nada más que quisiera aprender allí y el título me parecía cada vez algo más algo totalmente innecesario.

– Comencé a trabajar en un pequeño ISP de mi ciudad, pero esto lo dejo para el siguiente post, en el que narraré las experiencias de mi primer trabajo.

– Una vez descartada la Universidad decidí dedicar mis horas de aprendizaje a enfocarme en las áreas que más me interesaban. Realicé el curso CNAP de CISCO por las tardes/noches y aunque no era tan práctico como esperaba amplié bastante mis conocimientos de redes. Finalmente decidí no certificarme porque costaba un pico y porque creí que los conocimientos que había adquirido los tenía suficientemente afianzados como para poderlos demostrar por otros medios. También realicé un curso de Solaris en la Complutense de Madrid, cuando todavía Solaris era el rey de los sistemas operativos de servidor y lo que demandaban las grandes empresas. Mucho más adelante y gracias a mi empleador pude realizar un par de certificaciones en Linux: LPIC-1 y RHCE. De estas me quedo con RHCE que como he comentado en otras ocasiones es el examen que más me ha encantado de los que he hecho en mi vida.

Trastear, trastear y trastear. Siempre me ha encantado trastear en casa o con los amigos y creo que he aprendido muchísimas cosas de esas horas. Uno de los grandes éxitos de Linux, por poner un ejemplo, es que tienes a tu disposición en casa de la misma tecnología que tienen las empresas para ofrecer sus servicios, lo que es una ventaja enorme para el aprendizaje. Aún recuerdo como en mi piso de estudiante fuimos incorporando a nuestro servidor casero los distintos tipos de redes según estas iban evolucionando y se hacían asequibles a nuestro bolsillo. Primero teníamos toda la casa cableada con coaxial para luego pasarnos a RJ45 progresivamente en los cuartos y montar un puente entre ambas redes para los que aún no habían hecho la actualización y con el tiempo incorporar la tecnología inalambrica a nuestro super puente cuyo objetivo principal era poder echar unas buenas partidas al Counter Strike. En ese servidor teníamos nuestro correo, nuestras webs, nuestro ftp para intercambiar ficheros con la peña o nuestro servidor de Amule que echaba llamas, todo sobre un viejo 486 que ibamos renovando con las piezas que sobraban de nuestros PCs. ¿Se os ocurre un laboratorio mejor?

– Un día sentados en el curro delante del Barrapunto del día y viendo noticias de la útlima Hispalinux me giré hacia mi compañero de sistemas “el Chache” y le dije: “tio, ¿por qué en Albacete no tenemos nada de esto?”, tras hacer la pregunta a varios amigos y compañeros de la Universidad a los que nos encantaba Linux nos lanzamos a iniciar la asociación juvenil Linux Albacete. Es increíble la cantidad de cosas que he aprendido en las horas que le dedicamos a la asociación y así espero que lo sienta todo el que se acercaba a la misma, pues además de promover el uso de tecnologías libres el objetivo era el de compartir conocimiento entre todos nosotros, ¿puede haber algo más bonito?

Bueno, y podemos decir que después de todo este rollo introductorio, queda bastante claro porque decidí dedicarme profesionalmente al mundo del IT con tecnologías libres. En el sigueinte post os contaré las peripecias en mi primer trabajo como administrador de sistemas.

Experiencias en la administración de sistemas con Software Libre

12/5/2011 9:39 am

Este es el título, aunque no el orginial que más bien era Experiencias del Software Libre en las empresas TIC, de la charla que dí el pasado Viernes en el curso de Arquitectura de servidores con Software Libre que está realizando LibreSoft y la Universidad Rey Juan Carlos en el centro Madrid On Rails y en el que Andago participa cómo colaborador. En un principio pensé que no podría dar la charla al estar en Reino Unido pero al final conseguimos cuadrar las fechas con los días que ibamos a estar por España arreglando papeles. El curso que ha montado la gente de LibreSoft me parece superinteresante, de hecho tuvimos suerte de pillar una plaza para uno de los compañeros del departamento de IT, y es el tipo de formación del que siempre me he quejado que no ofrezca la Universidad cómo parte de su temario habitual. Esperemos que se les reconozca el éxito y puedan repetirlo en siguientes ediciones.

El caso es que cuando me puse a pensar sobre qué podía contar sobre el tema me llegaron muchísimas ideas de golpe y no sabía muy bien cuales serían más interesantes y cuales descartar. Entre ellas había muchísimas experiencias e historietas de distinto ambito, desde cuando empezaba a utilizar mis primeras distribuciones de Linux en casa, las cosas aprendidas en la Universidad y en LinuxAlbacete, cómo montamos la infraestructura de un pequeño ISP en mi primer trabajo y luego todos los proyectos, metodologías, infraestructuras y lecciones que he ido adquiriendo durante los últimos años en mis distintos puestos dentro de Andago. Así que al final intenté incluir un poquito de cada cosa con la idea de dar muchas ideas y conceptos, sin profundizar en el cómo (HOWTO), de forma que sirvieran de puntero para que la gente del curso, en caso de que le resultaran interesantes o de utilidad, pudieran investigar un poco más.

A continuación os dejo las transparencias por si os interesa echar un vistazo:

La audiencia era gente con experiencia en la administración de sistemas así que intenté profundizar en los temas menos comunes o con los que pudieran estar menos familiarizados. Finalmente me pasé un cuarto de hora de la hora y media que tenía asignada, cosa que ya me estaba temiendo cuando terminé de preparar la charla, pero espero no haber aburrido demasiado a nadie. Yo cómo siempre disfruté cómo un enano contando cosas e intentando contestar las preguntas que me fueron hiciendo.

También había pensado en incluir un resumen de todo lo que conté en la charla en este post, pero pensándolo mejor voy a ver si saco tiempo y hago una serie de posts sobre ello porque hay demasiada chicha para un sólo día.