Aplicando Scrum en el departamento de IT

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.

Mis inicios en la informática

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.

Gestionando servidores con Puppet

Aquí os dejo las transparencias de la charla «Gestionando servidores con Puppet» que impartí en los cursos del GUL de la Universidad Carlos III de Madrid el pasado 09 de Noviembre:

Las transparencias se liberan cómo Creative Commons Reconocimiento 2.5 de España respetando la licencia de las imágenes utilizadas cómo fondo, podéis ver un listado de los autores y la licencia de sus obras al final de las transparencias.

La charla se dividió principalmente en 3 partes: describir el problema que encaramos cuando intentamos administrar el creciente número de servidores que requiere cualquier entidad que consuma servicios de IT, algunas de las posibles soluciones que podemos encontrar así cómo qué características debe tener una solución a este problema y por último cómo Puppet puede ser esta solución y una pequeña introducción a cómo funciona.

Como siempre el auditorio estuvo bastante participativo y las preguntas hicieron más amena la exposición. Como siempre la parte de la demo siempre es la más complicada, de nuevo el bendito Android y la conexión 3G me facilitaron las cosas, pero sirvió para hacer una demostración de los conceptos mostrados en la parte teórica. Muchas gracias a todos los que os acercasteis a la charla y gracias por los comentarios positivos sobre la misma que hicisteis en el blog, así da gusto prepararse cualquier tema.

Hackeando luces en Callao

Hace unas semanas cuando paseabamos por la Gran Vía de Madrid a la altura de la plaza de Callao vimos un montón de luces de colores que salían por las ventanas de una fachada y nos acercamos a ver que era. Nos encontramos con una chica con su ordenador que controlaba cómo iban apareciendo las luces, me pareció muy curioso y le tomé un vídeo. Luego en casa Lili y yo nos animamos a añadirle una banda sonora y a subirlo a YouTube, a ver qué os parece:

Nunca supimos cuál era el motivo exacto del evento de luces pero ahora en esa misma fachada tienen montada una publicidad con grandes pantallas en las ventanas de una conocida marca de ropa por lo que suponemos que o era una prueba o algún tipo de inauguración del local.iconografia

El tema de controlar las luces de un edificio de forma coordinada, cómo si fueran pixeles, a través de un ordenador es un tema recurrente en la iconografia asociada a los hackers. Hay algunos videos impresionantes en youtube en los que se puede ver cómo juegan al space invaders o al snake usando esta técnica sobre la fachada de los edificios.

Nunca había hecho nada de edición de vídeo y quería probar a hacer algo sencillito cómo esto, añadir una pista de audio a un vídeo o algún efectillo, y me recomendaron que usara Kdenlive. Tras trastear un rato con la interfaz resultó tan sencillo cómo crear un proyecto nuevo con 3 pistas: una de vídeo y audio para cargar el vídeo que teníamos grabado y una de audio adicional para la canción que queremos mezclar y silenciar la pista de audio original del video, salvando el resultado en un formato de vídeo que prefieras.

Para el audio fuimos directamente a Jamendo en busca de alguna canción chula con licencia Creative Commons y nos quedamos con Square 1 de Jemex (CC Attribution-ShareAlike 3.0 Unported) que nos pareció muy adecuada, podéis oir el album completo a continuación:

Rescatando una instancia con EBS en Amazon

Este domingo, tras una increible fiesta mexicana la noche anterior, se me ocurre echar un vistazo al mail y me encuentro con un correo de Amazon indicándome que tienen problemas con el servidor anfitrión que alberga una de mis instancias de servidores virtuales, por cierto la que conseguí de forma gratuita.

We have noticed that one or more of your instances are running on a host degraded due to hardware failure.

i-55624c22

The host needs to undergo maintenance and will be taken down at 12:00 GMT on 2010-11-22. Your instances will be terminated at this point.

The risk of your instances failing is increased at this point. We cannot determine the health of any applications running on the instances. We recommend that you launch replacement instances and start migrating to them.

Feel free to terminate the instances with the ec2-terminate-instance API when you are done with them.

Sincerely,
The Amazon EC2 Team

El correo me dice que mi instancia está funcionando en un host degradado debido a un problema de hardware y que mi instancia será terminada en una operación de mantenimiento esta misma noche… al principio ni siquiera me lo podía creer ¿dónde quedó lo de la ubicuidad de la nube y el abstraerse de los problemas físicos? Dado que la instancia dispone de un almacenamiento persistente EBS, no podrían simplemente migrarla en vivo a otro servidor y santas pascuas. ¿Tendrá algo que ver con que se trata de una micro instancia, que está paravirtualizada o a que estemos en el pool de servicio gratuito? Igual han dedicado todos los servidores a punto de romperse a esta campaña de marketing… quién sabe.

Anteriormente cuando no disponíamos de imágenes con el almacenamiento directamente sobre EBS si una instancia era terminada todos los datos de la instancia que no salvaras explicitamente en un bloque EBS especialmente montado para ese propósito eran eliminados, ahora cuando terminas una instancia con EBS simplemente el EBS se queda almacenado para que lo anexes a otra instancia o para que lo borres si ya no vas a hacer uso de él. Así que bastaría con esperar a que pararan la imagen y levantar una nueva con ese EBS, pero al ir a conectarme comprobé que la instancia ya ni si quiera estaba en funcionamiento y no podía acceder a ella por web o por ssh, así que me lanzé ¡AL RESCATE!

El primer paso era parar la instancia que estaba fallando para poder liberar el EBS, pero sorpresa… la instancia no se para por mucho que se lo pidas, supongo que debido a los temibles problemas de hardware. Tras esperar veinte minutos decidí buscar un plan alternativo. Y aquí es dónde sacamos provecho de la potencia de los snapshots, así que simplemente hacemos un snapshot, es decir una copia, de nuestro EBS y creamos un nuevo EBS a partir del snapshot con lo que tendremos una copia exacta de nuestro almacenamiento disponible.

El siguiente paso es arrancar una instancia y asignarle el nuevo EBS que hemos sacado del snapshot. Me parecía recordar que podías hacer eso en un sólo paso pero a través del API y la línea de comando pero no encontré forma de hacerlo a través de la consola web así que hubo que hacerlo en varios pasos. Arrancamos la nueva instancia con un EBS por defecto, luego la paramos, desligamos el EBS de la instancia y lo borramos para a continuación enlazar el EBS que sacamos del snapshot con la instancia en la ubicación /dev/sda1 y ya estamos listos para arrancar una instancia clonada desde la original que estaba fallando.

Por otro lado, es posible que tengas que hacer alguna adaptación interna de tu servidor ya que tu dirección ip pública y privada en Amazon habrán cambiado, en mi caso a este nivel tuve que cambiar el /etc/hosts del servidor. Si dispones de una ip elástica para ofrecer los servicios te bastará con cambiar la instancia a la que apunta esta a la nueva instancia que hemos creado y tu servicio debería volver a la vida y responder de forma correcta a los dominios que la apunten. Cómo yo no dispongo a día de hoy de ip elástica, no entraba en el pack gratuito de Amazon, estaba usando la ip pública de Amazon cómo entrada a mis servicios y alguno de ellos cómo wordpress dependen de ella me tocó arreglarlos en la base de datos:

update wp_options set option_value=»http://minuevaippublicaamazon/miwordpress» where option_name=»stieurl»;
update wp_options set option_value=»http://minuevaippublicaamazon/miwordpress» where option_name=»home»;

La verdad es que se destapan dos temas igualmente de importantes respecto al servicio de Amazon: la fiabilidad de la nube y la felxibilidad de la que nos provee. Cada uno que saque sus conclusiones y vea hacia dónde se inclina la balanza.

Sorteo en el departamento de IT

Con la escusa de que habíamos acumulado algo de merchandising de los distintos eventos en los que hemos participado, decidimos hacer un pequeño sorteo dentro del departamento de IT para ver quién se quedaba cada cosa. Cómo no, el sorteo no podía ser por los medios tradicionales, lease papelitos o piedra-papel-tijera, así que me aventuré a tirar unas líneas de python que resolvieran el problema de forma sencilla, aunque como veréis luego decidimos complicarlo un pelín más. El sorteo lo proyectamos en la tele que tenemos para la monitorización justo al lado del departamento:

La primera versión del código era realmente sencilla y muestra lo fácil que es hacer algo con python, simplemente declara un array de personas y otro de regalos, recorre los regalos y va eligiendo una persona de forma aleatoria como ganador de cada regalo y eliminando esa persona del array de personas:

sorteo-simple.py (Pincha sobre el enlace para ver o descargar el código)

Pero así quedaba un poco simplón por lo que añadí alguna opción más para hacerlo más interesante. La idea es que había gente que sólo estaba interesada en algunos regalos y tenía su orden de preferencia, así que modifiqué el código para que las tuviera en cuenta en caso de que te tocara un regalo a modo de Wish List:

sorteo-wish-list.py (Pincha sobre el enlace para ver o descargar el código)

Y por supuesto el código fue enviado a todos los participantes para que lo auditaran antes de su ejecución con el consiguiente debate de cómo se podría hacer mejor… además en el correo me colé y puse para vuestra audición y alguno quería ponerlo con el festival. Y claro, así no hay forma de hacer trampa, con lo que finalmente no me tocó ningún regalo cómo podéis ver si pincháis sobre la imagen de la tele, pero al menos me queda esta entrada del blog cómo recuerdo.

Novedades en RHEL 6

En el post anterior comentaba las primeras impresiones de la instalación de RHEL 6 y os prometía ampliar algunas de las novedades que trae esta nueva versión después de la presentación que nos realizaron en el evento de partners de Red Hat.

Cómo la descripción general podéis verla en la web de Red Hat sobre RHEL os dejo las notas que tomé porque me sorprendieron o interesaron durante la presentación:

* Mejoras en la eficencia energética: se incorporan comandos como powertop e iotop para medir el consumo de los distintos procesos así cómo tuned, un demonio que va adaptando los recursos del sistema para mejorar la eficiencia

* Con cgroups podremos establecer un límite de recursos sobre un proceso a nivel de número y porcentaje de cpu, memoria, disco y red de forma dinámica.

* Se de usar PAM a SSSD

* Respecto al temido SE-Linux se crean dos nuevos modos: SE-Linux kiosk para aplicar políticas a sesiones en modo kiosko cuando es un terminal de uso público y SE-Linux sandbox para confinar aplicaciones que no tienen todavía definida una política predefinida de SE-Linux

* En cuanto a IPSEC se pasa de usar OpenVPN a OpenSwan

* Dispondremos de System Tap para depurar aplicaciones, pero al parecer también nos va a permitir depurar aplicaciones Java

* KVM entre muchas otras mejoras permite añadir recursos físicos en caliente (CPU, disco, memoria, etc…)

* Yum permite hacer rollback de una instalación !!!

* Simplificado el reporte de errores ante fallos graves que captura el estado de la máquina y permite enviarlo a Red Hat para abrir un bug

* En la parte de Cluster podemos destacar el uso de corosync, unfencing y la interfaz conga rediseñada

También hay grandes cambios en el tema de subscripciones y se complica un poco el tema de saber cuál aplica a tu caso, además de estar fuertemente ligado a la virtualización, pero básicamente tendremos que sacarlo de cruzar los siguientes datos:

* Por cada par de sockets (zocalos utilizados) del servidor anfitrion
* Por el número de guest RHEL máximo que podemos correr en ese anfitrión (1, 4 o ilimitado)
* Por el número de extras que queramos contratar (alta disponibilidad, GFS, XFS, soporte extendido, etc…)

Un caso curioso es el de los clusters de virtualización que tengan migración en vivo, en cuyo caso todos los servidores a los que pueda ir un guest RHEL deben de tener una subscripción activa y el máximo de guests que podremos ejecutar en total en el cluster saldrá de sumar los guests permitidos en cada una de las subscripciones de los nodos anfitriones (1 o 4 o más si apilamos varias subscripciones en ese mismo anfitrión) o será ilimitado en caso de tener subscripciones de tipo ilimitado en todos los nodos del cluster, ya que estas no se pueden mezclar. Un poco lioso.

Lo que sigue estando verde es el tema de usar RHEL en nubes públicas aunque se están avanzando acuerdos con los proveedores de Cloud para que lo ofrezcan por ahora no hay subscripciones que puedas pagar por uso provenientes de la propia Red Hat.

ACTUALIZACIÓN: Se me había olvidado comentar el tema de formación y certificación que también tiene sus novedades. Cómo comentaba por twitter casi me enteré antes de que estaba RHEL 6 en la calle porque me llegó un correo indicando que en breve va a estar obsoleta mi certificación RHCE, la saqué con la versión 4, y que la RHCT, la renové a la versión 5 en el evento de partners de Valencia dónde hacían exámenes gratuitos, se convalida con la nueva certificación RHCSA (Red Hat Certified System Administrator) que será la nueva certificación previa a sacar el RHCE.

Probando la instalación de RHEL 6

Hace un par de días se lanzaba definitivamente la nueva versión de Red Hat Enterprise Linux: RHEL 6. Y aunque ya le había echado un ojo a alguna Release Candidate he sacado un rato para probar la instalación en una máquina virtual de KVM de la edición de servidor de RHEL 6 recien descargada de Red Hat Network. La instalación ha sido muy sencilla y aquí os dejo los pasos y algunos comentarios al respecto.

La instalación arranca con la selección del tipo de acciones que queremos realizar: instalar, instalar en modo texto, recuperar el sistema, arrancar desde el disco local o hacer el test de memoria. Nada nuevo por ahora en el horizonte, seleccionamos la opción de instalar:

A continuación haremos la típica selección de idioma y teclado, en mi caso me gusta mantener el idioma en inglés, sobretodo porque es más fácil rastrear los mensajes de error por internet, y el teclado en castellano:

Seleccionamos nuestra ubicación en Madrid:

Y pasamos a seleccionar el dispositivo de almacenamiento en el que queremos instalar, siendo las opciones básico o especializado, permitiendo esta última opciones muy interesantes para el modo servidor cómo instalar en una cabina de almacenamiento o añadir drivers de nuestro raid hardware:


Continuar leyendo «Probando la instalación de RHEL 6»